This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Cannot find out when client disconnects



I am creating a server application where I am able to use the CC3000 to respond to requests from a client. I am able to connect to the CC3000 with the client and send and receive data no problem using the select() function and checking the writesds and readsds. However, when the client disconnects, the CC3000 has no idea and therefore never closes the socket.

I have tried using select() and checking the "exceptsds", but none of the bits are ever set.

I have tried sending select() and checking writesds, but it responds saying the socket is ready to receive data even after it has disconnected.

I have tried sending data of length "0", and of other various lengths, but the send() command always responds with a success, and and eventually the CC3000 buffers fill up (since the messages aren't going anywhere) and the program gets stuck.

I have tried sending the getsockopt() command also, but this command always returns a success.


What is the correct way to sense when a client has disconnected using the CC3000 module?

  • Hi,
     Im using recv() to receive data from client.. when client gets disconnected It returns -57 after  2 min.

    Then I added

    if (lEventType == HCI_EVNT_BSD_TCP_CLOSE_WAIT)
    {
    }

    in CC3000_UsynchCallback

    then recv  returns  -57 immediately after client gets disconnected.

    Hope it helps..

    Best wishes,

    Sooraj R K 

     

  • Hi Sooraj,

    can you give a bit more detail what your inserted code is doing?

    Adding just

    if (lEventType == HCI_EVNT_BSD_TCP_CLOSE_WAIT)
    {
    }

    does not do anything, is perhaps even optimized out by compiler. Do you perhaps add something between { ... } or do something in else branch?

    Best regards,

    Martin

  • Hi Martin,

     I have added just as in my previous reply,nothing more.When I debug, I find that when a client is disconnected, the  control does go inside the added condition in CC3000_UsynchCallback.I don't know how checking this asynchronous event changes the time to return ERROR_SOCKET_INACTIVE (-57). I hope someone has an explanation. Anyway it had solved my problem.

    Best Regards,

    Sooraj 

  • Hi All,

    As Sooraj answered, the correct way of handling a remote socket close is to wait and handle the HCI_EVNT_BSD_TCP_CLOSE_WAIT event.

    This event signals that the socket was closed by the other side. once you receive it you should perform a graceful close of the socket.
    Please note, that the socket may still have data sent for you before the remote side got disconnected, so it is recommended to check for data before closing the socket.

    There are numerous ways to implement an event handle, one possible way is to raise a "close_wait" global flag (per socket #) and check for it before issuing a command on the socket.

    Thanks,
    Alon.S

  • Hi Alon, I'm running into the same problem detecting closed connections (made a thread here before I saw this one, http://e2e.ti.com/support/low_power_rf/f/851/t/297316.aspx )  I don't follow how to detect the HCI_EVNT_BSD_TCP_CLOSE_WAIT event from the sockets API.  Can you give a concrete example of what APIs to call to detect a closed connection?

    Also should recv() return this -57 value after a few minutes on a closed socket?  Unfortunately I don't see that behavior occuring--I'm calling recv with a short timeout every 5 seconds on a socket and even after 5-10 minutes I'm still getting a value of zero back.

  • Hi Anthony Dicola,

      Give Patch sp version and host driver version no.

    Best Regards,
     Sooraj.

  • Actually, disregard the above question.  I found my issue with receiving the HCI_EVNT_BSD_TCP_CLOSE_WAIT event was really a problem with how I was using a library that handles CC3000 communication.  Once I fixed that problem I started detecting closed sockets.