Stack needs a timeout mechanism to reset the physical layer

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Abrupt disconnection of an outstation (i.e. yank a cat5 cable)

What is the expected output? What do you see instead?
Would expect port to fail quickly, but it hangs until the TCP send buffer fills 
up and the socket dies b/c of that.

TCP Keep alive is not the preferred remediation b/c the timeout is a 
system-wide parameter even though it can be turned on and off on a per socket 
basis.

A good strategy might be to hand the master/outstation an interface to reset 
the AsyncLinkRouter after a certain failure condition.

Original issue reported on code.google.com by jadamcrain on 13 Jul 2010 at 8:02

[GoogleCodeExporter]

This problem is actually much more severe when the DNP3 stack is being used as 
a slave instead of as a master.  If unsolicited mode has not been requested, 
when the cat5 cable is yanked the client will not be sending data and therefore 
will never fill up the TCP send buffer.  Thus, yanking the cat5 cable can 
effectively cause a slave to hang forever, not accepting new requests.

Original comment by emeze...@gmail.com on 9 Dec 2010 at 9:17

[GoogleCodeExporter]

SunEdison has provided a mechanism to set the TCP keepalive on a per socket 
basis and this change has been verified and will be merged pending the CLA.

It would be nice to have someone look into the equivalent windows functionality.

Original comment by jadamcrain on 14 Dec 2010 at 3:14

[GoogleCodeExporter]

I'm only vaguely familiar with DNP3, but why not just use the 
"REQUEST_LINK_STATUS" (Function Code 9) per the recommendations of the DNP3 
Spec? (Ref: DNP3 Spec, Volume 4 Data Link Layer, V2.01 Section 2.6.5)

Original comment by Master...@gmail.com on 14 Jul 2011 at 3:40