AdrianRossouw
commented
8 years ago No, it's supposed to be a long running session with many channels laid over, and messages sent across those channels.
The websocket especially seems to drop more often than not, and we're still trying to work out why. This seems to get close to it :
https://github.com/maxogden/websocket-stream/issues/69
Basically, the basic websocket api in the browser has no heartbeat functionality that is exposed in any meaningful way in the browser, and stuff like socket.io has to implement their own on top of it.
We were trying to debug what needed to be done, and if possible where it makes sense to add such a heartbeat. There's also some real weirdness that happens when you send messages over websocket-stream to connections that were closed, because something along the way does not properly unpipe.
I didn't know the SPDY implementation had similar issues, but I think that isn't going to be developed much further. The next step is to swap out the jschan-spdy implementation with one that uses this, and supports https/2 : https://github.com/indutny/spdy-transport
Are we supposed to create a new instance of SPDY and websocket client Session each time we have a graft message to send? My SPDY and Websocket graft client sessions to not seem to stay open for long periods of time, when attached to a graft object used by a long-running server.