Sensoray 2600 - Manual (Page 16)

2600 Family Instruction Manual 11 Chapter 3 : IOM Gateway
Figure 14: ModRsp Structure
3.6 Packet Routing
The gateway is responsible for routing MCmds to their target
modules and routing the resulting MRsps to the Ethernet client.
As described in the following sections, the routing process
consists of multiplexing and demultiplexing the messages that
pass between the client and IOMs.
3.6.1 Demultiplex Parser
Each received gateway command packet is demultiplexed into
individual MCmds, which are then transformed into equivalent
ModCmds and forwarded to the appropriate target modules for
further processing.
Since MCmds may have variable length, the gateway must
detect MCmd boundaries by parsing the gateway command
packet. As the parser scans the command packet, it constructs
a list of MCmd boundaries. When the end of the command
packet is reached, all MCmd boundaries are known and the
parser is finished. The entire command packet is parsed before
any MCmds are forwarded to their target modules.
3.6.1.1 Dropped Packets
A gateway command packet will be dropped if its
encapsulating UDP datagram has a UDP checksum error. In
addition, the parser will drop the command packet in response
to any of the following conditions:
• The parser reaches the end of the command packet, but the
MCmd that is being parsed has not ended.
• The declared size of the MCmd that is being parsed
exceeds the maximum valid MCmd size.
If the command packet is dropped for any reason, the gateway
thread will terminate prematurely and no gateway response
packet will be sent to the Ethernet client. A properly designed
client will detect this by means a communication time-out
while waiting for the gateway response packet to arrive.
3.6.2 Forwarding Sequence
When the command packet parser has finished parsing an
error-free command packet, the gateway will begin to forward
the command packet’s MCmds to their target modules. The
following sequence is repeated for each MCmd in the
command packet:
• The MM connects its IOM communication interface to the
IOM port associated with the MCmd.
• The MCmd is transformed into an equivalent ModCmd.
• The ModCmd is transmitted to the target IOM.
• The MM waits for a ModRsp, or a communication
time-out, whichever occurs first.
• If a ModRsp was received, it is checked for errors by
validating its size and checksum. If no errors are detected,
the ModCmd is transformed into an equivalent MRsp and
appended to the response packet. If a ModRsp was
received but is found to have errors, no MCmd will be
posted to the response packet. If a communication
time-out occurred, the gateway assumes that no response
is forthcoming and no MCmd will be posted to the
response packet.
After executing the above sequence for all MCmds in the
command packet, the gateway will transmit the response
packet to the Ethernet client.
3.6.3 Missing Responses
The Ethernet client is responsible for detecting the absence of
any expected MRsps in a response packet. See Section 3.8.2.2
for details.
3.7 Link Detection
3.7.1 Visual Indicators
A visual indicator LED, designated “LNK,” is present on all
IOMs. In addition, the MM has its own visual LNK indicators,
one per IOM port (see Figure 5). When a cable connection is
made from an IOM to one of the MM’s IOM ports, the LNK
indicators at both ends of the connection will activate to
provide visual confirmation that the link is detected.
No communications are required between the Ethernet client
and IOMs to light the LNK indicators. The MM automatically
establishes and maintains communication links to all attached
IOMs.
When a link indicator is lit, there is a high probability that the
communication interface is intact and the connected IOM is at
least partially functional.
3.7.2 Active Port List (APL)
The gateway maintains a list of IOM ports that have active
links; this list is called the active port list (APL). The APL
serves two purposes:
Field Type Function
MRspLen BYTE Length of the ModRsp, including the
header and checksum bytes.
Status BYTE Module status in effect before any
actions execute. See Section 3.4.1 for
details.
RspList[] BYTE List of responses generated by actions.
ChkSum BYTE Checksum of all bytes preceding the
ChkSum, including the header byte.
Chksum MRspLen
Header Action Responses
Status RspList[]