Subject: [hybi] interop tests - fragments

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Mon, 07 Mar 2011 12:48:37 -0500

I'm looking to test with a server that generates and sends fragmented
messages. Anyone implement that?

-- 
http://www.getfirefox.com/

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 8 Mar 2011 07:47:35 +1100

Pat,

The jetty server 7.3.1.v20110307 has API to will send/receive
fragments, but no test app that will do it out of the box, other than
test harnesses.

Ping me on email or #jetty on irc.freenode.net if you have a question
about usage

cheers

On 8 March 2011 04:48, Pat McManus @Mozilla <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Andy Green <[email-masked]>
Date: Mon, 07 Mar 2011 21:49:49 +0000

> messages. Anyone implement that?

libwebsockets supports fragmentation now, I added a fragmentation test 
server and client test applet to confirm it's at least internally 
consistent.  Greg I dunno if you're interested to knock something 
similar up for Jetty like you did for the test ping applet?

At the moment I had the test app turn off compression on the link.

http://git.warmcat.com/cgi-bin/cgit/libwebsockets/

Here's the README about it -->

Fraggle test app
----------------

By default it runs in server mode

$ libwebsockets-test-fraggle
libwebsockets test fraggle
(C) Copyright 2010-2011 Andy Green <[email-masked]> licensed under LGPL2.1
  Compiled with SSL support, not using it
  Listening on port 7681
server sees client connect
accepted v06 connection
Spamming 360 random fragments
Spamming session over, len = 371913. sum = 0x2D3C0AE
Spamming 895 random fragments
Spamming session over, len = 875970. sum = 0x6A74DA1
...

You need to run a second session in client mode, you have to
give the -c switch and the server address at least:

$ libwebsockets-test-fraggle -c localhost
libwebsockets test fraggle
(C) Copyright 2010-2011 Andy Green <[email-masked]> licensed under LGPL2.1
  Client mode
Connecting to localhost:7681
denied deflate-stream extension
handshake OK for protocol fraggle-protocol
client connects to server
EOM received 371913 correctly from 360 fragments
EOM received 875970 correctly from 895 fragments
EOM received 247140 correctly from 258 fragments
EOM received 695451 correctly from 692 fragments
...

The fraggle test sends a random number up to 1024 fragmented websocket 
frames
each of a random size between 1 and 2001 bytes in a single message, then 
sends
a checksum and starts sending a new randomly sized and fragmented message.

The fraggle test client receives the same message fragments and computes the
same checksum using websocket framing to see when the message has ended.  It
then accepts the server checksum message and compares that to its checksum.

-Andy

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 8 Mar 2011 09:11:37 +1100

Andy,

I will write a test client and server to match.

Actually, I think we should come up with a list of standardized sub-protocol
names that match to tests we can do for compatibility, and then also test
production servers don't accidentally deploy tests like echo.

I noticed you have a protocol name of  lws-mirror-protocol  for an echo
server.

How about:

org.ietf.websocket.test-echo              - echo all frames
org.ietf.websocket.test-echo-assemble     - echo messages after assembling
all fragments
org.ietf.websocket.test-echo-fragment     - echo frames randomly fragmented

org.ietf.websocket.test-consume           - consume all messages. Every 1s
send a text message formatted as follows "frames=%d messages=%d bytes=%d
binary=%d"
org.ietf.websocket.test-produce           - produce messages of random size
and fragmentation

It would be really handy if protocol names could be parameterised, so in the
last instance we could do something like:

org.ietf.websocket.
test-produce;minMsg=16;maxMsg=4096;fragment=true;pause=50ms

we could then also just have test-echo and the assemble and fragment
behaviours could be parameters.

cheers

On 8 March 2011 08:49, Andy Green <[email-masked]> wrote:
> consistent.  Greg I dunno if you're interested to knock something similar
up
> for Jetty like you did for the test ping applet?
>

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 8 Mar 2011 14:58:01 +1100

On 8 March 2011 09:11, Greg Wilkins <[email-masked]> wrote:

> org.ietf.websocket.test-produce           - produce messages of random
> size and fragmentation
>
>
>
Also

   org.ietf.websocket.test-echo-broadcast   - echo all frames to all
connected websockets

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 15 Mar 2011 00:40:53 +1100

Since not everybody doing interop will be familiar with Java,  I
thought I'd post some more explicit instructions of how to run the
jetty test client/server, plus descriptions of the test protocols that
they are using.

You can get the latest jetty aggregate jar with:
  wget -O jetty-all.jar
https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse/jetty/aggregate/jetty-all/7.3.2-SNAPSHOT/jetty-all-7.3.2-20110314.133648-9.jar

you also need a servlet jar:
  wget --user-agent=something
http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar

The server can then be run with

  java -cp jetty-all.jar:servlet-api-2.5.jar
org.eclipse.jetty.websocket.TestServer --port 8080

And the client with:

  java -cp jetty-all.jar:servlet-api-2.5.jar
org.eclipse.jetty.websocket.TestClient --help
  ERROR: [--help]
  USAGE: java -cp CLASSPATH class
org.eclipse.jetty.websocket.TestClient [ OPTIONS ]
    -h|--host HOST  (default localhost)
    -p|--port PORT  (default 8080)
    -b|--binary
    -v|--verbose
    -c|--count n    (default 10)
    -s|--size n     (default 64)
    -f|--fragment n (default 4000)
    -P|--protocol echo|echo-assemble|echo-fragment|echo-broadcast

The protocols supported are the ones I proposed earlier:

    org.ietf.websocket.test-echo
        Websocket messages are sent by the client and the server will
echo every frame.

    org.ietf.websocket.test-echo-broadcast
        Websocket messages are sent by the client and the server will
echo every frame to every connection.

    org.ietf.websocket.test-echo-assemble
        Websocket messages are sent by the client and the server will
echo assembled messages as a single frame.

    org.ietf.websocket.test-echo-fragment
        Websocket messages are sent and the server will echo each
message fragmented into 2 frames.

If there is no interest in making these common, then I'll drom the
org.ietf prefix

An example of running the test client is

[558] java -cp jetty-all.jar:servlet-api-2.5.jar
org.eclipse.jetty.websocket.TestClient --port 8080 --binary --count 3
--size 120 --fragment 40 --protocol echo-fragment
Jetty WebSocket PING localhost:8080 (localhost/127.0.0.1:8080) 120
bytes of data.
handshake OK for protocol 'org.ietf.websocket.test-echo-fragment'
120 bytes from localhost: frames=2 req=1 time=52.0ms opcode=0x05
120 bytes from localhost: frames=2 req=2 time=38.2ms opcode=0x05
120 bytes from localhost: frames=2 req=3 time=37.4ms opcode=0x05
--- localhost websocket ping statistics using 1 connection ---
9 frames transmitted, 6 received, 3 messages transmitted, 3 received,
time 3009ms
rtt min/ave/max = 37.448/42.534/51.974 ms

So 3x120B binary messages were sent in 3x40B fragments, for a total of
9 frames sent.  The echo-fragment protocol received these 3 messages
and echoed each back in 2 fragments, for 6 frames received.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 16 Mar 2011 10:20:24 +1100

hmmmm  there is no chorus of approval for some common testing sub
protocols - so unless anybody speaks up soon, I'll drop the
org.ietf.websocket from the protocols that jetty implements.

cheers

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 15 Mar 2011 23:27:17 +0000

I think this is a good idea. W3C has test suites for the APIs, but there is no equivalent for the protocol side at the IETF. This could be a way to incorporate some standard tests.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg
> Wilkins
> Sent: Tuesday, March 15, 2011 16:20
> To: hybi
> Subject: Re: [hybi] interop tests - fragments
> 
> hmmmm  there is no chorus of approval for some common testing sub protocols
> - so unless anybody speaks up soon, I'll drop the org.ietf.websocket from the
> protocols that jetty implements.
> 
> cheers
> 
> 
> > https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse
> > /jetty/aggregate/jetty-all/7.3.2-SNAPSHOT/jetty-all-7.3.2-20110314.133
> > 648-9.jar
> >
> > --size 120 --fragment 40 --protocol echo-fragment Jetty WebSocket PING
> > localhost:8080 (localhost/127.0.0.1:8080) 120 bytes of data.
> > time 3009ms rtt min/ave/max = 37.448/42.534/51.974 ms
> >

---

From: Andy Green <[email-masked]>
Date: Wed, 16 Mar 2011 06:41:54 +0000

On 03/15/2011 11:27 PM, Somebody in the thread at some point said:

 >> protocols - so unless anybody speaks up soon,

> I think this is a good idea. W3C has test suites for the APIs, but
> there is no equivalent for the protocol side at the IETF. This could
> be a way to incorporate some standard tests.

Yeah I don't think it's a bad idea either.  I will adapt the 
libwebsockets test server and fraggle when I get an evening free.

-Andy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 16 Mar 2011 10:31:02 +0900

I agree with Gabriel. I think common subprotocols and common frameworks 
and patterns is something that will draw attention in the websockets 
area soon. I think using the org.ietf.websocket label may be slightly 
premature, but as you have already used it, it's probably more confusing 
to change it, and then again change it back. I also think that writing 
an Internet Draft about the test protocols would be a good idea. This 
can be an individual draft and later be adopted by the WG (if we think 
we have the protocol itself sufficiently nailed down). Unfortunately, 
you have to wait two weeks for the submission to open again.

Regards,    Martin.

On 2011/03/16 8:27, Gabriel Montenegro wrote:
>> On 15 March 2011 00:40, Greg Wilkins<[email-masked]>  wrote:

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 17 Mar 2011 09:09:21 +1100

Martin,

OK, I'll put my hand up to write a draft describing these test
protocols.  Probably take me a week to find the time.

cheers

On 16 March 2011 12:31, "Martin J. Dürst" <[email-masked]> wrote:
> I agree with Gabriel. I think common subprotocols and common frameworks and
> patterns is something that will draw attention in the websockets area soon.
> I think using the org.ietf.websocket label may be slightly premature, but as
> you have already used it, it's probably more confusing to change it, and
> then again change it back. I also think that writing an Internet Draft about
> the test protocols would be a good idea. This can be an individual draft and
> later be adopted by the WG (if we think we have the protocol itself
> sufficiently nailed down). Unfortunately, you have to wait two weeks for the
> submission to open again.
>
> Regards,    Martin.
>
>> I think this is a good idea. W3C has test suites for the APIs, but there
>> is no equivalent for the protocol side at the IETF. This could be a way to
>> incorporate some standard tests.
>>
>>> protocols