Control chop Size in Java

#1

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

0 Likes

#2

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

···

Am 27.05.2012 08:57, schrieb robkoch86:

Best wishes
Robert

0 Likes

#3

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

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

···

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

0 Likes

#4

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

> 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.

···

On May 28, 8:14 am, robkoch86 <rober...@loggia.at> wrote:

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

Best wishes,
Robert

0 Likes

#5

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

···

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.

0 Likes