
 WebSockets Follow-Up - wglb
http://www.tbray.org/ongoing/When/201x/2012/03/28/WebSockets
======
fmstephe
Not related to the question of spec and standards processes but it is
interesting to ask the question of whether web sockets are architecturally
sound.

It certainly seems that for games like BrowserQuest they are more or less
necessary. But they do have a crucial property that a long lived connection
lives on one server - for a long time.

I have a location service where users are notified about other nearby users.
However, whenever I look at scaling the server responsible for this across
multiple threads or machines, I am always concerned by this massive fan-in
effect. Where multiple servers or threads will have to send nearby
notifications back to a single process to have that information sent down a
specific connection. This seems like it may become a bottleneck.

I don't know how this approach will turn out. I have thought about using
Server-Sent Events instead, but that is newer than websockets and is getting
less attention, so I don't feel secure that the support will be there.

I think that forgoing long lived connections is a very useful tool for
simplifying and scaling up web services. If we use websockets unwisely we
could end up painting ourselves into a corner.

Anyone has any thoughts on this? Some experience would be great to hear about.

NB: I put this same question to the blog itself.

~~~
daeken
WebSockets could easily end up doing terrible things for scalability of a
service. However, so can misusing Comet, improper database structures, etc. At
the end of the day, developers need to make an informed decision about what
technologies to use and not use; in many cases, that'll mean foregoing
WebSockets in favor of other solutions, but sometimes they're simply the best
tool for the job.

~~~
fmstephe
This is definitely true. My question is more along the lines of "what
scalability lessons will we have to learn now that the World of Warcraft guys
already know" (more or less). It'll be a different world from the firestorm of
short lived (often stateless) connections we worry about now.

------
angersock
Anyone here involved in the decision not to allow raw TCP/UDP/etc.? That
would've really let us do some fun things. :)

(I waned to write a self-hosting webpage, but WS doesn't get you there--the
real-time communication stuff might, though.)

~~~
axiak
Websockets is designed to work over all of the existing HTTP proxy systems
that currently exist. Could you imagine a system that's backwards incompatible
with the world wide web? In many institutions (schools, workplaces), internet
access is filtered through a proxy server.

~~~
angersock
Oh, no, I absolutely appreciate that. I'm just saddened that lower-level stuff
isn't exposed. Even just TCP access and listening would be great to have--
especially as raw TCP connections are pretty much the standard transport
exposed for HTTP (please correct me if I'm wrong in this assumption).

I'm not suggesting that it would be foolproof for consumer applications or
what have you--but being able to write something like netcat in javascript for
my browser would be pretty cool.

------
batista
_> I don’t know, myself; I haven’t worked on any apps in recent years that
needed this sort of persistent-binary-connection architecture. I have noted a
buzz of conversation in the last few days around BrowserQuest, a Mozilla.org
offering based on lots of HTML5 gooey goodness notably including WebSockets.
So maybe they really are a big deal._

WTF? It's like Tim Bray took a long vacation from relevance when he went to
work at Google, and never came back.

