Network interface device which allows peripherals to utilize network transport services6370592Abstract An input/output device is connected to peripheral equipment. The input/output device includes a plurality of network transport modules. Each network transport module implements a different network protocol. The input/output device includes a communication mechanism for communication with the peripheral equipment. The input/output device also includes a gateway module, which interacts with each of the network transport modules and with the communication mechanism. For each endpoint within an application programming interface (API) module within the peripheral equipment, a corresponding endpoint is implemented within the gateway module. A control channel between the gateway module and the API module is used to transport control messages between the gateway module and the API module. For a network transport module which requires data stream communication, control messages are exchanged over the control channel and data stream communication is established via a separate communication channel between the gateway module and the API module. Claims I claim: Description BACKGROUND
TABLE 1
struct x_generic_msg {
uint8 command;
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
};
command Identifies the message type.
result Result of the operation. This field is
only meaningful in replies.
reserved This field is currently unused, but is
reserved for future use. It also aligns
the following field on a 32 bit boundary.
p_endpoint The peripheral endpoint number the
message is related to.
d_endpoint The I/O device endpoint number the
message is related to.
Table 2 below sets out the format for the x_accept_ack message. This message acknowledges an x_accept_req on the listening endpoint.
TABLE 2
struct x_accept_ack {
uint8 command; /* X_ACCEPT_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 conn_seq; /* pending connection seq num */
};
command X_ACCEPT_ACK
result Result of the operation. Possible
errors:
TBADF Unknown endpoint
number.
TOUTSTATE Request not legal in
current state.
TNOTSUPPORT Transport does not
support this request.
TBADSEQ Unknown sequence
number.
TRESADDR Accepting endpoint
bound to different address.
TINDOUT Endpoint has
outstanding connect indications.
TRESQLEN Accepting endpoint
can't have qlen > 0.
TPROVMISMATCH Accepting
endpoint uses different transport.
TSYSERR System error.
TPROTO Other XIP protocol error.
p.sub.13 endpoin Peripheral endpoint number. This
t is the endpoint the x conn ind
arrived on, not the endpoint the
connection was actually accepted
on.
d_endpoin Device endpoint which sent this
t message.
conn_seq Same sequence number provided by
XIP API module 54 in the request.
Table 3 below sets out the format for the x_accept_req message. This message accepts a pending connect request indicated earlier by an x_conn_ind message.
TABLE 3
struct x_accept_req {
uint8 command; /* X_ACCEPT_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 conn_seq; /* pending connection seq num */
uint32 acc_endpoint; /* I/O device endpoint number */
};
command X_ACCEPT_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint which sent the
x conn ind message.
conn_seq Sequence number of the connect
request. The same number
provided in the x_conn_ind which
XIP API module 54 is accepting.
acc_endpoint Device endpoint on which to accept
the connection. This can either be
the same endpoint the connect
request arrived on or a different
one. If it is the same, the endpoint
will not be able to listen for any new
connections as long as it is
connected. If it is different, the new
endpoint must have been created
already with an x_open_req
message. The new endpoint may be
bound to an address already or it
may be unbound. If unbound, XIP
gateway module 41 will copy the
address from the listening
endpoint.
Table 4 below sets out the format for the x_bind_ack message. This message acknowledges an x_bind_req. It provides the full local address actually bound. It also provides the negotiated connect indication queue length.
TABLE 4
struct x_bind_ack {
uint8 command; /* X_BIND_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 bind_seq;
uint32 queue_len;
uint32 addr_len
uint8 address [addr_len]; /* variable length */
};
command X_BIND_ACK
result Result of the operation. Possible
errors:
TBADF Unknown endpoint
number.
TOUTSTATE Request not legal in
current state.
TBADADDR Incorrect address.
TNOADDR Unable to allocate
address.
TADDRBUSY Address already in
use.
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
bind_seq Same bind sequence number
specified by peripheral in the
x_bind_req message.
queue_len The number of outstanding connect
indications the transport module
will queue. This number will be
less than or equal to the length
requested in the x_bind_req
message. It will always be at least
one if the bind message requested a
non-zero queue length. See that
message for more information
about connect queuing.
addr_len Size in bytes of the local address
that follows.
address The local protocol address actually
bound to the endpoint.
Table 5 below sets out the format for the x_bind_req message. This message binds a local protocol address to a previously opened endpoint. For stream channels, it also specifies how many connect requests XIP API module 54 would like XIP gateway module 41 to queue on this endpoint. The connect request queue holds pending connections until XIP API module 54 has a chance to respond to them. The length of this queue does not determine the maximum number of simultaneous connections the transport module will support. It just determines the maximum burst size before XIP gateway module 41 drops additional connect requests. If the queue length is zero, the endpoint will not listen for connect requests. XIP gateway module 41 may select a smaller queue length, but not a larger one. However, if XIP API module 54 asked for a queue length greater than zero, XIP gateway module 41 must select a length of at least one. If the underlying transport provider allows it, any number of endpoints may share the same local address. However, only one of them may have a queue length greater than zero.
TABLE 5
struct x_bind_req {
uint8 command; /* X_BIND_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 bind_seq;
uint32 queue_len;
uint32 addr_len;
uint8 address[addr_len]; /* variable length */
};
command x_BIND_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint the address is to be
bound to.
bind_seq Bind sequence number. XIP API
module 54 must choose a unique
number for every bind request on a
datagram endpoint. Every
x_unitdata_in and x_unitdata_out
for this address will carry the same
number. This avoids stale
datagrams after a rebind.
queue_len Requested connect request queue
length. See below for details. This
field is ignored by connectionless
transports.
addr_len Size in bytes of the local address
that follows. The length may be
zero to request that the transport
module assign a unique local
address.
address Local address to bind to the
endpoint. The address is in the
format the endpoint's transport
expects.
Table 6 below sets out the format for the x_close_ack message. This message acknowledges an x_close_req message.
TABLE 6
struct x_close_ack {
uint8 command; /* X_CLOSE_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
};
command X_CLOSE_ACK
result Result of the operation. Possible
errors:
TBADF Unknown endpoint
number.
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
Table 7 below sets out the format for the x_close_req message. This message closes a transport endpoint. The endpoint ceases to exist. Any dedicated channel associated with the endpoint is also freed.
TABLE 7
struct x_close_req {
uint8 command; /* X_CLOSE_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
};
command X_CLOSE_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint to close.
Table 8 below sets out the format for the x_conf_ind message. This message confirms that a pending connection is complete. It is the final response to an x_conn_req message. It also provides the actual remote address connected to.
TABLE 8
struct x_conf_ind {
uint8 command; /* X_CONF_IND */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 addr_len
uint8 address[addr_len]; /* variable length */
};
command X_CONF_IND
result Meaningless in this message.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
addr_len Size in bytes of the address that
follows.
address Address of remote host 82
responding to the connection.
Table 9 below sets out the format for the x_conn_ack message. This message acknowledges an x_conn_req message. The connection is not actually up at this point. The transport provider will send an x_conf_ind message later to confirm the connection.
TABLE 9
struct x_conn_ack {
uint8 command; /* X_CONN_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
};
command X_CONN_ACK
result Result of the operation. Possible
errors:
TBADF Unknown endpoint
number.
TOUTSTATE Request not legal in
current state.
TNOTSUPPORT Transport does not
support this request.
TBADADDR Incorrect address.
TADDRBUSY Connection already
exists between same local and
remote address pair.
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
Table 10 below sets out the format for the x_conn_ind message. This message indicates an incoming connect request from a remote host. It can only happen on an endpoint with a connect queue length greater than zero that is not currently connected.
TABLE 10
struct x_conn_ind {
uint8 command; /* X_CONN_IND */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 conn_seq; /* pending connection seq num */
uint32 addr_len;
uint8 address[addr_len]; /* variable length */
};
command X_CONN_IND
result Meaningless in this message.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
conn_seq Sequence number of the connect
request. Used with multiple
connects to indicate which one XIP
API module 54 is responding to.
XIP gateway module 41 may use
any numbering scheme, except that
0XFFFFFFFF is not a valid
sequence number.
addr_len Size in bytes of the address that
follows.
address Address of the host requesting the
connection.
Table 11 below sets out the format for the x_conn_req message. This message initiates an active connection to the specified remote address.
TABLE 11
struct x_conn_req {
uint8 command; /* X_CONN_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 addr_len;
uint8 address[addr_len]; /* variable length */
};
command X_CONN_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint to connect.
addr_len Size in bytes of the address that
follows.
address Remote address XIP API module 54
wants to connect to
Table 12 below sets out the format for the x_discon_ack message. This message acknowledges an x_discon_req message. If the endpoint was in DATAXFER, INREL, or OUTREL state, XIP gateway module 41 also sends an EOHD flag on the dedicated stream channel. XIP API module 54 flushes all data until it receives the EOHD with the same number as in this message.
TABLE 12
struct x_discon_ack {
uint8 command; /* X_DISCON_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 conn_seq; /* pending connection seq num */
uint32 sync_num; /* channel EOHD marker seq num */
};
command X_DISCON_ACK
result Result of the operation. Possible
errors:
TBADF Unknown endpoint
number.
TOUTSTATE Request not legal in
current state.
TNOTSUPPORT Transport does not
support this request.
TBADSEQ Unknown sequence
number.
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
conn_seq Same sequence number provided by
XIP API module 54 in the request.
sync_num Most recent end-of-host-data
sequence number sent on dedicated
channel.
Table 13 below sets out the format for the x_discon_ind message. This message indicates that a connection is down. XIP API module 54 does not need to respond to this message; just clean up after the lost connection. The x_discon_ind message has three uses. The first use is to indicate that an existing connection was aborted. This is a hard disconnect. I/O device 34 will not accept any more data from peripheral equipment 33 or the remote end. However, there may be data in the channel between XIP gateway module 41 and XIP API module 54. I/O device 34 will drop any outbound data without sending it. XIP API module 54 will drop any inbound data without delivering it to the user. The second use of the x_discon_ind message is to indicate that a pending x_conn_req was denied by remote host 82. The third use of the x_discon_ind message is to indicate that a remote host requested a connection and then closed the connection before the local user had a chance to accept it. In this case the sequence number indicates which pending connection is closed. If the endpoint was in DATAXFER, INREL, or OUTREL state, XIP gateway module 41 also sends an EOHD flag on the dedicated stream channel. XIP API module 54 flushes all data until it receives the EOHD with the same number as in this message.
TABLE 13
struct x_discon_ind {
uint8 command; /* X_DISCON_IND */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 conn_seq; /* pending connection seq num */
uint32 sync_num; /* channel EOHD marker seq num */
uint32 reason; /* disconnect reason code */
};
command X_DISCON_IND
result Meaningless in this message.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
conn_seq Indicates that an incoming
connection was disconnected before
it was fully established. This is the
same sequence number from the
x_conn_ind message. If the
connection was fully established, or
was initiated by an x_conn_req
message, this value is
0XFFFFFFFF.
sync_num Most recent end-of-host-data
sequence number sent on dedicated
channel.
reason Transport specific disconnect
reason code. The ERS document for
each XIP implementation
documents what reason codes it
uses.
Table 14 below sets out the format for the x_discon_req message. This message has three uses. The second use of the x_discon_req message is to abort an open connection. This is a hard disconnect. The transport provider will not accept any more data from the remote end. However, there may be data in the pipe between the transport provider and XIP API module 54. The transport provider will drop any outbound data without sending it. XIP API module 54 will drop any inbound data without delivering it to the user. The second use of the x_discon_req message is to abort a pending active connect requested earlier by an x_conn_req message. The third use of the x_discon_req message is to reject a pending passive connect request indicated earlier by an x_conn_ind message.
TABLE 14
struct x_discon_req {
uint8 command; /* X_DISCON_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 conn_seq; /* pending connection seq num */
};
command X_DISCON_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint to disconnect.
conn_seq Used to reject a pending connect
request. This is the same sequence
number from the x_conn_ind
message. Ignored for active
connects and established
connections.
Table 15 below sets out the format for the x_ep inf_ack message. This message returns the protocol parameters requested by an x_ep_info_req message.
TABLE 15
struct x_ep_info_ack {
uint8 command; /* X_EP_INFO_ACK */
uint8 result;
uint/6 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
sint32 tsdu_size; /* Max TSDU size */
sint32 etsdu_size /* Max ETSDU size */
sint32 cdata_size; /* Connect data size */
sint32 ddata_size; /* Disconnect data size */
sint32 addr_size; /* TSAP size */
sint32 opt_size; /* Options size */
sint32 tidu_size; /* TIDU size */
sint32 serv_type; /* Service type */
sint32 current_state; /* Endpoint state */
sint32 provider_flag; /* Provider flags */
sint32 addr_fr_family; /* Address family */
};
command X_EP_INFO_ACK
result Result of the operation. Possible
errors:
TBADF Unknown endpoint
number.
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
tsdu_size Maximum Transport Service Data
Unit.
0 means the transport module does
not support the concept of TSDU,
although it does support a data
stream with no logical boundaries.
-1 means there is no limit on the
TSDU size.
-2 means the transport module
provider does not support normal
data.
etsdu_size Maximum Expedited Transport
Service Data Unit.
0 means the transport provider does
not support the concept of ETSDU,
although it does support an
expedited data stream with no
logical boundaries.
-1 means there is no limit on the
ETSDU size.
-2 means the transport provider
does not support expedited data.
cdata_size Maximum connection
establishment data.
-2 means the transport provider
does not support sending data with
connection establishment
primitives.
ddata_size Maximum disconnect data.
-2 means the transport provider
does not support sending data with
disconnect primitives.
addr_size Maximum protocol address size.
-2 means the transport provider
does not provide access to protocol
addresses.
opt_size Maximum number of bytes of
protocol-specific options.
-2 means the transport provider
supports reading options, but not
setting them.
-3 means the transport provider
does not support any options.
tidu_size Maximum Transport Interface
Data Unit.
serv_type Service type supported by the
transport provider.
COTS Connection oriented with no
orderly release support.
COTS_ORD Connection oriented
with orderly release support.
CLTS Connectionless (datagram)
service.
current_state The current state of the endpoint.
provider_flag Additional transport-specific flags.
None supported in this version.
addr_family Address family code for this
transport provider.
Table 16 below sets out the format for the x_ep_info_req message. This message retrieves transport provider parameters. It may be issued at any time and has no effect on the endpoint.
TABLE 16
struct x_ep_info_req {
uint8 command; /* X_EP_INFO_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
};
command X_EP_INFO_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint the peripheral
wants information about.
Table 17 below sets out the format for the x_new_state_ind message. This is the first XIP message sent. XIP gateway module 41 sends an x_new_state_ind message shortly after boot to notify peripheral equipment 33 that I/O device 34 supports XIP, to provide the XIP version number that I/O device 34 supports, and to provide the state of each transport number that I/O device 34 supports. XIP gateway module 41 also sends an x_new_state_ind whenever any transport is enabled or disabled. This happens when I/O device 34 is first powered up, when I/O device 34 is reset, when a protocol stack is enabled or disabled via the front panel, when a protocol stack is enabled or disabled via SNMP, before an I/O device firmware download, after an I/O device firmware download or when there is a network address change in the I/O device 34. An external I/O device also sends an x_new_state_ind when a new MLC peripheral becomes available. This happens when peripheral equipment 33 is first powered up, when peripheral equipment 33 comes back up after a power cycle, and when the parallel cable is connected or reconnected. The x_new_state_ind message always provides the state of every transport. Whenever XIP API module 54 receives a message showing that a transport is down, XIP API module 54 assumes all endpoints using that transport are now closed and clean up their resources. XIP API module 54 does not send x_close_req messages for the endpoints. XIP gateway module 41 must automatically close and clean up all endpoints whenever a transport becomes disabled or when the communication link to peripheral equipment 33 is cut off. If the network address for I/O device 34 changes, XIP gateway module 41 must tell XIP API module 54 that the transport module is down so that all endpoints are closed. XIP gateway module 41 may then immediately tell XIP API module 54 that the transport module is back up. If XIP API module 54 keeps a copy of the network address of I/O device 34, XIP API module 54 reloads the network address after every x_new_state_ind.
TABLE 17
struct x_new_state_ind {
uint8 command; /* X_NEW_STATE_IND */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* meaningless */
uint32 d_endpoint; /* meaningless */
uint32 version;
uint32 sync_num; /* channel EOHD marker seq
uint32 num_elements; num */
struct {
uint32 transport;
uint32 enabled;
} transport_list[num_elements];
};
command X_NEW_STATE_IND
result Meaningless in this message.
p_endpoint Meaningless in this message.
d_endpoint Meaningless in this message.
version XIP version number. Al-
ways 0x0201 for I/O devices
that support this specification.
sync_num End-of-host-data inbound
sequence number on all dedi-
cated channels affected by this
message.
num_elements The number of (transport, state)
pairs in the following table.
transport One of the transport numbers
supported by I/O device 34.
enabled Flag indicating whether the
transport module is enabled.
Table 18 below sets out the format for the x_new_state_res message. XIP API module 54 sends this message to acknowledge the x_new_state_ind. It also provides the XIP version number that XIP API module 54 supports. XIP API module 54 returns the same transport list provided in the x_new_state_ind message.
TABLE 18
struct x_new_state_res {
uint8 command; /* X_NEW_STATE.sub.' RES */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* meaningless */
uint32 d_endpoint; /* meaningless */
uint32 version;
uint32 sync_num; /* channel EOHD marker seq
uint32 num_elements; num */
struct {
uint32 transport;
uint32 enabled;
} transport_list[num_elements];
};
command X_NEW_STATE_RES
result Meaningless in this message.
p_endpoint Meaningless in this message.
d_endpoint Meaningless in this message.
version XIP version number. Always
0x0200 for peripherals that
support this specification.
sync_num End-of-host-data inbound
sequence number on all dedi-
cated channels affected by this
message.
num_elements The number of (transport, state)
pairs in the following table.
transport Copy of the transport list sent in
the x_new_state_ind.
enabled Copy of the transport list sent in
the x_new_state_ind.
Table 19 below sets out the format for the x_open_ack message. This message acknowledges an x_open_req message and, optionally, provides the backplane channel for data transfer on this endpoint.
TABLE 19
struct x_open_ack {
uint8 command; /* X_OPEN_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 transport;
uint32 chan_len;
uint8 channel[chan_len]; /* variable length */
};
command X_OPEN_ACK
result Result of the operation. Possible
errors:
TBADF Unable to create new
endpoint.
TBADNAME Unknown transport
number.
TBADCHAN Channel number
unknown or unavailable.
TTPDOWN Transport is down.
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint number. XIP API
module 54 will use this number to
send all future messages for this
endpoint.
transport Same transport number as in
request.
chan_len Size in bytes of the channel
information that follows. Will be
zero if XIP gateway module 41 does
not support separate channels or
XIP API module 54 did not request
one for this endpoint.
channel Channel which XIP gateway
module 41 will use for data
transfer. The exact meaning of the
channel field is specific to the
communication method between
peripheral equipment 33 and I/O
device 34. For I/O, this field will be
the 16 bit IOChannel number
selected by the card.
Table 20 below sets out the format for the x_open_req message. This message creates a new transport endpoint, binds it to a transport provider, and, optionally, binds it to a dedicated backplane channel. The channel number is required for stream transports. It is optional for datagram transports. XIP gateway module 41 may impose an upper limit on the number of open endpoints and reject extra ones with a TBADF error.
TABLE 20
struct x_open_req {
uint8 command; /* X_OPEN_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 transport;
uint32 chan_len;
uint8 channel[chan_len]; /* variable length */
};
command X_OPEN_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint number which
sent this message.
d_endpoint This field is meaningless since the
device has not assigned an endpoint
number yet.
transport Transport protocol module number
to bind to this endpoint.
chan_len Size in bytes of the channel
information that follows. Will be
zero if peripheral equipment 33
does not support separate channels
or does not wish to use one for this
endpoint.
channel Channel which peripheral
equipment 33 will use for data
transfer. The exact meaning of the
channel field is specific to the
communication method between
peripheral equipment 33 and I/O
device 34. For I/O, this field will be
the 16 bit Peripheral Unit number
selected by peripheral equipment
33.
Table 21 below sets out the format for the x_ordrel_ack message. This message acknowledges an x_ordrel_req. In order to synchronize the data stream, XIP API module 54 must also send an end-of-data flag on the dedicated data channel. See the backplane specifics section for how this is done. XIP gateway module 41 must receive both the x_ordrel_req and the matching end-of-data flag before acting on the request. Then it changes state, sends the orderly release to remote host 82, and sends the x_ordrel_ack. This could result in a significant delay between the x_ordrel_req and the x_ordrel_ack!
TABLE 21
struct x_ordrel_ack {
uint8 command; /* X_ORDREL_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 sync_num; /* channel EOPD marker seq num */
};
command X_ORDREL_ACK
result Result of the operation. Possible
errors:
TBADF Unknown endpoint
number.
TOUTSTATE Request not legal in
current state.
TNOTSUPPORT Transport does not
support this request.
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
sync_num Same number peripheral provided
in the request.
Table 22 below sets out the format for the x_ordrel_ind message. This message indicates that remote host 82 is done sending data. It is only legal for transport providers whose service type is COTS_ORD. Peripheral equipment 33 will not receive any more data, however it may continue to send data as long as it wishes. In order to synchronize the data stream, XIP gateway module 41 must also send an end-of-data flag on the dedicated data channel. Peripheral equipment 33 must receive both the x_ordrel_ind and the matching end-of-data flag before changing state and delivering the event to the application.
TABLE 22
struct x_ordrel_ind {
uint8 command; /* X_ORDREL_IND */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 sync_num; /* channel EOHD marker seq num */
};
command X_ORDREL_IND
result Meaningless in this message.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
sync_num Most recent end-of-host-data
sequence number sent on dedicated
channel.
Table 23 below sets out the format for the x_ordrel_req message. This message begins an orderly connection release, also known as a half-close. It is only legal for transport providers whose service type is COTS_ORD. Peripheral equipment 33 may not send any more data once it starts an orderly connection shutdown. However, the remote end may continue to send data as long as it wishes and XIP API module 54 must be prepared to receive it. In order to synchronize the data stream, XIP API module 54 must also send an end-of-data flag on the dedicated data channel.
TABLE 23
struct x_ordrel_req {
uint8 command; /* X_ORDREL_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 sync_num; /* channel EOPD marker seq num */
};
command X_ORDREL_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint to send orderly
release on.
sync_num Most recent end-of-peripheral-data
sequence number sent on dedicated
channel.
Table 24 below sets out the format for the x_sys info_ack message. This message returns the system parameter requested by an x_sys_info_req message.
TABLE 24
struct x_sys_info_ack {
uint8 command; /* X_SYS_INFO_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* meaningless */
uint32 d_endpoint; /* meaningless */
uint32 operation;
uint32 status; /* result of object access */
uint32 object_id;
uint32 val_len
uint8 value[val_len]; /* variable length */
};
command X_SYS_INFO_ACK
result Result of the operation. Possible
errors:
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Meaningless in this message.
d_endpoint Meaningless in this message.
operation Operation performed on object.
1 GET object's value.
2 SET object's value.
status Result of operation on object. See
the system information section for a
list of status codes.
object_id Object ID of system parameter
returned.
val_len Length of object's value.
value The actual value of the object as a
byte array. Peripheral equipment
33 must know how to interpret the
contents of the array.
Table 25 below sets out the format for the x_sys_info_req message. This message retrieves I/O device system parameters. It may be issued at any time and has no effect on any endpoint.
TABLE 25
struct x_sys_info_req {
uint8 command; /* X_SYS_INFO_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* meaningless */
uint32 d_endpoint; /* meaningless */
uint32 operation;
uint32 status; /* meaningless */
uint32 object_id;
uint32 val_len
uint8 value[val_len]; /* variable length */
};
command X_SYS_INFO_REQ
result Meaningless in this message.
p_endpoint Meaningless in this message.
d_endpoint Meaningless in this message.
operation Operation to perform on object.
1 GET object's value.
2 SET object's value.
status Meaningless in this message.
object_id Object ID of system parameter
requested.
val_len Length of the object's value. Zero
for a GET operation.
value The actual value of the object. Only
meaningful on SET operations.
Table 26 below sets out the format for the x_unbind_ack message. This message acknowledges an x_unbind_req.
TABLE 26
struct x_unbind_ack {
uint8 command; /* X_UNBIND_ACK */
uint8 result;
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
};
command X_UNBIND_ACK
result Result of the operation. Possible
errors:
TBADF Unknown endpoint
number.
TOUTSTATE Request not legal in
current state.
TSYSERR System error.
TPROTO Other XIP protocol error.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
Table 27 below sets out the format for the x_unbind_req message. This message unbinds the local protocol address from an endpoint. The endpoint may then be rebound to a different address with x_bind_req or it may be closed with x_close_req.
TABLE 27
struct x_unbind_req {
uint8 command; /* X_UNBIND_REQ */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
};
command X_UNBIND_REQ
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint to unbind.
Table 28 below sets out the format for the x_unitdata_in message. This message delivers a datagram received on a connectionless transport endpoint.
TABLE 28
struct x_unitdata_in {
uint8 command; /* X_UNITDATA.sub.' IN */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 bind_seq;
uint32 frag_flag;
uint32 addr_len
uint32 data_len
uint8 address[addr_len]; /* variable length */
uint8 data[data_len]; /* variable length */
};
command X_UNITDATA_IN
result Meaningless in this message.
p_endpoint Peripheral endpoint number.
d_endpoint Device endpoint which sent this
message.
bind_seq Same bind sequence number
specified by peripheral in the
x_bind_req message.
frag_flag Non-zero means that the next
x_unitdata_in message will be part
of the same TSDU. XIP gateway
module 41 uses this flag when it
can't fit the entire datagram TSDU
in one backplane message.
addr_len Size in bytes of the address that
follows.
data_len Size in bytes of the data that follows.
address Remote address which sent this
data. The address is only required
on the first x_unitdata_in of a
multi-part TSDU. It is optional on
the following parts. See the
transport specific address
information for more details on
address formats.
data The actual packet data.
Table 29 below sets out the format for the x_unitdata_out message. This message sends a datagram over a connectionless transport endpoint. Datagrams are unreliable. It is possible that the transport provider will drop the packet. There is no way to know if this happened.
TABLE 29
struct x_unitdata_out {
uint8 command; /* X_UNITDATA_OUT */
uint8 result; /* meaningless */
uint16 reserved;
uint32 p_endpoint; /* peripheral endpoint number */
uint32 d_endpoint; /* I/O device endpoint number */
uint32 bind_seq;
uint32 frag_flag;
uint32 addr_len;
uint32 data_len
uint8 address[addr_len]; /* variable length */
uint8 data[data_len]; /* variable length */
};
command X_UNITDATA_OUT
result Meaningless in this message.
p_endpoint Peripheral endpoint which sent
this message.
d_endpoint Device endpoint number.
bind_seq Same bind sequence number
specified by peripheral in the
x_bind_req message.
frag_flag Non-zero means that the next
x_unitdata_out message will be
part of the same TSDU. Peripheral
equipment 33 uses this flag when it
can't fit the entire datagram TSDU
in one backplane message.
addr_len Size in bytes of the address that
follows
data_len Size in bytes of the data that follows.
address Remote address to send data to.
The address is only required on the
first x_unitdata_out of a multi-part
TSDU. It is optional on the
following parts.
data The actual packet data.
Table 30 below gives three list summaries of the messages by name, by sender and by function.
TABLE 30
Listed by Name Listed by Sender Listed by Function
x_accept_ack Peripheral Initialize
x_accept_req x_accept_req x_new_state_ind
x_bind_ack x_bind_req x_new_state_res
x_bind_req x_close_req x_open_req
x_close_ack x_conn_req x_open_ack
x_close_req x_discon_req x_bind_req
x_conf_ind x_ep_info_req x_bind_ack
x_conn_ack x_new_state_res x_ep_info_req
x_conn_ind x_open_req x_ep_info_ack
x_conn_req x_ordrel_req x_sys_info_req
x_discon_req x_sys_info_req x_sys_info_ack
x_discon_ack x_unbind_req Active Connect
x_discon_ind x_unitdata_out x_conn_req
x_ep_info_ack I/O Device x_conn_ack
x_ep info_req x_accept_ack x_conf_ind
x_new_state_ind x_bind_ack Passive Connect
x_new_state_res x_close_ack x_conn_ind
x_open_ack x_conf_ind x_accept_req
x_open_req x_conn_ack x_accept_ack
x_ordrel_ack x_conn_ind Data Transfer
x_ordrel_ind x_discon_ack x_unitdata_in
x_ordrel_req x_discon_ind x_unitdata_out
x_sys info_ack x_ep_info_ack Disconnect
x_sys info_req x_new_state_ind x_discon_ind
x_unbind_ack x_open_ack x_discon_req
x_unbind_req x_ordrel_ack x_discon_ack
x_unitdata_in x_ordrel_ind x_ordrel_ack
x_unitdata_out x_sys_info_ack x_ordrel_ind
x_unbind_ack x_ordrel_req
x_unitdata_in Deinitialize
x_close_req
x_close_ack
x_unbind_req
x_unbind_ack
The following overview of the XIP protocol assumes some familiarity with network transports and APIs. A good background reference is the X/Open Transport Interface (XTI) Specification (document C438; available from X/Open by calling 415-323-7992). XIP provides a way for network applications in peripheral equipment 33 to access transport provider services on an intelligent I/O device, such as I/O device 34. Peripheral equipment 33 provides an API library such as TLI or BSD Sockets. I/O device 34 provides network transports such as TCP, UDP, SPX, and IPX. XIP is how the API library and the transport provider communicate with each other. The following discussion specifies the messages exchanged between XIP API module 54 within peripheral equipment 33 and XIP gateway module 41 within I/O device 34. To exchange messages there needs to be some communication mechanism between XIP API module 54 and I/O device 34. In FIG. 2 this communication mechanism is represented by I/O driver 55 within peripheral equipment 33 and by I/O driver 56 within I/O device 34. Collectively, the software and hardware part of the communication mechanism is referred to as "backplanes". The term "backplanes" encompasses actual physical backplanes, parallel cables, infrared links, and so on. Whatever the communication method, it must provide reliable delivery of XIP messages and data. Most, if not all, backplanes provide multiple channels to multiplex communications between different entities on peripheral equipment 33 and I/O device 34. XIP will use a single channel for all control messages. XIP, Version 2 also includes the option to dedicate a backplane channel to each endpoint for data transfer. Channels are described in more detail below. The fundamental XIP, Version 2 data structure is an endpoint. On peripheral equipment 33, endpoints map to sockets or file descriptors used by the application. On I/O device 34, they map to transport addresses (e.g. sockets or ports). Each endpoint has a unique identification number and state. The communication channel(s) used for XIP must have the following four properties. The first property is reliability. All messages sent will be delivered intact. This implies that channels have flow control so the sender does not overrun the receiver. The second property is internal ordering. All messages on a given channel will be delivered in the order sent. The third property is an end-of-data flag. Data channels have some mechanism for sending a flag that marks the end of data in a given direction. If the same data channel will be reused for the next connection, the end-of-data flag must have a sequence number or some other way to uniquely identify it. The fourth property is a half close. After sending an end-of-data flag in one direction, the other direction must continue to pass data. Communication channels do not require the property of external ordering. Different channels do not require interchannel ordering. In other words, messages sent on two different channels may be delivered in a different order. The XIP protocol is initialized at boot time starting with an x_new_state_ind message from I/O device 34. The x_new_state_ind message tells peripheral equipment 33 that I/O device 34 supports XIP and provides a list of available transports and their state. Peripheral equipment 33 answers with an x_new_state_res. This exchange gets XIP up and running. Table 31 below summarizes this exchange.
TABLE 31
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
<-- x_new_state_ind
x_new_state_res -->
The first step to sending data is to create an endpoint. Peripheral equipment 33 sends I/O device 34 an x_open_req message which includes the number of the network transport peripheral equipment 33 wants to use. I/O device 34 creates an endpoint data structure, attaches it to the requested transport, and replies with an x_open_ack message. Peripheral equipment 33 can open as many endpoints as it needs at any time it wants to. I/O device 34 may impose an implementation dependent upper limit on the number of endpoints. Table 32 below summarizes this exchange.
TABLE 32
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
x_open_req -->
<-- x_open_ack
XIP supports two classes of transport: connection oriented (a.k.a. stream), and datagram. The discussion below gives steps for transferring data over each. Endpoints are numbered. XIP is designed for "smart" I/O devices which have their own processor and memory. Thus, both peripheral equipment 33 and I/O device 34 maintain a data structure for each endpoint. Each chooses its own 32 bit numbers to address its own data structures. Peripheral equipment 33 and I/O device 34 exchange these numbers during endpoint creation. When peripheral equipment 33 sends a message to an endpoint of I/O device 34, peripheral equipment 33 uses the number of I/O device 34 for that endpoint. When I/O device 34 sends a message to an endpoint of peripheral equipment 33, I/O device 34 includes the number of peripheral equipment 33 for that endpoint. Senders also include their own number for the endpoint. That way, replies can simply be sent back to the endpoint from which they originated. Each endpoint has its own state. Table 33 below gives a summary of the states.
TABLE 33
UNINIT This state is never actually used since
uninitialized endpoints don't exist.
UNBND Endpoint is not bound to a protocol
address.
IDLE Endpoint is bound, but not connected.
This is the data transfer state for
datagram endpoints.
OUTCON Endpoint is in the process of initiating a
connection.
INCON Endpoint has incoming connect requests
pending.
DATAXFER Endpoint is connected and able to transfer
data.
OUTREL Endpoint has performed an orderly
release on the outbound half of the
connection. No more data will be
transmitted, but data may still be
received.
INREL Endpoint has performed an orderly
release on the inbound half of the
connection. No more data will be
received, but data may still be
transmitted.
After creating an endpoint, the next step depends on how peripheral equipment 33 intends to use it. One type of endpoint, stream endpoints, can be used in three different ways. The can be used to initiate outgoing connections, to listen for incoming connections, and to accept incoming connections. To initiate outgoing connections, the endpoint is usually bound to a dynamic address. Peripheral equipment 33 will send an x_bind_req with no address. I/O device 34 will automatically bind the endpoint to an unused local address. If, for some reason, the connection has to originate from a particular address, peripheral equipment 33 will specify that address in the x_bind_req message. To listen for incoming connections, peripheral equipment 33 sends an x_bind_req message with a non-zero connection indication queue length. The queue holds pending connections until peripheral equipment 33 accepts (or rejects) them. Incoming connections are often accepted on a different endpoint than they arrived on. That lets the listening endpoint continue listening for new connections. To accept a pending connect request, the accepting endpoint must be bound to the same address as the listen endpoint on which the connection arrived. If peripheral equipment 33 leaves the endpoint unbound, it will automatically be bound as the connection is accepted. Table 34 below summarizes this exchange.
TABLE 34
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
x_bind_req -->
<-- x_bind_ack
There are two kinds of connection establishment. Active connection occurs when peripheral equipment 33 initiates a connection to a remote host. Passive connection occurs when a remote host initiates a connection to peripheral equipment 33. To initiate an active connection, peripheral equipment 33 sends an x_conn_req message to a previously opened and bound endpoint on I/O device 34. The transport provider on I/O device 34 replies immediately with an x_conn_ack message and begins connecting to remote host 82. The connection is now in progress, but is not fully up yet. It takes time for remote host 82 to receive and respond to the request. Hopefully not too much later, the transport module receives the response, completes the connection, and sends peripheral equipment 33 an x_conf_ind message to confirm it. Now the connection is fully up and peripheral equipment 33 can send data. Table 35 below summarizes this exchange.
TABLE 35
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
x_conn_req -->
<-- x_conn_ack
<-- x_conn_ind
x_accept_req -->
<-- x_accept_ack
To wait for passive connections to arrive, peripheral equipment 33 creates a listen endpoint by specifying a connect queue length in the x_bind_req. The bind will also normally specify the local address since otherwise it is hard for remote host 82 to know what random unused address I/O device 34 picked. When a connect request arrives from a remote host, I/O device 34 sends an x_conn_ind message to peripheral equipment 33. Peripheral equipment 33 picks an endpoint on which to accept the connection and sends back an x_accept_req message. I/O device 34 immediately acknowledges peripheral equipment 33 with an x_accept_ack message and also sends a reply to remote host 82. At this point, the connection is up as far as peripheral equipment 33 is concerned. However, the transport module is still waiting for remote host 82 to confirm the connection. XIP does not include a state for this condition because the TLI API does not recognize this state and does not provide any way to tell the application when the connection is fully up. TLI assumes the connection is up as soon as it receives the x_accept_ack message. Thus, I/O device 34 goes to the DATAXFER state as soon as it sends the x_accept_ack. It may use flow control to prevent peripheral equipment 33 from actually sending data until the connection is fully up. Table 35 below summarizes this exchange.
TABLE 35
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
<-- x_conn_ind
x_accept_req -->
<-- x_accept_ack
One more complication is peripheral equipment 33 may choose to accept a connection two different ways. It may accept on the same endpoint on which the connection arrived or on a different one. Using the same endpoint prevents that endpoint from listening for new connections for the duration of the current connection. To avoid that, peripheral equipment 33 may pass the connection to a different endpoint so the original one can keep listening. Table 36 below summarizes this scenario.
TABLE 36
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
Pass Listen Listen Pass
Endpoint Endpoint Endpoint Endpoint
x_open_req -->
<-- x_open_ack
x_bind_req -->
<-- x_bind_ack
(later)
<-- x_conn_ind
x_open_req -->
<-- x_open_ack
x_accept_req -->
(DATA- <-- x_accept_ack (DATA-
XFER XFER
state) state)
The x_open_req exchange shown in Table 36 above could also be done well in advance of actually accepting the connection. It is up to the application to manage its accepting endpoints. The accepting endpoint also does not have to be bound to an address. In that case, I/O device 34 will automatically bind it to the same address as the listening endpoint. For data transfer, each connection has its own dedicated backplane channel that takes care of sending and receiving data, flow control, etc. XIP does not specify the actual stream data transfer mechanism. Various backplane transfer data differently. Table 37 below sets out an example for the IIO backplane protocol.
TABLE 37
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
PACKET_WRITE -->
<-- PACKET_READ
There are two ways to disconnect a stream: orderly and abortive. Orderly releases are reliable so that both sides know all data was delivered. When one end of the connection is finished sending data, it indicates an orderly release which tells the other end that no more data will be arriving on this connection. When the other end is finished it does the same. When both sides have received a release the connection is considered down. An orderly release is also known as a "half-close" because data can still arrive after sending a release. Abortive releases are unreliable. The connection is terminated immediately with no acknowledgments. Data may be lost! Any data which is queued to be sent may be dropped. Any data received after an abort may be dropped. Either end of the stream can initiate either kind of disconnect. They are called local and remote disconnect to distinguish who initiated it. XIP communicates all types of disconnect with messages on the XIP control channel. Those disconnects also have to be synchronized with data on the data channel. XIP assumes no synchronization between channels so it is possible for control messages to "pass up" data packets leading to race conditions. In some case, these race conditions can even cause data loss. To prevent that, XIP uses an end-of-data marker in the data channel after the last valid data for the connection. The marker travels in the same channel as the data so it remains in the correct place in the data stream. Note that the marker does not initiate the disconnect or cause any endpoint state change. It only provides a synchronization point for the disconnect messages on the control channel. The actual marker mechanism is backplane specific. On IIO, XIP uses the command information field of the IIO packet header. The markers are CI_ACTION_SYNC_END_OF_HOST_DATA (EOHD) for the inbound side and CI_ACTION_END_OF_PERIPHERAL_DATA (EOPD) for the outbound side. Other backplanes will use markers with the similar meanings. EOHD requires peripheral equipment 33 to answer by sending an EOHD acknowledgment (EOHDa) on the outbound side. The EOHDa must not be sent until all data, including any EOPD, is sent. EOPD does not require any answer from I/O device 34. The tables below which describe various releases show the message and flag exchange for each connection termination scenario. Events in the tables below listed in capital letters (CAPS) travel in the data channel. Events in the tables listed in lower case travels in the control channel. The numbers in parenthesis are example EOHD and EOPD sequence numbers. Table 38 below describes a local release.
TABLE 38
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
Data Control Control Data
(normal -->
data flow)
EOPD (10) x_ordrel_re -->
q (10)
<-- x_ordrel_ack
(10)
<-- (possibly
more data)
<-- x_ordrel_ind EOHD (20)
(20)
EOHDa -->
(20)
I/O device 34 may not send a successful x_ordrel_ack until it has received the matching EOPD. Peripheral equipment 33 must receive both the x_ordrel_ind message and its matching EOHD flag before changing state and notifying the application. Peripheral equipment 33 also may not send the EOHDa until it has sent the EOPD. Table 39 below describes a remote release.
TABLE 39
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
Data Control Control Data
<-- (normal
data flow)
<-- x_ordrel_ind EOHD
(20) (20)
(possibly -->
more data)
EOPD (10) x_ordrel_req -->
(10)
EOHDa -->
(20)
<-- x_ordrel_ack
(10)
Peripheral equipment 33 must receive both the x_ordrel_ind message and its matching EOHD flag before changing state and notifying the application. I/O device 34 may not send a successful x_ordrel_ack until it has received the matching EOPD. Table 40 below describes a local abort.
TABLE 40
Messages Initiated by Message Messages Initiated by
Peripheral Equipment 33 Direction I/O device 34
Data Control Control Data
(normal -->
data flow)
x_discon_req -->
<-- x_discon_ack EOHD
(20) (20)
EOHDa -->
(20)
After sending the x_discon_req, peripheral equipment 33 may drop all data until it sees the x_discon_ack and the EOHD with the matching number (20 in this example). After receiving the x_discon_req, peripheral equipment 33 may drop all data until it sees the EOHDa with the matching number (20 in this example). Table 41 below describes a remote abort.
TABLE 41
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
Data Control Control Data
<-- (normal
data flow)
<-- x_discon_ind EOHD
(20) (20)
EOHDa -->
(20)
After sending the x_discon_ind, I/O device 34 may drop all data until it sees the EOHDa with the matching number (20 in this example). After receiving the x_discon_ind, peripheral equipment 33 may drop all data until it sees the EOHD with the matching number (20 in this example). Table 42 below describes the interchange for transport down. When an I/O device transport protocol module goes down, I/O device 34 aborts all connections and closes all endpoints associated with that transport. There are no XIP messages for each endpoint. Everything is implicit in the x_new_state_ind message. However, I/O device 34 must send an EOHD flag on each channel connected to that transport which had an established connection. Peripheral equipment 33 should treat this as a remote abort on each affected endpoint. When the transport module comes back up, I/O device 34 sends another x_new_state_ind message. None of the endpoints for other transports should be affected by either message.
TABLE 42
Messages Initiated by
Peripheral Equipment Message Messages Initiated by I/O
33 Direction device 34
Data Control Control Data
(xport down)
<-- x_new_state EOHD
_ind (20) (20)
EOHDa x_new_state -->
(20) _res (20)
(xport back up)
<-- x_new_state
_ind (20)
x_new_state -->
res (20)
I/O device 34 sends an EOHD on every channel whose endpoint was in DATAXFER, INREL, or OUTREL state and whose transport went down. Peripheral equipment 33 must acknowledge the EOHD on every channel with an EOHDa containing the same sequence number. Sequence numbers must always increase, and this number is shared by all channels, so I/O device 34 must choose one bigger than the maximum number used on all affected channels. Table 43 below illustrated connection reject. In rare situations either end may reject a connect request. The application in peripheral equipment 33 may reject a passive connect or remote host 82 may reject an active connect. Peripheral equipment 33 rejects a passive connect by sending an x_discon_req instead of an x_accept_req.
TABLE 43
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
<-- x_conn_ind
x_discon_req -->
<-- x_discon_ack
I/O device 34 indicates that remote host 82 rejected an active connect by sending an x_discon_ind instead of an x_conf_ind. This is illustrated by Table 44 below.
TABLE 44
Message Messages Initiated by I/O
Peripheral Direction device 34
x_conn_req -->
<-- x_conn_ack
<-- x_discon_ind
In reject cases, the endpoint never made it to DATAXFER state so there is no need to synchronize the data channel. I/O device 34 does not need to send an EOHD marker. Datagram endpoints are created with x_open_req, just like stream endpoints. What makes them different is they are connected to a datagram transport instead. Datagram endpoints have the option to use a dedicated channel or the XIP control channel for their data transfer. After creating a datagram endpoint, peripheral equipment 33 sends an x_bind_req message to give the endpoint a local address. As with stream endpoints, peripheral equipment 33 may specify the address or allow I/O device 34 to assign an unused one. When the endpoint will use a dedicated channel for data transfer, each x_bind_req on that endpoint must contain a unique bind sequence number. The same number is used in every x_unitdata_out and x_unitdata_in message. Otherwise, if peripheral equipment 33 rebinds the endpoint, there is a race condition where a stale packet in the data channel can be delivered to the wrong address. This is illustrated by Table 45 below.
TABLE 45
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
x_open_req -->
<-- x_open_ack
x_bind_req -->
<-- x_bind_ack
Datagrams may be transferred over a dedicated backplane channel or over the XIP control channel. The message is exactly the same for both. Every packet on the data channel has an XIP message header that includes the remote address. The advantage to using dedicated channels is peripheral equipment 33 can manage buffers differently. It could, for example, use larger buffers on the dedicated channels to increase datagram throughput. It can also prevent one endpoint from starving others for control channel buffers. When using dedicated channels, every datagram message header must also include a bind sequence number. This is the same number assigned by peripheral equipment 33 in the most recent x_bind_req on this endpoint. Peripheral equipment 33 and I/O device 34 drop all datagrams that don't match the latest bind sequence number to avoid the stale datagram race condition. This is illustrated by Table 46 below.
TABLE 46
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
x_unitdata_out -->
<-- x_unitdata_in
Table 47 below illustrates deinitialization. When peripheral equipment 33 is done with a particular transport address it may unbind that address from the endpoint with an x_unbind_req message. Peripheral equipment 33 may then rebind the endpoint to a different address or close it.
TABLE 47
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
x_unbind_req -->
<-- x_unbind_ack
When peripheral equipment 33 is done with an endpoint it removes that endpoint with an x_close_req message. This is illustrated by Table 48.
TABLE 48
Messages Initiated by Message Messages Initiated by I/O
Peripheral Equipment 33 Direction device 34
x_close_req -->
<-- x_close_ack
Each endpoint is controlled by an endpoint state machine. Table 33 above shows the states in the endpoint state machine. Table 49 below shows what request messages peripheral equipment 33 may send to an endpoint in each state.
TABLE 49
DAT
OUT IN AXFE OUT IN
UNINIT UNBND IDLE CON CON R REL REL
x_open_req YES
x_ep_info_req YES YES YES YES YES YES YES
x_bind_req YES
x_unitdata_out YES
x_conn_req YES
x_accept_req YES
x_ordrel_req YES YES
x_dison_req YES YES YES YES YE
x_unbind_req YES
x_close_req YES
Table 50 below shows what asynchronous messages I/O device 34 may send to an endpoint in each state. (It does not show acknowledgment messages. They are always sent in response to a peripheral request.)
TABLE 50
UN UN OUT IN DATA OUT
IN
INIT BND IDLE CON CON XFER REL
REL
x_unitdata_in YES
x_conn_ind YES YES
x_conf_ind YES
x_ordrel_ind YES YES
x_discon_ind YES YES YES YES
YES
x_new_state_ind YES YES YES YES YES YES YES
YES
Table 51 below shows the state transitions caused by various events. XIP changes states on _IND and successful _ACK messages. It does not 10 change state on _REQ messages or _ACK messages with a non-zero result code.
TABLE 51
UN UN OUT IN DATA OUT IN
INIT BND IDLE CON CON XFER REL REL
x_open_ack UN
BND
x_bind_ack IDLE
x_unitdata_in IDLE
x_unitdata_out IDLE
x_conn_ack OUT
CON
x_conf_ind DATA
XFER
x_conn_ind IN IN
CON CON
x_accept_ack IDLE
1,2
<pass conn>3 DATA DATA
XFER XFER
x_ordrel_ack OUT
IDLE
REL
x_ordrel_ind IN IDLE
REL
x_discon_ack IDLE IDLE2 IDLE IDLE
IDLE
x_discon_ind IDLE IDLE2 IDLE IDLE
IDLE
x_unbind_ack UN
BND
x_close_ack UN
INIT
x_new_s | ||||||