AJAX multipart streaming rather than Websocket

[Matt]

Hi,

I'm dealing with an application scenario where two way communication as provided by websocket is not really needed.

The scenario is a situation where the client should send a request to the server (AJAX), and expect a streaming of the result payload from the server. The server cannot send the full result right away in this application scenario, but rather it sends over parts of the result as they gradually become available to it. That is the scenario, and I think websockets is somewhat of an overhead here. 

What I'd rather like to have, is that the server will send its response in chunks (as permitted by the http protocol itself), and the client would process each chunk as it arrives, using just plain chunked http.

What transport string should I use for io.set('transports'... in socket.io's configuration, in order to accomplish that, if that is possible?

The list of protocols employed by websocket that I found does not correlate one-to-one with transport name examples wherever they appear.

I seem to think that websocket incurs more overhead as it constantly polls and keeps-alive the connection compared to a chunked http response. Also I don't need long polling where the polling goes on indefinitely, but rather only stream a single chunked reply per a specific client request (whereas the rest of my client-server interaction will be old school regular http requests and responses). Is that possible with socket.io? or should I just implement it myself?

Thanks in advance for your answer about which socket.io transport name corresponds to that behavior if any, and any comment about the overhead of websocket over a chunked response.

Thanks!

Matan

P.S. a pointer to the source code section where this can be inferred would also be fine; I understand the api is not fully documented outside the code.

[Erich Buri]

Hi,

I don't see, how websocket could not be helpful to you in this situation. Afaik, you can think of websocket as regular sockets over http.  You " ... seem to think that websocket incurs more overhead as it constantly polls and keeps-alive the connection compared to a chunked http response." - but the polling is rather in case of a fallback-transport. And keeping alive the connection is not an issue, as long as you send data anyway (no difference here compared to 'chunked').

Now, given the fact, that you want to issue an ajax-call, I have to assume that you are going to process the response in JavaScript - either directly or indirectly letting for example JQuery handle the response. Then it's tricky to process a response in parts (where you could profit from chunked), compared to processing it onCompletion.

With socket.io, sending and receiving messages bidirectionally, is easy and implementable in a easy-to-read/understand way. So, you could use socket.io and send messages with more information on a subject as the server receives that information himself and register handler on these messages in the client/JS/Browser

--
You received this message because you are subscribed to the Google Groups "Socket.IO" group.
To unsubscribe from this group and stop receiving emails from it, send an email to socket_io+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matan Safriel]

Thanks Erich,

However a chunked message is the most suitable in my scenario, as I don't need to keep the websocket connection beyond the point of satisfying that special single request that needs to stream to the client. That request occurs roughly once in the lifetime of a user. 

With socket.io, I couldn't insofar locate documentation for how to close the connection, and I don't think it's application-level polling is as lean as an http chunked response, are you sure about that? 

So my initial question about how to utilize the chunked response 'transport' in websocket still holds..... I hope someone can pick it up

Matan

--
You received this message because you are subscribed to a topic in the Google Groups "Socket.IO" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/socket_io/-Bh57euk7ww/unsubscribe.
To unsubscribe from this group and all its topics, send an email to socket_io+...@googlegroups.com.

[Elvio Rogelio Toccalino]

I know this is not what you want to hear, but my suggestion would be to io.connect() from the client when the user requests the data, and eventually then socket.disconnect() from the server when all data has been passed.

2013/7/19 Matan Safriel <ma...@cloudaloe.org>

--

You received this message because you are subscribed to the Google Groups "Socket.IO" group.

To unsubscribe from this group and stop receiving emails from it, send an email to socket_io+...@googlegroups.com.

[Matan Safriel]

Thanks. I didn't realize socket.disconnect also exists. However why would you recommend that over chunked http? Does anyone know what is the socket.io transport name for chunked http responses?

[Dmitry]

Well, why you afraid of websockets? If you need chunked http, you don't need socket.io. Just fire regular XHR and google how to handle multipart data.

[Matan Safriel]

I ultimately found the transport name in socket.io for this.
It's good to use a library that can switch between protocols if things change, that's all Dmitry (e.g. if old browsers buffer the http chunks before handing over to the javascript code, if that's not just a myth). Reading the websocket rfc, it seems it in itself it has little overhead, although the socket.io default seems to websocket ping too often to my taste (every few seconds or a bit more), I wonder why (?!).

I think this pretty much 'answers my own question', combined with the comment about using .disconnect(). And by the way, Android's native browser doesn't support websocket, so here's one small answer to all 'automatically use the latest buzz' folks earlier on this thread ;)

[Dmitry]

I think the message of this topic was that if you use higher-level abstration such as socket.io, just give it some freedom to choose the transport that works on the current client's platform. The default transport should be websocket, since modern browsers support it in the first place, it's fast and it also avoids some issues like internal browser limit on the number of open connections to the same domain which prevents your app from working if you have multiple tabs opened, for example. If, for some reason, they don't work, socket.io will choose another protocol. For some reason you insisted that you wanted chunked xhr always, that's why I doubted the reasoning of using socket.io in your case.

[Matan Safriel]

Thanks!