With the release of Jetty 7.5.0 and the latest draft 13 of the WebSocket protocol, the API for the client has be re-factored a little since my last blog on WebSocket: Server, Client and Load Test.
WebSocketClientFactory
When creating many instances of the java WebSocketClient, there is much that can be shared between multiple instances: buffer pools, thread pools and NIO selectors. Thus the client API has been updated to use a factory pattern, where the factory can hold the configuration and instances of the common infrastructure:
WebSocketClientFactory factory = new WebSocketClientFactory();
factory.setBufferSize(4096);
factory.start();
WebSocketClient
Once the WebSocketClientFactory is started, WebSocketClient instances can be created and configured:
WebSocketClient client = factory.newWebSocketClient();
client.setMaxIdleTime(30000);
client.setMaxTextMessageSize(1024);
client.setProtocol("chat");
The WebSocketClient does not need to be started and the configuration set is copied to the connection instances as they are opened.
WebSocketClient.open(…)
A websocket connection can be created from a WebSocketClient by calling open and passing the URI and the websocket instance that will handle the call backs (eg onOpen, onMessage etc.):
Future future = client.open(uri,mywebsocket);
WebSocket.Connection connection = future.get(10,TimeUnit.SECONDS);
The open call returns a Future to the WebSocket.Connection. Like the NIO.2 API in JDK7, calling get with a timeout imposes a connect time on the connection attempt and the connection will be aborted if the get times out. If the connection is successful, the connection returned by the get is the same object passed to the WebSocket.onOpen(Connection) callback, so it may be access and used in either way.
WebSocket.Connection
The connection instance accessed via the onOpen callback or Future.get() is used to send messages and also to configure the connection:
connection.setMaxIdleTime(10000);
connection.setMaxTextMessageSize(2*1024);
connection.setMaxBinaryMessageSize(64*1024);
The maximum message sizes are used to control how large messages can grow when they are being aggregated from multiple websocket frames. Small max message sizes protect a server against DOS attack.
25 Comments
Andy Manson · 07/09/2011 at 18:54
wow…sounds like excellent progress. is there any plan to allow anyone else to run this stuff (e.g. by posting a sample on a repository someplace, and a link to it at the end of the post)?
gregw · 07/09/2011 at 23:04
The jetty project contains some examples, and I’ve attached the source of another example project. You can get it at http://webtide.intalio.com/wp-content/uploads/2011/09/example-websocket.zip
b0b · 08/09/2011 at 15:06
Example doesn’t compile due to missing classes in jetty-websocket-7.5.0-v20010901.jar (it is empty)
gregw · 08/09/2011 at 15:17
Ooops that source is now against 7.5.1-SNAPSHOT. My bad. I’ll re-release when 7.5.1 is out in the next day or two.
Leah · 14/09/2011 at 06:46
I’m now try to run dotCMS on Jetty for two weeks but can’t succeed.
It seems some questions about javax.mail.session in web.xml
mail/MailSession
javax.mail.Session
Container
The error is about these tags.
WARN::Configuration problem at | ?mail/MailSession| ?javax.mail.Session| ?Container| : java.lang.IllegalStateException: Nothing to bind for name javax.mail.Session/default
May you give me some hints to resolve the issue?
I think the issue is about some missing jar file or need to be any else setting in web.xml.
Thanks for your kindly answer.
Neil Hart · 24/09/2011 at 17:33
Any update on the example code?
Thanks
Jason Turner · 19/10/2011 at 10:52
How does the Jetty WebSocket implementation address support for reverse proxies?
gregw · 19/10/2011 at 23:57
Jason,
The jetty websocket implementation makes no special provisions for reverse proxies. The websocket protocol designed to have a reasonable chance of passing through many styles of intermediaries, but there will be some that will not allow a successful websocket connection to be established.
Hopefully once the websocket specification is final, these intermediaries will have a good motivation to be updated to support HTTP upgrade mechanism.
Meanwhile, the best way to handle such intermediaries, is to use something like cometd.org, which can try websockets, and if that fails, it will fall back to long polling.
We have a java client for cometd for both HTTP and websockets.
Jeremy · 06/12/2011 at 19:57
I just discovered that the WebSocket Client doesn’t support SSL.
Do you anticipate ‘wss’ support being added in the near future?
Thanks!
simon · 12/12/2011 at 11:56
Jeremy, see http://webtide.intalio.com/2011/12/websocket-over-ssl-in-jetty/
Shahid · 04/03/2012 at 03:47
Many thanks for ws4py I can cronifm that it works great with cherrypy 3.2.0 and Chrome 14.0.835.159 beta on OSX. It also works great with Firefox 7.0 on OSX, with a small modification Firefox sends Connection:keep-alive, Upgradein the initial handshake, and the current logic at ws4py/server/cherrypyserver.py:125 will only accept Connection: UpgradeI don’t know enough about the relevant standards to say who should change, but it’s an easy tweak to ws4py if you’re interested.Finally, a dumb question: how should I initialize a handler derived from WebSocketHandler? I want to pass arguments to its constructor, but since it’s instantiated by WebSocketTool I don’t see how to get to the new instance to hook it into the rest of my application.Cheers!Tim
Nicholas · 09/04/2012 at 19:50
This is really eitcixng stuff, and nice that Jetty has picked this up so fast, even if things are still moving around spec wise.So my interest is getting this to work with GWT. I have the above running fine, and all I’m doing extra is deploying my own Servlet to try and experiment with the websocket connection.In the above example you are using:var location = document.location.toString().replace( http:’,’ws:’);Which in my case is going to give me a GWT generated URL. That isn’t going to match against anything the server is expecting is my guess.Any tips on what my ws: url should look like? Or how to get some extra debug on the doWebSocketConnect call? so far I don’t think I’m hitting that method at all WireShark seems to hint at some websocket attempt, but I only see the request side, but not an upgrade response.Somewhere better to discuss this?
Ryan · 18/12/2011 at 04:31
Will the Jetty websocket client be able to handle connecting to servers which have http basic authentication enabled? It doesn’t appear that it does currently, I’m hoping it will in the future?
Greg Wilkins · 18/12/2011 at 22:33
Jetty websockets can certainly handle basic auth on the handshake. It is treated as a normal HTTP request up until the 101 response is sent.
The problems is the browsers don’t handle 401 or 302 responses for the handshake, nor supply credentials. You need to raise this with the W3c, as the protocol supports it and the browsers need to be encouraged to support it.
cheers
Ryan · 19/12/2011 at 21:44
Thanks for the reply, the jetty websocket client doesn’t provide a way to authenticate during the connection either. I was wondering if that would added. If not, maybe I’ll add it and submit it.
That will certainly not help adoption much if none of the standard http authentication mechanisms will work with the browser websocket implementations. Hopefully they’ll end up supporting it. I’m running into problems with that currently.
gregw · 19/12/2011 at 23:21
Ah good point about our client. We should support adding arbitrary cookies and headers for such things as auth.
A patch to that effect would be very much welcome.
cheers
Prakash · 04/03/2012 at 10:58
Sylvain:Thanks for the quick response, I filed the tikcet. In the meantime, I figured-out that I can access the handler using cherrypy.request.ws_handler, and it’s working well I’ve got a simple application that delivers images to the client running on my localhost.In the long run, I need to deploy my little app behind an Apache reverse proxy that provides SSL and authentication. Any issues you’re aware of? I have some vague idea that secure sockets are required to go through a proxy, are they supported via cherrypy + ws4py?Many thanks,Tim
Ryan · 21/12/2011 at 20:58
The client does support cookies, I’ll add the support into the code and submit a patch. It won’t be very hard.
Andy · 01/03/2012 at 01:00
If I want to just embed the websocket client in my application without having to use the rest of the Jetty jars, if there a way to do it? I know I can figure it out by stripping out all other jars/classes and working my way up to fix the missing class failures. But if somebody has already figured out the set of mininum jars needed for this configuration, it will help me a bunch
thanks
Andy
narendra · 21/03/2012 at 05:21
hai,
I am using jetty websocket server version 7.5.But problem is when webpage idle in 15 min it will automatically close the connection.pls suggest me what is the problem.
gregw · 21/03/2012 at 12:49
That is because either the client or the server is implementing an idle timeout. If you want to keep it open, you need to use the server API to send some pings or other keep alive messages
Patrick · 08/04/2012 at 09:59
hi greg,first off, thanks for the soarwfte, your time, this blog and your replies. my previous question might be a little ambiguous. since i’m using cometd, i’m trying to tie the dao layer to the ajax layer. i’ve been experimenting with the examples for 2 whole days and have a better understanding now. i read all the docs on the jetty website, but couldn’t find any examples on how to apply the QoSFilter on the ContinuationCometServlet (since i’ll be calling the dao layer from the servlet). is this the right way to do it (or is there a better way)? any suggestions on this?thanks
Manish · 27/02/2013 at 10:39
We have a java client that is behind a proxy server. I want to connect tomcat websocket implementation with our java standalone client (not on browser). Can we use proxy server with your client API to connect websocket. If you have any sample java code for this, please send us. Thanks in Advance.
Greg Wilkins: Jetty WebSocket Client API updated · 03/09/2011 at 03:31
[…] Read more: Greg Wilkins: Jetty WebSocket Client API updated […]
Jetty WebSocket Client API updated | Eclipse | Syngu · 03/09/2011 at 05:33
[…] creating many instances of the java WebSocketClient, there is much that… Read more… Categories: Eclipse Share | Related […]
Comments are closed.