Part Number: DK-TM4C129X
Tool/software: TI-RTOS
In my application I use fdPoll to track the status of a number of open sockets. After my application has sent a message back on a particular socket, the next time I try an fdPoll, I will see that there is data available for reading, but when I read the data, it returns a 0, and I get the error Connection Reset by peer. Which is fine, except the socket is still open on the host, and I am still able to read/write from it.
As a debugging function, I added in a pair of calls to fdStatus before the read is executed, to see what the condition of the stocket is. First, I'm calling wiith a request type of FDSTATUS_TYPE, which returns a status of 0, and the fact that it is an FDSTATUS_TYPE_SOCKET (as I expect, it is a data socket created by accept). Next, I called fdStatus with a request of FDSTATUS_RECV, and it return a status of 0, and a result of -1, showing that I have an error. These sockets are opened in non-blocking mode, but the host that is connected to the device has not closed the socket, which is the error that is being reported. I can send another message from my host, which is received, and a response returned, but again, every time, when the request has been cleared by a successful recv call, the fdPoll routine will still show POLLIN on the channel (even though I've read everything OK), and when recv() is called, again I will get a Connection Reset by peer error.
I'm at a loss as to how to account for this, or what to do about it, with the exception of just ignoring the call.
Any ideas?
