• AVR Freaks

Hot!WINC1500 TCP Socket Bind & Close

Author
DougD
Senior Member
  • Total Posts : 110
  • Reward points : 0
  • Joined: 2012/12/24 10:12:06
  • Location: 0
  • Status: offline
2020/08/13 12:40:58 (permalink)
0

WINC1500 TCP Socket Bind & Close

I'm confused by the network socket 'Bind' and 'Close' operations, and was wondering if I could get some clarification on how to use them.
 
I implemented the Microchip MLA's TCP Server example on a WINC1500 Access Point (AP), and I already know my local host's IP and Port number to start AP mode.  Do I need to wait until a remote TCP Client connects before calling the 'Bind' function?  The MLA's TCP Server example waits until the client connects before doing the 'Bind', but I don't understand why.
 
I thought that the 'Bind' operation simply ties my AP's IP and TCP Server Port number together, to send them to a remote client that connects, so it'll know what IP and Port destination to send packets to.  I thought the host TCP Server's 'listen' socket was independent of the remote TCP Client's IP and Port number.
 
I'm also unclear about how to handle remote TCP Client socket disconnects, whether from a socket callback "receive" event indicating a negative message length, or from a wifi callback "M2M_WIFI_CONN_STATE_CHANGED_EVENT" event.  The MLA example code closes the remote TCP Client socket, but does _not_ close the local TCP Server socket.
 
I understand the problem with not closing TCP Client sockets--there are seven of them--and if you don't re-use them by closing them you'll eventually run out.  But is anything wrong with leaving the TCP Server's 'listen' socket open indefinitely?  If not, would I need to 'Bind' to it again, or could I just 'listen' and 'accept' any subsequent connections by the remote TCP Client?
 
post edited by DougD - 2020/08/13 13:48:14
#1

3 Replies Related Threads

    aschen0866
    Super Member
    • Total Posts : 4587
    • Reward points : 0
    • Joined: 2006/01/08 22:18:32
    • Location: San Diego
    • Status: offline
    Re: WINC1500 TCP Socket Bind & Close 2020/08/13 17:28:03 (permalink)
    5 (1)
    Check out Wi-Fi Network Controller Software Design Guide Section 6.3.2 TCP Server Operation
     
    DougD
    Do I need to wait until a remote TCP Client connects before calling the 'Bind' function?

    No. As a TCP server, your code needs to go through socket() -> bind() -> listen() -> server ready. An incoming connection will get a new socket if there is one available from the pool.
     
    DougD 
    I thought that the 'Bind' operation simply ties my AP's IP and TCP Server Port number together, to send them to a remote client that connects, so it'll know what IP and Port destination to send packets to. 

    bind() has nothing to do with a client connection. A client needs to know the IP and port number before connecting to the server.
     
    DougD 
    I'm also unclear about how to handle remote TCP Client socket disconnects, whether from a socket callback "receive" event indicating a negative message length, or from a wifi callback "M2M_WIFI_CONN_STATE_CHANGED_EVENT" event. 

    Don't confuse WiFi callback events with socket callback events. If WiFi is disconnected, you'll likely need to tear down all your TCP/UDP connections.
     
    DougD 
    But is anything wrong with leaving the TCP Server's 'listen' socket open indefinitely?  If not, would I need to 'Bind' to it again, or could I just 'listen' and 'accept' any subsequent connections by the remote TCP Client?
     

    No. There is nothing you can do to accept a connection. However, you can close it if you don't want to go any further. If a client disconnects properly, the socket gets released back to the pool. If a client simply drops dead, it will leave the TCP connection in the half-open state. It is your server's responsibility to time out and close an idle connection. Otherwise, you will run out of sockets.




    #2
    DougD
    Senior Member
    • Total Posts : 110
    • Reward points : 0
    • Joined: 2012/12/24 10:12:06
    • Location: 0
    • Status: offline
    Re: WINC1500 TCP Socket Bind & Close 2020/08/13 18:57:28 (permalink)
    0
    Hi, thanks for your reply.
     
    I wonder why the MLA's TCP Server example code waits for a wifi client to connect before doing the 'Bind'.  Maybe it was just personal preference.
     
    The code in the TCP Server Operation section you reference does close both sockets after finishing a session.  But the MLA's TCP Server example only closes one of them (the tcp_client_socket?) when it gets a receive error.  I don't see why I should need to close (and then re-open, bind, listen) my Access Point's 'listen' socket every time a remote client drops out or disconnects.
     
    In field testing, I've had intermittent dropouts of my wifi client due to a weak signal, but I don't know which callback is triggered--the socket "receive error" callback, or the wifi "connection state changed" callback.
    #3
    DougD
    Senior Member
    • Total Posts : 110
    • Reward points : 0
    • Joined: 2012/12/24 10:12:06
    • Location: 0
    • Status: offline
    Re: WINC1500 TCP Socket Bind & Close 2020/08/17 09:15:12 (permalink)
    0
    Well, it seems that it wasn't enough for me to simply close the tcp_client_socket and the tcp_server_socket when the client's wifi connection dropped out.  Sometimes I still couldn't re-connect, even after closing both sockets.
    What I ended up doing was to re-do the AP from scratch in the wifi_cb case "M2M_WIFI_CONN_STATE_CHANGED_EVENT:"
    ...
    m2m_wifi_disable_ap();
    SetAppState(APP_STATE_START);
     
    This seems to let me reconnect to the AP reliably after the wifi signal drops out, at least so far.
     
    #4
    Jump to:
    © 2020 APG vNext Commercial Version 4.5