94
Serial and TCP Protocols
It is possible to use XON/XOFF flow control without any involvement by the EM1500. This mode is
known as end-to-end XON/XOFF. For example, if a pair of EM1500s are being used as a serial extender,
the EM1500s are configured for a flow control of “None,” i.e., they do not do any local flow control of
their respective serial ports. In this case, XON/XOFF characters are transmitted between the EM1500s as
normal data characters. If the attached devices are both using XON/XOFF flow control, such control
passes through the EM1500s without modification, so that the XON/XOFF convention is handled entirely
by the attached devices.
This is a legitimate approach; however, it is possible for data to be lost under some circumstances. The
problem is that the EM1500s have limited size buffers and, because they are set up with no local flow con-
trol, it is possible for their receive buffers to overflow if there is a backup on the network side. This is
likely to occur with low bandwidth or high latency network connections. For example, if the network has a
1 second round-trip time (which is possible for satellite links) then, at 230.4 kbps, a total of about 25,000
characters could be in transit over the network. Half of these characters, or 12,500, could be flowing in
each direction. This is far greater than the total network buffering, 5,000 bytes, available in the
EM1500 for each direction. Hence, incoming data from the serial device might have to be dropped by the
EM1500 before the sender sees the XOFF character that is still in the network. Similarly, the EM1500
might have several thousand characters buffered to send to the device even after the device sends an XOFF
to pause the flow.
For the above reason, it is best to use end-to-end flow control only when the network bandwidth is high
and the latency short: in practice, that means that the network connection does not travel long-distance.
B.2 Network Protocols
This section outlines how the serial data is transferred over the network. The EM1500 supports three
modes of transfer, or network protocols. The protocol to use for any serial port must be configured using
the Protocol tab in the configuration program.
The available protocols are:
•
Raw (neither “Modem server” nor “Rabbit extensions” checked)
•
Modem server (RFC2217 - “Modem server” checked but not “Rabbit extensions”)
•
Modem server with extensions (“Rabbit extensions” checked)
The first protocol simply sends raw serial data over the TCP connection. This gives the best network band-
width utilization, but completely removes any other information about the serial port, such as the modem
control line status.
The “Modem server” protocol, officially known as RFC2217, allows a network host to remotely control a
serial port almost as if it were a local serial port on the host. IBM PC and compatible hosts mostly use a
serial port interface modeled after the original Intel UART chipset. A UART (universal Asynchronous
Receiver/Transmitter) is a computer peripheral chip that interfaces the host CPU to an RS232 serial port.
RFC2217 allows the host to operate a UART in “remote control,” i.e., over the Internet. Naturally, some of
the timing critical functions are not available; however, most of the UART functionality can be controlled.
Modem server protocol is useful when a host computer needs to interface to a remote serial device as if it
were a local device, without necessitating any change to applications that assume the serial port is local.
The host is required to install a special device driver which converts the application's local requests into
Summary of Contents for EM1500
Page 14: ...10 www rabbit com Introduction...
Page 22: ...18 www rabbit com Getting Started...
Page 76: ...72 www rabbit com EM1500 Configuration...
Page 90: ...86 www rabbit com EM1500 Specifications...
Page 104: ...100 www rabbit com Serial and TCP Protocols...
Page 118: ...114 www rabbit com EM1500 FAQ...