4 ms·

I get that the overhead of an individual message over an individual connection is lower, but for that efficiency you give up layer 7 routing capability, make lo

by markbnj 10y ago

I get that the overhead of an individual message over an individual connection is lower, but for that efficiency you give up layer 7 routing capability, make load balancing difficult, have more long-lived connections to your servers. Does HN generally feel like these are worthwhile tradeoffs?

sametmax 10y ago
There is more to this trade off, because push enables many neat things: - you can halves the number of DB requests by 2 because refreshing is done by message passing half of the time instead of making a new requets trigerring DB calls. - cache invalidation is pro-active, and linked to events instead of just time. - you can have much more live stuff: settings, routing, configuration in general. You only need to load it once from your store, after that, any update is propagated. A CMS becomes cheap. - making clients talk to each others is easy. - websocket don't have CORS issues. You client code can query your live site, or a local backend, and synchronize both. - you can use the same canal of communication between your user clients and internal (micro-services) clients. The architecture becomes simpler. - if you have a heavy authentication process and complex sessions data, they can now be store with the persistent connection instead of being queried for every request. Of course, not all that is enabled by default. You need to use some framework such as crossbar.io or meteorjs to get those benefits for free. Yet, it's very sweet.
- deleted 10y ago
  [deleted]
mark242 10y ago
Absolutely yes. Connections are very very cheap to maintain, and very very expensive to build up and break down. Even in environments with load balancers, stateful firewalls, etc., it is much easier to keep a socket open than it is to create a new one. If you're doing any kind of realtime data, websockets are the way to go. It is way, way easier to do stream processing and deal with backpressure than it is to have a gigantic number of clients doing http polling. When Cloudflare mentions that websockets haven't had a gigantic uptake, I don't wonder if it's because Amazon's ELB doesn't support them and people don't want to roll their own haproxy solution.
- lostcolony 10y ago
  ELBs support websockets fine with TCP/Secure TCP listeners. What they -don't- support at that layer is sticky sessions, ip hashing, or similar; when a connection drops, you could reconnect to -any- instance behind the ELB. You have to engineer for that. They also don't support Socket.IO if you have more than one instance behind the ELB (as, presumably, you do). This is because Socket.IO doesn't just open a websocket connection, and on failure fall back to something else; instead, it makes a REST call to the backend to see what connections it supports, then makes the websocket call. Both of these calls have to hit the same Socket.IO instance, because they're tied together with a session identifier. If they hit separate ones, then Socket.IO rejects the websocket, because that instance has never seen that session identifier before. But this is particular to Socket.IO's implementation, and not websockets themselves.
- takeda 10y ago
  How is that better than HTTP with keep-alive. With that approach you also have long standing connection, but when connection is broken it'll be reestablished seamlessly.
CyberDildonics 10y ago
Maybe you should ask the people using your web site if they care.

by markbnj 10y ago

sametmax 10y ago

There is more to this trade off, because push enables many neat things: - you can halves the number of DB requests by 2 because refreshing is done by message passing half of the time instead of making a new requets trigerring DB calls. - cache invalidation is pro-active, and linked to events instead of just time. - you can have much more live stuff: settings, routing, configuration in general. You only need to load it once from your store, after that, any update is propagated. A CMS becomes cheap. - making clients talk to each others is easy. - websocket don't have CORS issues. You client code can query your live site, or a local backend, and synchronize both. - you can use the same canal of communication between your user clients and internal (micro-services) clients. The architecture becomes simpler. - if you have a heavy authentication process and complex sessions data, they can now be store with the persistent connection instead of being queried for every request. Of course, not all that is enabled by default. You need to use some framework such as crossbar.io or meteorjs to get those benefits for free. Yet, it's very sweet.

deleted 10y ago
[deleted]

mark242 10y ago

Absolutely yes. Connections are very very cheap to maintain, and very very expensive to build up and break down. Even in environments with load balancers, stateful firewalls, etc., it is much easier to keep a socket open than it is to create a new one. If you're doing any kind of realtime data, websockets are the way to go. It is way, way easier to do stream processing and deal with backpressure than it is to have a gigantic number of clients doing http polling. When Cloudflare mentions that websockets haven't had a gigantic uptake, I don't wonder if it's because Amazon's ELB doesn't support them and people don't want to roll their own haproxy solution.

lostcolony 10y ago
ELBs support websockets fine with TCP/Secure TCP listeners. What they -don't- support at that layer is sticky sessions, ip hashing, or similar; when a connection drops, you could reconnect to -any- instance behind the ELB. You have to engineer for that. They also don't support Socket.IO if you have more than one instance behind the ELB (as, presumably, you do). This is because Socket.IO doesn't just open a websocket connection, and on failure fall back to something else; instead, it makes a REST call to the backend to see what connections it supports, then makes the websocket call. Both of these calls have to hit the same Socket.IO instance, because they're tied together with a session identifier. If they hit separate ones, then Socket.IO rejects the websocket, because that instance has never seen that session identifier before. But this is particular to Socket.IO's implementation, and not websockets themselves.
takeda 10y ago
How is that better than HTTP with keep-alive. With that approach you also have long standing connection, but when connection is broken it'll be reestablished seamlessly.

CyberDildonics 10y ago

Maybe you should ask the people using your web site if they care.