nmkhoa / unitt

Automatically exported from code.google.com/p/unitt
0 stars 0 forks source link

Can't connect to ws://echo.websocket.org #13

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
I'm initializing the web socket this way:

mainURL = @"ws://echo.websocket.org";

ws = [[WebSocket10 webSocketWithURLString:mainURL delegate:self origin:nil 
protocols:nil tlsSettings:nil verifyHandshake:YES] retain];

Then I'm calling startMyWebSocket which calls open on the web socket (ws). 
Right after calling open I get a didReceiveError with a nil NSERROR*.

What is the expected output? What do you see instead?
I'm expecting to have the didOpen callback fired, instead the didReceiveError 
is called with a nil NSERROR*.

What version of the product are you using? On what operating system?
I'm writing an app for ipad 4.3 and i'm testing it with the ipad 4.3 simulator.

Please provide any additional information below.

I've tried all different web sockets implementations that come with the 
library, 00, 07, 08 and 10 and all have the same results.

I've tried connecting to a different websocket server and I managed to get the 
didOpen callback called but I never managed to receive any messages at all.

Original issue reported on code.google.com by rpadr...@gmail.com on 11 Sep 2011 at 3:17

GoogleCodeExporter commented 8 years ago
I forgot to say that I can connect successfully to ws://echo.websocket.org via 
telnet using the terminal app on osx.

Original comment by rpadr...@gmail.com on 11 Sep 2011 at 3:37

GoogleCodeExporter commented 8 years ago
If you are using the WebSocket10 class, you need to make sure you are 
connecting to a rev10 web socket server. The server used for 
ws://echo.websocket.org uses a much older, non-compatible, deprecated version 
of the specification. I know there is a Java server (Jetty v8 - 
http://www.eclipse.org/jetty/downloads.php) and a Node.js server (WebSocket 
Node - https://github.com/asutherland/WebSocket-Node) that support rev07. I 
don't know of any servers that have a working implementation of rev10. I do 
know that the ws://echo.websocket.org is woefully out of date. The server 
closes the socket when you try to connect using any of the more recent versions 
of the web socket specification. Are you having trouble connecting to a server 
that is running a more recent version of the specification?

Original comment by joshuadmorris@gmail.com on 11 Sep 2011 at 4:16

GoogleCodeExporter commented 8 years ago
Thanks for the quick reply.

I was trying to connect to ws://echo.websocket.org only for testing.

The server I want to connect to is ws://eu1.fhbox.net:8889, I have no idea what 
revision of the web sockets is the server running but I already asked the 
server developer and I'm waiting for his response.

Anyway, I sucessfully connected to ws://eu1.fhbox.net:8889 using rev08, I sent 
a message to the server but got no reply. Try connect to it using the 
http://websocket.org/echo.html client and send any message to the server, the 
server will reply to you but by using your library the didReceiveTextMessage ( 
or the binary version ) are never called.

Any help is appreciated, thanks.

Original comment by rpadr...@gmail.com on 11 Sep 2011 at 5:45

GoogleCodeExporter commented 8 years ago
It looks like its rev00. Try using rev00 and set "verifyHandshake" to NO. See 
if that works for you. The data framing changed after rev00 and its not 
backwards compatible. 

Original comment by joshuadmorris@gmail.com on 12 Sep 2011 at 4:52

GoogleCodeExporter commented 8 years ago
Seems to work quite well with rev00, thanks for suggesting this implementation.

I was told by the server developer that the server implements draft76 of the 
web sockets.

http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76

Which implementation best represents this revision ?

Thanks.

Original comment by rpadr...@gmail.com on 12 Sep 2011 at 9:07

GoogleCodeExporter commented 8 years ago
Rev-00 best represents that version, but the handshake security key code is 
commented out due to a bug. Therefore, you don't want to verify the handshake. 
It will still verify the normal protocol mechanics, just not the security keys.

Original comment by joshuadmorris@gmail.com on 12 Sep 2011 at 2:56