WebSocketServlet (and chat example) comments
Hi, I have been playing with the web sockets support in 7.0.27. I have some comments and, as requested in the readme, am sending them to the dev list. Caveat: it's been a while since .27, so perhaps some of these issues are addressed in the nightly builds. Anyhow, here we go: 1) In the createWebSocketInbound method implemented by the chat example's subclass of WebSocketServlet, there is seemingly no way to interrogate the incoming request for information like post/get parms as in a conventional servlet. Since these can be sent later via a message, so this is only a slight problem. However, a more serious problem is that I can't get at the IP address of the incoming request when the connection is being created. This means I can't implement something like a block list (common in games) to remove annoying things like DOS attacks and misbehaving players from hitting my server at the point where a connection is created (and hence resources used). Access to some form of parms would allow me to do additional validation (like user name and login) at this stage as well. 2) MessageInbound is oddly named. Really this is a persistent connection, so likely it should likely be named something like WebSocketConnection. The chat example hints at this, and maintains a list of "connections", which are instances of the subclass of MessageInbound. Since you have onTextMessage and onBinaryMessage methods from which to hang actual message processing, this rename would be consistent. 3) As mentioned, the chat example maintains a list of connections. Connections (MessageInbound instances) are added to this list when connections are established. However, they are never removed when the connection is closed, so the list grows. The broadcast method silently ignores the IOException presumably caused by writing to these connections. 4) I get what look like a timeout (and the connection closes) in case of inactivity in the chat example. However, I can't see a way to adjust this, or turn the behavior off. See previous comment about the non-removal from the list of connections. Previously, in comet, we dealt with things like this by doing an immediate reconnect from the javascript side of networking code, but it would be nice to have control over this during this time around the wheel. best regards MR
Re: WebSocketServlet (and chat example) comments
> > > >> 3) As mentioned, the chat example maintains a list of connections. > >> Connections (MessageInbound instances) are added to this list when > >> connections are established. However, they are never removed when the > >> connection is closed, so the list grows. The broadcast method silently > >> ignores the IOException presumably caused by writing to these > connections. > > > > Opps. We'll get that fixed. > > I don't see this in the code or when I test it. Could you explain the > circumstances in which this happens please? Wups, I am wrong on this. I was looking at a modified example of Chat, and when I went back and looked at the original version, the call to remove was there in the onClose method. It is still silently ignoring the exception caught in broadcast() however. MR >
Re: WebSocketServlet (and chat example) comments
Thanks, comments below. I'm going to address the chat example connection pruning in a separate mail. >> 1) In the createWebSocketInbound method implemented by the chat example's > >> subclass of WebSocketServlet, there is seemingly no way to interrogate > the > >> incoming request for information like post/get parms as in a > conventional > >> servlet. Since these can be sent later via a message, so this is only a > >> slight problem. However, a more serious problem is that I can't get at > the > >> IP address of the incoming request when the connection is being created. > >> This means I can't implement something like a block list (common in > games) > >> to remove annoying things like DOS attacks and misbehaving players from > >> hitting my server at the point where a connection is created (and hence > >> resources used). Access to some form of parms would allow me to do > >> additional validation (like user name and login) at this stage as well. > > >Fair point. Would making the request object available be sufficient? It > >would almost certainly be wrapped in a façade with the wrapped request > >set to null after the method completes to prevent sub-classes retaining > >a reference to the request which would create all sorts of problems. > I think that would be fine. It doesn't need to be there perpetually but it would be nice to be able to pull stuff out of it at the time the connection is created. > >> 2) MessageInbound is oddly named. Really this is a persistent > connection, > >> so likely it should likely be named something like WebSocketConnection. > >> The chat example hints at this, and maintains a list of "connections", > >> which are instances of the subclass of MessageInbound. Since you have > >> onTextMessage and onBinaryMessage methods from which to hang actual > message > >> processing, this rename would be consistent. > > >Another fair point. I can't decide whether to change this now or to wait > >until JSR 356 is more advanced and change it then. Thoughts ? Great, thanks >> 4) I get what look like a timeout (and the connection closes) in case of > >> inactivity in the chat example. However, I can't see a way to adjust > this, > >> or turn the behavior off. See previous comment about the non-removal > from > >> the list of connections. Previously, in comet, we dealt with things > like > >> this by doing an immediate reconnect from the javascript side of > networking > >> code, but it would be nice to have control over this during this time > >> around the wheel. > > >That was a 'feature' of the first implementation. WebSocket now uses an > >infinite time out by default (this required some low level changes to > >the APR/native connector which slowed down the 7.0.28 release a little) > >and the application can change the time out on a per connection basis. > Makes sense. Thanks for the work on this, we all appreciate tomcat. MR
latency - websockets vs. REST
I'm seeing some differences in the latency of making a post request via jQuery versus sending a websockets message. It maybe that this is overhead in my application caused by processing the json I am sending in the message, but I find this hard to believe. I imagined that web socket connection should be faster than REST due to it not creating and destroying the socket, however this does not seem to be the case. Is there a reason why websockets should be slower? I thing I can code up a small test case to illustrate this if this is something people are interested in .. MR
Re: latency - websockets vs. REST
This was using .35 with the default connector (just a generic tomcat install using the installer, on windows 7 64bit) from current firefox. I can't tell you the exact time difference currently, but I can say that if I chain the calling of the REST API off the end off the completion of the WebSocket's sendMessage, the REST API call will consistently beat the web socket to the end point. Which (I think) means that either it's latency in moz's web socket implementation, or it's at the server end. I will make a test case which does exact timing and is separated from our application and report back on what I find. MR On Tue, Jan 29, 2013 at 12:11 PM, Mark Thomas wrote: > On 29/01/2013 20:04, Michael Roberts wrote: > > I'm seeing some differences in the latency of making a post request via > > jQuery versus sending a websockets message. It maybe that this is > overhead > > in my application caused by processing the json I am sending in the > > message, but I find this hard to believe. I imagined that web socket > > connection should be faster than REST due to it not creating and > destroying > > the socket, however this does not seem to be the case. Is there a reason > > why websockets should be slower? > > > > I thing I can code up a small test case to illustrate this if this is > > something people are interested in .. > > Tomcat version? > Connector? > How much difference? > > REST can (and should for performance) use HTTP keep-alive. > > There is some overhead in upgrading an HTTP connection to use WebSocket > so for a single request I'd expect the REST request to be faster. Once > both connections are established, WebSocket should be faster (note that > binary messages will be faster than text ones). > > If you have a test case that demonstrates this with established > connections I'd certainly be interested. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: latency - websockets vs. REST
oh, and this was using an established connection. text message however. On Tue, Jan 29, 2013 at 12:19 PM, Michael Roberts wrote: > > This was using .35 with the default connector (just a generic tomcat > install using the installer, on windows 7 64bit) from current firefox. I > can't tell you the exact time difference currently, but I can say that if I > chain the calling of the REST API off the end off the completion of the > WebSocket's sendMessage, the REST API call will consistently beat the web > socket to the end point. Which (I think) means that either it's latency in > moz's web socket implementation, or it's at the server end. > > I will make a test case which does exact timing and is separated from our > application and report back on what I find. > > MR > > On Tue, Jan 29, 2013 at 12:11 PM, Mark Thomas wrote: > >> On 29/01/2013 20:04, Michael Roberts wrote: >> > I'm seeing some differences in the latency of making a post request via >> > jQuery versus sending a websockets message. It maybe that this is >> overhead >> > in my application caused by processing the json I am sending in the >> > message, but I find this hard to believe. I imagined that web socket >> > connection should be faster than REST due to it not creating and >> destroying >> > the socket, however this does not seem to be the case. Is there a >> reason >> > why websockets should be slower? >> > >> > I thing I can code up a small test case to illustrate this if this is >> > something people are interested in .. >> >> Tomcat version? >> Connector? >> How much difference? >> >> REST can (and should for performance) use HTTP keep-alive. >> >> There is some overhead in upgrading an HTTP connection to use WebSocket >> so for a single request I'd expect the REST request to be faster. Once >> both connections are established, WebSocket should be faster (note that >> binary messages will be faster than text ones). >> >> If you have a test case that demonstrates this with established >> connections I'd certainly be interested. >> >> Mark >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> >
Re: latency - websockets vs. REST
ok, I'll get to this start of next week with a comprehensive test case and report back. M On Tue, Jan 29, 2013 at 12:23 PM, Martin Grigorov wrote: > You can check with Google Chrome and/or IE10 to see whether it is not > something in Firefox > > > On Tue, Jan 29, 2013 at 9:19 PM, Michael Roberts wrote: > > > This was using .35 with the default connector (just a generic tomcat > > install using the installer, on windows 7 64bit) from current firefox. I > > can't tell you the exact time difference currently, but I can say that > if I > > chain the calling of the REST API off the end off the completion of the > > WebSocket's sendMessage, the REST API call will consistently beat the web > > socket to the end point. Which (I think) means that either it's latency > in > > moz's web socket implementation, or it's at the server end. > > > > I will make a test case which does exact timing and is separated from our > > application and report back on what I find. > > > > MR > > > > On Tue, Jan 29, 2013 at 12:11 PM, Mark Thomas wrote: > > > > > On 29/01/2013 20:04, Michael Roberts wrote: > > > > I'm seeing some differences in the latency of making a post request > via > > > > jQuery versus sending a websockets message. It maybe that this is > > > overhead > > > > in my application caused by processing the json I am sending in the > > > > message, but I find this hard to believe. I imagined that web socket > > > > connection should be faster than REST due to it not creating and > > > destroying > > > > the socket, however this does not seem to be the case. Is there a > > reason > > > > why websockets should be slower? > > > > > > > > I thing I can code up a small test case to illustrate this if this is > > > > something people are interested in .. > > > > > > Tomcat version? > > > Connector? > > > How much difference? > > > > > > REST can (and should for performance) use HTTP keep-alive. > > > > > > There is some overhead in upgrading an HTTP connection to use WebSocket > > > so for a single request I'd expect the REST request to be faster. Once > > > both connections are established, WebSocket should be faster (note that > > > binary messages will be faster than text ones). > > > > > > If you have a test case that demonstrates this with established > > > connections I'd certainly be interested. > > > > > > Mark > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com <http://jweekend.com/> >
