Client.connected() Never Goes False?

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!

Issue noted and added to the backlog for fixes to the TCP library. thanks guys!

1 Like

Guys, we have now fixed the TCPClient::connected() implementation .
Please try the latest master commits in core-firmware repo. Thanks.

2 Likes

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

// TCP CLIENT EXAMPLE  
  if (client.connect(hostname, 80)) {
    client.print("GET ");
    client.print(path);
    client.print(" HTTP/1.1\r\n");
    client.print("HOST: ");
    client.print(hostname);
    client.print("\r\nConnection: close\n\r\n");
  } else {
    Serial.println("\r\n\r\nConnection Failed!");
    client.flush();
    client.stop();
  }

  while(client.connected()) {
    Serial.println("STILL CONNECTED..");
    while (client.available() > 0) {
      char c = client.read();
      Serial.print(c);
      if (c == -1) {
        Serial.println("\r\n\r\nc == -1\r\n");
        client.flush();
        client.stop();
      }
    }
  }
  Serial.println("NOT CONNECTED..");
  client.flush();
  client.stop();
  Serial.println("DONE! FLUSH/STOP.");

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.

@B​Dub 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

/C/Spark/core-firmware (master)
$ git log
commit b20fecd29e21164381d35f7f867329ecbc72d606
Author: Satish Nair <satishgn77@gmail.com>
Date:   Fri Feb 7 21:34:05 2014 +0530

    Latest binaries following TCPClient's updated code

commit 8d7dca256f9df82efee017d4f9eee7c928ec909e
Author: Satish Nair <satishgn77@gmail.com>
Date:   Fri Feb 7 21:32:31 2014 +0530

    Updated implementation of TCPClient's available() and read() methods

commit 99143ef27c4ac053787cd34ab101171ebf441c59
Author: Satish Nair <satishgn77@gmail.com>
Date:   Fri Feb 7 21:25:56 2014 +0530

    MAX_SOCK_NUM increased from 4 to 8

commit b9121a45e9a5893b7cc61dcde37402a319a9b8f1
Author: Satish Nair <satishgn77@gmail.com>
Date:   Fri Feb 7 18:06:52 2014 +0530

    Updated binaries after bug fixes

commit ab42a580b79321756b1392d18c85846481df00ec
Author: Satish Nair <satishgn77@gmail.com>
Date:   Fri Feb 7 18:01:44 2014 +0530

    Bug fix: Completed TCPClient::connected() implementation

commit 804d9d8bce87296ca25cab52f3f84a60d552a308
Author: Satish Nair <satishgn77@gmail.com>
Date:   Fri Feb 7 17:57:47 2014 +0530

    Keep track of wlan_sockets[] using HCI_EVNT_BSD_TCP_CLOSE_WAIT event

commit d3d2f61df82aab744e82f7b97abb3bc8e7917835
Author: Satish Nair <satishgn77@gmail.com>
Date:   Thu Feb 6 20:27:24 2014 +0530

    Latest build binaries following recent bug fixes

commit 26c6b53fad39e3fb5a51c781bb1f945681fe499b
Author: Satish Nair <satishgn77@gmail.com>
Date:   Thu Feb 6 20:21:26 2014 +0530

    Core resets after getting stuck in CC3000 blocking calls (pull common libs)

commit 0cd736d21c789524d86601779589693b3debe939
Author: Satish Nair <satishgn77@gmail.com>
Date:   Thu Feb 6 18:15:26 2014 +0530

    Bug fix: Updated TCPServer implementation

Ok. The latest master tip should be. Please try pulling again.

commit 99143ef27c4ac053787cd34ab101171ebf441c59
"MAX_SOCK_NUM increased from 4 to 8"

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

@BDub try git reset --hard origin/master

1 Like

That worked, thanks!