On 29/01/2012 22:49, Costin Manolache wrote: > 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.
Good point. I thought I was seeing data arriving earlier than that but what you says makes sense. I'll need to go back and double check exactly what I was seeing. > 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 ). Agree the lightweight buffers are the way to go. >>> 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. Blocking was simpler to implement. As I think I said earlier in this thread, non-blocking is a possible enhancement - if there is interest - but it isn't my focus right now. Also at the back of my mind is a preference that this works with BIO as it isn't clear to me at this point what the Servlet spec is going to end up saying about web socket support and I'd rather not end up in the position where using BIO meant non-spec compliance. There are a lot of unknowns there so this may end up being an unnecessary restriction. Overall, it is early days for WebSocket so I may end up being completely wrong about a lot of this. We'll see how things evolve. > Why not copy some of the javascript interface ( onopen / onmessage / etc ) > ? The interface isn't complete yet. What you describe is not a million miles from what I expect the Message based interface will end up looking like. That said, it appears from reading the protocol and various blogs around it that the folks that wrote it had all sorts of weird and wonderful clients in mind for this and that has certainly influenced the protocol design. If all clients were JavaScript the protocol would look very different (and the server side would be a whole lot easier to implement). I am trying to keep the options open rather than impose arbitrary limits on things to make a particular interface viable. > 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. What I have so far is also influenced by what other containers are doing with a view to getting some form of convergence. I think all the containers are taking the view that their current API is a starting point and things are likely to change a lot. How they change will (hopefully) be driven by user demand. We'll see where we end up. Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
