Subject: [hybi] mux extension document?

From: Tobias Oberstein <[email-masked]>
Date: Wed, 10 Aug 2011 12:12:59 -0700

could s.o. give me a pointer where to find info on x-google-mux?

thanks

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 11 Aug 2011 09:55:39 +0900

On Thu, Aug 11, 2011 at 04:12, Tobias Oberstein <[email-masked]
> wrote:

>  could s.o. give me a pointer where to find info on x-google-mux?

Here
https://docs.google.com/a/google.com/document/d/14DYRxmRTPVhV1GbVXlxg8KVrS1SEq4UhCNq6q8iNOws/view

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 11 Aug 2011 06:03:07 -0700

here is some feedback ..

1) The use of opcode 7 is the only use of the WebSocket extension points, no reserved bits whatever,  right? 

2) AddChannel 1 is illegal, since logical channel 1 is identical to the data channel on the physical WebSockets connection?

3) Same with DropChannel .. or is that equivalent to Close on physical?

4) "If the extension is successfully negotiated during the handshake, all data frames MUST be sent using the MUX opcode (defined as 0x7)
-- except for frames on logical channel 1 before any AddChannel has been sent, in which case they may be sent normally on the physical channel."

I don't get it:

As long as a peer has not yet sent a AddChannel:

it MAY send data frames with opcode 1/2 which then are assigned to logical channel 1 and alternatively
it MAY send data frames with opcode 7 and mux_opcode 0, in which case those are also assigned to channel 1?

5)
"If the extension is successfully negotiated during the handshake, all data frames MUST be sent using the
MUX opcode (defined as 0x7)"

Does that mean that continuation frames are no longer allowed on the physical WS? No fragmented messages?

6)
"The payload data of a MUX frame is defined as 1 or more MUX blocks, each defined as below (note that MUX frames
may be fragmented across mutliple WebSocket frames)."

Shouldn't that read "The payload data of a MUX _message_ ... (not that MUX _messages_ .."

Or is "frame" in "MUX frame" something different from "frame" in the WS sense?

7) Is the following then a valid example?

On physical WS:

[opcode = 7, fin = 0, [++++++++++]][opcode = 0, fin = 0, [+++++]][ opcode = 0, fin = 1, [+++++++++++++]] = Fragmented Mux message

[++++++++++][+++++][+++++++++++++] = frames of Mux message payload on physical WS
[******][******][****************] = sequence of Mux blocks

8)
For MUX Opcode 0 (DATA):
"The remainder of this block is a complete WebSocket frame, which may itself be fragmented, multiplexed, masked, etc.
 The end of this mux block is determined by the length of the frame."

By "the length" of which frame?

The enclosing physical WS frame or the wrapped WS frame?

===

I'll stop here ... I got lost.

---

From: "Len Holgate" <[email-masked]>
Date: Tue, 30 Aug 2011 18:48:13 +0100

Tobias,

Thank you for providing such a useful test suite. It has complemented my own
unit testing of my implementation and has helped me nail a few bugs in my
code.

Everything passes, well, except that 9.4.1 and 9.5.1 seem to randomly fail
(with the Autobahn test server as well as my own server). My server seems to
think that your client test closes the connection cleanly on it (TCP recv
returns 0) part way through the test... This results in the 'default' error
which implies a timeout but I've tried increasing the timeout to 200 seconds
and it still fails after around 6 with the same issues; and sometimes it
works...

Results, if you're interested, here:
http://www.serverframework.com/ServerFramework/6.5/WebSockets/

Thanks again.

Len
http://www.lenholgate.com
http://www.serverframework.com

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 30 Aug 2011 11:16:48 -0700

Len,

> Thank you for providing such a useful test suite. It has complemented my
> own unit testing of my implementation and has helped me nail a few bugs in
> my code.

Thanks! Thats nice to hear.
 
> (with the Autobahn test server as well as my own server). My server seems
> to think that your client test closes the connection cleanly on it (TCP recv
> returns 0) part way through the test... This results in the 'default' error which
> implies a timeout but I've tried increasing the timeout to 200 seconds and it
> still fails after around 6 with the same issues; and sometimes it works...

Few comments .. don't know if it helps:

- those cases are really extreme (fragment size 64 with payload 8M, chopsize = 1 octet)
- did you run on loopback or remote? you could try different platform and/or loopback/remote ..
- don't know your Python background: when you change a CaseXX.py, you need to do
"python setup.py install" again to get that into site-packages. Also, try add a print timeout
somewhere to see if the change really happens, because it's strange that it doesnt obey
- you can reenable wirelog for those cases (and decrease the payload to something small;),
so you can see what happens on wire
- to really find out what happens, you'd probably needed to run the tests remote and
sniff the traffic (wireshark/tcpdump)

Lastly, your project is commercial, but you might nevertheless be interested in putting it
onto

http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations

I'll extend the test suite to cover UTF-8/Handshake (open/close) as soon as I find time
again .. should those issues persist for you, we can try to nail it down (then, because
for the moment, I'm a bit overwhelmed with other stuff)

Cheers,
Tobias

---

From: "Len Holgate" <[email-masked]>
Date: Tue, 30 Aug 2011 19:48:22 +0100

> payload 8M, chopsize = 1 octet)

Yes, I know. The issue doesn't seem to be on my side anymore, but it may
well be.

> platform and/or loopback/remote ..

So far it's all been on loopback. When I get a moment I may run it remotely
and grab the wireshark logs.

> "python setup.py install" again to get that into 
> site-packages. Also, try add a print timeout

I worked that out eventually. The timeout does seem to be changed as the
error then states the new timeout value. The actual test still terminates
after 6 secs or so though.

> payload to something small;),

I've enabled the wirelog, that didn't show much, except that the test thinks
it has sent everything and started the timeout and then that I close the
connection. 

At present, since it's the only failing test I'm not going to spend that
much time on it. 

Are any of the other tests multi-fragment with 1 byte chopsize? If not I'll
add one that's a bit more manageable and see if I can find out what's wrong
in my code.

> http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations

Ok, I wasn't sure if commercial stuff could be added. 

> for the moment, I'm a bit overwhelmed with other stuff)

I know the feeling. More tests would be good, but the test suite as it
stands has been very useful to me.

Len