On Saturday, February 17, 2007 2:21 AM, "Frédéric BERNON"
<[EMAIL PROTECTED]> 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.
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
