blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
3.2.4 Decompressor processing 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 is TYPE_ERROR or an unrecognized type, a `toss' flag is set in the state to force COMPRESSED_TCP packets to be discarded until one with the C bit set or an UNCOMPRESSED_TCP packet arrives. Nothing (a null packet) is returned.

  • If the packet is TYPE_IP, an unmodified copy of it is returned and the state is not modified.

  • If the packet is UNCOMPRESSED_TCP, the state index from the IP protocol field is checked./24/ If it's illegal, the toss flag is set and nothing is returned. Otherwise, the toss flag is cleared, the index is copied to the state's last connection received field, a copy of the input packet is made,/25/ the TCP protocol number is restored to the IP protocol field, the packet header is copied to the indicated state slot, then the packet copy is returned.
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:
  • If the C bit is set in the change mask, the state index is checked. If it's illegal, the toss flag is set and nothing is returned. Otherwise, last connection received is set to the packet's state index and the toss flag is cleared.

  • If the C bit is clear and the toss flag is set, the packet is ignored and nothing is returned.
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'.)
  • The next two bytes in the incoming packet are the TCP checksum. They are copied to the saved header.

  • If the P bit is set in the change mask, the TCP PUSH bit is set in the saved header. Otherwise the PUSH bit is cleared.

  • If the low order four bits (S, A, W and U) of the change mask are all set (the `unidirectional data' special case), the amount of user data in the last packet is calculated by subtracting the TCP and IP header lengths from the IP total length in the saved header. That amount is then added to the TCP sequence number in the saved header.

  • If S, W and U are set and A is clear (the `terminal traffic' special case), the amount of user data in the last packet is calculated and added to both the TCP sequence number and ack fields in the saved header.

  • Otherwise, the change mask bits are interpreted individually in the order that the compressor set them:

    • If the U bit is set, the TCP URG bit is set in the saved header and the next byte(s) of the incoming packet are decoded and stuffed into the TCP Urgent Pointer. If the U bit is clear, the TCP URG bit is cleared.

    • If the W bit is set, the next byte(s) of the incoming packet are decoded and added to the TCP window field of the saved header.

    • If the A bit is set, the next byte(s) of the incoming packet are decoded and added to the TCP ack field of the saved header.

    • If the S bit is set, the next byte(s) of the incoming packet are decoded and added to the TCP sequence number field of the saved header.

  • If the I bit is set in the change mask, the next byte(s) of the incoming packet are decoded and added to the IP ID field of the saved packet. Otherwise, one is added to the IP ID.

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

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609