[En-Nut-Discussion] Network Link state on at91_emac and others

[Thiago A. Corrêa]

On Mon, Sep 15, 2008 at 1:55 PM, Alain M. <alainm at pobox.com> wrote:
>
> Harald Kipp escreveu:
>> Ole Reinhardt wrote:
>  >
>>> - What should correctly happen if a link loss is detected? From my
>>>   understanding, this should be communicated up to the socket layer to
>>>   abort the currently opened sockets and set the socket error
>>>   appropriate, right?
>>
>> Not really. It's an essential feature of TCP/IP to keep the connection
>> established even during link loss. An optional "keepalive" extension can
>> be used to detect this situation. But this is optional and not yet
>> implemented in our stack.
>>
>> There are different views on this topic, because the initial intention
>> of TCP/IP is sometimes not practicable in real world applications.
>
> I agree, in general every effort should be taken to reestablish the
> connection. Sometimes not even a timeout is desirable. I have already
> implemented such behaviour in the past with success...

Well, I agree to some extent. Perhaps a cable disconnect should
trigger the timeout counter and droping the sockets when it reaches
zero is the safest thing to do. On the other hand if cable is
reinserted before that, then do nothing.

Consider that on a connection, the PC sends data soon after the cable
is disconnected on the nut box. The PC will eventually timeout and
drop the connection, and when the cable is reinserted to the nut box,
it will not see any of the transmission attempts form the PC and might
be stuck in the NutTcpReceive beliving the connection is still open.
In this state the PC box can't even reestablish the connection if the
nut application isn't threaded in a maner similar to the HTTP example.
If done multiple times, the socket descriptors will also run out even
on the HTTP example and we will end up with an unresponsive nut box
until NutTcpReceive times out, if it has any timeout.


>> Fully agree. I started on this some time ago without any final result.
>> IMHO, the following should be done first:
>>
>> 1. Implement functions for starting or shut down an interface.
>>
>> 2. Implementing an _ioctl() function in Ethernet drivers to control shut
>> down or start interface, query or set MAC address, registering a link
>> callback etc.
>
> Maybe a thread to take care of the connection is desirable. I have seen
> here in the list that some people have implemented it. If not standard
> in Nut, this could be facilitated and even an example could be available.

Does Nut threads die gracefully now days? Having one for
initialization might be a problem if that's not the case.

> ---From later messages on this thread:---
> Whatever you do, please keep in mind that some of us use multiple
> network interfaces on one board. Simply killing all sockets when the
> cable has been pulled is likely to cause
> me problems.
>
> I disagree the general Windows behaviour is to return -1 to socket
> functions if network is down. Normaly Win/Linux TCP does not detect that
> the cabe was removed, The TCP socket will first try to send it's packets
> and will eventualy timeout.
>

AFAIK recv's and send's fails instantaneously under windows when cable
is disconnected, but bind's will still work across cable
connect/disconnect cycles. At least that's what I remember from my UO
server development days :D

Of course, it only applies to the interface in question, the other
interfaces where nothing happened remain the same.

Kinds Regards,
     Thiago A. Correa