You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Warnier <aw...@ice-sa.com> on 2013/07/03 18:39:05 UTC
websockets questions
Hi.
I am looking for general and not so general info about websockets.
I have read the Wikipedia article, RFC 6455, the websocket API doc on MSDN, and pretty
much all that I have been able to find on the WWW.
But I am still not sure if I have a full picture.
This is the context : we are currently developing an application in which a client
(initially, a user with a browser) enters a search expression
and submits it to the server, for the server application to execute against a number of
"information providers" (say Google Scholar, Pubmed and Amazon).
The application on the server then, connects in parallel to these information providers,
submits the search to each, and starts collecting results (list of articles or books
e.g.). These results "trickle in" from the various sources, at different rates.
The client is impatient, so it would be of benefit to start showing results in the browser
as soon as some are available (on the server), and keep updating his display after that
with whatever arrives from each source, more or less as it arrives.
Typically, such an "update" from the server would be from 20 to 50 "references" (title,
authors, etc.), so basically text, probably sent to the browser in JSON format.
One "classic" way for us to implement this, would be by doing some kind of regular polling
from the browser side, to ask if there is any update available.
This is technically easy via AJAX techniques, but it requires quite a bit of machinery on
the server side (sessions, long-running processes to reconnect to etc.), and is not very
efficient.
We were thus thinking that this might be a good case for implementation through a
websockets connection, even though the needs are not as "real-time" as a game or a
chat-like application for instance. And of course for our team of young developers, it
would be rather attractive to be using some real cutting-edge technology..
However, from all my current perusing, it does seem to me that websockets is still not
really "production-ready" (I am not talking about the Tomcat implementation per se, but
more generally). For example, I could find a discussion thread from back in March this
year (http://www.gossamer-threads.com/lists/apache/dev/423880), in which it seems that an
Apache httpd proxy module for websockets is just in its infancy at the moment.
There is also the fact that native websockets capability in IE is only available since
IE-10, and that solutions which allow this to work in lower IE versions are a bit "iffy"
(relying on a diversion through Adobe's FlashPlayer e.g.).
(Most of our customers are largish corporations, which are not going to update their
browsers, nor open special ports in their firewalls, just to please us).
So, in short - so to speak - does anyone have comments to contribute about this ?
Thanks
André
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: websockets questions
Posted by Martin Grigorov <mg...@apache.org>.
Hi Andre,
On Thu, Jul 4, 2013 at 12:17 PM, André Warnier <aw...@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<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: websockets questions
Posted by Rossen Stoyanchev <rs...@gopivotal.com>.
Andre, if you happen to use the Spring Framework already, we have a
milestone release (version 4.0 M1) that provides fallback options based on
the SockJS protocol. The next milestone 2 due in a week will provide higher
level (sub-protocol) support for messaging patterns such as pub-sub and
point-to-point.
Rossen
Re: websockets questions
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Fri, Jul 5, 2013 at 3:40 AM, André Warnier <aw...@ice-sa.com> wrote:
> We're still one level remote of thinking of any implementation, and trying
> to understand
> 1) how exactly websockets works
>
Most websocket implementations (RI/glassfish, atmosphere, tomcat, etc...)
are open source, so diving in the code is definitely an 'option' for
understanding how websockets work.
> 2) if that general "technology" is, today, sufficently mature and stable
> for us to develop an application based on it, or we should wait another 6
> months, a year,..
>
honestly, I think it is sufficiently mature, since websockets are becoming
the trend (incorporated in RI/glassfish/JavaEE7, I've seen recent tomcat
7.0.35+ releases that had websocket changes, no need to mention how 'alive'
atmosphere is...smile).
i think it is more a question of feasibility for you and your team to join
in on the trend/fun...
> But we are a small outfit, and the fact that Google may be using it (with
> a backup team of 50 developers to shore up their implementation) does not
> really help us.
>
funny. google's backup team of 50 developers versus how many open source
developers using/coding atmosphere, tomcat, glassfish-websockets
(grizzly?). :)
>
> The reason why I put this question on the Tomcat users list is because it
> is a list I'm subscribed to, because I know that it is a good-quality list
> with little "noise", because I know that Mark and Rainer are - to various
> degrees probably - involved in Tomcat support for websockets.
+1
> for the moment the general information available on websockets seems
> otherwise a bit "scarce".
>
>
true, but websocket open source code is plentiful and available. :)
> This being said, the information already gathered here on this list tends
> to vindicate my posting on it. It has already cleared up a number of points
> for us, and added a couple of questions which we did not think of asking.
> Thanks.
>
>
IMO (or maybe based on fact/history), not much chatter about websockets on
tomcat user list, but if you find your way to atmosphere google groups mail
list, there will be plenty of chatter over there. I will not encourage you
to venture over to atmosphere google groups and ask questions such as this,
since I'm sure the desire/goal over there is to post topics related to
'using atmosphere and any questions/issues while attempting to use
atmosphere and atmosphere's trunk (latest version(s))'. i'm definitely
someone that love to use latest versions of open source software.
sometime ago, when I migrated from glassfish to tomcat/tomee (so I could do
websockets, um, more effortlessly in my web app), I came across the fact
that Jeanfrancois (Atmosphere developer/committer) had something to do with
the websocket implementation in glassfish/RI, i think it is called grizzly,
but I could be wrong. I'm not as versed with glassfish/RI as I used to
be..when I was a glassfish 'user'. :)
FYI, at the moment, i'm not writing low level websocket client/server code;
i'm using PrimeFaces Push only/entirely, which is PrimeFaces + atmosphere.
:)
definitely not trying to encourage you to use a certain framework; one
thing I like about Tomcat list is that there is a wide range of topics that
I can listen to and/or chime-in on, when interested and when feasible. :)
I love this user community (mail list).
Re: websockets questions
Posted by André Warnier <aw...@ice-sa.com>.
Howard W. Smith, Jr. wrote:
> On Thu, Jul 4, 2013 at 1:43 PM, Pierre Goupil <go...@gmail.com>wrote:
>
>> Regarding browser support, a framework like Atmosphere handles pretty well
>> having WebSockets when they are available and falling-back to another Comet
>> implementation (such as long-polling or http-streaming) when they are not.
>>
>
> agreed, but I think the goal/desire, here, is to not use Atmosphere.
>
Correct. In truth, we're not sure that we want to use Tomcat either.
We're still one level remote of thinking of any implementation, and trying to understand
1) how exactly websockets works
2) if that general "technology" is, today, sufficently mature and stable for us to develop
an application based on it, or we should wait another 6 months, a year,..
We know that there are a series of "web application frameworks" which support websockets.
Unfortunately, these are not frameworks which we are using right now, and we don't really
want to change our tools in the middle of the river.
We also know that there are a number of organisations which already use it in production.
But we are a small outfit, and the fact that Google may be using it (with a backup team of
50 developers to shore up their implementation) does not really help us.
The reason why I put this question on the Tomcat users list is because it is a list I'm
subscribed to, because I know that it is a good-quality list with little "noise", because
I know that Mark and Rainer are - to various degrees probably - involved in Tomcat support
for websockets. So I figured that there was some solid knowledge of the protocol available
here. I am also on the Apache httpd list, and I've done some searches on the WWW in
general, and for the moment the general information available on websockets seems
otherwise a bit "scarce".
This being said, the information already gathered here on this list tends to vindicate my
posting on it. It has already cleared up a number of points for us, and added a couple of
questions which we did not think of asking. Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: websockets questions
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Thu, Jul 4, 2013 at 1:43 PM, Pierre Goupil <go...@gmail.com>wrote:
> Regarding browser support, a framework like Atmosphere handles pretty well
> having WebSockets when they are available and falling-back to another Comet
> implementation (such as long-polling or http-streaming) when they are not.
>
agreed, but I think the goal/desire, here, is to not use Atmosphere.
Re: websockets questions
Posted by Pierre Goupil <go...@gmail.com>.
Regarding browser support, a framework like Atmosphere handles pretty well
having WebSockets when they are available and falling-back to another Comet
implementation (such as long-polling or http-streaming) when they are not.
Le 4 juil. 2013 17:12, "Mark Thomas" <ma...@apache.org> a écrit :
> On 04/07/2013 15:52, André Warnier wrote:
> > Mark Thomas wrote:
> >> On 04/07/2013 10:17, André Warnier wrote:
> >>> 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.
> >>
> >> The connection has to be kept open but you can use non-blocking IO to
> >> only allocate a thread to process data when there is data to process.
> >>
> >> The exact behaviour varies between Tomcat 7 and Tomcat 8.
> >>
> >> BIO 7 & 8 - 1 thread per connections, blocking IO, doesn't scale
> >>
> >> NIO / APR 7 - 1 thread per currently processed frame, non-blocking
> >> between frames, scales better
> >>
> >> NIO / APR 8 - threads only allocated where there is data to process,
> >> scales best
> >
> > "data to process" meaning an entire websocket "message" I suppose ?
>
> No. Data means bytes on the wire. It doesn't matter if those bytes are
> an entire message (multiple frames), a single frame, part of a frame of
> even the last few bytes of one frame and the first few bytes of the
> next. Tomcat will read what is available, process it as far as possible
> given that data it has to hand (for example if the application indicates
> it will except it, partial data can be passed to the application if it
> is available) and then release the thread and wait for the next set of
> bytes to turn up.
>
> > Another question while we're at it :
> > As I understand from the specs/docs, there are 2 kinds of messages :
> > text or "blob".
> > And I found that there are 2 ways of reading that data, corresponding to
> > these 2 types of messages.
> > However, I do not find anywhere a function or method or call which would
> > allow for example the server-side application to find out in advance if
> > the data currently available for reading is one or the other type. Did
> > I miss that somewhere, or do I misunderstand the specs/docs ?
>
> Actually, there are three types exposed to applications: Text, Binary,
> Pong.
> The application only finds out what type the message is when the
> container calls the appropriate message handler. Note if an application
> doesn't have a handler for a particular message type then the message is
> ignored.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: websockets questions
Posted by Mark Thomas <ma...@apache.org>.
On 04/07/2013 15:52, André Warnier wrote:
> Mark Thomas wrote:
>> On 04/07/2013 10:17, André Warnier wrote:
>>> 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.
>>
>> The connection has to be kept open but you can use non-blocking IO to
>> only allocate a thread to process data when there is data to process.
>>
>> The exact behaviour varies between Tomcat 7 and Tomcat 8.
>>
>> BIO 7 & 8 - 1 thread per connections, blocking IO, doesn't scale
>>
>> NIO / APR 7 - 1 thread per currently processed frame, non-blocking
>> between frames, scales better
>>
>> NIO / APR 8 - threads only allocated where there is data to process,
>> scales best
>
> "data to process" meaning an entire websocket "message" I suppose ?
No. Data means bytes on the wire. It doesn't matter if those bytes are
an entire message (multiple frames), a single frame, part of a frame of
even the last few bytes of one frame and the first few bytes of the
next. Tomcat will read what is available, process it as far as possible
given that data it has to hand (for example if the application indicates
it will except it, partial data can be passed to the application if it
is available) and then release the thread and wait for the next set of
bytes to turn up.
> Another question while we're at it :
> As I understand from the specs/docs, there are 2 kinds of messages :
> text or "blob".
> And I found that there are 2 ways of reading that data, corresponding to
> these 2 types of messages.
> However, I do not find anywhere a function or method or call which would
> allow for example the server-side application to find out in advance if
> the data currently available for reading is one or the other type. Did
> I miss that somewhere, or do I misunderstand the specs/docs ?
Actually, there are three types exposed to applications: Text, Binary, Pong.
The application only finds out what type the message is when the
container calls the appropriate message handler. Note if an application
doesn't have a handler for a particular message type then the message is
ignored.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: websockets questions
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Jul 4, 2013 at 5:52 PM, André Warnier <aw...@ice-sa.com> wrote:
> Mark Thomas wrote:
>
>> On 04/07/2013 10:17, André Warnier wrote:
>>
>>> 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.
>>>
>>
>> The connection has to be kept open but you can use non-blocking IO to
>> only allocate a thread to process data when there is data to process.
>>
>> The exact behaviour varies between Tomcat 7 and Tomcat 8.
>>
>> BIO 7 & 8 - 1 thread per connections, blocking IO, doesn't scale
>>
>> NIO / APR 7 - 1 thread per currently processed frame, non-blocking
>> between frames, scales better
>>
>> NIO / APR 8 - threads only allocated where there is data to process,
>> scales best
>>
>
> "data to process" meaning an entire websocket "message" I suppose ?
>
>
>> Note that JSR356 allows blocking writes. If the client or the server opt
>> to send data using a blocking write then that will use a thread until
>> the write completes.
>>
>> Load-balancers should cope perfectly happily with this.
>>
>> There is no upgrade or WebSocket support in AJP yet.
>>
>>
> Thanks for these precisions.
>
> Another question while we're at it :
> As I understand from the specs/docs, there are 2 kinds of messages : text
> or "blob".
> And I found that there are 2 ways of reading that data, corresponding to
> these 2 types of messages.
> However, I do not find anywhere a function or method or call which would
> allow for example the server-side application to find out in advance if the
> data currently available for reading is one or the other type. Did I miss
> that somewhere, or do I misunderstand the specs/docs ?
>
The application is being notified. The container calls either
onMessage(String/CharBuffer) or onMessage(byte[]/ByteBuffer) on the
endpoint (or whatever is the exact API)
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: websockets questions
Posted by André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> On 04/07/2013 10:17, André Warnier wrote:
>> 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.
>
> The connection has to be kept open but you can use non-blocking IO to
> only allocate a thread to process data when there is data to process.
>
> The exact behaviour varies between Tomcat 7 and Tomcat 8.
>
> BIO 7 & 8 - 1 thread per connections, blocking IO, doesn't scale
>
> NIO / APR 7 - 1 thread per currently processed frame, non-blocking
> between frames, scales better
>
> NIO / APR 8 - threads only allocated where there is data to process,
> scales best
"data to process" meaning an entire websocket "message" I suppose ?
>
> Note that JSR356 allows blocking writes. If the client or the server opt
> to send data using a blocking write then that will use a thread until
> the write completes.
>
> Load-balancers should cope perfectly happily with this.
>
> There is no upgrade or WebSocket support in AJP yet.
>
Thanks for these precisions.
Another question while we're at it :
As I understand from the specs/docs, there are 2 kinds of messages : text or "blob".
And I found that there are 2 ways of reading that data, corresponding to these 2 types of
messages.
However, I do not find anywhere a function or method or call which would allow for example
the server-side application to find out in advance if the data currently available for
reading is one or the other type. Did I miss that somewhere, or do I misunderstand the
specs/docs ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: websockets questions
Posted by Mark Thomas <ma...@apache.org>.
On 04/07/2013 10:17, André Warnier wrote:
> 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.
The connection has to be kept open but you can use non-blocking IO to
only allocate a thread to process data when there is data to process.
The exact behaviour varies between Tomcat 7 and Tomcat 8.
BIO 7 & 8 - 1 thread per connections, blocking IO, doesn't scale
NIO / APR 7 - 1 thread per currently processed frame, non-blocking
between frames, scales better
NIO / APR 8 - threads only allocated where there is data to process,
scales best
Note that JSR356 allows blocking writes. If the client or the server opt
to send data using a blocking write then that will use a thread until
the write completes.
Load-balancers should cope perfectly happily with this.
There is no upgrade or WebSocket support in AJP yet.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: websockets questions
Posted by André Warnier <aw...@ice-sa.com>.
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
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: websockets questions
Posted by Jess Holle <je...@ptc.com>.
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.
--
Jess Holle