I noticed that client.connected() never seems to return false, even after I’ve emptied the buffer.
Here’s a simple test case:
void loop()
{
if (client.available()) {
c = client.read();
Serial1.print(c);
delay(50);
}
if (!client.connected()) {
client.stop();
digitalWrite(D7, HIGH);
for(;;);
}
}
All characters are printed to the LCD, so I know client.read() doesn’t have any data left. However, the LED on D7 never lights up. I know the LED itself is working in the script, because I’m calling it in setup() as an OUTPUT then toggling it from HIGH to LOW before proceeding to the main loop().
I thought I’d seen mention of trouble with this elsewhere, but I couldn’t find a thread on it. Anyone else seeing this?
Currently it doesn’t look like the sockets will close automatically… so the only way .connected() is going to be false is if you .stop() first. I think they are working on filling out the TCP library a little more.
void TCPClient::stop()
{
if (closesocket(_sock) == 0)
{
_sock = MAX_SOCK_NUM;
}
}
uint8_t TCPClient::connected()
{
if (_sock == MAX_SOCK_NUM)
{
return 0;
}
//To Do
return 1;
}
Okay, that’s what I thought, but I just wanted to confirm. There’s been so many threads (a lot of them repeats) on TCP problems, that it’s hard to keep up. I’m even passing Connection: close as a header when doing the initial HTTP call, so I know it’s closing on the remote size. Hopefully they fix this up in the next push!
@satishgn the update works great, but I had to play with things in my code for a while to make it work because even though I received all of my data and available() == 0, connected() was still coming back true after I get all of my data. It’s very important to use “Connection: close” … read on for exact examples.
Very important, if you don’t send the “Connection: close” with the right number of \n and \r the server will not close the connection after sending all of the data. Your output will then hang like this:
HANGING OUTPUT:
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: private, no-cache, no-store, must-revalidate
Content-Type: application/json; charset=UTF-8
ETag: "3b748a4834d1a98396710d2fc519192e2a2f0b65"
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Pragma: no-cache
X-FB-Rev: 1113726
X-FB-Debug: PnXtOCMVhPc5t/aHZjBBBWkuTKmR0n1LkKDIImYRQwM=
Date: Fri, 07 Feb 2014 17:42:11 GMT
Transfer-Encoding: chunked
3F4
{ my data }
0
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
But if you do include the “Connection: close\n\r\n” it will work beautifully:
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
STILL CONNECTED..
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: private, no-cache, no-store, must-revalidate
Content-Type: application/json; charset=UTF-8
ETag: "3b748a4834d1a98396710d2fc519192e2a2f0b65"
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Pragma: no-cache
X-FB-Rev: 1113726
X-FB-Debug: OywoYB01ClQRWwgIbdm/jLEMJKyOUzKDztc/Jlqw+tQ=
Date: Fri, 07 Feb 2014 18:20:46 GMT
Transfer-Encoding: chunked
3F4
{ my data }
0
NOT CONNECTED..
DONE FLUSH/STOP.
@BDub what was the last pulled commit # when you tested this?
I had to revert back some code related to TCPClient() recently because of some blocking issues in the code though I literally did a reset --hard, a mistake from my part.
the latest stable commit should point to this as of today : https://github.com/spark/core-firmware/commit/99143ef27c4ac053787cd34ab101171ebf441c59
@satishgn Hmm, not sure what command reverts it back… “git reset --hard” seems like a desperate way to do it. git pull and git pull origin and git pull origin master all say everything is current.
EDIT: ok even tried git reset --hard master and it still points to “Latest binaries following TCPClient’s updated code”