Control chop Size in Java

[robkoch86]

Hello,

I'm working on a Java-based WebSockets-proxy and started to use the Autobahn test suite to ensure that all frames are processed correctly and not modified. I love Autobahn as it is so comprehensive - great work!

Unfortunately I got stuck with some test cases. Specifically I have problems with 1.1.8. Basically I fail to pass test cases where the chop size (= payload size of one TCP packet) is checked. How can I ensure the retransmission with the same chop size?

• How can I retrieve the chop size in Java (when working with Sockets)? I mean, I'm operating on an input stream that is not packet-aware.
• How can I set the chop size (i.e.: finish the TCP packet)? Once I retrieved the chop size, does flush() suffice to start a new TCP packet?

I searched the web, but was not able to find something appropriate. I hope that there is someone out, that used Autobahn with Java or is experienced with networking in Java and can guide me into the right direction.

If it won't be possible, is it really necessary for a WebSockets implementation (with regards to the standard - RFC6455) to adhere to this chop-size?

Best wishes
Robert

[Tobias Oberstein]

Am 27.05.2012 08:57, schrieb robkoch86:
> Hello,
>
> I'm working on a Java-based WebSockets-proxy and started to use the
> Autobahn test suite to ensure that all frames are processed correctly
> and not modified. I love Autobahn as it is so comprehensive - great work!

Thanks! Good to get positive feedback ..

>
> Unfortunately I got stuck with some test cases. Specifically I have
> problems with 1.1.8. Basically I fail to pass test cases where the chop
> size (= payload size of one TCP packet) is checked. How can I ensure the
> retransmission with the same chop size?

The "chopped tests" test whether an implementation is agnostic to how
the TCP stream is split up into TCP segments and IP packets ..

>
> * How can I retrieve the chop size in Java (when working with

> Sockets)? I mean, I'm operating on an input stream that is not
> packet-aware.

> * How can I set the chop size (i.e.: finish the TCP packet)? Once I

> retrieved the chop size, does flush() suffice to start a new TCP packet?
>
> I searched the web, but was not able to find something appropriate. I
> hope that there is someone out, that used Autobahn with Java or is
> experienced with networking in Java and can guide me into the right
> direction.

The packetizing of a TCP stream into TCP segments and IP packets is done
and under the control of the TCP stack within the OS kernel. There is no
(easy) way of fully/exactly controlling this process, only heuristics.
Like pushing 1 byte to the stream, then syncing/flushing, and waiting
for some time, so that the chance of having that 1 byte sent out in a
separate segment / IP packet is quite high.

>
> If it won't be possible, is it really necessary for a WebSockets
> implementation (with regards to the standard - RFC6455) to adhere to
> this chop-size?

An implementation failing 1.1.8 isn't "TCP-clean", and this is a severe
problem of the implementation that really needs to be fixed. You won't
find any mentioning of "TCP-clean" in RFC6455, since it's just assumed
that a WS impl. is able to cope with any possible packetizing of a TCP
stream.

Hope this helps,
Tobias

>
> Best wishes
> Robert

[robkoch86]

Thank you Tobias for your answers! Now I have got a few more.

On Sunday, May 27, 2012 11:09:58 AM UTC+2, Tobias Oberstein wrote:

The packetizing of a TCP stream into TCP segments and IP packets is done
and under the control of the TCP stack within the OS kernel. There is no
(easy) way of fully/exactly controlling this process, only heuristics.
Like pushing 1 byte to the stream, then syncing/flushing, and waiting
for some time, so that the chance of having that 1 byte sent out in a
separate segment / IP packet is quite high.

 So controlling the outgoing channel is possible in a fuzzy-way, but how can I determine the chop size used on the incoming channel? I mean, how can I retrieve the packet size when operating on a continuous input stream.

An implementation failing 1.1.8 isn't "TCP-clean", and this is a severe
problem of the implementation that really needs to be fixed. You won't
find any mentioning of "TCP-clean" in RFC6455, since it's just assumed
that a WS impl. is able to cope with any possible packetizing of a TCP
stream.

The question is, how severe would be a network intermediary (proxy) that changes packet-frames associations? As you said, any WS implementation should work with any possible packetizing. So it might happen, that my proxy concatenates 6 chops together and outputs only 2 chops for one WS-frame.

Best wishes,
Robert

[Tobias Oberstein]

On May 28, 8:14 am, robkoch86 <robert.k...@loggia.at> wrote:
> Thank you Tobias for your answers! Now I have got a few more.
>
> On Sunday, May 27, 2012 11:09:58 AM UTC+2, Tobias Oberstein wrote:
> > The packetizing of a TCP stream into TCP segments and IP packets is done
> > and under the control of the TCP stack within the OS kernel. There is no
> > (easy) way of fully/exactly controlling this process, only heuristics.
> > Like pushing 1 byte to the stream, then syncing/flushing, and waiting
> > for some time, so that the chance of having that 1 byte sent out in a
> > separate segment / IP packet is quite high.
>
>  So controlling the outgoing channel is possible in a fuzzy-way, but how
> can I determine the chop size used on the incoming channel? I mean, how can
> I retrieve the packet size when operating on a continuous input stream.

You can only do that as part of low-level network sniffing like it's
done i.e. in tcpdump or Wireshark.

But why would you want to do that in the context of writing a
WebSocket implementation anyway?

>
> An implementation failing 1.1.8 isn't "TCP-clean", and this is a severe
>
> > problem of the implementation that really needs to be fixed. You won't
> > find any mentioning of "TCP-clean" in RFC6455, since it's just assumed
> > that a WS impl. is able to cope with any possible packetizing of a TCP
> > stream.
>
> The question is, how severe would be a network intermediary (proxy) that
> changes packet-frames associations? As you said, any WS implementation

Thats fine. Note that a WS intermediary is even allowed to change the
WS fragmentation of WS messages (as long as there is no WS extension
negotiated or the extensions negotiated and their specific
fragmentation rules (if any) are fully understood by the
intermediary.)

> should work with any possible packetizing. So it might happen, that my
> proxy concatenates 6 chops together and outputs only 2 chops for one
> WS-frame.

Also fine. Just make sure your proxy can consume any packetization or
in other words: make your implementation TCP clean .. not assume
anything about in which chops you receive octets.

>
> Best wishes,
> Robert

[robkoch86]

On Tuesday, May 29, 2012 1:08:05 PM UTC+2, Tobias Oberstein wrote:

Also fine. Just make sure your proxy can consume any packetization or
in other words: make your implementation TCP clean .. not assume
anything about in which chops you receive octets.

Ok, thank you very much - that is the point I was interested in. As a result the chopped tests are allowed to fail when my intermediary is turned on between the browser and the Autobahn test server.

Best wishes,
Robert