On Sun, Jan 29, 2012 at 2:19 AM, Mark Thomas <ma...@apache.org> wrote:
> On 29/01/2012 01:20, Costin Manolache wrote: > > On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas <ma...@apache.org> wrote: > > > > Not complaining - it's great to add this feature, please commit it - but > > I'm wondering > > if a lighter interface wouldn't be better. From looking at the > > implementation, it seems > > after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole > > Request / Processor / etc tree ). > > I agree there is certainly scope to do that. My initial focus has been > on functionality and minimal changes to existing code - hence the > current approach. > > I'm not overly keen on the additional overhead myself and can see > several ways to reduce it. Output is easier than input since we know the > output buffers are clear on upgrade. Input is a little trickier since > there may be some data in the input buffer and that would need to be > drained before switching to the lighter weight approach. > I don't think the upgrade protocol allows clients to send payload before receiving the response headers / handshaking, so I think it wouldn't be a problem. In terms of actual code changes - I think the main problem is that nio/apr/oio input/output are implemented in Internal[Input/Output][Nio/Apr]Buffer which are quite heavy- it would be a huge change to modify that. However it may be possible to have some lighter buffers - just the socket and methods to read/write. At least that's what I've been trying with spdy - which also involves some protocol switching. The change is also minimal in endpoint-specific code ( it's just adding few hooks and some new code ). I think this is something to look at once the implementation is more > feature complete. Whatever we do, I'd like to keep the following aims in > mind: > - minimal endpoint specific code > - minimal changes to what we have now > - keep the generic upgrade and the protocol specific parts separate > I agree. > > > Would it be possible for example to release the Request, like it's done > > after request, > > in keep-alive, and use a lighter parser/callback on the socket ? I think > > one of the use cases > > for websockets is to support a _lot_ of open connections. > > That is certainly one approach. It will be easier to explore options > when we have a wider range of examples to work / test with. > > > Also the interface may be simpler without InputStreams. > > I thought long and hard about that. Looking around, some implementations > are message based, some are stream based. There are good arguments for > both. Unfortunately the WebSocket protocol is a messages based protocol > with no maximum message length. A message is one or more frames and a > frame is up to 2^63 bytes. While most usages will be small(ish) messages > that can be buffered without undue overhead, any application that wants > larger messages needs to use a stream based interface to be able to > scale. That is why I went for both. > Well, the message is sent from javascript - I don't think 2^63 frames are likely, and even if they are, I don't think a blocking InputStream interface is best choice. Why not copy some of the javascript interface ( onopen / onmessage / etc ) ? Or onMessage(byte[] initialData) + onMessageData(byte[] moreBytes) ? In other words - make it 'async' from start. I wouldn't even worry about the string conversions for text frames in a low-level interface. Costin > > Thanks for the feedback. Much appreciated. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
