4 ms·

You've also got to wonder about the extra overhead of running deflate on everything that you send with the XHR version of the code, and why there couldn't be so

by anonjon 17y ago

You've also got to wonder about the extra overhead of running deflate on everything that you send with the XHR version of the code, and why there couldn't be some sort of compression applied to the packets sent through WebSocket if it is a really big deal. Also, obviously, the smaller your send/receive, the better the improvement that your websocket code would see over XHR. I can imagine an application of websockets where you open multiple sockets and send a number of constantly updating data-streams from the server. A lot of articles seem to imply that websockets is simply XHR 2.0, and I'm sure it will be used as such for a while. But it seems to me that there are certain things that you can do with this that simply cannot be done efficiently with other technology. (Imagine being able to smoothly track a mouse cursor or watch another person edit a document in real time, how would you do that with XHR?).

axod 17y ago
>> "or watch another person edit a document in real time, how would you do that with XHR?" Works fine on Etherpad. Having said that, I agree, the lag with WebSocket is likely to be a less. Hopefully WebSocket will get the ability to do deflate/gzip soon as well. That would make it a very clear winner.
- anonjon 17y ago
  Works fine but doesn't work in the same way. On etherpad there is a lag and updates get chunked. With websockets you could do it by the keystroke with little to no overhead.
  - mbreese 17y ago
    Really? You're still sending packets, so instead of sending roughly 1k of data, you're going to send a packet with roughly 1 byte of information on each keystroke? What I'd really like to see is the breakdown of the number of packets sent as opposed to the number of bytes. I doubt the difference would be as significant.
    - Retric 17y ago
      At a full 60WPM ~= 60 * 6 keystroke per second *1kb/keystroke~= 360kb / second. However, clunking at 1/20th of a second is probably fine.

by anonjon 17y ago

axod 17y ago

>> "or watch another person edit a document in real time, how would you do that with XHR?" Works fine on Etherpad. Having said that, I agree, the lag with WebSocket is likely to be a less. Hopefully WebSocket will get the ability to do deflate/gzip soon as well. That would make it a very clear winner.

anonjon 17y ago
Works fine but doesn't work in the same way. On etherpad there is a lag and updates get chunked. With websockets you could do it by the keystroke with little to no overhead.
- mbreese 17y ago
  Really? You're still sending packets, so instead of sending roughly 1k of data, you're going to send a packet with roughly 1 byte of information on each keystroke? What I'd really like to see is the breakdown of the number of packets sent as opposed to the number of bytes. I doubt the difference would be as significant.
  - Retric 17y ago
    At a full 60WPM ~= 60 * 6 keystroke per second *1kb/keystroke~= 360kb / second. However, clunking at 1/20th of a second is probably fine.