[ECOS] network problems

Jonathan Larmour jifl@eCosCentric.com
Mon Apr 14 14:40:00 GMT 2003

Roland Caßebohm wrote:
> On Montag, 14. April 2003 11:58, Nick Garnett wrote:
>>Andrew Lunn <andrew.lunn@ascom.ch> writes:
>>[ferror() on sockets]
>>>A socket is a stream, so this should work.
>>But only if you have used fdopen() to convert a file descriptor into a
>>stdio FILE object. That's relatively rare for sockets.
>>>Why should an operation been needed? When the socket is closed because
>>>of a timeout or the peer, i would expect the local end to be closed
>>>and -EPIPE or something similar set in the error indicator. I've not
>>>tried this, so i could be totally wrong.
>>There's no mechanism for signalling events in the TCP/IP stack back up
>>to the stdio library. The only way that you can see that something has
>>happened asynchronously is to call down into the stack and get a
>>error code back. If no such call has been made, the FILE stream will
>>be oblivious of any changes.
> What about SIGPIPE? But I think it is not implemented in the stacks.

Again, AFAIK that's only if you actually try and do something like write() 
to the socket. If you read from the socket, you won't get SIGPIPE until 
there's no buffered data left to read. At least that's the theory - if 
practice doesn't match that, that's a problem!

> But my problem seems to be more general, because the host which wants to
> close the connection, don't send any packet, although any FINISH packet
> to the board running eCos. So the TCP-stack of eCos can't notice that
> the host wants to close the connection.

It should definitely send a FIN, even if there's outstanding data in the 
send queue. That's what I've seen in the past with linux anyway.

eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

More information about the Ecos-discuss mailing list