tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: websockets questions
Date Thu, 04 Jul 2013 09:17:40 GMT
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?

> 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).
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:
For additional commands, e-mail:

View raw message