[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Router issues with lwip

From: K.J. Mansley
Subject: Re: [lwip-users] Router issues with lwip
Date: 25 Jun 2004 15:24:05 +0100

On Wed, 2004-06-23 at 10:41, Martin Glunz wrote:
> Yes indeed, I'm using the sockets api to send the data and there seems
> no way the get the EOF via the send() call. The application never calls
> recv() as no data shall be received. Getting the EOF should be easier
> using the event based api, but I absolutely do not want to restructure
> the application.

OK, I've had a look to see what the standard means of informing a
process that is only using send()/write()/etc that a FIN/RST has been
received is:

The receipt of the FIN by the sending process only indicates that the
remote process will not be sending any more data. [in this case it
wasn't sending anything anyway!]  It is valid to continue to write to
the socket.  The receipt of a RST by the sending process indicates that
the remote process has terminated.

When a process writes to a socket that has received a RST, the SIGPIPE
signal should be sent to the process.  The default action of this signal
is to terminate the process.  If the process either catches the signal
and returns from the signal handler, or ignores the signal, the write
operation returns EPIPE.

So, there does appear to be some incorrect behaviour from the
non-lwip-PC with a RST being sent when a process has closed a connection
(rather than the process having terminated) - unless I've misunderstood
the example anyway.  Regardless of that though the solution to
preventing the lwip (sending) application from hanging is for us to send
SIGPIPE and return EPIPE in this eventuality.  I'll file a bug report to
this effect, and if there are any volunteers to do something about it,
that would be great!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]