4 ms·

There could be a huge benefit for someone who wants to send websocket frames to say, 100,000 clients. You can't do that with a single server; you'd run out of p

There could be a huge benefit for someone who wants to send websocket frames to say, 100,000 clients. You can't do that with a single server; you'd run out of ports (reuse aside). You'd also have a lot of load on one server. At the cost of a little latency to the true event, you can increase performance and scalability dramatically by sending the event to just a few intermediaries that then broadcast the event to a subset of clients.

tobz 12y ago
I don't think this feature functions as a fanout mechanism.
jkarneges 12y ago
FWIW, we provide this at Fanout.io. Our service is able to act as a passthrough proxy for WebSockets, not as a DDoS protection service like CloudFlare, but to handle large one->many deliveries as you describe. You can publish a message once, and it can be injected downstream into any number of open connections.
toast0 12y ago
> There could be a huge benefit for someone who wants to send websocket frames to say, 100,000 clients. You can't do that with a single server; you'd run out of ports (reuse aside). You would not run out of ports, as long as your clients have some IP diversity. Connections must be unique with the key being the 5-tuple: {Protocol, SourceAddr, SourcePort, DestAddr, DestPort}. If you have one server listening on one port, each client address can theoretically have 65535 connections (in practice, you're unlikely to find a client that will allocate their ports well enough to use all the ports). Assuming your websockets are mostly idle, handling 100k connections for one server doesn't really need that big of a server either, see WhatsApp blog post about 2.2 million connections on one server in 2012: http://blog.whatsapp.com/196/1-million-is-so-2011 http://blog.whatsapp.com/196/1-million-is-so-2011 Caveats: dual 6-core westmere cpu, 100 G ram, normal connection count is lower per server; connections are mostly idle; some tuning required. See also 2.8 M connections documented on page 16 of Erlang Factory presentation: http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf http://www.erlang-factory.com/upload/presentations/558/efsf2...

tobz 12y ago

I don't think this feature functions as a fanout mechanism.

jkarneges 12y ago

FWIW, we provide this at Fanout.io. Our service is able to act as a passthrough proxy for WebSockets, not as a DDoS protection service like CloudFlare, but to handle large one->many deliveries as you describe. You can publish a message once, and it can be injected downstream into any number of open connections.

toast0 12y ago

> There could be a huge benefit for someone who wants to send websocket frames to say, 100,000 clients. You can't do that with a single server; you'd run out of ports (reuse aside). You would not run out of ports, as long as your clients have some IP diversity. Connections must be unique with the key being the 5-tuple: {Protocol, SourceAddr, SourcePort, DestAddr, DestPort}. If you have one server listening on one port, each client address can theoretically have 65535 connections (in practice, you're unlikely to find a client that will allocate their ports well enough to use all the ports). Assuming your websockets are mostly idle, handling 100k connections for one server doesn't really need that big of a server either, see WhatsApp blog post about 2.2 million connections on one server in 2012: http://blog.whatsapp.com/196/1-million-is-so-2011 http://blog.whatsapp.com/196/1-million-is-so-2011 Caveats: dual 6-core westmere cpu, 100 G ram, normal connection count is lower per server; connections are mostly idle; some tuning required. See also 2.8 M connections documented on page 16 of Erlang Factory presentation: http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf http://www.erlang-factory.com/upload/presentations/558/efsf2...