Ethernet Sheild and GSM router

I would use my code in your sketch. Where are you using your current code now?

Ok, i dont want to rewrite it all as its all in the above posts, my code is, the problem is and what libaray im using is.

As i said, if you read the early posts you will see that your code to use in my sketch is insignificant as im not trying to download bytes using my sketch aim tryign to make a connection to a pusher-app server or my custom websocket server using a GSM router. The code pylon was referring to was the websocket library code.

Andy

@SurferTim: He cannot take your code because the connection is not closed by the server after the reception of the handshake lines. It just reads the first few lines from the server and checks for the connection OK string, then returns a success flag.

@OP: The code I posted is a replacement for the appropriate code in the library, not for use in your sketch. The library is not prepared for a result not being delivered in one packet. The length of 14 is the length of the string the library is testing for plus carriage return and linefeed. If you get more characters: OK but you have to get at least this much to be able to successfully check for a proper connection initialization.

Cheers for the clearup pylon, i was aware you meant the library code and i have tried changing it but to still no avail.

Any other ideas? Im sure the response string is large than 14 bytes?

Thanks
Andy

@pylon: Thanks! I did not see the persistent connection part. I have used those quite successfully with a joystick control from my Linux box to the ethernet shield, but it was a custom server, and not http based. I used a "stop byte" value to insure I got the whole transmission.

@OP: My bad. Is this a http based server, or a custom server? If it is a persistent http server, you may need to parse the response header for "Content-Length: 14". It may not be the same every time.

But you can't even connect, so this part doesn't even matter until you can connect to the server.

Its using the WebSocket protocol and initally i had my own custom server setup running a nodejs websocket but now im using a pusher server (a ready made websocket server with better debugging utilities for testing). Then using this websocket library for arduino you can connect to the websocket server over http which then gets upgraded to a tcp connection. But the connection and handshaking is done over http by sending a receiving headers, but what pylon is saying is the retruned headers that complete the handshake are being split by the GSM router (in order to cope with the load) which the library isnt prepared for and therefore failes to complete a handshake, hence no connection.

Whilst im thinking pylon, could there also be a problem with the GSM splitting the handshake request headers to the server? Does the server need to be ready for split data or shouldnt this matter so much?

Thanks
Andy

@SurferTim: It's a WebSocket server, the connection is persistent. The problem is, that the connect method of his library returns also false if a connection has been established but the initial handshake was not what it expected. The way the library is programmed, it assumes that the whole answer from the server is transferred in one packet and does no additional checking on that assumption.

This is the log of a interactive session doing the same:

 telnet ws.pusherapp.com 80
Trying 50.17.194.145...
Connected to ws.pusherapp.com.
Escape character is '^]'.
GET /app/8bce0224d7dae3e8e75e?client=js&version=1.9.0 HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: ws.pusherapp.com
Origin: ArduinoWebSocketClient

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: ArduinoWebSocketClient
WebSocket-Location: ws://ws.pusherapp.com/app/8bce0224d7dae3e8e75e?client=js&version=1.9.0

{"event":"pusher:connection_established","data":"{\"socket_id\":\"13296.159584\"}"}

As you can see, there is no Content-Length header in the response but some JSON to parse. As the connect method just checks the first line till after the response code, I hacked the buffer length in. A correct parser would be the better solution but this needs a more in-depth knowledge of the protocol than I have.

Whilst im thinking pylon, could there also be a problem with the GSM splitting the handshake request headers to the server? Does the server need to be ready for split data or shouldnt this matter so much?

Usually a server should be prepared for that, the lower levels of the TCP stack does the re-arrangement and the application receives a stream of bytes. Arduino is also receiving a stream of bytes but the library is checking only for at least one byte available and then assumes that the whole response is received. This assumption is wrong, at least in the case of the GSM router as it seems.

Have you tried your sketch with my modification of the library code?

Just to update, i have tried your mod tothe library and also tried myself to increase the bytes available before continuing but still no luck.

Im confused as there is massive hype about websockets being the asnwer to the common problem of real-time apps and machine 2 browser communication, yet i cant find much at all regarding doing this using a GSM.

Im sure its down to the library which i have little knowledge about, ive tried contacting the creator who seems very active on his github but unfortunatly doesnt seem to want to respond.

If you have any other ideas i fully welcome them.

Thanks
Andy

Try inserting debugging output to the serial console. You (we) must get a feeling where it stops so we may find the problematic part and, eventually, even a fix for it. Insert a Serial.print() after almost every line in the WebSocketClient and PusherClient connect methods, put out every character you receive from the server (if any). Post the serial output you get.

Ive been tryingt o work out how i can do this...Can i put Serial.print in the library code?

Note: So you can :slight_smile: I really like arduino! Ok ill play now and see whats outgoing and incoming (or rather not doing!)

Thanks
Andy

Ok from quick tests, i printed each line sent to server and then i print each line that is returned:

My IP address: 192.168.2.98.
Connecting to server...
SENT
GET /app/8bce0224d7dae3e8e75e?client=js&version=1.9.0 HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: ws.pusherapp.com
Origin: ArduinoWebSocketClient
RECV
HTTP/1.1 502 Bad Gateway
Date: Wed, 10 Oct 2012 08:59:17 GMT
Content-Type: text/plain
Content-Length: 29

Very strange?

Thanks
Andy

Hmmh, looks like you had a transparent proxy in between (which wasn't really transparent though). Have you really checked the same telnet sequence as I did over the GSM router? If you haven't your GSM provider probably puts all request on a transparent proxy and that proxy is not able to handle WebSocket requests.

Ive not done the telnet ove the GSM, i have used the pusher API to create a connection using Javascript and run that in my laptop browser using the GSM as my internet connection and it connects fine?

Is that not the same?

Thanks
Andy

No, it don't have to be the same. Try the telnet session as I've posted earlier from your laptop, not using the browser but just the telnet command. I'd expect you to get the same output as with the Arduino but it's worth a try.

Could you quickly tell me how you did your telnet? If i try to telnet using the windows won either via command promt or telnet terminal and i try to connect to ws.pusherapp.com 80 i just get a flashing cursor? (i assumed connected) how do you do the websocket upgrade handshake?

Thanks
Andy

On the first line of my log is the telnet command. I did it on my linux box but on the windows command line you should be able to enter the same command in this order. On Windows 7 machines you may have to install the telnet command first (was a post in this forum, i don't have Windows).

Then all the lines up to and including the first blank line are stuff I entered, the rest is the output from the server. If you enter these lines you do the upgrade to the websocket.

Managed to get the telnet to work (in passive mode), outputs the exact 501 response as the arduino! :frowning:

I guess "thats it" then?

Unless you have some more excellent ideas? :slight_smile:

Thanks for you help btw, much appriciated.

Andy

Do you have the possibility to change the GSM provider? Maybe you can call their service center and they disable the proxy for your account? What country are you in? What provider do you use?

Hmm unfortunatly it defeats the object of what im trying to achive, i think ill go down a different route but it serves for a new thread.

Thank you again, much appriciated.

Andy