search

gisogrimm / ov-server

GNU General Public License v3.0
2 stars 0 forks source link

Run an ov server by yourself #1

Open lebochequirit opened 3 years ago

lebochequirit commented 3 years ago

Hi Giso, I just got another RPi and can't wait to set up an ovbox \o/

Is it at all intended that people/ensembles run their own roomservice servers to distribute server load? If so, could you perhaps drop a few words as to server and connectivity specs it would require into the readme? Would it decently run on a Uberspace shared host (as coturn obviously does), a local (Ubuntu?) machine with port forwarding or would I need a VPS or even bare metal server? Ideally, several servers could federate or set public and be connected by a load balancer in front.

Thanks in advance for your thoughts (and for the project as a whole).

L.B.Q.R.

gisogrimm commented 3 years ago

Hi L.B.Q.R.,

for the time being it is not recommended to set up an own roomservice. In the ideal world everyone would be able to use peer-to-peer mode, which means that the roomservice actually provides only STUN services, and no audio is routed via the room server. But many users are not able to use peer-to-peer mode, either because of a very limited upload bandwidth, or because their network provider does not allow the applied UDP hole punching method (e.g., all tested mobile network providers). In that case the audio is distributed by the room service. In that case it depends mostly on your geographic location (in internet metrics) - the room services I currently provide are all hosted in Frankfurt, Germany. They should be well reachable (low ping times, low jitter) from most places in Europe, but if for example a US based ensemble is rehearsing, they would definitely not want to route their audio to Europe and back - here actually the speed of light is the limiting factor, and playing rhythmic music together is not possible. In that case it would be better to use a local room service. Another issue is the hardware: If the audio is routed through the room server, it should add as little jitter as possible. This means, that an ideal room server is a bare metal server directly connected to the internet backbones. The rooms with three stars in the current room list are something like this. A VPS typically introduces some jitter, because it is sharing its hardware with many other services. If you have a very good internet connection, e.g., fibre optics, actually even a raspberry pi can be an ideal room server, hosting one or more rooms. To improve server reliability in the future I will protect the system in a way that you would need some server key to provide room services. So the current room service interface is going to change on the long run. In that case it could be possible to add automatic spawning of room services depending on the needs. Best, Giso

lebochequirit commented 3 years ago

Hi Giso, seems like the first ever use case for a Raspberry Colocation I've seen so far ;-) Is the jitter issue caused by EMV disturbance or merely performance based? As to the latter, a root server with dedicated CPU cores and RAM like the netcup ones might be worth a try.

Cheers, L.B.Q.R.