Application Issues

Determine Received UDP Datagram's Interface 

If a UDP socket server is bound to the “any” address, then it is not currently possible to know which interface received the UDP datagram. This is a limitation in the BSD socket API. As a solution, the NetSock_CfgIF function has been implemented in the µC/TCP-IP socket API. With this function, it is possible to associate a socket to a specific interface so that all communications with this socket pass through the specified interface.

An other way to guarantee which interface a UDP packet was received on, is to bind the socket server to a specific interface address.

If no interface is linked to a socket (using NetSock_CfgIF) and if a UDP datagram is received on this listening socket bound to the “any” address and the application transmits a response back to the peer using the same socket, then the newly transmitted UDP datagram will be transmitted from the default interface. The default interface may or may not be the interface in which the UDP datagram originated.

Detecting if a Socket is Still Connected to a Peer 

Applications may call NetSock_IsConn() to determine if a socket is (still) connected to a remote socket (see function NetSock_IsConn()).

Alternatively, applications may make a non-blocking call to recv(), NetSock_RxData(), or NetSock_RxDataFrom() and inspect the return value. If data or a non-fatal, transitory error is returned, then the socket is still connected; otherwise, if ‘0’ or a fatal error is returned, then the socket is disconnected or closed.

Receiving -1 Instead of 0 When Calling recv() for a Closed Socket

When a remote peer closes a socket and the target application calls one of the receive socket functions, µC/TCP-IP will first report that the receive queue is empty and return a -1 for both BSD and µC/TCP-IP socket API functions. The next call to receive will indicate that the socket has been closed by the remote peer.

This is a known issue and will be corrected in subsequent versions of µC/TCP-IP.

The Application Receives Socket Errors Immediately After Reboot 

Immediately after a network interface is added, the physical layer device is reset and network interface and device initialization begins. However, it may take up to three seconds for the average Ethernet physical layer device to complete auto-negotiation. During this time, the socket layer will return NET_SOCK_ERR_LINK_DOWN for sockets that are bound to the interface in question. 

The application should attempt to retry the socket operation with a short delay between attempts until network link has been established.

Please refer to section Network Interface Link State for the detailed information on how to get the link state of an inteface.