📄 rfc914.txt
字号:
Farber & Delp & Conte [Page 6] RFC 914 September 1984Thinwire ProtocolAppendix A -- Example of Thinwire I Compression Here is an example of how Thinwire I would operate in a common situation. The connection is a TCP/IP Telnet connection. The first TCP/IP Telnet packet is on the next page; it simulates the typing of the character "a". The second packet would be produced by typing "d"; it is shown on the following page. The compressed version is on the third page following. [NOTE: The checksums pictured have not been calculated. Binary in MSB to LSB format]Farber & Delp & Conte [Page 7] RFC 914 September 1984Thinwire Protocol 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header:|Version| IHL |Type of Service| Total Length | |0 1 0 0|0 1 0 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0|P | 4 | 5 | 0 | 41 |a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c | Identification |Flags| Fragment Offset |k |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0|e | 1 | 0 | 0 |t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Time to live | Protocol | Header Checksum |1 |0 1 1 0 0 1 0 1|0 0 0 0 0 1 1 0|0 1 1 1 0 1 1 1 0 0 0 1 0 1 0 0| | 101 | 6 | nnn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | |1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 1 1 0 0 0 1 0 1 0 0| | 192. | 5. | 39. | 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | |0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0| | 10. | 2. | 0. | 52 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header:| Source Port | Destination Port | |0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1| | 1025 | 27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 0 0| | 300 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0| | 100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |offset | Reserved |U A P R S F| Window | |0 1 0 1|0 0 0 0 0 0|0 1 0 0 0 0|0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| | 5 | 0 | 16 | 512 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | |0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| | nnn | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |0 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| | "a" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Farber & Delp & Conte [Page 8] RFC 914 September 1984Thinwire Protocol 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header:|Version| IHL |Type of Service| Total Length | |0 1 0 0|0 1 0 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0| | 4 | 5 | 0 | 41 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P | Identification* |Flags| Fragment Offset |a |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0|c | 2 | 0 | 0 |k +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e | Time to live*| Protocol | Header Checksum* |t |0 1 1 0 0 1 1 0|0 0 0 0 0 1 1 0|0 1 1 1 0 1 1 1 0 0 0 1 0 1 0 0|- | 102 | 6 | nnn |2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | |1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 1 1 0 0 0 1 0 1 0 0| | 192. | 5. | 39. | 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | |0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0| | 10. | 2. | 0. | 52 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header:| Source Port | Destination Port | |0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1| | 1025 | 27 |* 's +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+show | Sequence Number* |changed|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 0 1|fields | 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number* | |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 1| | 101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |offset | Reserved |U A P R S F| Window | |0 1 0 1|0 0 0 0 0 0|0 1 0 0 0 0|0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| | 5 | 0 | 16 | 512 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum* | Urgent Pointer | |0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| | nnn | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data* | |0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| | "d" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Farber & Delp & Conte [Page 9] RFC 914 September 1984Thinwire Protocol The Thinwire Driver finds the template (which is the previous packet sent), compares the template to the packet and creates a change message (field names of change record data have been added for comparison): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Descriptor byte| Data: |Descriptor byte| Data: | |offset |length | Identification|offset |length | Time to live | |0 0 1 0|0 0 0 1|0 0 0 0 0 0 1 0|0 0 1 0|0 0 0 1|0 1 1 1 0 1 1 0| | 2 | 1 | 2 | 2 | 1 | 102 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Descriptor byte| Data: |Descriptor byte| | offset| length| Header Checksum |offset |length | |0 0 1 0|0 0 1 0|1 1 1 1 0 0 1 0 1 0 1 1 0 1 0 0|1 1 1 1|0 0 1 0| | 2 | 2 | nn | 15 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data: |Descriptor byte| Data: |Descriptor byte| | Seq Number |offset |length | Ack Number |offset |length | |0 0 1 0 1 1 0 1|0 0 1 1|0 0 0 1|0 1 1 0 0 1 0 1|0 1 1 1|0 0 1 0| | 301 | 3 | 1 | 101 | 7 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data: |Descriptor byte| Data: | | -- TCP Checksum -- |offset |length | data | |0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|0 0 1 0|0 0 0 1|0 1 1 0 0 1 0 0| | nn | 2 | 1 | "d" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Descriptor byte| |offset |length | |0 0 0 0|0 0 0 0| the 0 0 offset/length record ends the update. | 0 | 0 | +-+-+-+-+-+-+-+-+ Thinwire I then sends this message over the line where the previous packet is updated to form the new packet. Note: One can see that a series of null descriptor bytes will reset the connection.Farber & Delp & Conte [Page 10] RFC 914 September 1984Thinwire ProtocolAppendix B -- Examples of Thinwire II Compression This Appendix provides an example of how the Thinwire II would operate in a common situation. The same original packets are used as in Appendix A, so only the updates are shown. As the later field definitions depend on the contents of earlier fields, a field by field analysis of the update packets will be useful. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thinwire II |U|L|Template no| Len of change | Type of Packet| minimum |0|0|0 0 0 1 0 1|0 0 0 1 1 0 0 1|0 0 0 0 0 0 0 1| header: |N N| 5 | 41 | TCP/IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first bit is the UPDATE bit. If it is a 0 this packet describes a new template, and the entire new packet is included, following the header. If there was a previous template with the same number, it will be cleared and replaced by the new template. If the UPDATE bit is a 1, then this packet should be used to update the template with the number given in the template number field. The second bit is the LONG bit. If it is a 1 it indicates a LONG packet. This means that the update length field will be 16 bits instead of 8 bits. The remaining 6 bits in the first byte indicate the template number that this packet is an update to. The template number is followed by 1 or 2 bytes (depending on the value of the LONG bit) which give the length of the packet. This is the number of data bytes following the variable length header. If the UPDATE bit is 0 on this packet, the next byte will be a flag telling what type of packet the sender thinks this packet is. The flag will be saved by the receiver to interpret the update packets. Type 0 is for unknown types. If the type 0 flag is set, there will be no updates to this template number. Type 1 is TCP/IP; the method of updating will be described below. Type 2 is UDP/IP; the method of update is not described at this time. At this time we have enough information to encode packet 1 of the example. Assuming for the moment that this is the first packet for this connection, the UPDATE bit would be set to 0. As the packet has a length of 41 and so can be described in 8 bits, the LONG bit would be set to 0. A template number not in use (or the oldest in useFarber & Delp & Conte [Page 11] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -