Jetty-7.0.1 has been extended with a WebSocket server implementation based on the same scalable asynchronous IO infrastructure of Jetty and integrated into the Jetty Servlet container.
WebSocket came out of work on HTML5 by the What Working Group to specify a mechanism to allow two way communications to a browsers. It is currently being standardized at the W3C for the WebSocket API and by the IETF for the WebSocket protocol and is soon to be supported by releases of Firefox, and Chromium. While I have significant concerns about the websockets protocol, it is important that server concerns are considered in the standardization process. Thus to follow the IETF model of "rough consensus and working code", it is important that Jetty has a working implementation of the protocol.
The key feature of the Jetty Websocket implementation is that it is not another separate server. Instead it is fully integrated into the Jetty HTTP server and servlet container. so a Servlet or Handler can process and accept a request to upgrade a HTTP connection to a WebSocket connection. Applications components created by standard web applications can then send and receive datagrams over the WebSocket with non blocking sends and receives.
Below is an example of a SIMPLE "Chat" application written using the Jetty WebSocketServlet, which can handle normal doGet style requests, but will call doWebSocketConnect if an upgrade request is received:
public class WebSocketChatServlet extends WebSocketServlet
{
private final Set _members = new CopyOnWriteArraySet();
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException ,IOException
{
getServletContext().getNamedDispatcher("default").forward(request,response);
}
protected WebSocket doWebSocketConnect(HttpServletRequest request, String protocol)
{
return new ChatWebSocket();
}
class ChatWebSocket implements WebSocket
{
Outbound _outbound;
public void onConnect(Outbound outbound)
{
_outbound=outbound;
_members.add(this);
}
public void onMessage(byte frame, byte[] data,int offset, int length)
{}
public void onMessage(byte frame, String data)
{
for (ChatWebSocket member : _members)
{
try
{
member._outbound.sendMessage(frame,data);
}
catch(IOException e) {Log.warn(e);}
}
}
public void onDisconnect()
{
_members.remove(this);
}
}
}
The client side of this chatroom is implemented by this script, whose key sections include:
join: function(name) {
this._username=name;
var location = document.location.toString().replace('http:','ws:');
this._ws=new WebSocket(location);
this._ws.onopen=this._onopen;
this._ws.onmessage=this._onmessage;
this._ws.onclose=this._onclose;
},
_onopen: function(){
$('join').className='hidden';
$('joined').className='';
$('phrase').focus();
room._send(room._username,'has joined!');
},
_send: function(user,message){
user=user.replace(':','_');
if (this._ws)
this._ws.send(user+':'+message);
},
_onmessage: function(m) {
if (m.data){
var c=m.data.indexOf(':');
var from=m.data.substring(0,c).replace('<','<').replace('>','>');
var text=m.data.substring(c+1).replace('<','<').replace('>','>');
...
}
}
This example is included in the test webapp shipped with Jetty-7.0.1, and has been tested with the websocket client in dev releases of Google Chromium 4.0.
The intention for the jetty-websocket server is to be the focus of trial and experimentation with the protocol, it's implementation and framesworks like cometd that might use it. All should be considered Alpha and highly likely that they will change with feedback received. Hopefully using the protocol with real servers, clients and applications will result in the experience required to feedback to the IETF requirements that will drive the improvement of the protocol.
One example of an area that needs to be improved is the discovery and/or negotiation of idle timeouts for the WebSocket connections. Currently the jetty-server is inheriting the idle timeout of the HTTP connection, which is 30s by default. This means that the demo chat application drops it's connection after 30 seconds of no conversation. This is not exactly what you want in a chat room, but because there is no way to discover or configure the idle timeouts of other parties to a websocket connection (including proxies), then the application has no choice but to handle the idle close event itself.
Posted at 03:46PM Nov 24, 2009 by gregw in General | Comments[21]
