websockets - the bell-bottoms of the web?
by bear
Now that more browsers are supporting (or have enabled support) for websockets, I am starting to see more people touting the benefit for them because, like this ycombinator comment suggests:
“Do you anticipate that the use of WebSockets will improve performance? If so, can you estimate to what degree?”
It will since you don’t need to open and close connections all the time. I can’t estimate at what degree, but I think the communication will be much faster since currently some time is used to re-create connections.
But I see that as a false benefit. The original model for HTTP was to use the “classic” open, request, retrieve, close sequence; now all modern web servers support a single (or a small number of) connect per web session to allow for more efficient data throughput. What is false is that websockets will now run into the same problems that web servers and other client-to-server applications have been running into: NAT traversal and cross-domain issues.
Remember that websockets are just that - the browser allowing you to open a persistent socket to another tcp/ip endpoint. It doesn’t provide any of the services that are now required on the back-end. The javascript coder will need to start layering on top of their code routines that implement STUN, TURN, ICE and/or SIP.
This leads me to think that current server implementations that already support these technologies could/should be modified to support websockets - I’m looking at you XMPP :)