This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: network problems


On Montag, 14. April 2003 11:58, Nick Garnett wrote:
> Andrew Lunn <andrew dot lunn at ascom dot 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.

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.

Roland

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]