Installation guide

84 DC 900-1325I
Freeway Server-Resident Application (SRA) Programmer Guide
6.4 Filter Restrictions
Filters are limited in what they can and can’t do, and some of these restrictions are
described in this section. Most notable among these is the issue of byte ordering.
As mentioned in Section 6.3, the pointer received as a parameter by a filter function
points at the ICP header, which is always in network byte order. The protocol header
and data, however, are in the native byte ordering of the machine on which the client
application resides. This is important because a function may only want to filter packets
that contain actual data, and bypass ICP control packets (such as configuration
requests). Thus, the command in the protocol header might need to be scanned, and
therefore the filter function must know the byte ordering of the protocol header. Also, if
the data is not a byte-oriented stream (for example, not character data), the filter might
need to perform byte swapping when modifying the data portion of the packet.
On packets being sent to the WAN, the status field of the ICP header indicates the byte
ordering. Zero indicates big-endian byte ordering, while 0x4000 indicates little-endian
byte ordering. However, on packets being received from the WAN, there is no such indi-
cation because the status field contains the ICP error indication!
If the byte ordering of the receiving machine is not known in advance, the only way for
a filter to determine “on the fly” what byte ordering is used in a packet from the WAN
is by duplicating the method used in the ICP boards. A global table should be main-
tained that is accessible by both filter functions (that is, the “to WAN” filter function
and the “from WAN” filter function). Attach requests to the ICPs should be intercepted,
and an entry made into the table that cross references the session with the byte order
used. The “from WAN” filter can then determine the byte ordering of any packet it
receives based on the table entries. The “from WAN” filter should also intercept
responses to detach requests, and clear the corresponding table entries when it detects
such packets. (Table entries should also be cleared if an attach request response indi-
cates an error, in which case the attach was unsuccessful.) Contact Protogate’s Customer