5 ms·

Very interesting. How does it work scaling? Possible to have one loadbalancer with multiple servers? With autscaling? Or only works with one server for now?

Sean-Der 6y ago
From the README he has these numbers For one-to-many communication (lectures), the behaviour is linear, and Galène should be able to serve about 400 participants per core Scaling wise what are you trying to do? * You can put different rooms on different servers. They don't have to aware of each other. * If you want to scale out the broadcast case you will probably want to follow the ingest pattern. Have one server forward to n with viewers. * If you want really large conference calls you will need to think about the experience. Residential internet can only accept so many incoming feeds. Do you want to enable/disable them on the fly? Do you want to have 'active speaker' only view etc.. not just a scaling problem but also UX.
- jech 6y ago
  > You can put different rooms on different servers. They don't have to aware of each other. Yes. You could then use a reverse HTTPS proxy to route each client to the right instance of Galène. For very large groups, that need to be split between multiple servers, you'll need to wait until we implement server federation (distributing a group over multiple, geographically distant servers). I know for a fact that Jitsi implements federation, not sure about Ion-SFU.
  - Natfan 6y ago
    How would I actually go about doing this? By default I can see that the process binds to localhost:8443, which is not accessible via other devices. Running the following command doesn't seem to work either: galene -http 0.0.0.0:8443 Using a nginx server as a reverse proxy, I have the following that works for HTTP but not WebSocket: server { server_name galene.domain.com; location / { proxy_pass https://127.0.0.1:8443/; proxy_set_header Host $host; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/natfan.io/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/natfan.io/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } Thoughts? Happy to move this to Github if that's easier too.
    - jech 6y ago
      By default, we bind to ":8443", which is Go's notation for port 8443 on all IP addresses, IPv4 and IPv6. Galène's WebSocket is located at /ws, and I believe that nginx requires that you configure this specially. See https://www.nginx.com/blog/websocket-nginx/ https://www.nginx.com/blog/websocket-nginx/. An alternative to reverse proxying is to use HTTP redirects: you can define a group as {"redirect":"https://otherserver.example.com:8443/group/groupname https://otherserver.example.com:8443/group/groupname"} and Galène will send an HTTP redirect whenever somebody attempts to join this group. I'll be glad to continue this conversation on the mailing list (https://lists.galene.org/postorius/lists/galene.lists.galene.org/ https://lists.galene.org/postorius/lists/galene.lists.galene...).
- amelius 6y ago
  > Have one server forward to n with viewers. Does this mean that the server has to send n identical packets for every packet that would have been sent in a 1:1 situation? I don't know if a different solution exists, but this seems wasteful.
  - jech 6y ago
    Not really. In a p2p scenario with n participants, every participant needs to send (n - 1) copies of the packet. In a centralised scenario, each participant sends just one copy of the packet, and the server duplicates it (n - 1) times. Whether this is wasteful depends on where the server is located. If the server is close to the receivers, it is a net gain. If the server is in the US while all of the participants are in Europe, it's a terrible waste, since all of the packets need to cross the Atlantic. Server federation solves the issue: you put one server in the US, one in Europe, and each packet crosses the Atlantic exactly once.
    - amelius 6y ago
      Shouldn't there be some kind of broadcast mode, where TCP/IP solves the problem of routing (n-1) identical packets in the most efficient way possible? How does this work when e.g. the BBC broadcasts an internet live stream with millions of viewers? Shouldn't a conference call work in essentially the same way?
      - jech 6y ago
        Duplicating a packet in the network is called multicast, and it isn't implemented in the real Internet. Most large-scale broadcasts use technologies such as HTTP Live Streaming (HLS) or MPEG-DASH, which carve a video into 3-second intervals that are then distributed using ordinary HTTP over a CDN. The problem with these technologies is that they have a latency of a few seconds, which means that you cannot have a meaningful conversation over them.

Sean-Der 6y ago

From the README he has these numbers For one-to-many communication (lectures), the behaviour is linear, and Galène should be able to serve about 400 participants per core Scaling wise what are you trying to do? * You can put different rooms on different servers. They don't have to aware of each other. * If you want to scale out the broadcast case you will probably want to follow the ingest pattern. Have one server forward to n with viewers. * If you want really large conference calls you will need to think about the experience. Residential internet can only accept so many incoming feeds. Do you want to enable/disable them on the fly? Do you want to have 'active speaker' only view etc.. not just a scaling problem but also UX.

jech 6y ago
> You can put different rooms on different servers. They don't have to aware of each other. Yes. You could then use a reverse HTTPS proxy to route each client to the right instance of Galène. For very large groups, that need to be split between multiple servers, you'll need to wait until we implement server federation (distributing a group over multiple, geographically distant servers). I know for a fact that Jitsi implements federation, not sure about Ion-SFU.
- Natfan 6y ago
  How would I actually go about doing this? By default I can see that the process binds to localhost:8443, which is not accessible via other devices. Running the following command doesn't seem to work either: galene -http 0.0.0.0:8443 Using a nginx server as a reverse proxy, I have the following that works for HTTP but not WebSocket: server { server_name galene.domain.com; location / { proxy_pass https://127.0.0.1:8443/; proxy_set_header Host $host; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/natfan.io/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/natfan.io/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } Thoughts? Happy to move this to Github if that's easier too.
  - jech 6y ago
    By default, we bind to ":8443", which is Go's notation for port 8443 on all IP addresses, IPv4 and IPv6. Galène's WebSocket is located at /ws, and I believe that nginx requires that you configure this specially. See https://www.nginx.com/blog/websocket-nginx/ https://www.nginx.com/blog/websocket-nginx/. An alternative to reverse proxying is to use HTTP redirects: you can define a group as {"redirect":"https://otherserver.example.com:8443/group/groupname https://otherserver.example.com:8443/group/groupname"} and Galène will send an HTTP redirect whenever somebody attempts to join this group. I'll be glad to continue this conversation on the mailing list (https://lists.galene.org/postorius/lists/galene.lists.galene.org/ https://lists.galene.org/postorius/lists/galene.lists.galene...).
amelius 6y ago
> Have one server forward to n with viewers. Does this mean that the server has to send n identical packets for every packet that would have been sent in a 1:1 situation? I don't know if a different solution exists, but this seems wasteful.
- jech 6y ago
  Not really. In a p2p scenario with n participants, every participant needs to send (n - 1) copies of the packet. In a centralised scenario, each participant sends just one copy of the packet, and the server duplicates it (n - 1) times. Whether this is wasteful depends on where the server is located. If the server is close to the receivers, it is a net gain. If the server is in the US while all of the participants are in Europe, it's a terrible waste, since all of the packets need to cross the Atlantic. Server federation solves the issue: you put one server in the US, one in Europe, and each packet crosses the Atlantic exactly once.
  - amelius 6y ago
    Shouldn't there be some kind of broadcast mode, where TCP/IP solves the problem of routing (n-1) identical packets in the most efficient way possible? How does this work when e.g. the BBC broadcasts an internet live stream with millions of viewers? Shouldn't a conference call work in essentially the same way?
    - jech 6y ago
      Duplicating a packet in the network is called multicast, and it isn't implemented in the real Internet. Most large-scale broadcasts use technologies such as HTTP Live Streaming (HLS) or MPEG-DASH, which carve a video into 3-second intervals that are then distributed using ordinary HTTP over a CDN. The problem with these technologies is that they have a latency of a few seconds, which means that you cannot have a meaningful conversation over them.