On 07/02/2012 02:23, Jonathan Drake wrote: > I'm one the three CS grad students working on WebSocket (along with Petr > Praus). > > Just wanted to give an update on our progress, to let you know what we're > working on: > > Adding support for fragmented payloads:
Excellent. That and handling control frames are the biggest gaps right now in my view. > Right now, after receiving a frame, StreamInbound unmasks the payload in a > WsInputStream and passes it up to the servlet via > onBinaryData()/onTextData(). > To support fragmented frames, we add an intermediate step: after unmasking > the payload, write it to a PipedOutputStream connected to a > PipedInputStream that we pass upward via onBinaryData()/onTextData(). When > the next fragment arrives, keep streaming data through the pipe. Piped[Input|Output]Stream are intended to be used with a separate thread at each end. There is currently only a single thread processing the incoming data. How do you propose to provide the additional thread? > This has the advantage of also allowing us to stream huge payloads (RFC > 6455 allows for a 64-bit extended length field---way too much data to > buffer in memory all at once). That is certainly a requirement. However, there is more than one way to meet that requirement. > It has the minor disadvantage of breaking the ByteBuffer wrappers from > MessageInbound (we can still use them for small payloads if we buffer > fragments in memory) Could you clarify what is broken in what circumstances please. MessageInbound is expected to work providing that the message (regardless of how many fragments it is spread across) is smaller than the available buffer size. My expectation is that the current echo example would continue to work regardless of whether or not the messages were in a single fragment or multiple fragments. > I'm working on a patch that implements this...maybe a day or two. > > I'd appreciate any early criticism you may have---otherwise I mainly just > want to prevent duplicate work by explaining what we're up to. Thanks for the heads up. The approach you describe isn't the one I had in mind, but that is a good thing. It provides an opportunity to compare and to take the best from both. It would be nice to have a test case or an example client for this. Unless there is an easy way to force a browser to fragment packets, I suspect a test case will be required. Given that the implementation currently uses blocking IO, my approach was going to be something along the lines of: a) read the headers b) call onBinaryData() / onTextData() c) make the payload available via WsInputStream until the end of the fragment d) read the headers for the next fragment e) make the payload available via WsInputStream until the end of the fragment f) repeat d) & e) until the final fragment is processed g) return EOF on the next read This would mean moving most of the code currently in StreamInBound.onData() to WsInputStream I haven't tried coding this up or anything so there is no guarantee it would actually work. Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
