Ok, but im not sure if the code you posted was a modification to the "websocket library" code or for use in the arduino IDE, if its for arduino IDE then its pointless as i cant event connect to the server, as ive stated in my above posts.

when i plug the arduino into the GSM router that has a internet connect i cannot connect to the server, yet plugging the arduino into a normal intenet router (home internet) it connects fine.

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.

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

@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?

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

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.

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.

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.

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.