Re: websockets questions

[Howard W. Smith, Jr.]

On Thu, Jul 4, 2013 at 1:43 PM, Pierre Goupil 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

[Pierre Goupil]

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"  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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: websockets questions

[Mark Thomas]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: websockets questions

[Martin Grigorov]

On Thu, Jul 4, 2013 at 5:52 PM, 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 ?
>
>
>> 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
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: websockets questions

[André Warnier]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: websockets questions

[Mark Thomas]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: websockets questions

[Martin Grigorov]

Hi Andre,


On Thu, Jul 4, 2013 at 12:17 PM, André Warnier  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
>
>  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
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: websockets questions

[André Warnier]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org