RFC914 日本語訳
0914 Thinwire protocol for connecting personal computers to theInternet. D.J. Farber, G. Delp, T.M. Conte. September 1984. (Format: TXT=57288 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group David J. Farber
Request for Comments: 914 Gary S. Delp
Thomas M. Conte
University of Delaware
September 1984
コメントを求めるワーキンググループデヴィッドJ.ファーバーの要求をネットワークでつないでください: 914 ゲーリーS.デルプトーマスM.コンテデラウエア大学1984年9月
A Thinwire Protocol
for connecting personal computers
to the INTERNET
パーソナルコンピュータをインターネットに接続するためのThinwireプロトコル
Status of this Memo
このMemoの状態
This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards. Distribution of this memo unlimited.
このRFCはパーソナルコンピュータがある低速ネットワーク相互接続のARPA-インターネット、およびソリューションの可能なメソッドで特定の問題に議論の焦点を合わせます。 提案されたソリューションのいずれもARPA-インターネットの規格として本書では意図しません。 むしろ、全体的な合意が適切なソリューションに関して問題に現れることが望まれています、結局規格の採用に通じて。 メモこれほど無制限の分配。
What is the Problem Anyway ?
Problem Anywayは何ですか?
As we connect workstations and personal computers to the INTERNET, many of the cost/speed communication tradeoffs change. This has made us reconsider the way we juggle the protocol and hardware design tradeoffs. With substantial computing power available in the $3--10K range, it is feasible to locate computers at their point of use, including in buildings, in our homes, and other places remote from the existing high speed connections. Dedicated 56k baud lines are costly, have limited availability, and long lead time for installation. High speed LAN's are not an applicable interconnection solution. These two facts ensure that readily available 1200 / 2400 baud phone modems over dialed or leased telephone lines will be an important part of the interconnection scheme in the near future. This paper will consider some of the problems and possibilities involved with using a "thin" (less than 9600 baud) data path. A trio of "THINWIRE" protocols for connecting a personal computer to the INTERNET are presented for discussion.
私たちがワークステーションとパーソナルコンピュータをインターネットに接続するとき、費用/速度コミュニケーション見返りの多くが変化します。 これで、私たちは私たちがプロトコルとハードウェアデザイン見返りを操る方法を再考しました。 $3--10K範囲で利用可能なかなりのコンピューティングパワーで、それらの使用のポイントでコンピュータの場所を見つけるのは可能です、ビル、存在から遠く離れた私たちのホーム、および他の場所に高速接続を含んでいて。 ひたむきな56kボー系列は、高価であり、有用性を制限して、長い間、インストールのための時間を導きます。 LANの高速ものは適切なインタコネクトソリューションではありません。 これらの2つの事実が、ダイヤルされたか賃貸された電話回線の上の1200 / 2400個の容易に利用可能なボー電話モデムが近い将来のインタコネクト体系の重要な部分になるのを確実にします。 この紙は「薄い」(9600年未満のボー)データ経路を使用するのにかかわる問題と可能性のいくつかを考えるでしょう。 パーソナルコンピュータをインターネットに接続するための"THINWIRE"プロトコルの三つ組は議論のために紹介されます。
Although the cost and flexibility of telephone modems is very attractive, their low speed produces some major problems. As an example, a minimum TCP/IP Telnet packet (one character) is 41 bytes long. At 1200 baud, the transmission time for such a packet would be around 0.3 seconds. This is equivalent to using a 30 baud line for single character transmission. (Throughout the paper, the assumption is made that the transmission speed is limited only by the speed of the communication line. We also assume that the line will act as a synchronous link when calculating speed. In reality, with interrupt, computational, and framing overhead, the times could be 10-50% worse.)
電話モデムの費用と柔軟性は非常に魅力的ですが、それらの低速はいくつかの大した問題を生産します。例として、最小のTCP/IP Telnetパケット(1つのキャラクタ)は41バイト長です。 1200年のボーでは、そのようなパケットのためのトランスミッション時間はおよそ0.3秒でしょう。 これはただ一つのキャラクタトランスミッションに30ボー系列を使用するのに同等です。 (紙中では、伝送速度が通信回線の速度だけによって制限されるという仮定はされます。 また、私たちは、速度について計算するとき、系列が同期リンクとして機能すると思います。 中断によるほんとうはコンピュータと、オーバーヘッドを縁どっていて、回は10-50%より悪いかもしれません。)
In many cases, local echo and line editing can allow acceptable
多くの場合、ローカルエコーと系列編集が許容できる、許容できる。
Farber & Delp & Conte [Page 1]
ファーバー、デルプ、およびコンテ[1ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
Telnet behavior, but many applications will work only with character at a time transmission. In addition, multiple data streams can be very useful for fully taking advantage of the personal computer/Internet link. Thus this proposal.
しかし、telnetの振舞い、多くのアプリケーションが一度にキャラクタだけと共にトランスミッションを扱うでしょう。 さらに、複数のデータ・ストリームが非常にパーソナルコンピュータ/インターネットリンクの完全に取っている利点の役に立つ場合があります。 その結果、この提案。
There are several forms that a solution to this problem can take. Three of these are listed below, followed by descriptions of possible solutions of each form.
この問題への解決が取ることができる数個の形があります。 それぞれのフォームの可能なソリューションの記述があとに続いていて、これらの3は以下に記載されています。
o As a non-solution, one can learn to live with the slow
communication (possibly a reasonable thing to do for background
file transfer and one-time inquiries to time, date, or
quote-of-the-day servers).
o 非ソリューションとして、人は、遅いコミュニケーション(ことによるとバックグラウンドファイル転送と1回の問い合せのために時間、日付、または今日の名言サーバにする妥当なこと)を受け入れることを学ぶことができます。
o Using TCP/IP, one can intercept the link level transmissions,
and try various kinds of compression algorithms. This provides
for a symmetrical structure on either side of the "Thinwire".
o TCP/IPを使用して、ものは、リンク・レベル送信を妨害して、様々な種類の圧縮アルゴリズムを試みることができます。これは"Thinwire"のどちらかの側の対称の構造に備えます。
o One could build an "asymmetrical" gateway which takes some of
the transport and network communication overhead away from both
the serial link and the personal computer. The object would be
to make the PC do the local work, and to make the
interconnection with the extended network a benefit to the PC
and not a drain on the facilities of the PC.
o 人は連続のリンクとパーソナルコンピュータの両方から遠くで輸送とネットワークコミュニケーションオーバーヘッドのいくつか取る「非対称的な」ゲートウェイを建設できました。 オブジェクトは、PCに地方の仕事をさせて、PCの施設の上で拡大ネットワークがあるインタコネクトをドレインではなく、PCへの利益にすることになっているでしょう。
The first form has the advantage of simplicity and ease of implementation. The disadvantages have been discussed above. The second form, compression at link level, can be exploited in two ways.
最初のフォームには、簡単さの利点と実装の容易さがあります。 上で損失について議論しました。 2つの方法で、2番目のフォーム(リンク・レベルにおける圧縮)を利用できます。
Thinwire I is a simple robust compressor, which will reduce the 41
byte minimum TCP/IP Telnet packets to a series of 17 byte update
packets. This would improve the effective baud rate from 30 baud
to 70 baud over a 1200 baud line (for single character packets).
Thinwire Iは簡単な強健なコンプレッサーです。(そのコンプレッサーは41バイトの最小のTCP/IP Telnetパケットを一連の17バイトのアップデートパケットに変えるでしょう)。 これは1200年のボー系列(単一のキャラクタパケットのための)の上で30ボーから70ボーまで有効なボーレートを改良するでしょう。
Thinwire II uses a considerably more complex technique, and takes
advantage of the storage and processing power on either side of
the thinwire link. Thinwire II will compress packets from
multiple TCP/IP connections from 41 bytes down to 13 bytes. The
increased communication rate is 95 (effective) baud for single
character packets.
Thinwire IIはthinwireリンクのどちらの側面でもかなり複雑なテクニックを使用して、ストレージと処理能力を利用します。 Thinwire IIは複数のTCP/IP接続からパケットを41バイトから13バイトまで圧縮するでしょう。 増強されたコミュニケーションレートは単一のキャラクタパケットのための95の(有効)のボーです。
The third form balances the characteristics of the personal computer, the communications line, the gateway, and the Internet protocols to optimize the utility of the communications and the workstation itself. Instead of running full transport and internet layers on the PC, the PC and the gateway manage a single reliable stream, multiplexing data on this stream with control requests. Without the interneting and flow control structures traveling over the communications line on a per/packet basis, the data flow can be
3番目のフォームは、コミュニケーションとワークステーション自体に関するユーティリティを最適化するためにパーソナルコンピュータの特性、コミュニケーション系列、ゲートウェイ、およびインターネットプロトコルのバランスをとっています。 完全な輸送とインターネット層をPCに動かすことの代わりに、PCとゲートウェイはただ一つの信頼できるストリームを管理します、コントロール要求と共にこのストリームに関するデータを多重送信して。 /パケット基礎あたりのaをコミュニケーション系列の上を移動するinternetingとフロー制御構造がなければ、データフローはそうであることができます。
Farber & Delp & Conte [Page 2]
ファーバー、デルプ、およびコンテ[2ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
compressed a great deal. As there is some switching overhead, and a reliable link level protocol is needed on the serial line, the average effective baud rate would be in the 900 baud range.
多くを圧縮しました。 何らかの切り換えオーバーヘッドがあって、信頼できるリンク・レベルプロトコルがシリアル・ラインの上で必要であるように、平均した有効なボーレートが900ボー範囲にあるでしょう。
Each of these Thinwire possibilities will be explored in detail.
それぞれのこれらのThinwireの可能性は詳細に探られるでしょう。
Thinwire I
Thinwire I
The simplest technique for the compression of packets which have similar headers is for both the transmitting and receiving host to store the most recent packet and transmit just the changes from one packet to the next. The updated information is transmitted by sending a packet including the updated information along with a description of where the information should be placed. A series of descriptor-data blocks would make up the update packet. The descriptor consists of the offset from the last byte changed to the start of the data to be changed and a count of the number of data bytes to be substituted into the old template. The descriptor is one byte long, with two four bit fields; offsets and counts of up to 15 bytes can be described. In the most pathological case the descriptor adds an extra byte for every 15 bytes (or a 6% expansion).
同様のヘッダーがあるパケットの圧縮のための最も簡単なテクニックは、伝えるのと受信ホストの両方が最新のパケットを保存して、まさしく1つのパケットから次までの変化を伝えることです。 アップデートされた情報は、情報が置かれるべきであるところに関する記述に伴うアップデートされた情報を含むパケットを送ることによって、伝えられます。 一連の記述子データ・ブロックがアップデートパケットを作るでしょう。 記述子は、古いテンプレートに代入するために変えるためにデータの始まりに変わる最後のバイトからのオフセットとデータ・バイトの数のカウントから成ります。 記述子は2時4分による長さ1バイトの噛み付いている分野です。 オフセットと最大15バイトのカウントについて説明できます。 最も病理学的な場合では、記述子は15バイト(または、6%の拡張)毎の付加的なバイトを加えます。
An example of Thinwire I in action is shown in Appendix A. A sequence of two single character TCP/IP Telnet packets is shown. The "update" packet which would actually be transmitted is shown following them. Each Telnet packet is 41 bytes long; the typical update is 17 bytes. This technique is a useful improvement over sending entire packets. It is also computationally simple. It suffers from two problems: the compression is modest, and, if there is more than one class of packets being handled, the assumption of common header information breaks down, causing the compression of each class to suffer.
動作中のThinwire Iに関する例はAppendixに2つの単一のキャラクタTCP/IP TelnetパケットのA.A系列が示されるのが示されます。 実際に伝えられる「アップデート」パケットはそれらに続くのが示されます。 それぞれのTelnetパケットは41バイト長です。 典型的なアップデートは17バイトです。 このテクニックは送付の全体のパケットの上の役に立つ改良です。 また、それも計算上簡単です。 それは2つの問題に苦しみます: 圧縮は穏やかです、そして、扱われる1つ以上のクラスのパケットがあれば、一般的なヘッダー情報の仮定に失敗します、それぞれのクラスの圧縮に苦しむことを引き起こして。
Thinwire II
Thinwire II
Both of the problems described above suggest that a more computationally complex protocol may be appropriate. Any major improvement in data compression must depend on knowledge of the protocols being used. Thinwire II uses this knowledge to accomplish two things. First, the packets are sorted into classes. The packets from each TCP connection using the thinwire link, would, because of their header similarities, make up a class of packets. Recognizing these classes and sorting by them is called "matching templates". Second, knowledge of the protocols is used to compress the updates. A bitfield indicating which fields in the header have changed, followed only by the changed fields, is much shorter than the general form of change notices. Simple arithmetic is allowed, so 32 bit
上で説明された問題の両方が、計算上より複雑なプロトコルが適切であるかもしれないと示唆します。 データ圧縮におけるどんな全面的な改良も使用されるプロトコルに関する知識によらなければなりません。 Thinwire IIは、2つのものを達成するのにこの知識を使用します。 まず最初に、パケットはクラスに分類されます。 thinwireリンクを使用しているそれぞれのTCP接続からのパケット、それらのヘッダーの類似性のために、パケットのクラスを構成しているでしょう。 それらによるこれらのクラスとソーティングを認識するのは「合っているテンプレート」と呼ばれます。 2番目に、プロトコルに関する知識は、アップデートを圧縮するのに使用されます。 ヘッダーのどの分野が変化したかを示す変えられた分野だけがあとに続くbitfieldは一般的な形式に関する変更通知よりはるかに短いです。 簡単な演算が許されているので、32に噛み付きました。
Farber & Delp & Conte [Page 3]
ファーバー、デルプ、およびコンテ[3ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
fields can often be updated in 8 or 16 bits. By using the sorting, protocol-specific updating, Thinwire II provides significant compression.
8ビットか16ビットで分野をしばしばアップデートできます。 分類していて、プロトコル特有のアップデートを使用することによって、Thinwire IIは重要な圧縮を提供します。
A typical transaction is described in Appendix B. The "template matching" is based on the unchanging fields in each class of packet. A TCP/IP packet would match on the following fields: network type field(IP), version, type of service, protocol(TCP), and source and destination address and port. Note that the 41 bytes have been reduced to 13 bytes. An additional advantage is that multiple classes of packets can be transported across the same line without affecting the compression of each other, just by matching and storing multiple templates.
典型的なトランザクションはAppendix B.で説明されます。「テンプレート照合」はそれぞれのクラスのパケットの変らない分野に基づいています。 TCP/IPパケットは以下のフィールドで合っているでしょう: タイプ分野(IP)、バージョン、サービスのタイプ、プロトコル(TCP)、ソース、送付先アドレス、およびポートをネットワークでつないでください。 41バイトが13バイトまで減少したことに注意してください。 追加利点は同じ系列の向こう側に互いの圧縮に影響しないで複数のクラスのパケットを輸送できるということです、マルチテンプレートを合わせて、保存するだけで。
Some of the implications of this system are:
このシステムの含意のいくつかは以下の通りです。
o The necessity of saving several templates (one for each
TCP/IP connection ) means that there will be a relatively
large memory requirement. This requirement for current
personal computers is reasonable. In addition, the gateway
must keep tables for several connections at a time.
o 数個のテンプレート(各TCP/IP接続あたり1つ)を取っておくという必要性は、比較的大きいメモリ要件があることを意味します。 現在のパーソナルコンピュータのためのこの要件は妥当です。 さらに、ゲートウェイは一度に、いくつかの接続のためのテーブルを保たなければなりません。
o The Thinwire links are slow (that's why we call them thin);
much slower than normal disk access. There is no reason that
inactive templates cannot be swapped out to disk and
retrieved when needed if memory is limited. (Note that as
memory density increases, this is less and less of a
problem.)
o Thinwireリンクは遅いです(それは私たちがそれらが薄いと言う理由です)。 正常なディスクアクセサリーよりはるかに遅いです。 メモリが限られるなら必要である場合、不活発なテンプレートをディスクへの外で交換して、検索できない理由が全くありません。 (メモリ密度が増えるのに従ってこれが問題のますます少なさであることに注意してください。)
o There is state information in the connections. If the two
sides get out of synchronization with each other, data flow
stops. This means that some method of error detection and
recovery must be provided.
o 接続には州の情報があります。 2つの側が互いとの同期を出るなら、データフローは止まります。 これは、誤り検出と回復の何らかのメソッドを提供しなければならないことを意味します。
o To minimize the problem described above, the protocol used on
the serial line must be reliable. See Appendix D for details
of SLIP, Serial Line Interface Protocol, as an example of
such a protocol. There must also be periodic
resynchronization. (For example, every Nth packet would be
transmitted in full).
o 上で説明された問題を最小にするために、シリアル・ラインの上で使用されるプロトコルは信頼できなければなりません。 SLIPの細部、Serial線Interfaceプロトコルに関してAppendix Dをそのようなプロトコルに関する例と考えてください。 また、周期的な再同期があるに違いありません。 (例えば、あらゆるNthパケットがすべて伝えられるでしょう。)
o The asynchronous link is not, by its nature, a packet
oriented system; a packet structure will need to be layered
on the character at a time transfer. However, if the
protocol layer below thinwire (SLIP) can be trusted, the
formation of packets is a simple matter.
o 非同期なリンクは本質的にパケット指向のシステムではありません。 パケット構造は、時間転送のときにキャラクタの上で層にされる必要があるでしょう。 しかしながら、thinwire(SLIP)の下のプロトコル層を信じることができるなら、パケットの構成は簡単な事柄です。
o Thinwire II will need to be enhanced for each new protocol
o Thinwire IIは、それぞれの新しいプロトコルのために高められる必要があるでしょう。
Farber & Delp & Conte [Page 4]
ファーバー、デルプ、およびコンテ[4ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
(TCP, UDP, TP4) it is called upon to service. Any packet
type not recognized by the Thinwire connection will be
transmitted in full.
(TCP、UDP、TP4) それでは、サービスに呼ばれます。 Thinwire接続によって認められなかった少しのパケットタイプもすべて伝えられるでしょう。
For maintaining full network service, Thinwire II or a close variant seems to be the solution.
完全なネットワーク・サービスを維持するために、Thinwire IIか近い異形がソリューションであるように思えます。
Thinwire III
Thinwire III
When transmissions at the local network (link) level are not required, if only the available services are desired, then a solution based on Thinwire III may be appropriate. A star network with a gateway in the center serving as the connection between a number of Personal Computers and the Internet is the key of Thinwire III. Rather than providing connections at the network/link level, Thinwire III assumes that there is a reliable serial link (SLIP or equivalent) beneath it and that the workstation/personal computer has better things to do than manage TCP state tables, timeouts, etc. It also assumes that the gateway supporting the Thinwire III connections is powerful enough to run many TCP connections and several SLIP's at the same time. The gateway fills in for the limitations of the communications line and the personal computer. It provides a gateway to the INTERNET, managing the transport and network functions, providing both reliable stream and datagram service.
企業内情報通信網(リンク)レベルにおけるトランスミッションは必要でないときに、営業品目だけが望まれているなら、Thinwire IIIに基づくソリューションが適切であるかもしれません。 センターのゲートウェイが多くのパーソナルコンピュータとインターネットとの関係として機能する星のネットワークはThinwire IIIのキーです。 ネットワーク/リンク・レベルで接続を提供するよりむしろ、Thinwire IIIはそこの下に信頼できる連続のリンク(SLIPか同等物)があって、ワークステーション/パーソナルコンピュータにはするためにTCPステートテーブル、タイムアウトなどを管理するより良いものがあると仮定します。 また、それは、Thinwire IIIが接続であるとサポートするゲートウェイが同時に多くのTCP接続と数個SLIPのものを車で送るほど強力であると仮定します。 ゲートウェイはコミュニケーション系列とパーソナルコンピュータの限界の代理をします。 信頼できるストリームとデータグラムサービスの両方を提供して、輸送とネットワーク機能を管理して、それはインターネットへのゲートウェイを提供します。
In Thinwire III, the gateway starts an interpreter for each SLIP connection from a personal computer. The gateway will open TCP, UDP, and later TP4 connections on the request of the personal computer. Acting as the agent for the personal computer, it will manage the remote negotiations and the data flow to and from the personal computer. Multiple connections can be opened, with inline logical switches in the reliable data flow indicating which connection the data is destined for. Additional escaped sequences will send error and informational data between the two Thinwire III communicators.
Thinwire IIIでは、ゲートウェイはそれぞれのSLIP接続のためにパーソナルコンピュータからインタプリタを始めます。 ゲートウェイはパーソナルコンピュータの要求のときにTCP、UDP、および後のTP4接続を開くでしょう。 パーソナルコンピュータのためのエージェントとして務めて、それはパーソナルコンピュータとパーソナルコンピュータからのリモート交渉とデータフローを管理するでしょう。 複数の接続を開くことができます、確実な資料流動におけるインライン論理的なスイッチが、データがどの接続に運命づけられているかを示していて。 追加逃げられた系列は2Thinwire III伝達者の間に誤りと情報のデータを送るでしょう。
This protocol is not symmetric. The gateway will open connections to the INTERNET world as an agent for the personal computer, but the gateway will not be able to open inbound connections to the personal computer, as the personal computer is perceived as a stub host. The personal computer may however passively open connections on the gateway to act as a server. Extended control sequences are specified to handle the multiple connection negotiation that this server ability will entail.
このプロトコルは左右対称ではありません。 ゲートウェイはパーソナルコンピュータのためのエージェントとしてインターネットの世界に接続を開くでしょうが、ゲートウェイは本国行きの接続をパーソナルコンピュータに開くことができないでしょう、パーソナルコンピュータがスタッブホストとして知覚されるとき。 しかしながら、パーソナルコンピュータは、サーバとして機能するようにゲートウェイの上で接続を受け身に開くかもしれません。Extended制御配列は、このサーバ能力が伴う複数の接続交渉を扱うために指定されます。
This protocol seems to ignore the problem of flow control. Our thought is that the processing on either side of the communication link will be much speedier than the link itself. The buffering for the communication line and the user process blocking for this will
このプロトコルはフロー制御の問題を無視するように思えます。 私たちの考えは通信リンクのどちらかの側での処理がリンク自体よりはるかに迅速になるということです。 通信回線のためのバッファリングとこれのためのユーザ・プロセスブロッキングはそうするでしょう。
Farber & Delp & Conte [Page 5]
ファーバー、デルプ、およびコンテ[5ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
provide most of the flow control. For the rare instances that this is not sufficient, there are control messages to delay the flow to a port or all data flow.
フロー制御の大部分を提供してください。 まれなインスタンスのために、十分でないことで、ポートへの流れを遅らせるコントロールメッセージがあるか、またはすべてのデータが流れます。
A tentative specification for Thinwire III is attached as Appendix C.
Thinwire IIIのための一時的な仕様はAppendix Cとして添付されます。
The authors acknowledge the shoulders upon which they stand, and apologize for the toes they step on. Ongoing work is being done by Eric Thayer, Guru Parulkar, and John Jaggers. Special thanks are extended to Peter vonGlahn, Jon Postel and Helen Delp for their helpful comments on earlier drafts. Responses will be greatly appreciated at the following addresses:
The authors acknowledge the shoulders upon which they stand, and apologize for the toes they step on. Ongoing work is being done by Eric Thayer, Guru Parulkar, and John Jaggers. Special thanks are extended to Peter vonGlahn, Jon Postel and Helen Delp for their helpful comments on earlier drafts. Responses will be greatly appreciated at the following addresses:
Dave Farber <Farber@udel-ee> Gary Delp <Delp@udel-ee> Tom Conte <Conte@udel-ee>
Dave Farber <Farber@udel-ee> Gary Delp <Delp@udel-ee> Tom Conte <Conte@udel-ee>
Farber & Delp & Conte [Page 6]
Farber & Delp & Conte [Page 6]
RFC 914 September 1984 Thinwire Protocol
RFC 914 September 1984 Thinwire Protocol
Appendix A -- Example of Thinwire I Compression
Appendix 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.
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]
[NOTE: The checksums pictured have not been calculated. Binary in MSB to LSB format]
Farber & Delp & Conte [Page 7]
Farber & Delp & Conte [Page 7]
RFC 914 September 1984 Thinwire Protocol
RFC 914 September 1984 Thinwire 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 1
IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 1
TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 1 TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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]
Farber & Delp & Conte [Page 8]
RFC 914 September 1984 Thinwire Protocol
RFC 914 September 1984 Thinwire 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 1
IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 1
TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 1 TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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]
Farber & Delp & Conte [Page 9]
RFC 914 September 1984 Thinwire Protocol
RFC 914 September 1984 Thinwire 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):
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 |
+-+-+-+-+-+-+-+-+
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.
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]
Farber & Delp & Conte [Page 10]
RFC 914 September 1984 Thinwire Protocol
RFC 914 September 1984 Thinwire Protocol
Appendix B -- Examples of Thinwire II Compression
Appendix 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.
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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 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 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.
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.
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 use
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 use
Farber & Delp & Conte [Page 11]
Farber & Delp & Conte [Page 11]
RFC 914 September 1984 Thinwire Protocol
RFC 914 September 1984 Thinwire Protocol
template number) would be assigned to this packet. The number 5 is illustrated. The Length of Packet would be given as 41, and the Type Flag set to TCP/IP (1). The 41 bytes of the packet would follow.
template number) would be assigned to this packet. The number 5 is illustrated. The Length of Packet would be given as 41, and the Type Flag set to TCP/IP (1). The 41 bytes of the packet would follow.
The transmission of packet 2 requires the specification of Type 1 (TCP/IP) updating. There are portions of the packets which will always be the same; these are described in the body of the paper, and are used to match the template. These do not need to be transmitted for an update. There are portions of the packet which will always (well almost always) change. These are the IP Header checksum, the IP Identification number, and the TCP checksum. These are transmitted, in that order, with each template update immediately after the packet length byte/bytes. Following the invariant portion of the header are updates to the fields which change some of the time. Which fields are different is indicated with a bitfield describing the changes.
The transmission of packet 2 requires the specification of Type 1 (TCP/IP) updating. There are portions of the packets which will always be the same; these are described in the body of the paper, and are used to match the template. These do not need to be transmitted for an update. There are portions of the packet which will always (well almost always) change. These are the IP Header checksum, the IP Identification number, and the TCP checksum. These are transmitted, in that order, with each template update immediately after the packet length byte/bytes. Following the invariant portion of the header are updates to the fields which change some of the time. Which fields are different is indicated with a bitfield describing the changes.
The Bitfield is used to indicate which fields (of those that may stay the same) have changed. The technique for updating the field varies with the field description. The specifications for TCP/IP are shown in Table B-1.
Bitfieldは、どの分野(同じままであるかもしれないものの)が変化したかを示すのに使用されます。 フィールド記述に従って、分野をアップデートするためのテクニックは異なります。 TCP/IPのための仕様はTable B-1に示されます。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thin- |U|L|Template no| Len of change | Type of Packet|
wire II|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | 44 |
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 +~+~+~+~+~.~+~+~+~+~+~+~+~+~+~+.+~+~+~+~+~+~+~+~+~+~+~.~+~+~+~+~+
- . . .
1 . . .
+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
| 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|
| "a" |
+-+-+-+-+-+-+-+-+
+++++++++++++++++++++++++が薄くする0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3|U|L|テンプレートノー| 変化のレン| パケットのタイプ| ワイヤII|0|0|0 0 0 1 0 1|0 0 0 1 1 0 0 1|0 0 0 0 0 0 0 1| ヘッダー: | N N| 5 | 41 | TCP/IP| +++++++++++++++++++++++++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+++++++++++++++++++++++++++++++++ヘッダー: | バージョン| IHL|サービスのタイプ| 全長| |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 | 44 | +++++++++++++++++++++++++++++++++c| 識別|旗| 断片オフセット| 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 +~+~+~+~+~.~+~+~+~+~+~+~+~+~+~+.+~+~+~+~+~+~+~+~+~+~+~.~+~+~+~+~+ - . . . 1 . . . +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+ | チェックサム| 緊急の指針| |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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| |0 1 1 0 0 0 0 1| | "a"| +-+-+-+-+-+-+-+-+
Farber & Delp & Conte [Page 12]
ファーバー、デルプ、およびコンテ[12ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
The changed field update information is added to the update header in the order that the bits appear in the field. That is, if both the IP packet length bit and the Time to Live bit are set, the 2 new bytes of the IP Packet length will precede the 1 new byte of the Time to Live field.
変えられた分野アップデート情報はビットがその分野で見えるオーダーにおけるアップデートヘッダーに加えられます。 すなわち、IPパケット長ビットとLiveビットへのTimeの両方が用意ができていると、IP Packetの長さの新しい2バイトはTimeの新しい1バイトにLive分野に先行するでしょう。
The update for packet 2 is shown below. Note that this is an update to template 5, the length of update is 8 bits with a value of 1. The new checksums and IP Identification Number are included, and the flags are set to indicate changes to the following fields: Time to Live, Add 8 bits to Sequence and Acknowledgement Numbers. The new data is one byte following the header.
パケット2のためのアップデートは以下に示されます。 これがテンプレート5へのアップデートであるというメモ、1の値に従って、アップデートの長さは8ビットです。 新しいチェックサムとIP Identification Numberは含まれています、そして、旗が以下の分野への変化を示すように設定されます: Liveへの時間、SequenceへのAdd8ビット、およびAcknowledgement民数記。 新しいデータはヘッダーに続く1バイトです。
Thinwire II would send this message over the line where it would be reassembled into the correct packet.
Thinwire IIはそれが正しいパケットに組み立て直されるところに系列の上のこのメッセージを送るでしょう。
Note: For purposes of synchronization, if three 0 length, template 0, type 0 packets are received, the next non-zero byte should be treated as a start of packet, and the template tables cleared.
以下に注意してください。 同期の目的のために、タイプ0パケットは3 0の長さ、テンプレート0であるなら、受け取られていて、次の非ゼロバイトはパケットの始まりとして扱われるべきであり、テンプレートテーブルはきれいにされました。
____________________________________________________________________
____________________________________________________________________
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|L|Template no| Len of change | IP Header Checksum |
|1|0|0 0 0 1 0 1|0 0 0 0 0 0 0 1|0 1 1 1 0 1 1 1 0 0 0 1 0 1 0 0|
|Y|N| 5 | 1 | nnn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Identification number | TCP Checksum |
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|
| 2 | nnn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bitfield | Time to Live |add to Seq no. | add to Ack Num|
|0 0 1 0 1 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1|
| T Ad8 | 1 | 1 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
|0 0 0 1 0 1 1 1|
| "d" |
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|L|テンプレートノー| 変化のレン| IPヘッダーチェックサム| |1|0|0 0 0 1 0 1|0 0 0 0 0 0 0 1|0 1 1 1 0 1 1 1 0 0 0 1 0 1 0 0| |Y|N| 5 | 1 | nnn| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Identification番号| TCPチェックサム| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0| | 2 | nnn| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bitfield| 生きる時間|Seq No.に加えてください。 | Ackヌムに加えてください。| |0 0 1 0 1 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1| | T Ad8| 1 | 1 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| |0 0 0 1 0 1 1 1| | 「d」| +-+-+-+-+-+-+-+-+
Packet 2. Thinwire II update
パケット2。 Thinwire IIアップデート
____________________________________________________________________
____________________________________________________________________
Farber & Delp & Conte [Page 13]
ファーバー、デルプ、およびコンテ[13ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
Appendix C -- Tentative Specification for Thinwire III
付録C--Thinwire IIIのための一時的な仕様
Thinwire III, as stated in the body of this paper, provides multiple virtual connections over a single physical connection. As Thinwire III is based on a single point to point connection, much of the per/datagram information (routing and sequencing) of other transport systems can be eliminated. In the steady state any bytes received by thinwire III are sent to the default higher level protocol connection. There are escaped control sequences which allow the creation of additional connections, the switching of the default connection, the packetizing of datagrams, and the passing of information between the gateway and the personal computer. The gateway and the personal computer manage a single full duplex stream, multiplexing control requests and streams of data through the use of embedded logical switches.
この紙のボディーに述べられているThinwire IIIは単独の物理接続の上に複数の仮想接続を提供します。 Thinwireとして、IIIは接続を指す単一のポイントに基づいています、多く、もう一方の/データグラム情報(ルーティングと配列)に従って、輸送システムを排除できます。 定常状態では、thinwire IIIによって受け取られたどんなバイトもデフォルトの、より高い平らなプロトコル接続に送ります。 ゲートウェイとパーソナルコンピュータの間で追加接続の作成、デフォルト接続の切り換え、データグラムのpacketizing、および情報の通過を許す制御配列逃げられます。 ゲートウェイとパーソナルコンピュータはただ一つの全二重ストリームを管理します、埋め込まれた論理的なスイッチの使用でデータのコントロール要求とストリームを多重送信して。
The ascii character "z" (binary 01011011 ) is used as the escape character. The byte following the "z" is interpreted to determine the command. Table C-1 shows the general classes the bytes (Request codes) can fall into.
ASCIIキャラクタ「z」(2進の01011011)は拡張文字として使用されます。 「z」に続くバイトは、コマンドを決定するために解釈されます。 分類するC-1がバイト(コードを要求する)を司令官に示すテーブルは落ちることができます。
In order to transmit the character "z", two "z"'s are transmitted. The first is interpreted as an escape, the second as the lower case letter "z" to be transmitted to the default connection. The letter z was chosen as the escape for its low occurrence in text and control data streams, because it should pass easily through any lower level protocols, and for its generally innocuous behavior.
キャラクタ「z」を伝えるために、2「z」が伝えられます。 1番目はエスケープ(デフォルト接続に伝えられるべき小文字「z」としての2番目)として解釈されます。 テキストと制御データでの低発生のためのエスケープが流れるとき、文字zは選ばれました、どんな下のレベルプロトコル、およびその一般に無毒の振舞いによっても容易に通るべきであるので。
Descriptions of specifications of each of the Request codes are below.
それぞれのRequestコードの仕様の記述が以下にあります。
Starting with the range 0-31; these Request codes change the default connection. After a connection has been established, any characters which come across the line that are not part of a Request code sequence are transmitted to one of the connections. To begin with this connection defaults to Zero, but when the "Switch Default Connection" command is received, characters are sent to the connection named in the request until a new request is received. Zero is a special diagnostic connection; anything received on connection number Zero should be echoed back to the sender on connection number One. Anything received on connection number One should be placed on the diagnostic output of the receiving host. Any other connection number indicates data which should be sent out the numbered connection. If the numbered connection has not been opened, the data can be thrown away, and an Error Control Message returned to the sender.
範囲0-31から始まります。 これらのRequestコードはデフォルト接続を変えます。 接続が確立された後に、Requestコード系列の一部ではなく、系列に出くわすどんなキャラクタも接続のひとりに伝えられます。 初めに、この接続はZeroをデフォルトとしますが、「スイッチデフォルト接続」コマンドが受け取られているとき、新しい要求が受信されるまで要求で指定された接続にキャラクタを送ります。 ゼロは特別な診断接続です。 接続番号Zeroに受け取られたものは何でも接続数のOneのときに送付者にecho backであるべきです。 接続番号Oneに受け取られた何でも受信ホストの診断出力に置かれるべきです。 いかなる他の接続番号も、そうするべきであるデータが番号付の接続を派遣したのを示します。 番号付の接続が開かれていないなら、データを無駄にできました、そして、Error Control Messageは送付者に戻りました。
Escapes followed by numbers 32 through 255 are for new connections, requests for information, and error messages. The escape will be
ミッドナイト・ゾーンは新しい接続、情報に関する要求、およびエラーメッセージのためのものです、続いて、No.32〜255があります。 エスケープはそうでしょう。
Farber & Delp & Conte [Page 14]
ファーバー、デルプ、およびコンテ[14ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
followed by a Request code, a one byte Request Sequence Number (so that the Reply to Request can be asynchronously associated with the Request), and the arguments for the specific request. (The length of the argument field will be determined by the Request code.) The format of the request will be as pictured below:
Requestコード、1バイトのRequest Sequence Number(RequestへのReplyをRequestに非同期に関連づけることができるように)、および特定の要求のための議論は支えています。 (議論分野の長さはRequestコードによって測定されるでしょう。) 以下で描写されるとして要求の形式があるでしょう:
"z" <Request Code> <Request Sequence Number> [ <Arguments> ... ]
「z」<要求コード><は一連番号>を要求します。[<議論>]
At this time the Request codes 32-63 are reserved.
このとき、Requestコード32-63は予約されています。
The Request codes 64-127 are for stream server open requests. For the purposes of compression, many of the common servers are assigned single byte codes. See Table C-2.
Requestコード64-127はストリームサーバ戸外の要求のためのものです。 圧縮の目的のために、シングルバイトコードは一般的なサーバの多くに割り当てられます。 テーブルC-2を見てください。
Request code 68 is to a connection to the default hostname server used by the gateway. It takes 3 bytes for this request. It has the form:
ゲートウェイによって使用されるデフォルトホスト名サーバとの接続にはコード68があるよう要求してください。 それはこの要求に3バイト取ります。 それには、フォームがあります:
"z" < 68 > < Request Sequence Number >
「z」<68><要求一連番号>。
Request code 95 is to open any specified TCP Port at the specified address. It takes 9 bytes for this request. It has the form:
コード95が指定されたアドレスのどんな指定されたTCP Portも開くことであるよう要求してください。 それはこの要求に9バイト取ります。 それには、フォームがあります:
"z" < 95 > < Request Sequence Number > < 4 bytes of IP address> <
2 bytes of TCP Port >
IPの4バイトが、><が2バイトのTCP Port>であると扱うという「z」<95><要求Sequence Number><。
Request codes 96-127 are RESERVED for alternate transport protocols.
コード96-127が代替のトランスポート・プロトコルのためのRESERVEDであるよう要求してください。
The Request codes 128-191 are used for framing Datagrams and opening new Datagram connections. The code 128 is the Start of Datagram code. The format is:
Requestコード128-191は、データグラムを縁どっていて、新しいデータグラム接続を開くのに使用されます。 コード128はデータグラムコードのStartです。 形式は以下の通りです。
"z" <128> <Length of Datagram (2 bytes)> <Socket> Data ...
データグラム(2バイト)><Socket>Dataの「z」<128><の長さ…
As with the Stream opens, there are a number of assigned ports with codes for them. They are listed in Table C-3.
Streamと共に開くとき、それらのためのコードがある多くの割り当てられたポートがあります。 それらはTable C-3で記載されています。
The Request Codes 192-254 are control, status and informational requests. These are still under development, but will include:
Request Codes192-254はコントロールと、状態と情報の要求です。 これらは、まだ開発中ですが、以下を含むでしょう。
-flow control
-get host/server/protocol by entry/name/number.
-additional error messages
-overall reset
-open passive connection
-エントリー/名前/数に応じて、フロー制御はホスト/サーバ/プロトコルを得ます。 --全体的に見て追加エラーメッセージはオープンな受け身の接続をリセットしました。
The Request Code 252 is the request to close a connection. This Code, followed by the connection number, indicates that no more data
Request Code252は接続を終えるという要求です。 接続番号があとに続いたこのCodeはそのより多くのデータを示します。
Farber & Delp & Conte [Page 15]
ファーバー、デルプ、およびコンテ[15ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
will be sent out this connection number. A second request with the same connection number will indicate that no more data will be accepted on this connection.
この接続番号から、送るでしょう。 同じ接続番号がある2番目の要求は、それ以上のデータが全くこの接続のときに受け入れられないのを示すでしょう。
The Request Code 253 is the information request for a connection. The protocol, status, and port number of the connection should be returned. The format of this reply has yet to be specified.
接続を求めてRequest Code253は情報要求です。 接続のプロトコル、状態、およびポートナンバーは返されるべきです。 この回答の形式はまだ指定されていません。
The Request code 254 is an error notification. These are to be acknowledged with their Request Sequence Numbers. Error codes are under development.
Requestコード254はエラー通知です。 これらはそれらのRequest Sequence民数記で承認されることになっています。 エラーコードは開発中です。
The Request code 255 is the Reply to Request. The Request Sequence Number identifies the request being replied to. The format is:
Requestコード255はRequestへのReplyです。 Request Sequence Numberは答えられる要求を特定します。 形式は以下の通りです。
"z" <255> <Request Sequence Number (in reply to)> <Length of reply
(1 byte)> Reply...
に対して「z」<255><要求Sequence Number、()、回答(1バイト)>Replyの…><Length
The Thinwire Drivers on each side will wait at their inbound sockets, and relay across the thinwire link character-by-character/packet-by-packet for the stream/datagram connections.
それぞれの側の上のThinwire Driversは接続を彼らの本国行きのソケットで待っていて、ストリーム/データグラムのためのキャラクタごとの/パケットごとのthinwireリンクの向こう側にリレーするでしょう。
Thinwire III is labeled as a tentative specification, because at this time, in order to publish this RFC in a timely fashion, several minor issues are still unresolved. An example is the scheduling of serial line use. Short messages could be given priority over long packets, or priority schemes could be changed during the session, depending upon the interactive desire of the user. Addition issues will be resolved in the future.
Thinwire IIIは一時的な仕様としてラベルされます、いくつかの小さな問題がこのとき直ちにこのRFCを発行するためにまだ未定であるので。 例はシリアル・ライン使用のスケジューリングです。 長いパケットに短いメッセージを優先させることができましたか、またはセッションの間、優先権体系を変えることができました、ユーザの対話的な願望によって。 追加問題は将来、解決されるでしょう。
Farber & Delp & Conte [Page 16]
ファーバー、デルプ、およびコンテ[16ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
Appendix D -- Serial Line Interface Protocol (SLIP)
付録D--シリアル・ラインインタフェースプロトコル(メモ用紙)
Initial Specifications and Implementation Suggestions
初期の仕様と実装提案
PHILOSOPHY
哲学
The world is a dangerous place for bits. Data transmission can be
an time consuming business when one has to make sure that bits
don't get lost, destroyed, or forgotten. To reduce such problems,
the Serial Line Interface Protocol (SLIP) maintains an attitude
toward the world that includes both a mistrust of serial lines and
a margin of laziness. Examples of this approach include how SLIP
recovers from errors and how SLIP handles the problem of
resequencing (see PROTOCOL SPECIFICATIONS and IMPLEMENTATION
SUGGESTIONS).
世界は何ビットも危険な場所です。 人が、失われているか、破壊されるか、またはビットが忘れられていないのを確実にしなければならないとき、データ伝送は時間がかかった企業であるかもしれません。 そのような問題を減少させるために、Serial線Interfaceプロトコル(SLIP)はシリアル・ラインの不信用と不精のマージンの両方を含んでいる世界に対する態度を維持します。 このアプローチに関する例は、SLIPがどのようにエラーを回復するか、そして、SLIPがどのように、再配列するという問題を扱うかを(PROTOCOL SPECIFICATIONSとIMPLEMENTATION SUGGESTIONSを見てください)含んでいます。
THE MESSAGE FORMAT
メッセージ・フォーマット
Both the Sender Task and the Receiver Task communicate using a
standard message format and the Sender and Receiver Task of one
machine's SLIP communicate using a shared buffer. The message
begins with a 1 byte Start of Header token (StH, 11111111) and is
followed by a sequence number of four bits (SEQ) and an
acknowledgement number of four bits (ACK). Following the StH, SEQ
and ACK, is a 5 bit length field which specifies the length of the
data contained in the message. Following the length is a three bit
field of flags. The first bit is used to indicate that the a
receive error has occurred, and the ACK is actually a repeat of
the Last Acknowledged message (a LACK). The second bit is used to
indicate a Synchronize Sequence Numbers message (SSNM), and the
third bit is used to indicate a Start of Control Message (SOCM);
all three of these flags are explained below. Finally, at the end
of the message is an exclusive-or checksum. The message format is
shown in figure D-1.
Sender TaskとReceiver Taskの両方が標準のメッセージ・フォーマットを使用することで交信します、そして、1台のマシンのSLIPのSenderとReceiver Taskは共有バッファを使用することで交信します。 メッセージのHeaderトークン(StH、11111111)の1バイトのStartと共に始まって、4ビットの一連番号(SEQ)と4ビットの承認番号(ACK)はあとに続いています。 続いて、StH(SEQとACK)はメッセージに含まれたデータの長さを指定する5ビットの長さの分野です。 長さに続くのは、旗の3ビットの分野です。 最初のビットはaが受信されるのを示すのに使用されて、誤りが発生して、ACKが実際にLast Acknowledgedメッセージ(LACK)の反復であるということです。 2番目のビットはSynchronize Sequence民数記メッセージ(SSNM)を示すのに使用されます、そして、3番目のビットはControl Message(SOCM)のStartを示すのに使用されます。 これらのすべての3個の旗が以下で説明されます。 最終的に、メッセージの終わりに、排他的論理和チェックサムがあります。 メッセージ・フォーマットは図D-1に示されます。
________________________________________________
________________________________________________
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | StH | SEQ | ACK | Length |Flags|...Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... The maximum data length is 32 bytes. 0 1 2 3 4 5 6 7 This limits the vulnerability of receiver ...-+-+-+-+-+-+-+-+-+-+ timeout errors occurring because of bit error .Data...| Checksum | in the length field. ...-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | StH| SEQ| ACK| 長さ|旗|...データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 最大のデータの長さは32バイトです。 これが制限する0 1 2 3 4 5 6 7 受信機の…脆弱性-ビット誤り.Dataのために発生する++++++++++タイムアウト誤り…| チェックサム| 長さの分野で。 ...-+-+-+-+-+-+-+-+-+-+
Figure D-1. SLIP Message Format
図D-1。 メモ用紙メッセージ・フォーマット
________________________________________________
________________________________________________
Farber & Delp & Conte [Page 17]
ファーバー、デルプ、およびコンテ[17ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
The Sender, when idle but needing to acknowledge, will send out
short messages of the same format as a regular message but with
the SOCM flag set and the data field omitted. ( This short
message is called a SOCM, and is used instead of a zero length
message to avoid the problem of continually ACK'ing ACK's ). The
Sender Task, when originating a connection (see STARTING UP AND
FINISHING OFF COMMUNICATIONS), will send out another short message
but with the SSNM flag set and the data omitted. This message (a
SSNM) used for a TCP-style 3 way startup handshake.
Sender怠けますが、通常のメッセージとして同じ形式の短いメッセージを出すと認めるのが必要ですが、SOCM旗のセットとデータ・フィールドで省略されると。 (この短いメッセージがSOCMと呼ばれて、絶えず問題を避けるゼロ・レングスメッセージの代わりに使用される、ACK'ing ACKのもの) 接続(STARTING UP AND FINISHING OFF COMMUNICATIONSを見る)を溯源するとき、別の短いメッセージにもかかわらず、SSNM旗のセットとデータが省略されている状態で、Sender Taskは出すでしょう。 このメッセージ(SSNM)はTCP-スタイル3道に始動握手を使用しました。
PROTOCOL SPECIFICATIONS and SUGGESTIONS
プロトコル仕様と提案
The SLIP module, when called with data to send, prepends its
header (SEE ABOVE) to the data, calculates a checksum and appends
the checksum at the end. (This creates a message.) The message
has a sequence number associated with it which represents the
position of the message in the Sender SLIP's buffers. The
sequence number for the message can range from 0 to 15 and is
returned in the ACK field of the other machine's Sender SLIP
messages to acknowledge receipt.
SLIPモジュール、いつが終わりに送るデータ、prependsでヘッダーをデータに(SEE ABOVE)と呼んで、チェックサムについて計算して、チェックサムを追加するか。 (これはメッセージを作成します。) メッセージには、それに関連している一連番号があります(Sender SLIPのバッファのメッセージの位置を表します)。 メッセージのための一連番号は、0〜15まで及ぶことができて、領収書を受け取ったことを知らせるもう片方のマシンのSender SLIPメッセージのACK分野で返されます。
There are two scenarios for transmission. In the first, both
SLIP's will be transmitting to each other. To send an
acknowledgement, the Receiver SLIP uses the ACK field in its next
outgoing message. To receive an acknowledgement, the Sender checks
the ACK field of its Receiver's incoming messages. In the second
scenario, one SLIP may have no data to transmit for a long time.
Then, as stated above, to acknowledge a received message, the
Receiver has its Sender send out a short message, the SOCM (SEE
ABOVE) which specifies the message it is acknowledging. The SOCM
includes a checksum of its total contents. If there is a checksum
error, THE SOCM IS IGNORED.
トランスミッションのための2つのシナリオがあります。 1番目、SLIPが互いに伝える両方で。 承認を送るために、Receiver SLIPは次の送信されるメッセージでACK分野を使用します。 承認を受けるために、SenderはReceiverの入力メッセージのACK分野をチェックします。 2番目のシナリオでは、1SLIPが長い間送らないデータを全く持っているかもしれません。 そして、受信されたメッセージを承認するために上に述べられているように、ReceiverはSenderに短いメッセージ(それが承認しているメッセージを指定するSOCM(SEE ABOVE))を出させます。 SOCMは総コンテンツのチェックサムを含んでいます。 チェックサム誤りがあれば、THE SOCM IS IGNOREDです。
When there is a checksum error on a received normal message, the
Receiver asks its Sender to send out a SOCM with the LACK flag
set, or set the LACK flag on its next message. The Sender sends
this flag ONCE then ceases to increment the acknowledgement number
(the ACK) while the Receiver continues to check incoming messages
for the sequence number of the message with a checksum error.
(Note that it continues to react to the acknowledgement field in
the incoming messages.) When it finds the needed message, it
resumes accepting the data in new messages and increments the
acknowledgement number transmitted accordingly.
チェックサム誤りが受信された正常なメッセージにあるとき、Receiverは、LACK旗のセットがあるSOCMを出すか、または次のメッセージにLACK旗をけしかけるようにSenderに頼みます。 Receiverは、メッセージの一連番号がないかどうかチェックサム誤りに入力メッセージについて問い合わせ続けていますが、Senderは次にONCEが増加するのをやめるこの旗に承認番号(ACK)を送ります。 (入力メッセージの承認分野に反応し続けていることに注意してください。) 必要なメッセージを見つけるとき、それは、新しいメッセージのデータを受け入れるのを再開して、それに従って、伝えられた承認番号を増加します。
The sending SLIP must never send a message greater than four past
the last message for which it has received an acknowledgement
(effectively a window size of four). Under normal processing
loads, a window size greater than four should not be needed, and
this decreases the probability of random errors creating valid
発信しているSLIPはそれが承認(事実上4のウィンドウサイズ)を受けた最後のメッセージを超えて4以上をメッセージに決して送ってはいけません。 正常処理負荷の下では、ウィンドウサイズより多くのfourを必要とするべきではありません、そして、これは有効な状態で無作為の誤りに作成されるという確率を減少させます。
Farber & Delp & Conte [Page 18]
ファーバー、デルプ、およびコンテ[18ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
acknowledgement or sequence numbers. If the Sender has four
unacknowledged messages outstanding, it will retransmit the old
messages, starting from the oldest unacknowledged message. If it
receives an acknowledgement with the LACK flag set, it transmits
the message following the LACK number and continues to transmit
the messages from that one on. Thus a LACK is a message asking
the Sender to please the Receiver. If the Sender times out on any
message not logically greater than four past the last acknowledged
message, it should retransmit the message that timed out and then
continues to transmit messages following the timed out message.
承認か一連番号。 Senderに未払いの4つの不承認のメッセージがあると、最も古い不承認のメッセージから始めて、それは古いメッセージを再送するでしょう。 LACK旗のセットによる承認を受けるなら、それは、LACK番号に従って、メッセージを送って、それからメッセージを送り続けています。 したがって、LACKはReceiverを喜ばせるようにSenderに頼むメッセージです。いずれかのSender回がを超えて4以上を論理的でなく通信させるなら、それは、外で調節されたメッセージを再送するべきであり、調節された出ているメッセージに従って、次に、メッセージを送り続けています。
The following describes a partial implementation of SLIP. System
dependent subjects like buffer management, timer handling and
calling conventions are discussed.
以下はSLIPの部分的な実現について説明します。 バッファ管理、タイマ取り扱い、および呼び出し規則のようなシステムに依存する問題について議論します。
The SLIP implementation is subdivided into four modules and two
sets of input/output interfaces. The four modules are: The Sender
Task, The Receiver Task, the buffer Manager, and SLIPTIME (the
timer). The two interfaces are to the higher protocol and to the
lower protocol (the UARTian, an interrupt driven device driver for
the serial lines).
SLIP実現は4つのモジュールと2セットのI/Oインターフェースに細分されます。 4つのモジュールは以下の通りです。 Sender Task、Receiver Task、バッファマネージャ、およびSLIPTIME(タイマ)。 より高いプロトコルと、そして、低いプロトコルに2つのインタフェースがあります(UARTian、シリーズのための中断の駆動デバイスドライバは立ち並んでいます)。
OPERATIONS OF THE SENDER TASK
送付者タスクの操作
The Sender Task takes a relatively noncomplex approach to
transmitting. It sends message zero, sets a timer (using the
SLIPTIME Task) on the message, and proceeds to send and set timers
for messages one, two, and three. When the Receiver Task tells
the Sender Task that a message has been acknowledged, the Sender
Task then clears the timer for that message, and marks it
acknowledged. When the Sender Task has finished sending a
message, it checks several conditions to decide what to do next.
It first checks to see if a LACK has been received. If it has then
it clears all the timers, and begins retransmitting messages
(updating the acknowledgement field and checksum) starting from
the one after the LACK'ed message. If there is not a LACK waiting
for the Sender Task, it checks to see if any messages have timed
out. If a message has timed out, the Sender Task again will clear
the timers and begin retransmitting from the message number which
timed out. If neither of these conditions are true, the Sender
Task checks to see if, because it has looped back to retransmit,
it has any previously formulated messages to send. If so, it send
the first of these messages. If it does not have previously
formulated messages, it checks to see if it is more than three
past the last acknowledged message. If so, it restarts from the
message after the last acknowledged message. If none of these are
true, then it checks to see if there is more data waiting to be
transmitted. If there is more data available, it forms the
largest packet it can, and begins to transmit it. If there is no
Sender Taskは伝えることへの比較的「非-複雑」なアプローチを取ります。 それは、メッセージ1、2、およびthreeにタイマをメッセージゼロを送って、メッセージにタイマ(SLIPTIME Taskを使用する)を設定して、送って、設定しかけます。 Receiver Taskが、メッセージが承認されたとSender Taskに言うとき、Sender Taskは、次に、そのメッセージのためにタイマをきれいにして、それが承認されているとマークします。 Sender Taskが、メッセージを送り終えたとき、それは次に何をしたらよいかを決めるいくつかの状態をチェックします。 それは、最初に、LACKが受け取られたかどうかを見るためにチェックします。 その時があるなら、それは、すべてのタイマをきれいにして、LACK'edメッセージの後のものから始めて、メッセージ(承認分野をアップデートして、チェックサム)を再送し始めます。 Sender Taskを待つLACKがなければ、それは、何かメッセージが外で調節されたかどうか確認するためにチェックします。 メッセージは外で時間があると、Sender Taskが再びタイマをきれいにして、外で調節されたメッセージ番号から再送し始めるでしょう。 これらの状態のどちらも本当でないなら、Sender Taskは、再送するために輪にし返したのでそれで何か発信する以前に定式化されたメッセージがあるかどうか確認するためにチェックします。 そうだとすれば、それはこれらのメッセージの1番目を送ります。 以前に定式化されたメッセージがないなら、それは、メッセージにおいて先最後に承認されたそれが3以上であるかどうか確認するためにチェックします。 そうだとすれば、それは次々と最後に承認されたメッセージから再開します。 これらのいずれも本当でないなら、それは、伝えられるのを待つより多くのデータがあるかどうか確認するためにチェックします。 利用可能なより多くのデータがあれば、それは、そうすることができる中で最も大きいパケットを形成して、それを伝え始めます。 いいえがあれば
Farber & Delp & Conte [Page 19]
ファーバー、デルプ、およびコンテ[19ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
more data to transmit, it checks to see if it needs to acknowledge
a message received from the other side. If so then it sends a
SOCM. If none of the above conditions create work for the Sender
Task, the task suspends itself.
送るより多くのデータであり、それは、それが、反対側から受け取られたメッセージを承認する必要であるかどうか確認するためにチェックします。 そうだとすれば、そして、それはSOCMを送ります。 上記の状態のいずれもSender Taskのために仕事を作成しないなら、タスクはそれ自体を中断させます。
Note that the Sender Task uses the Receiver Task to find out about
acknowledgements and the Receiver Task uses the Sender Task to
send acknowledgements to the other SLIP on the other side (via the
ACK field in the Sender Task's message). The two tasks on one
machine communicate through a small buffer. Because
acknowledgements need to be passed back to the Sender Task
quickly, the Receiver Task can wake up the Sender Task (unblock
it).
Sender Taskが承認を見つけるのにReceiver Taskを使用して、Receiver Taskが反対側(Sender TaskのメッセージのACK分野を通る)でもう片方のSLIPに承認を送るのにSender Taskを使用することに注意してください。 1台のマシンに関する2つのタスクが小さいバッファを通って交信します。 承認が、すばやくSender Taskに戻される必要があるので、Receiver TaskはSender Task(それを「非-妨げ」る)を起こすことができます。
OPERATIONS OF THE RECEIVER TASK
受信機タスクの操作
The Receiver Task checks the checksums of the messages coming into
it. When it gets a checksum error, it tells the Sender Task to
mark the next acknowledgement as a LACK. It then throws away all
messages coming into it that don't match the message it wants and
continues to acknowledge with the last ACK until it gets the
message it wants. As a checksum error could be the result of a
crashed packet, and the StH character can occur within the packet,
when a checksum error does occur, the recovery includes scanning
forward from the last StH character for the next StH character
then attempting to verify a packet beginning from it. A valid
message includes a valid checksum, and sequence and
acknowledgement numbers within the active window of numbers. This
eliminates the need for the resequencing of messages, because the
Receiver Task throws away anything that would make information in
its buffers out of sequence.
Receiver Taskはそれに入るメッセージのチェックサムをチェックします。 チェックサム誤りを得るとき、それは、LACKとして次の承認をマークするようにSender Taskに言います。 そして、それは欲しいメッセージを得るまでそれが欲しく、最後のACKと共に承認し続けているメッセージに合っていないそれに入るすべてのメッセージを無駄にします。 チェックサム誤りが発生するとき、チェックサム誤りが墜落しているパケットの結果であるかもしれなく、StHキャラクタがパケットの中に起こることができるように、それから始まるパケットについて確かめるのを試みながら、回復は、その時次のStHキャラクタのために最後のStHキャラクタから前方にスキャンするのを含んでいます。 有効なメッセージは数のアクティブウィンドウの中に有効なチェックサム、系列、および承認番号を含んでいます。 これはメッセージの再配列の必要性を排除します、Receiver Taskが系列からバッファの情報を作る何でも捨てるので。
OPERATIONS OF SLIPTIME
SLIPTIMEの操作
The timer task will maintain and update a table of timers for each
request. Its functions should be called with the timer length and
the sequence number to associate with the timer. Its functions
can also be called with a request to delete a timer. An
interrupt-driven mechanism is used to update the running timers
and to wake up the Sender when an alarm goes off.
タイマタスクは、各要求のためのタイマのテーブルを維持して、アップデートするでしょう。 機能は、タイマと交際するためにタイマの長さと一連番号で呼ばれるべきです。 また、タイマを削除するという要求で機能を呼ぶことができます。 アラームが鳴りだすとき、中断駆動のメカニズムは、走行タイマをアップデートして、Senderを起こすのに使用されます。
Farber & Delp & Conte [Page 20]
ファーバー、デルプ、およびコンテ[20ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
THE INPUT AND OUTPUT INTERFACES
入出力インタフェース
To force SLIP to do something, the higher protocol should create a
buffer and then call SLIP, passing it a pointer to the buffer.
SLIP will then read the buffer and begin sending it. The call to
SLIP will return the number of bytes written, negative number
indicates to the caller that SLIP could not do the request. Exact
error numbers will be assigned in the future. To ask SLIP to
receive something, one would call SLIP and SLIP would immediately
return the number of bytes received or a negative number for an
error (nothing ready to receive, for example).
SLIPに何かをさせるように、より高いプロトコルは、バッファを作成して、次に、SLIPと呼ぶべきです、バッファへのポインタをそれに渡して。 SLIPは次に、バッファを読んで、それを送り始めるでしょう。 SLIPへの呼び出しは書かれて、負の数がSLIPができなかった訪問者が示すバイト数に要求を返すでしょう。 正確なエラー番号は将来、割り当てられるでしょう。 何か、1を受け取るようにSLIPに頼むために、SLIPと呼んで、SLIPはすぐに、誤り(何でもない、例えば、受信する準備ができているもの)の受け取られたバイト数か負数を返すでしょう。
SLIP, when it wants to talk to the underworld of the serial
interface, will do much the same thing only through a buffer
written to by the UARTian (for received data) and read from by the
UARTian (for sent data).
シリアルインタフェースの下層社会と話したがっているとき、SLIPはUARTian(受信データのための)によって書かれていて、UARTian(送られたデータのための)によって読まれたバッファだけを通して似たり寄ったりのことをするでしょう。
OPERATIONS OF THE BUFFER/WINDOW MANAGER
バッファ/ウィンドウマネージャの操作
The Manager tends a continuous, circular buffer for the Sender
Task in which data to be sent (from the downcalling protocol) is
stored. This buffer is called the INPUT-DATA BUFFER (IDBuff).
The Manager also manages a SENDER TASK'S OUTPUT-DATA BUFFER
(SODBuff), which is its output buffer to the UARTian.
マネージャは送られる(downcallingプロトコルから)データが格納されるSender Taskのための連続して、円形のバッファ傾向があります。 このバッファはINPUT-DATA BUFFER(IDBuff)と呼ばれます。 また、マネージャはSENDER TASKのOUTPUT-DATA BUFFER(SODBuff)を管理します。(OUTPUT-DATA BUFFERはUARTianへのその出力バッファです)。
The IDBuff has associated with it some parameters. These
parameters include: START OF MEMORY (SOM), the start of memory
reserved for the IDBuff; END OF MEMORY (EOM), the end of memory
reserved; START OF DATA (SOD), the beginning of the used portion
of the IDBuff; and END OF DATA (EOD), the end of data in the
IDBuff. The SOM and EOM are constants whereas the SOD and EOD are
variables.
IDBuffはいくつかのパラメタをそれに関連づけました。 これらのパラメタは: START OF MEMORY(SOM)、IDBuffのために予約されたメモリの始まり。 END OF MEMORY(EOM)、予約されたメモリの終わり。 START OF DATA(SOD)、IDBuffの中古の部分の始まり。 END OF DATA(EOD)、IDBuffのデータの終わり。 SOMとEOMは定数ですが、SODとEODは変数です。
The SODBuff is composed of four buffers for four outbound messages
(less the checksum). The buffers can be freed up to be
overwritten when the message that they contain is acknowledged by
the SLIP on the other side of the line. When a message is in the
SODBuff, it has associated with it a sequence number (which is the
message's sequence number). The Sender Task can reference the
data in the SODBuff and reference acknowledgements via this
sequence number.
SODBuffが4つの外国行きのメッセージのための4つのバッファで構成される、(より少なさ、チェックサム) それらが含むメッセージが線の反対側の上のSLIPによって承認されるとき、上書きされるためにバッファを開けることができます。 メッセージがSODBuffにあるとき、それは一連番号(メッセージの一連番号である)をそれに関連づけました。 Sender Taskはこの一連番号でSODBuffと参照承認におけるデータに参照をつけることができます。
When the application has data to be transmitted, it is placed in
the IDBuff by the application using functions from the Manager and
the EOD is incremented. If the data the application wants to send
won't fit in the buffer, no data is written, and the application
can either sleep, or continue to attempt to write data until the
アプリケーションに伝えられるべきデータがあると、それはマネージャから機能を使用しながら、アプリケーションでIDBuffに置かれます、そして、EODは増加されています。 アプリケーションが送りたがっているデータがバッファをうまくはめ込まないなら、データが全く書かれないで、アプリケーションは、眠るか、またはデータを書くのを試み続けることができます。
Farber & Delp & Conte [Page 21]
ファーバー、デルプ、およびコンテ[21ページ]
RFC 914 September 1984 Thinwire Protocol
RFC914 1984年9月のThinwireプロトコル
data will fit. The Sender Task calls a Manager function to fill a
message slot in the SODBuff. The Sender Task then sends its
message from the SODBuff.
データは合うでしょう。 Sender Taskは、SODBuffのメッセージスロットを埋めるためにマネージャ機能を呼びます。 そして、Sender TaskはSODBuffからメッセージを送ります。
The Manager also maintains a buffer set for the Receiver Task. The
buffers are similar to those of the Sender Task. There is a
CHECKSUMMED OUTPUT-DATA BUFFER (CODBuff), which is the final
output from SLIP that the higher level protocol may read. The
CODBuff is also controlled by the four parameters START OF MEMORY,
END OF MEMORY, START OF DATA, and END OF DATA (SOM, EOM, SOD, and
EOD).
また、マネージャは、バッファがReceiver Taskのためにセットしたと主張します。 バッファはSender Taskのものと同様です。 CHECKSUMMED OUTPUT-DATA BUFFER(CODBuff)があります。(CHECKSUMMED OUTPUT-DATA BUFFERは、より高い平らなプロトコルが読むかもしれないSLIPからの最終産出物です)。 また、CODBuffは4パラメタSTART OF MEMORY、END OF MEMORY、START OF DATA、およびEND OF DATA(SOM、EOM、SOD、およびEOD)によって制御されます。
There is also an inbound circular buffer the analog of the
SODBuff, called the RECEIVER TASK'S INPUT-DATA BUFFER (RIDBuff).
そこでは、RECEIVER TASKのINPUT-DATA BUFFER(RIDBuff)は、本国行きの円形のバッファもSODBuffのアナログであると呼びました。
When the UARTian gets data, it places the data in the RIDBuff.
After this, the Receiver Task checksums the data. If the checksum
is good and the Receiver Task opts to acknowledge the message, it
moves the data to the CODBuff, increments EOD, and frees up space
in the RIDBuff. The higher level application can then take data
off on the CODBuff, incrementing SOD as it does so.
UARTianがデータを得るとき、それはRIDBuffのデータを置きます。 この後、Receiver Taskチェックサム、データ。 チェックサムが良く、Receiver Taskがメッセージを承認するために選ぶなら、それは、RIDBuffでデータをCODBuffに動かして、EODを増加して、スペースを開けます。 そして、そうするのに従ってSODを増加して、より高い平らなアプリケーションはCODBuffでデータを取り去ることができます。
STARTING UP AND FINISHING OFF COMMUNICATIONS
コミュニケーションを立ち上げて、仕上げます。
The problem is that the SLIP's on either side need to know (and
keep knowing) the sequence number of the other SLIP. The easiest
way to solve most of these problems is to have the SLIP check the
Request to Send and Clear to Send Lines to see if the other SLIP
is active. On startup, or if it has reason to believe the other
side has died, the SLIP assumes: all connections are closed, no
data from any connection has been sent, and both its SEQ and the
SEQ of the other SLIP are zero. To start up a connection, the
instigating SLIP sends a SSNM with its starting sequence number in
it. The receiving SLIP acknowledges this SSNM and replies with
its starting sequence number (combined into one message). Then
the sending SLIP acknowledges the receiving SLIP's starting
sequence number and the transmission commences. This is the three
way handshake taken from TCP, After which data transmission can
begin.
問題はSLIPがもう片方のSLIPの一連番号を知る(知り続けてください)サイド必要にあるということです。 これらの問題の大部分を解決する最も簡単な方法はSLIPにもう片方のSLIPがアクティブであるかどうか確認するためにSendへのRequestとSend線へのClearをチェックさせることです。 始動かそれともそれで反対側が死んだと信じる理由があるかどうかに関して、SLIPは以下を仮定します。 すべての接続が閉じられます、そして、どんな接続からのデータも全く送りません、そして、SEQともう片方のSLIPのSEQの両方がゼロです。 接続、扇動を立ち上げるために、始めの一連番号がそれにある状態で、SLIPはSSNMを送ります。 受信SLIPは始めの一連番号(1つのメッセージに結合される)があるこのSSNMと回答を承諾します。 そして、発信しているSLIPはSLIPの始めの一連番号とトランスミッションが始める受信を承認します。 これは3道です。TCP、それのデータ伝送が始まることができるAfterから取られた握手。
Farber & Delp & Conte [Page 22]
ファーバー、デルプ、およびコンテ[22ページ]
一覧
スポンサーリンク
