What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 133 Stack Exchange communities.

I was examining the Network tab in a chat room, and noticed an interesting phenomenon. There was a WebSockets connection, but it was only used for receiving data. When I entered a message, it send an 'old-fashioned' XHR to send the message. This made me wonder why.

Note: by 'send', I mean, 'client to server'.

So, my question is this:

Does the chat system have WebSocket support for sending messages?

  1. Yes, but it's not being used.
  2. Not yet, but it's on the way.
  3. No, and it maybe never will.
share|improve this question
6  
4. ?? 5. Profit! –  Robert Harvey Nov 20 '12 at 21:13
3  
@RobertHarvey +1 for misinterpreting a multiple-choice question and successfully applying a meme. Well done! –  Kendall Frey Nov 20 '12 at 21:18

1 Answer 1

up vote 8 down vote accepted

4. No, and who knows what the future brings.

As originally created, chat used only XHRs, for both directions. The websockets standard was still a mess back then, so it wasn't even an option. When that situation stabilized, we added websockets as a third way to receive chat events (next to AJAX polling and to receiving them from other browser tabs). It's completely optional, and the browser will gladly fall back to polling in a heartbeat if something is wrong with the websockets connection (and in browsers that don't support websockets, it's fine with only polling to begin with).

Switching the server -> client direction to websockets significantly reduces the number of requests. In the client -> server direction, i.e. sending messages, this reduction would have far less of an impact; there's obviously a lot more polling going on than speaking. It would however be a pretty large amount of work, probably larger than making the other direction work.

The invasiveness of the change into the chat toolchain would be much bigger in this case, since this direction of communication includes all kinds of rendering, storing, updating, etc. logic, where the opposite direction is much simpler – grab a bunch of event objects and send them to the client. Okay, I may be oversimplifying just a tiny bit.

A smaller issue that's coming to me (but I haven't fully thought this through) is that the way chat currently works requires a request-response model for sending messages (where the server acknowledges that it has received the message, what id it has assigned it, etc.). This isn't a major problem to do over websockets, but it's of course more work than just using HTTP, which is made for this model in the first place.

To sum up, I wouldn't expect this to happen anytime soon – there's very little to be gained by switching to websockets for the second direction, but a lot of work required. Who knows what'll be going on two years from now, but for now, I wouldn't hold my breath :)

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .