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

[Frédéric BERNON]

Hi David,

You're right, if the protocol got a specific message to poll the peer, this is 
not a problem. But some protocols don't get them. Sometimes, we can found some 
workarounds. By example, with Telnet : you can send a "<SPACE><BACKSPACE>" to 
peer to force a communication checking, but, it can only work with my own 
telnet clients/servers. More, when you port some sources, you need to adapt 
them, and it's not very always simple.

To my point of view, porting applications on LwIP at socket layer would need to 
do only very limited modifications on applications. I thought that enable to 
customize default values with lwipopts.h seems to be in the "lwip spirit". If 
doing this is "too specific", ok, I will do it only in my own lwip copy. It's 
like IGMP, some modifications don't seem to be very "popular" (even if with 
good #ifdef, there is no more code), so, I just set them in my copy... :)

I just look the DNP protocol. Is it a very used protocol? Do you an overview 
about it (send me a private email if you can)... 
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de David Empson
Envoyé : dimanche 18 février 2007 23:56
À : Mailing list for lwIP users
Objet : Re: RE : [lwip-users] Questions about LwIP KEEPALIVE...


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.




_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf