On 09/02/2012 02:41, Petr Praus wrote: > Our initial idea was some form of a streaming API where the reader code > receiving the message fills a stream that's somehow connected to a client > code that would be consuming it. Hence the Piped[Input|Output]Stream stuff. > I also think the individual frames of a fragmented messages should not be > exposed to the client code. If I remember correctly, RFC specifies that its > up to the implementation to decide. What do you think?
I agree. > And, what are your other ideas for supporting huge payloads? Streaming is the only (scalable / efficient) game in town for that. > I'm not sure about other browsers but Chrome 16 fragments payloads so that > WS frames fit into MSS of the underlying protocol (TCP). So if I sent > string larger than roughly 1450 bytes from the client javascript, I got > fragments packets. Beware that "lo" device on Linux has by default MTU > 16436 so on localhost, the above value of 1450 bytes is much larger. Ah. Interesting. That could be very useful. >> Given that the implementation currently uses blocking IO > > Just to make sure, processor.read() calls are always blocking, right? I assume you mean UpgradeProcessor.read() rather than Processor.read() (which doesn't exist). Yes, UpgradeProcessor.read() is (currently) always blocking. > I'm > somewhat confused by Nio/Bio/Apr in combination with this. As I understand > it, any of the three can be used at the user's will and so the processor > can be of type UpgradeNioProcessor. In that case the read on the underlying > socket is not blocking. Yes it is. It is performed using a blocking Selector. The parameter is there to allow non-blocking reads but that makes the whole API a lot more complicated so it is currently on the "We'll look at implementing it a) if there is a demand for it and b) we can come up with a sane API" category. > So how come read on the UpgradeProcessor will > always be blocking? Can you shed some light on this? Thanks Take a look at UpgradeNioProcessor.readSocket() and the value of the block parameter whenever that method is called. >> 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. >> > > This seems like a sensible approach, I'll look into it. Sounds good. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
