Re: RE : [lwip-users] Questions about LwIP KEEPALIVE...

[David Empson]

On Saturday, February 17, 2007 2:21 AM, "Frédéric BERNON" 
<address@hidden> wrote:
> In changing that, I want to be able to close my tcp connections when the 
> virtual circuit between my client
> and my server is broken, to avoid waiting a too long time before the 
> client detect the problem (in this
> protocol, it can have a long time between exchanges, but if the link is 
> "broken", we have to change to
> another server...).

I'm in the process of implementing changes to our DNP 3.0 protocol driver to 
use TCP/IP (LWIP).  The DNP 3.0 documentation specifically mentions the 
keep-alive problem, and it suggests that rather than modifying or relying on 
the TCP keep-alive timer (which might not be possible in some TCP/IP 
stacks), it is better to implement a higher level method for the client to 
poll the server regularly, so it can rapidly detect a broken connection and 
reconnect.

In DNP 3.0's case, the recommended method is for the client to send a DNP 
3.0 data link layer "request link status" every ten seconds (if no other 
messages have been sent). The server is supposed to respond with a simple 
ack.

The server doesn't need a similar mechanism unless it is also able to 
initiate a connection to the client (i.e. both ends can listen for and 
initiate connections).

A little background: DNP 3.0 is a SCADA protocol used to transfer current 
state and event information for digital and analog inputs and outputs 
between a "slave" device (e.g. a device operating in a power substation) and 
a "master" device (e.g. a display terminal in a central office). The slave 
typically acts as the TCP/IP server (listening) and the client typically 
acts as the TCP/IP client (connecting) but it is possible for a slave to 
initiate a connection if it restarts and wants to send data.

The typical data flow for DNP 3.0 over TCP/IP will be for the server (DNP 
3.0 slave) to send data to the client (DNP 3.0 master) when data changes 
occur. The client (master) can also poll the server (slave) to get current 
state information and to issue control operations, but these are random and 
likely to be rarely sent, or regularly sent at a slow rate.