tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 51181] Add support for Web Sockets
Date Wed, 18 Jan 2012 22:35:07 GMT

--- Comment #26 from Mark Thomas <> 2012-01-18 22:35:07 UTC ---
I dug out my old ideas and have been updating them. You can see how far I have
got in [1]. Note that this is all very early days and pretty much everything is
subject to change and a lot of the detail is missing. That said, I think the
broad strokes are heading in the right direction.

Key points are:
- Limited connector (BIO/NIO/APR) specific code (thanks to the previous
- Write apps by extending WebSocketServlet
- Also interface to implement / base class to extend for reading / writing
- Provide stream-based and message-based APIs (stream will be implemented first
and then message-based with configurable buffers on top off the streaming API)
- message-based API likely to be similar to Jetty's - will align to common API
if at all possible
- reading/writing will use blocking IO per message (much, much simpler to
implement and only the NIO connector could do non-blocking - could possibly add
non-blocking IO later if there is sufficient demand)

As soon as I have something that roughly works end to end (i.e. I can get the
WebSocket equivalent of HelloWorld working) I'll commit this to trunk with the
aim of back-porting it to 7.0.x once the integration points are stable. It
looks as if the integration points are going to be few and well defined so they
should be stable pretty quickly which bodes well for getting this into 7.0.x.

The message-based API isn't dissimilar to the Comet-style API proposed above
but rather than a single call-back with different event types, there will be
one call-back per event type (close, text message, binary message). Control
messages will be handled at a lower level.

One caveat and I can't stress this enough. The devil will be in the detail and
experience with the Servlet 3.0 async work has shown that what appears to be a
complete, working implementation may need a major re-write to make it stable.
It isn't beyond the realm of possibility that there is a huge logical flaw in
the approach I have taken so far that necessitates ripping most of this up and
starting again.

Finally, there has been an awful lot of interest in this enhancement request
but not much in the way of contributions. Hopefully as the code starts to get
committed, contributions will be easier. Discussions on the patch are best held
on the dev mailing list. I only wrote this progress report in BZ in case folks
who are cc'd on the bug aren't on the dev list.


Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message