Connected: An Internet Encyclopedia
3.2.4 Decompressor processing

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1144
Up: 3 The compression algorithm
Up: 3.2 The ugly details
Prev: 3.2.3 Compressor processing
Next: 4 Error handling

3.2.4 Decompressor processing

3.2.4 Decompressor processing

Because of the simplex communication model, processing at the decompressor is much simpler than at the compressor --- all the decisions have been made and the decompressor simply does what the compressor has told it to do.

The decompressor is called with the incoming packet,/22/ the length and type of the packet and the compression state structure for the incoming serial line. A (possibly re-constructed) IP packet will be returned.

The decompressor can receive four types of packet: the three generated by the compressor and a TYPE_ERROR pseudo-packet generated when the receive framer detects an error./23/ The first step is a `switch' on the packet type:

If the packet was not handled above, it is COMPRESSED_TCP and a new TCP/IP header has to be synthesized from information in the packet plus the last packet's header in the state slot. First, the explicit or implicit connection number is used to locate the state slot: At this point, last connection received is the index of the appropriate state slot and the first byte(s) of the compressed packet (the change mask and, possibly, connection index) have been consumed. Since the TCP/IP header in the state slot must end up reflecting the newly arrived packet, it's simplest to apply the changes from the packet to that header then construct the output packet from that header concatenated with the data from the input packet. (In the following description, `saved header' is used as an abbreviation for `the TCP/IP header saved in the state slot'.)

At this point, all the header information from the incoming packet has been consumed and only data remains. The length of the remaining data is added to the length of the saved IP and TCP headers and the result is put into the saved IP total length field. The saved IP header is now up to date so its checksum is recalculated and stored in the IP checksum field. Finally, an output datagram consisting of the saved header concatenated with the remaining incoming data is constructed and returned.


Next: 4 Error handling

Connected: An Internet Encyclopedia
3.2.4 Decompressor processing