Release Notes for EtherCom version May 25 2001
==============================================


This release fixes a problem introduced in the previous release
(December 12, 2000).

If keepalive segments were being sent (that is, if remoteretry
was set to a non-zero value) then the EM1000 would occasionally
lock up and have to be manually reset.

It is recommended that all EM1000s be upgraded to this new release
for additional robustness.  This applies whether or not keepalives
were actually being used.  This release also includes improvements
to enhance the reliablility of the TCP/IP connection.

Normally, it is recommended that keepalives (which is a form of
polling) not be used.  The only circumstance where their use is
justified is:

  . Two EM1000s are being used to establish a virtual RS232 serial
    link.  One is set to "connect active" and the other to
    "connect listen".

and either

  . The serial stream is unidirectional, with data entering the
    "connect listen" and exiting from the "connect active".  If
    data travels the opposite direction, it is only ever in
    response to data coming in the usual direction.  For example,
    only XON/XOFF flow control.  This would typically be the
    case if a printer or plotter was connected to the "active"
    end.  Keepalives could be avoided by simply connecting the
    printer or plotter device to the "listen" end.

or

  . A "conversation" can be initiated from either end of the
    link, for example a terminal attached to the "listen" end
    needs to log in to a host, but the terminal also needs to
    receive occasional log messages.

Keepalives are not necessary if conversations are always initiated
from the active end.  This is because the link will
be automatically reestablished is the "listen" side ever
fails.


Configuration Parameters
------------------------

The only parameter affected by this release is RemoteRetry.  This
now allows keepalives to be selectively set.  If remoteretry is
set to zero, no keepalives will be used.  If set to an even number
of seconds, keepalives will not be used but remote host retry interval
will be set.  If set to an odd number, both keepalives and remote
retry will be in effect for the given value.

Implementation Notes
--------------------

These notes are repeated from the previous release, for your
convenience.

Since EM1000s are often used to establish a permanent virtual circuit
between two RS232 devices, it is important for the EM1000s to ensure
that their peer is available and still connected on the same TCP/IP
socket.  TCP/IP itself does not support this functionality.  If one
end of a connection is, for example, powered off then the other end
will not know about this until it tries to send data over the
connection.

Because of this limitation in TCP/IP, and packet-switched networks
in general, it is necessary for the application to periodically
poll the other end when there has been no data transfer for, say,
15 seconds.

As with any polling scheme, there is always a tradeoff between 
responsiveness and overhead.  On a LAN, 15 seconds is a reasonable
minimum interval for polling.  Over the greater internet, the
interval should be increased to at least 2 minutes.

Under TCP/IP, the polling is implemented via keep-alive packets
which are basically packets with zero data content, but which
require a response from the peer.  In the case that the peer is
not available, these packets will be dropped.  When the peer
becomes available again, it will notice that the keep-alive
packets do not correspond with any current connection, and will
send a response indicating the connection should be reset.  On
receipt of this response, the poller will attempt to re-establish
a proper connection.

This ensures that a passive ("connect listen") end of a connection,
should it fail and restart, will eventually reconnect to the
active end which, if it otherwise had nothing to send, would
never realize the passive end had dropped the connection.