Hi Andre,
On Thu, Jul 4, 2013 at 12:17 PM, André Warnier <a...@ice-sa.com> wrote: > I'll just add a little bit of info (and guesses) below. > > Jess Holle wrote: > >> Unfortunately I don't have any information -- just related questions. >> >> 1. For someone currently using Apache httpd+mod_jk to load balance >> requests, what does one do about load balancing WebSockets requests >> between Tomcat instances? >> * As Andre alluded to, the only mention of websocket handling in >> Apache httpd really appears to be in its infancy. >> * It would kind of seem like mod_jk should be expanded to deal >> with WebSockets... >> * In any case, there would still be questions as to how this >> interacts with mod_jk within the same web app. >> 2. Any other browser considerations beyond requiring IE 10+? Are >> relatively recent Chrome, Firefox, and Safari WebSocket ready? >> > > http://en.wikipedia.org/wiki/**WebSocket#Browser_support<http://en.wikipedia.org/wiki/WebSocket#Browser_support> > > 3. How well do WebSockets play with existing network infrastructure? >> * IP load balancers >> * HTTP(S) forward and reverse proxy servers >> * Timeouts (idle, response, etc...) >> >> In general, if WebSockets don't just "get along with" existing >> network infrastructure in this regard but rather place requirements >> and restrictions upon it to function properly, then it will be a >> while before those of us who need to deploy a single solution into >> many disparate environments can leverage WebSockets in any >> substantive fashion. >> >> > The way I understand websockets is : > > - it starts with a "normal" HTTP request from client to server. In that > HTTP request, there is a header requesting an "upgrade" of the > (theoretically one-off fire-and-forget) HTTP connection, to a websocket > connection > - if the server supports it, it does "set aside" the existing TCP > connection (client-server), to be from now managed as a permanent > client-server connection, and it lets the client know about this. > > From then on, the client and server have a permanent TCP connection, on > which they can exchange "websocket messages" back and forth, until they > agree that they are done, and drop the connection. > > To me that means that at some point, there must be on the server side a > process or thread which is dedicated to this websocket client for as long > as it takes, and this process/thread in the meantime is no longer available > to process other HTTP requests. > (That's because the basic idea is that the "websocket application" on the > server side can keep sending messages asynchronously to the client - and > vice-versa - so I don't see how this can work with different > threads/processes on the server; but I'm not that smart, so it may be that > the implementation is smarter). > AFAIK when using BIO socket this is the case. But when using NIO (and AJP?!) Tomcat uses different threads per data frame. > For that same reason, it would seem that the very concept of > "load-balancing" must be suspended once the websocket connection is > established. > > If there is a front-end between the client and the server (which actually > runs the application that "converses" with the client over the websocket), > then at the level of this front-end that connection must be like some kind > of "tunnel", which merely passes packets back and forth between the client > and the back-end websocket-enabled application. > That's a bit what the Apache httpd mod_proxy_(websocket) (not sure of the > name anymore) sounds like. > I have seen Rainer involved in that mod_proxy_(websocket) discussion, and > since Rainer is one of the mod_jk developers, I would think that there must > be some link with mod_jk. Which would make some sense, because if a browser > connects to Tomcat through Apache httpd and mod_jk, and then requests an > upgrade to websockets, mod_jk must be able to at least know that what is > going to pass further on that connection is not HTTP-like anymore. > But that's about all I've been able to sniff and guess so far. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org > >
