On 20/02/2012 02:55, Petr Praus wrote: > Hi Mark, > I noticed you wrote a websocket test client, I haven't looked at it > extensively
It won't take long to look at - it is a very simple client. > but I wanted to ask - have you considered using Autobahn for > testing? It's rather extensive opensource websocket testing suite. I haven't. I just took a quick look. Looks like a nice tool. My test client is intended to be something we can run in the unit tests to look at very specific issues. It isn't intended to be a general WebSocket client, nor to test the full range of functionality. I think Autobhan is something we would run separately - a bit like we do with the WebDAV test suite and the TCKs. > It already contains a lot of stuff we need to test including fragmentation > testing. Yep, it looks really good. I dread to think how many failures we'd get with the current code :) What we can do is to provide the necessary servlet that AutoBahn needs to talk to as part of the examples web app. That way, anyone can run the test suite with minimal effort. > On Fri, Feb 17, 2012 at 14:50, Mark Thomas <ma...@apache.org> wrote: > >> On 16/02/2012 04:01, Petr Praus wrote: >>> Hello, attached is our patch. It applies cleanly on top of current trunk >>> rev. 1244719. It has rudimentary support for fragmentation (callback >>> after last frame), supports close messages and ping/pong. Sorry for not >>> sending a patchset but I thought it wouldn't really make sense, since >>> there were quite a lot of back and forth changes. Let me know if I >>> should send a patchset instead. >> >> The final diff is fine to work with from my point of view. >> >>> >>> (Jonathan's summary) >>> "Echoing fragments. Close messages. Pings/pongs. >>> >>> Just barely works. :) Fragmentation support is very limited: a mere >>> callback when last frame received. >> >> Repeating what I already wrote in BZ on fragmentation so there is a >> complete set of review comments in one place >> >> I am extremely reluctant to apply the current fragmentation patch. It >> relies on buffering individual fragments and - given the maximum >> fragment size - that is simply not going to scale. This is why the >> current API is built on streams and does not buffer unless the message >> based API is used. >> >> I'd like to fully explore the possibility of supporting fragments >> without using buffering before starting down that path. >> > > I understand your concern, the main idea was that the logic that pertains > only to a single frame and the information about the frame itself should be > encapsulated there. What about letting the client code know there's a new > frame before we begin reading the data but still keep the frames > encapsulated in WebSocketFrame? Getting fragmentation support working with streams was easier than I expected. Essentially, just pushing the frame header processing code down into the InputStream was all that was required. I prefer the approach where the client gets one notification per 'message' rather than per frame. Need up is handling the control messages. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
