Issue in Netty when communicating with Java Client

[GoogleCodeExporter]

During a test suite we noticed that we "sometimes" cannot connect our Java 
Client with the Netty engine. With the TCP Engine the problem does not appear. 
The Java Client (i.e. the Swing GUI) often responds "Not a WebSocket Server" 
which let's us suspect that we have an issue in the handshake. We probably need 
to check the websocket handshake class processing especially for Netty here.

Original issue reported on code.google.com by fivefeetfurther@gmail.com on 9 Aug 2010 at 2:26

[GoogleCodeExporter]

looks like there's some problem with the way handshaking response is sent by 
the NettyEngine handler but i noticed it only happens with java client so might 
have to check if the java client is generating handshaking request very 
specific to TCP engine.

Original comment by mailtopu...@gmail.com on 29 Aug 2010 at 7:55

[GoogleCodeExporter]

Set this to high prio, needs to be fixed because users want to benefit from NIO.

Original comment by fivefeetfurther@gmail.com on 9 Sep 2010 at 1:26

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by fivefeetfurther@gmail.com on 14 Oct 2010 at 2:28

• Added labels: Milestone-v0.11

[GoogleCodeExporter]

This still can easily be reproduced: Connecting with Java Client the Java 
Client sometimes mentiones "not a WebSocket Server". To repro start the server 
using netty engine, and use the Java client (admin UI), and click connect.
Sometimes it works, sometomes not. Works perfectly with TCPEngine.

Original comment by fivefeetfurther@gmail.com on 15 Oct 2010 at 4:14

[GoogleCodeExporter]

Additional finding here: Only when the abovementioned error occurs...
When successfully connected and a shutdown command is sent apparently some 
threads keep running, so that the application does not shutdown properly
To repro start the server using netty engine, and use the Java client (admin 
UI) - or corresponding "shutdown" command from browser client - and the server 
won't terminate. You have to kill the process then!
This only happens when a previous connection was not successful, so here 
obviously something "remains" in the system. Please clean-up.

Original comment by fivefeetfurther@gmail.com on 15 Oct 2010 at 4:28

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

The "not a WebSocket Server" exception is thrown by 
WebSocketHandshake.verifyServerResponse(byte[] bytes). This method verifies the 
response hash of the server. I couldn't figure out how the Netty engine works, 
but I think there is a failure both in the Java client and the Netty engine.

Sec-WebSocket-Key1 and -2 have to contain between 1 and 12 white spaces. These 
spaces have to be inserted at a random position _other than the start or end_ 
of the string (step 23 of creating the client handshake). In 
WebSocketHandshake.insertSpaces(...) is the first error:
int split = rand(0, key.length());
has to be changed to
int split = rand(1, key.length()-1);

If there are any spaces at the end of the key, the Netty engine seems to trim 
them off and thus computes the wrong response which causes the exception. The 
specification says that the header field values are between ": " and CRLF (step 
5 of reading client's handshake). Therefore the server should actually work 
without any problems despite of the failure in the client.

Original comment by roderick...@gmail.com on 23 Oct 2010 at 7:26

[GoogleCodeExporter]

First off, thanks a lot to Roderik, you isolated the issue we experienced for 
months now :-) Great Work!
Especially since Netty will allow us to go beyond the thread limits (thanks 
also to Puran here!) of the TCPEngine and hence is supposed to allow a lot more 
concurrent connections, I feel very happy particularly about this fix! Of 
course, I immediately applied it to the code and checked-it out: it works 
perfectly!
To complete it I had to update the NettyEngineHandler which only accepted 
"Sec-WebSocket-Protocol", now it also accepts "WebSocket-Protocol" (w/o "Sec-" 
prefix) which is still used by the latest FlashBridge from Hiroshi Ichikawa 
(gimite).

Original comment by fivefeetfurther@gmail.com on 25 Oct 2010 at 2:49

• Changed state: Started

[GoogleCodeExporter]

Just ran into this issue as well and finally tracked it down to the 
WebSocketHandshake.inserSpaces() problem roderick describes above.

Love your client so far, but it is unusable for us when we try to connect to a 
Jetty server. Looking forward to this fix. :-)

Original comment by ben.plow...@gmail.com on 11 Jan 2011 at 11:14

[GoogleCodeExporter]

Dont know if its right here:
Netty doe not work for me, too: Against 1.0b1

I am working with a TokenPlugin/HTML javascript client, which worked great with 
0.1 and Netty. Now the last response I can give u for now is:

2011-10-24 18:06:43,401 DEBUG - NettyEngineHandler: message received in the 
engine handler
2011-10-24 18:06:43,405 DEBUG - NettyEngineHandler: Channel is 
disconnected:value

I will try to find out more, but hope you can find it faster :)

Original comment by strongAR...@googlemail.com on 24 Oct 2011 at 4:08