I have a problem with sockets:(Coldfire DilnetPC DNP5280)
I have a listen socket that can send data to a remote client. If a client connects, the server socket opens a file and sent its bytes to the socket so the remote client can process the bytes.
I noted that when i disrupt (eg 0.2sec ) the network connection the transfer does not resume. The same happens when using a slow connection.(e.g. with a gateway through internet)
The program seems to block on the send() function. The full sendbuffer seems to block the send() becorse the data can't be delivered but it should resume as ethernet communication proceeds.
I would expect get a return value of -1 when the network disruption takes too long (causing a sent timeout) but this is not the case.
When i do this experiment between two windows machines i don't get this problem. (transfer resumes a few moments i reconnect the network ) neither does it occur between 2 linux desktop machines.
Is there a problem with the TCPIP stack in ucLinux ? or with the low level network driver ?
If the Network connection is broken, neither of the sockets is informed that the connection is lost. Both think it's still working.
The one that some time later sends a packet does not receive an acknowledge packet from the addressees stack, so, after some 90 seconds it declares the connection broken and the application is informed. Still the other end thinks the connection is still working (though idle).
If (e.g.) the client application knows that the connection is broken, it might try a reconnect. If the cable is restored, the server will decline the connect, as it thinks there is still a working connection.
To improve this situation you need to implement a life check protocol lin the application or use the stack's "keep alive" feature.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.