gtpc1m1gTransmission Control Protocol/Internet Protocol

Inbound Message Flow

Inbound message flow involves the following steps:

  1. The CDLC IP router or the OSA-Express card sends packets to the TPF system.
  2. The IP trace read processing routine starts to process the packets and, sometimes, processes packets completely.
  3. IP Opzero continues processing packets that contain user data.
  4. The protocol layer (TCP Opzero, UDP Opzero, or RAW Opzero) either queues the input message off the socket or passes the data to the application if a read-type API call is pending.
  5. If a read-type API call is not pending when the data is processed by Opzero, the socket API processing layer dequeues the data and passes it to the application later on when the application does issue a read-type API.

When packets are received from a CDLC IP router or OSA-Express card, each packet is passed to the IP trace read processing routine. This routine determines which socket the packet is for and completely processes certain control information, such as TCP connection requests and standalone acknowledgements of TCP data. Packets are added to the IP trace table if the IP trace function is active for those sockets.

Packets that are not completely processed by the IP trace read processing routine (which includes all packets that contain user data), are passed via the TPF input list to IP Opzero. The main function of IP Opzero is to put fragmented messages back together. When a packet is too large to be sent across a physical network, the packet is split into smaller packets. The final destination must then put the pieces back together before delivering the message to the protocol layer. Whenever possible, tune your network to avoid IP fragmentation to prevent the overhead involved in the IP router splitting up the packet and the IP Opzero overhead involved in reassembling the message.

The protocol layer (TCP Opzero, UDP Opzero, or RAW Opzero) is responsible for queuing the input message or passing it directly to the application if a read-type API call is pending on the socket.

TCP Opzero does the following:

  1. If the data is old (which means this is a duplicate packet), the data is discarded.
  2. If the data is received out of order (which means the sequence number of the start of this data is not the next expected sequence number), the data is queued until it becomes the next expected piece of data.
  3. If there is a read, recv, or recvfrom API call pending for this socket, the suspended ECB is posted. When the application ECB is reactivated, the socket API processing layer copies the data from the link layer read buffer to the application work area specified on the read-type API call. If more data is in the packet than will be received by the application, the excess data is queued in the receive buffer of the socket.
  4. If there is an activate_on_receipt API call pending for the socket, a new ECB is created, the data is copied to the new ECB, and the application program specified on the activate_on_receipt API call is activated. If more data is in the packet than will be received by the application, the excess data is queued in the receive buffer of the socket.
  5. If there is no read, recv, recvfrom, or activate_on_receipt API call pending for the socket, the data is queued in the receive buffer of the socket.

UDP Opzero does the following:

  1. If there is no available space in the receive buffer of the socket to queue the input message, the input message is discarded. Remember, there is no flow control for UDP sockets.
  2. If there is a read, recv, or recvfrom API call pending for this socket, the suspended ECB is posted. When the application ECB is reactivated, the socket API processing layer copies the input message from the link layer read buffer to the application work area specified on the read-type API call.
  3. If there is an activate_on_receipt API call pending for the socket, a new ECB is created, the input message is copied to the new ECB, and the application program specified on the activate_on_receipt API call is activated.
  4. If there is no read, recv, recvfrom, or activate_on_receipt API call pending for the socket, the input message is queued in the receive buffer of the socket.

RAW Opzero does the following:

  1. Processes control messages; for example, ICMP ECHO requests (PING messages) and ICMP errors.
  2. Copies the input message to the receive buffer of each RAW socket whose protocol matches the protocol of the input message.
  3. After copying the input message, if there is a read, recv, or recvfrom API call pending for this socket, the suspended ECB is posted.
  4. If there is an activate_on_receipt API call pending for the socket, a new ECB is created, the input message is copied to the new ECB, and the application program specified on the activate_on_receipt API call is activated.