<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div dir="auto">
<div dir="auto">Hi Daniel,</div>
<div dir="auto"><br>
</div>
<div dir="auto">thanks for replying!</div>
<div dir="auto"><br>
</div>
<div dir="auto">IMO, that reading of network byte order is a
common misconception. The rfc for IP/UDP/TCP defined that the
fields of the IP headers would be encoded in big endian, which
was a very common native byte order at the time. Afaik, there
has never been any kind of standard defining that network
protocols should be big endian - that is just an interpretation
of the term "network byte order".</div>
<div dir="auto"><br>
</div>
<div dir="auto">Any application layer protocol in the ISO/OSI
stack can define byte orders as the author likes. And in times
where likely >95% of all compute resources natively speak
little endian, the sensible choice is pretty obvious in my view.</div>
<div dir="auto"><br>
</div>
<div dir="auto">But back to the actual problem here: Websockets,
as any layered network protocol, need to be transparent. I
transfer a binary message (which is a byte blob, in case of the
WebSocket API its a ByteBuffer) to the websocket layer, which
uses the WS protocol on top of TCP on top of IP on top of
ethernet/wifi/5G/whatever to transport it to the reciever. And
on the other and, another websocket layer removes all the things
around and again just delivers a byte blob to the application.
That final byte blob must have the exact same content as the
original one, or the protocol is unusable. And this expectation
is what the bug violates. The byte order of the source buffer is
just a hint for extracting multi-byte values from it. It cannot
influence the byte blob recieved by the communication partner.</div>
<div dir="auto"><br>
</div>
<div dir="auto">It is very likely that very few people have
stumbled upon that problem, because (for historic reasons, but
unreasonably so) you have to actually work hard in Java in order
to work with little endian ByteBuffers (although the JVM
internally works with native byte order, which again is 95%
little endian). But to be frank: if any developer has ever built
a system based on the Java Websocket API, using little endian
ByteBuffers in the client and hacking the server in order to
work with the unintentional re-ordering of bytes at the API
boundary (which is actually hard, because that has to be applied
selectively, when fragmentation and alignments come into play),
they surely deserve the pain of a malfunctioning system when
some undocumented misbehaviour present since Java 11 is fixed...</div>
<div dir="auto"><br>
</div>
<div dir="auto">Ok, rant over, sorry :-)</div>
<div dir="auto"><br>
</div>
<div dir="auto">have a good evening</div>
<div dir="auto">Simon Fischer<br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div id="aqm-signature" dir="auto" style="color: black;">
<div dir="auto"><span style="color: #b3b3b3;"><br>
</span></div>
<div dir="auto"><u><span style="color: #b3b3b3;">
</span></u></div>
<div dir="auto"><u><span style="color: #b3b3b3;"><br>
</span></u></div>
<div dir="auto"><span style="color: #b3b3b3;">Simon Fischer</span></div>
<div dir="auto"><span style="color: #b3b3b3;"><br>
</span></div>
<div dir="auto"><span style="color: #b3b3b3;">Developer - CoDaC</span></div>
<div dir="auto"><span style="color: #b3b3b3;">Department
Operation</span></div>
<div dir="auto"><span style="color: #b3b3b3;"><br>
</span></div>
<div dir="auto"><span style="color: #b3b3b3;"><br>
</span></div>
<div dir="auto"><span style="color: #b3b3b3;">Max Planck
Institute for Plasmaphysics</span></div>
<div dir="auto"><span style="color: #b3b3b3;">Wendelsteinstrasse
1</span></div>
<div dir="auto"><span style="color: #b3b3b3;">17491 Greifswald,
Germany</span></div>
<div dir="auto"><span style="color: #b3b3b3;"><br>
</span></div>
<div dir="auto"><span style="color: #b3b3b3;"><br>
</span></div>
<div dir="auto"><span style="color: #b3b3b3;">Phone: +49(0)3834
88 1215</span></div>
<div dir="auto"><br>
</div>
</div>
<div dir="auto"><br>
</div>
<div id="aqm-original" style="color: black;">
<div dir="auto">On March 5, 2025 19:50:33 Daniel Fuchs
<a class="moz-txt-link-rfc2396E" href="mailto:daniel.fuchs@oracle.com"><daniel.fuchs@oracle.com></a> wrote:</div>
<div><br>
</div>
<blockquote type="cite" class="gmail_quote"
style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;">
<div dir="auto">Hi Simon,</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thank you for the report.</div>
<div dir="auto"><br>
</div>
<div dir="auto">I am not too familiar with WebSocket. But
since this is</div>
<div dir="auto">a networking protocol I would expect binary
data to be</div>
<div dir="auto">transferred on the wire in network byte order.</div>
<div dir="auto"><br>
</div>
<div dir="auto">So the expectation from WebSocket::sendBinary
that the</div>
<div dir="auto">byte buffer is in network byte order (big
endian) does</div>
<div dir="auto">not seem unrealistic to me.</div>
<div dir="auto"><br>
</div>
<div dir="auto">More concretely, since the API is there since
java 11</div>
<div dir="auto">(at least in its standard form), it would be
difficult</div>
<div dir="auto">to change this long standing behavior.</div>
<div dir="auto"><br>
</div>
<div dir="auto">That said - a deeper analysis of the issue and
possible</div>
<div dir="auto">options is probably warranted. At least the
expectations</div>
<div dir="auto">should be documented.</div>
<div dir="auto"><br>
</div>
<div dir="auto">best regards,</div>
<div dir="auto"><br>
</div>
<div dir="auto">-- daniel</div>
<div dir="auto"><br>
</div>
<div dir="auto">On 05/03/2025 17:53, Fischer, Simon wrote:</div>
<blockquote type="cite" class="gmail_quote"
style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;">
<div dir="auto">Hi all,</div>
<div dir="auto"><br>
</div>
<div dir="auto">no idea if I am in the right place here, but
I have no account to create </div>
<div dir="auto">a tracker issue and also could not find out
how to get one…</div>
<div dir="auto"><br>
</div>
<div dir="auto">I was just using the java.net.html.WebSocket
(jdk17 specifically, but </div>
<div dir="auto">the issue should still be there at least in
21 from a quick look into </div>
<div dir="auto">the code) for testing purposes and stumbled
upon what I think is a bug:</div>
<div dir="auto"><br>
</div>
<div dir="auto">When I supply a _/little endian/_ ByteBuffer
to WebSocket.sendBinary, </div>
<div dir="auto">the payload will be scrambled on the way to
the server.</div>
<div dir="auto"><br>
</div>
<div dir="auto">The actual issue is in
jdk.internal.net.http.websocket.Frame. The </div>
<div dir="auto">loop()-portion of the transferMasking
algorithm uses </div>
<div dir="auto">ByteBuffer.putLong(ByteBuffer.getLong)
(“dst.putLong(j, src.getLong(i) ^ </div>
<div dir="auto">maskLong);”) to try to optimize the masking
and data transfer. Problem </div>
<div dir="auto">is that src is a ByteBuffer provided by the
user, with the endianness </div>
<div dir="auto">set by the user, while dst is an internally
allocated ByteBuffer with </div>
<div dir="auto">the default byte order. This obviously can
lead to 8-byte-blocks of the </div>
<div dir="auto">original message being re-ordered on the way
to the client.</div>
<div dir="auto"><br>
</div>
<div dir="auto">The solution IMO would be to ensure that
both buffers are set to the </div>
<div dir="auto">same endianness. And it should probably be
_/native endian/_, as the use </div>
<div dir="auto">of a specific endianness would likely render
the </div>
<div dir="auto">long-vectorization/optimization useless on a
machine which does not </div>
<div dir="auto">support that endianness natively (getLong
would reverse the byte order </div>
<div dir="auto">when loading into native CPU register and
putLong would reorder again). </div>
<div dir="auto">In that case, actually any case, care must
also be taken with regard to </div>
<div dir="auto">the right encoding of the “maskLong” 64bit
integer.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Alternatively, one could just adopt the
documentation to require the </div>
<div dir="auto">ByteBuffer provided to
WebSocket.sendBinary() to be default(/big)-endian </div>
<div dir="auto">encoded. Semi-solution IMO.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Would be interested in feedback and hope
this finds somebody who can </div>
<div dir="auto">make use of it J</div>
<div dir="auto"><br>
</div>
<div dir="auto">Best regards</div>
<div dir="auto"><br>
</div>
<div dir="auto">Simon Fischer</div>
<div dir="auto"><br>
</div>
<div dir="auto">-- </div>
<div dir="auto"><br>
</div>
<div dir="auto">Simon Fischer</div>
<div dir="auto"><br>
</div>
<div dir="auto">Developer</div>
<div dir="auto"><br>
</div>
<div dir="auto">E5-CoDaC</div>
<div dir="auto"><br>
</div>
<div dir="auto">Max Planck Institut for Plasmaphysics</div>
<div dir="auto"><br>
</div>
<div dir="auto">Wendelsteinstrasse 1</div>
<div dir="auto"><br>
</div>
<div dir="auto">17491 Greifswald, Germany</div>
<div dir="auto"><br>
</div>
<div dir="auto">Phone: +49(0)3834 88 1215</div>
<div dir="auto"><br>
</div>
</blockquote>
</blockquote>
</div>
<div dir="auto"><br>
</div>
</div>
</body>
</html>