通信プロトコルの基礎。その1/4。著者:吉田作太郎

通信プロトコルの基礎。

 これは、データー通信の基礎である。
ここに、Aという装置とBという装置の二つの装置があったとする。
この二つの装置は、互いにデーターを送信したり受信したりする事ができたとしよう。
つまり、トランシーバーの様な装置だったとする。
この二つのトランシーバーが、互いに通信し合い一つのシステムを作る事としよう。
その時の二つのトランシーバーの間での互いの交信をスムーズに行う事を一番の目的として交信の手順を定めた仕様の事を通信プロトコルと呼ぶ。
この通信プロトコルは、その他にも、二番目の目的、三番目の目的など有り、さまざまなサービスが考え出されている。
ここで、オンラインとは二つの機械の間での通信を自動的にする処理の事を言い、オフラインとはこの二つの機械の間の通信を人間の手を仲介とする処理の事を言う。
また、二つの機械の通信装置の通信回線が一本であり、その一本の回線で送受信をまかなうハードウェアの仕様の事を半二重通信回線と呼ぶ。
また、通信回線が二本であり、その二本の通信回線で、一方を送信用専用、一方を受信用専用と定めてデーターの送受信をする事ができるハードウェアの仕様を全二重通信回線と呼ぶ。
さて、私の知る限り、この通信プロトコルにとって必要な技術は次の3点に集約される。
1. リトライシーケンス。
2. リカバリー。
3. ポーリングの技術。
この3点の事を理解してオンラインの通信プロトコルを設計すれば、だいたいどこに出しても申し分の無い商品として成り立つオンラインのアプリケーション・プログラムを設計する事ができるだろう。
ここで記述する技術とは、だいぶ昔によく使われた通信プロトコルではあり、RS232Cを用いたトランザクション・データー(通信電文)の通信プロトコルの基礎を中心に解説する。
通信処理とは、ノンストップが要求される。
伝送エラーが発生しても独自に自らの処理を続ける事が要求されるのである。
そこで、通常、通信にリトライする処理とポーリングして相手の状態を確かめリカバリーする処理を通信プロトコルに付け加えた。
こういう仕様を加えられた通信は、エラーが発生したらいろいろと復旧できる仕組みを持ち、電源を入れ直したらただちに復旧する事が自動的にできる。
また、装置が故障しても代わりの装置をつなげて電源を入れ直せば、自動リカバリー処理のためにシステムをスムーズに修復する事ができる。
それまでの仕様を実現するためのパラメーターをスケールアップしてゆく流れを中心に通信手順のメカニズムであるプロトコルの説明をしてゆく。
さて、補足として、通信プロトコルには「無視」という言葉が重要になってくる。
通信エラーが発生して、通信が混乱したら、へたな救済策を出すよりも、「無視」した方が、はるかに効果が絶大だからだ。
又、通信プロトコルのリトライシーケンスやリカバリー処理より、機械同士のコミュニケーションの設計とは記憶を共有する様に作るのがコツでもある。
しかし、こういう通信プロトコルというのがいかに巧妙で立派だとしても、これは機械の立場での事であり、実際の人間同士のコミュニケーションと通信プロトコルは違うものである。
実際の人間同士のコミュニケーションの場において「無視は良いですね。」と言ったら人格を疑われる事があるので、そういう言葉を使うにも注意が必要である事を付け加えておく。
人との関係とは、まず、挨拶。そして、言葉のかけ合いが、基本である。

 さて、私は、「無視のコミュニケーション」に説明すると、ほとんどの人間は、それは悪い事だと言い張る。
機械と人間とは違うとか言い出す。
で、ここで、あえて、無理とは分かっていながら、「無視のコミュニケーション」についての説明がしたい。

 無視とは、コミュニケーションを拒絶している事であろうか?
機械のプロトコルにおいての無視とは、単なる約束事であり、これは積極的なコミュニケーションをし続けている事である。
拒絶のコミュニケーションではなく、空のコミュニケーションである。
この空のコミュニケーションがあるからこそ、リトライシーケンスやリカバリー処理がスムーズにできるのであり、この空のコミュニケーションから多くの可能性を持つコミュニケーションを作り出す事が可能となるのである。
 無視のコミュニケーションとは、拒絶のコミュニケーションではなく、そこから多くの可能性を作り出す空のコミュニケーションであり、智慧のあるコミュニケーションとなる可能性を秘めている。
つまり、無視とは、すき間無くコミュニケーションする機械の中で自然発生的に生まれるアクシデントに対して、間を与え、空のコミュニケーションをする事を定義して、復旧運営する可能性を持たせるなどの智慧を作り出す事に役に立っている。
この空のコミュニケーションがあるおかげで、障害発生時、同じコミュニケーションの応酬によって偏りが発生しているプログラムに偏りを無くし、別のコミュニケーションに導いて障害を克服する事ができるプロトコルを構築する事ができるのである。
機械のコミュニケーションにおける無視とは、無関心である事とは違う。
助け合いを有効に行うために無視するのである。
 しかし、それでも、無視は良くないと強情に言う者がいれば、説得として、方便として、「それは間を置く事だ。」と言うしかないだろう。
こういうコミュニケーション論で苦しんでいる時、私の話を聞いた人は、「それは、無視とは違う。忍耐強く、愛を持って見守っている事だよ。」と言ってくれた人がいた。
人を説得する事とは難しいものだ。

 さて、機械のコミュニケーションとは何か?
私の世界では、始めに「存在」ありきである。
通信する相手が存在するか存在しないかを確かめる事が一番大切なのだ。
次に、存在する相手が、どの様な状態であるかを把握する事が大事なのだ。
そこから、やっと、コミュニケーションの本題に入ってゆく事ができる。
もし、「存在」が有るとしたら、相手を呼び出す電文を送り続ければ反応が返ってくるものである。
それは、一般社会において挨拶する事と似ている。
そして、その挨拶によって積極的なコミュニケーションをさせる事が、私の考える機械のコミュニケーションの姿なのだ。


<目次>

1.電文とトランザクション・データー。 6
2.一電文の送信。 7
2.1.送りっぱなし電文。 7
2.2.STX,ETXで電文を囲む。 7
2.3.トランスペアレントな電文。 9
2.4.トランスペアレントな電文との混合型電文。 13
3.レスポンスを求める電文。 14
3.1.リトライシーケンスの電文。 14
3.2.リトライシーケンスの重複をさける電文。 15
3.2.1.電文を二重にする。(押し出し電文) 15
3.2.2.電文にシーケンス番号を付ける。 16
3.3.トランスペアレントな電文のレスポンスの場合。 16
4.ポーリング電文を活用する技術。 17
4.1.主局からの電文の再構成。 18
4.2.主局からの電文のフォーマット。 20
4.3.従属局からのレスポンス用電文フォーマット。 20
4.3.1.従属局が送り出す、主局から受け取ったシーケンス番号について。 20
4.3.2.従属局が送り出す、主局から受け取った電文種類について。 21
4.3.3.従属局が送り出す、内部エラーメッセージについて。 21
4.4.Q電文のプロトコル。 21
4.5.P電文の活用。 22
4.6.レスポンスの間引き。 22
4.7.リセット電文の必要性。 23
4.8.その他。(ヘルスチェック) 23
4.9.クライアント・サーバー。 24
5.親局と複数の子局のある電文形式。(マルチポイントの電文) 25
6.トランスペアレントでない電文の送受信+ENQコードについて。 26
7.トランスペアレントな電文の送受信+ENQコードについて。 28
8.XON,XOFFコードについて。 30
9.リクエストメニュー電文。 31
10.ネットワーク通信の有用性。 32
11.パケット通信に関して。 33
11.1.パケット通信によるデジタル通信の中継局に関しての考察。 33
11.2.OSIとTCP/IP。 35
11.2.1.セッション層の工夫。 38
11.2.2.送信権の確保の工夫。(全4重通信の構想) 38
11.2.3.マルチタスクとパケット。 38
11.2.4.TCPとUDP。 40
11.2.5.データーリンク層によるネットワーク通信。 40
11.2.6.コミュニケーションとは記憶を共有する事だ。 40
11.3.ネットワーク通信のデバッグ環境。 41
12.オンライン処理の基本的な通信エラー対策に関して。 42
13.ノンストップのシステムを作る事。 43
14.ポーリングと人間関係。 44
15.通信プロトコルを作る時の苦労。 45
16.昔のBASICでの通信割り込みの問題。 47
17.データー通信とアプリケーション。 49



1.電文とトランザクション・データー。

トランザクション・データーとは、命令と情報を持った文字列の事である。
コンピューター間の通信に使われるトランザクション・データーの事を昔の通信プロトコルでは、電文と呼んだ。
ここでは、その電文の送受信のやりとりについて解説する。



2.一電文の送信。

 送信側と受信側がはっきりしている、1対1のコンピューター間の一方方向の通信について解説する。

2.1.送りっぱなし電文。
 特に無手順と呼ばれている通信プロトコルである。
むき出しのトランザクション・データーを通信電文として一文字ずつ送信し、受信する側は、その内容をチェックして正常ならばその受信電文のデーターを取り込み受け入れる。

2.2.STX,ETXで電文を囲む。
 送信側は、むき出しのトランザクション・データーの先頭に、「STX」コードを付け、終わりに「ETX」コードを付け、その後、エラーチェックコードを付加して、一つの通信電文を作る。
受信する側は、「STX」コードを同期してから通信電文を受け取り開始し、「ETX」コードを受信したら、その後のエラーチェックコードを参照して正常ならば受け取った「STX」から「ETX」まで囲われた通信電文を確定したとみなす。
異常ならば無視して、また、次に「STX」コードが来るまで待つ。
また、「STX」コードを受信して、「ETX」コードが来る前に「STX」コードが来たら、新たな「STX」コードから始まった電文受信して「ETX」コードを受信しエラーチェックコードをチェクして電文が正常であるかどうか確かめる。
その後、確定した通信電文のトランザクション・データーの内容を受信する側は見て、正常ならばその受信電文の内容を受け入れ、異常ならば無視する。
 次に第一のエラー制御について述べる。
RS232Cの通信において、通信する文字列の文字の一つ一つにパリティーチェックが入っており通信の異常を監視する。
「STX」コードを受信しても、途中でパリティーエラーが発生したら、その電文は無視して、次の「STX」コードを探して次の電文を受信する作業に入る。
 第二のエラー制御について述べる。
送信する側は、電文に「STX」コード、トランザクション・データーの文字列、「ETX」コードを付ける時に、送信電文のエラーチェックコードを作って「ETX」コードの後に付加する。
受信する側は、「STX」コードと「ETX」コードで囲まれた電文の内容からエラーチェックコードを作り出し「ETX」コードの次にあるエラーチェックコードと一致するか確かめて一致したら正常電文とみなして、受け取り開始していた通信電文を確定したとみなす。
エラーチェックコードを作る方法とは、通信電文に使う文字列の文字の一つ一つを、加算して作ったり、EORして作ったり、CRCコードを生成して作ったりする。
通信プロトコルを作る際には、エラーチェックコードの生成には何を選ぶかを決めて運用する事。
ただし、第二のエラー制御は通信プロトコルにより無くても良い。
これらの事を考えて受信する側の通信電文を確定する状態遷移図の手順を以下に示す。
※ 状態遷移図内の赤字は、状態ではなく処理内容を記述する。

  ( 始 め )
     ↓
(「STX」コード検出(同期) )←――――――――――
     ↓              ↑      ↑
(電文受信処理)←(新たに)      │      │
  │  │     ↑ (受信していた文字列を無視)│
  │  │(受信していた文字列を無視)↑      │
  │  ↓     ↑        │      │
  │ 「STX」コードを検出 )   │      │
  ↓                 │      │
「ETX」コード検出          │      │
  ↓                 │      │
エラーチェックコードと一致――――→(不一致)    │
  ↓(一致)                    │
受信電文確定 ―――――――――――――――――――→│
                           │
○ 文字カウントして長すぎる電文:          │
    受信していた文字列を無視して――――――――→│
○ パリティーエラーを検出した電文:         │
     受信していた文字列を無視して―――――――→│

上図のマトリックス(初期値は①)
│    1  2 3 4  5  6 7
│①   ②  ― ― ×  ×  ① ①
│②  (②) ② ③ ×  ×  ① ①
│③   ④  ④ ④ ×  ×  ① ①
│④   ×  × × ①1 ①2 ① ①

上のマトリックスの各項目
│○ マトリックスの縦列
│  ① 「STX」コード検出(同期)
│  ② 電文受信処理
│  ③ 「ETX」コード検出
│  ④ エラーチェック
│○ マトリックスの横列
│  1.STXコード受信
│  2.STX,ETX.以外のコード受信
│  3.ETX.コード受信
│  4.エラーチェックコードと一致
│  5.エラーチェックコードと不一致
6.受信処理が文字カウントして長すぎる電文
│      (データーレングス・オーバー)
│  7.パリティーエラーの検出
│○ マトリックス内の各項目についての説明。
│  ―  無視。
│  ×  対象外(チェックしない)。
│  ①  受信電文レングスを0にして、
      「STX」コードを検出待ち処理。
│  ①1 受信電文確定処理実行して①の処理を実行。
│  ①2 受信電文不確定処理実行して①の処理を実行。
│  ②  電文受信処理。電文レングスのカウント。
│ (②) 新たに「STX」を受信したので、
│     今まで受信した電文を破棄すると同時に、
│     受信電文レングスのカウントを1にして、
│     新たに「STX」コードから始まる電文を受信する。
│  ③  「ETX」コード検出。
│  ④  エラーチェックコード処理。

 この状態遷移図とは、状態遷移図ではない。単なるフロチャートだと言う人間がいるだろう。
状態遷移図とは、イベントが有って、それによって状態が移り変わる。
これを表すのに、二種類の状態遷移図が存在する事となるだろう。
○ イベントに左右されず状態の変化だけに注目した状態遷移図とマトリックス。
○ 全てのイベントに対して対応して記述した状態遷移図とマトリックスである。
人によっては、全てのイベントに対して対応して記述した状態遷移図の事を単なるフロチャートだと言う人間が存在するが、プログラマーに仕様を渡して仕事をさせるには、全てのイベントに対して対応して記述した状態遷移図とマトリックスが必要な時もある。

2.3.トランスペアレントな電文。
 「STX」,「ETX」の電文では、「STX」コードと「ETX」コードを電文として送る事ができない。
そこで、どんな文字列の電文でも送れる電文の必要性が出てきた。
それができる電文をトランスペアレントな電文と呼ぶ。
HDLCプロトコルでは、トランスペアレントな電文を送れるが、電文コード主体のプロトコルでは、新たに「DLE」コード(データーリンクエスケープコード)を利用して、次の様なトランスペアレントな電文を作るのである。
送信側は、むき出しのトランザクション・データーの先頭に、「DLE」+「STX」の2つのコードを付け、終わりに「DLE」+「ETX」コードの2つを付け、その後、エラーチェックコードを付加して、一つの通信電文を作る。ここで、トランザクション・データーの中身に、1つの「DLE」コードがあったとしたら、「DLE」+「DLE」と2つのコードに変換して電文を作る。
次に受信する側は、「DLE」+「STX」の2つの連続するコードを同期してから通信電文を受け取り開始し、「DLE」+「ETX」の2つの連続するコードを受信したら、その後のエラーチェックコードを参照して正常ならば受け取り開始した通信電文を確定したとみなす。
その後、確定した通信電文のトランザクション・データーの内容を受信する側は見て、正常ならばその受信電文の内容を受け入れる。
また、電文を受信して「DLE」コードを確認したらその次も「DLE」コードならば、一つの「DLE」コードとして取り扱って電文受信処理を続ける。電文受信を開始して、「DLE」+「ETX」でも「DLE」+「DLE」コードでもなかったら、異常電文としてその電文の文字列を無視する。
 次に第一のエラー制御について述べる。
RS232Cの通信において、通信する文字列の文字の一つ一つにパリティーチェックが入っており通信の異常を監視する。
「DLE」+「STX」コードを受信しても、途中でパリティーエラーが発生したら、その電文は無視して、次の「DLE」+「STX」コードを探して次の電文を受信する作業に入る。
 第二のエラー制御について述べる。
送信する側は、電文に「DLE」+「STX」コード、トランザクション・データーの文字列、「DLE」+「ETX」コードを付ける時に、送信電文のエラーチェックコードを作って「ETX」コードの後に付加する。
受信する側は、「DLE」+「STX」コードと「DLE」+「ETX」コードで囲まれた電文の内容からエラーチェックコードを作り出し「ETX」コードの次にあるエラーチェックコードと一致するか確かめて一致したら正常電文とみなして、受け取り開始していた通信電文を確定したとみなす。
エラーチェックコードを作る方法とは、通信電文に使う文字列の文字の一つ一つを、加算して作ったり、EORして作ったり、CRCコードを生成して作ったりする。
通信プロトコルを作る際には、エラーチェックコードの生成には何を選ぶかを決めて運用する事。
ただし、第二のエラー制御は通信プロトコルにより無くても良い。
これらの事を考えて受信する側の通信電文を確定する手順の状態遷移図を以下に示す。
※ 状態遷移図内の赤字は、状態ではなく処理内容を記述する。

  ( 始 め )
     ↓
( 「DLE」コード検出(同期) ) ←―――――――――――――
     ↓                 ↑        ↑
( 「STX」コード検出  )→( 「STX」以外 )     │
     ↓                          │
(   電文受信処理    )←――――――――――――――  │
     ↓             ↑         ↑  │
( 「DLE」コード検出  )  (新たに)       │  │
 │   │  │   │      │         │  │
 │   │  │   │ (受信していた文字列を無視) │  │
 │   │  │   ↓      ↑         │  │
 │   │  ↓  「STX」コードを検出 )     │  │
 │   │(「DLE」コード検出:           │  │
 │   │   1文字の「DLE」コードとして     │  │
 │   ↓      取り扱い電文受信処理へ)――――→│  │
 │ 「ETX」コード検出                   │
 │   ↓                          │
 │ エラーチェックコードと一致                │
 │   │(一致)  ↓(不一致)              │
 │   │    (受信していた文字列を無視)―――――――→│
 │   ↓                          │
 │ 受信電文確定 ―――――――――――――――――――――→│
 ↓                              │
「DLE」、「STX」,「ETX」以外のコード:        │
       受信していた文字列を無視)―――――――――――→│
                                │
  ○ 文字カウントして長すぎる電文:             │
            受信していた文字列を無視して―――――→│
  ○ パリティーエラーを検出した電文:            │
            受信していた文字列を無視して―――――→│


上図のマトリックス(初期値は①)
│    1  2  3 4  5  6  7 8
│①   ②  ―  ― ―  ×  ×  ① ①
│②   ① (③) ① ①  ×  ×  ① ①
│③   ④  ①  ③ ①  ×  ×  ① ① 
│④   ③ (③) ① ⑤  ×  ×  ① ①
│⑤   ⑥  ⑥  ⑥ ⑥  ×  ×  ① ①
│⑥   ×  ×  × ×  ①1 ①2 ① ①

上のマトリックスの各項目
│○ マトリックスの縦列
│  ① DLE+STXのDLEコード受信処理(同期)
│  ② DLE+STXのSTXコード受信処理(同期)
│  ③ 電文受信処理
│  ④ 電文受信処理「DLE」コード検出。
│  ⑤ 電文受信処理「DLE+ETX」コード検出。
│  ⑥ エラーチェクコード処理。

│○ マトリックスの横列
│  1.DLEコード受信
│  2.STXコード受信
│  3.DLE,STX,ETX.以外のコード受信
│  4.ETX.コード受信
│  5.エラーチェックコードと一致
│  6.エラーチェックコードと不一致
│  7.受信処理が文字カウントして長すぎる電文
│    (データーレングス・オーバー)
│  8.パリティーエラーの検出
│○ マトリックス内の各項目についての説明。
│  ―  無視。
│  ×  対象外(チェックしない)。
│  ①  受信電文レングスを0にして、
│     「STX」コードを検出待ち処理。
│  ①1 受信電文確定処理実行して①の処理を実行。
│  ①2 受信電文不確定処理実行して①の処理を実行。
│  ②  DLE+STXのSTXコード受信処理。
│     受信電文レングスのカウントを1に設定。
│  ③  電文受信処理。電文レングスのカウント。
│ (③) 新たに「DLE+STX」を受信したので、
│     今まで受信した電文を
│     破棄すると同時に、
│     受信電文レングスのカウントを2にして、
│     新たに「DLE+STX」コードから始まる
│     電文を受信する。
│  ④  電文受信処理「DLE」コード検出。
│  ⑤  電文受信処理「DLE+ETX」コード検出。
│  ⑥ エラーチェクコード処理。

ただし、追加として、もし、電文の一番最後のチェックサムコードが、DLEならば、DLEを一つ追加させて、DLE+DLEとする。

2.4.トランスペアレントな電文との混合型電文。
 受信側が、最初に「DLE」コードを受信したら、トランスペアレントな電文として処理し、最初に「STX」コードを受信したら、一般の電文を受信したとして電文を処理してゆく事にすれば、どちらとも対応可能な装置を作る事が可能かもしれない。

「DLE」 : データー リンク エスケープ コード。
        (デリートとは違う)
「STX」 : スタート オブ テキスト   コード。
「ETX」 : エンド  オブ テキスト   コード。



3.レスポンスを求める電文。

 ここから、品質の良い通信をするための通信プロトコルの領域に入ってくる。
通信プロトコルとは、通信の仕組みを作る事である。
さて、今まで、受信する側は、障害のある電文を無視してきた。
今回は、障害のある電文が来たら、電文の再送を要求する電文を出して送信側に電文を再送してもらう。
また、障害が無く正常に受信されたら、送信側に正常ですという応答(レスポンス)を出して次の電文を送ってもらう事とする。
また、電文を送信して、レスポンスが返って来なかったら、送信する側は、また電文の再送をして確実に受信する側に電文を受信してもらう仕組みも作る。
 電文の異常は、送信側が作った時に発生するものと、通信の途中でノイズが入って発生するものがある。
デバッグ時には正しい電文と異常な電文を作って動作確認して、送受信側の装置のプログラムを作る。
実用段階において送信側が正しい電文が作れずに電文を送信する事が無い様にきちっとデバッグして作る事。
もし、ここで、そういう事態になったとしたら、この場合の通信プロトコルは、通信途中でノイズや切断があっての電文異常と判断して、送信側から電文を再送してもらって正しい電文を受信しようとする事となるだろう。

3.1.リトライシーケンスの電文。
 送信側の電文を受信したら、受信側は、確実にレスポンスを送信側に出してもらう。
正常に受信したら、受信側は、「ACK」コードを送信側に送る。
受信している電文にパリティーエラーなどの異常が発見されたならば、受信側は、「NAK」コードを一回だけ送信側に送り、電文受信は今までの受信電文を捨てて、また最初に「STX」コードのある電文が来るのを待つ。
また、受信した電文の終りに「ETX」コードの後のエラーチェックコードを確かめて電文異常と判断したならば「NAK」コードを送信側に送る。
「NAK」コードを受信した送信側は、受信する側にまた同じ電文を送信する。
電文を送信する側が電文を送って、なかなか電文を受信する側からレスポンスが帰って来なかった場合、電文異常があって受信する側がその電文を無視したとみなして電文を再送する。(タイムアウト処理)
この様に電文を送信する側に電文を再送してもらう仕組みの事をリトライシーケンスと呼ぶ。
リトライシーケンスとは、タイムアウト処理で判別した受信側からのレスポンスの無応答にも受信側からの「NAK」コードのレスポンスを受信しても働く。
通信プロトコルでは、このリトライシーケンスを実行するにも限度を設ける。
電文を送信する側は、「NAK」用と無応答用に限度を設けて、その回数をオーバーしたら、通信が切断したものとみなしてリトライシーケンスのセッションを終了する。
通常、このリトライシーケンスの限度は、どちらも3回あたりが適正だとされている。
 さて、受信する側が電文異常を探知しても、「STX」から始まっている一電文を受信した訳では無い場合、「NAK」を出さない。
これは、電文の無視ではなく、電文の形を持たない文字列の無視である。
それを無視しないで「NAK」のレスポンスを出すと、受信する側は、一電文に対してたくさんの「NAK」を出力し続ける事態が発生し、それにより異常なリトライシーケンスが発生して送信する側は多くの電文を出力する事により通信が混乱してしまう結果を生むものである。
だから、こういう場合、無視して無応答でなければならない。

3.2.リトライシーケンスの重複をさける電文。
受信側が正常な電文を受け取って「ACK」コードを送信したのに、送信側が伝送路のノイズなどの影響で「ACK」を受信できなかった場合、送信側はリトライシーケンスによって同じ電文を送信する。
この時、受信側は同じ電文を重複して受け取ってしまう。
電文が重複しても大丈夫なトランザクション・データーなら問題無いが、電文が重複して二重になるといけないトランザクション・データーの場合、この異常に対応する手段が必要とされる。
ここでは、そのプロトコルについて考える。
○ 電文が重複しても許される電文:上書き電文。(問題無し)
○ 電文が重複したら異常となる電文:加算電文など。(課題となり解決策を以降説明)

3.2.1.電文を二重にする。(押し出し電文)
 一回目の電文にデーターを送り、二回目の電文にそれを承認する電文を送る。
受信する側は、一回目の電文を正常(正常とはトランザクション・データーの内容もチェックする事である)に受信したら、そのトランザクション・データーを記憶し内容を実行しないで送信する側に「ACK」のレスポンスを返す。
ここで、二回目に送るはずの承認する電文が来ないで新たな正常な電文が来たら、前のトランザクション・データーの内容を排除して、新たなトランザクション・データーの内容を上書きして記憶し内容を実行しないで送信する側に「ACK」のレスポンスを返す。
次に送信する側は、一回目の電文に対して承認を与える電文を二回目に送る。
ここで受信する側は、二回目の承認を与える電文を受け取ると一回目に記憶しておいたトランザクション・データーを有効とみなして受信するコンピューターは、そのトランザクション・データーの内容を実行すると同時に送信する側に「ACK」のレスポンスを返す。
一度承認した電文に対して二重の承認電文を受け取ったら、すでにトランザクション・データーの内容を実行したので無効とするが、送信する側には「ACK」のレスポンスを返す。
これにより、リトライシーケンスの問題点である、送信側の「ACK」コードの受信エラーのために発生する電文の二重送信のために発生する受信側の電文の二重実行がさけられる。
これを私は「押し出し電文」と名付ける。

3.2.2.電文にシーケンス番号を付ける。
 電文にトランザクション・データーとは別にヘッダーを設けてそこにシーケンス番号のエリアを設けて取り付ける。
電文を送信する側のシーケンス番号は、初期値は「0」から始まる。
そして、電文を送信するたびに1つずつカウントアップされる。
そして、MAXになったら、今度は「1」から始まってカウントアップされる。
 受信する側は、電文が正常ならば、レスポンスにシーケンス番号を取り付けて送信側に送り、電文の内容を保存する。
そして、次の正常な電文が来たら、以前の電文の内容が承認されたものとして実行して、「ACK」にシーケンス番号を取り付けてレスポンスを返す。
また、「NAK」を送信する際にもシーケンス番号を付けてレスポンスを返す。
連続する電文は、シーケンス番号を取り付けて次々に送信するが、次に送る電文が無いとすると、以前の電文の内容を承認するための押し出し電文を送信して、受信側に以前の電文を承認させる。
 送信する側は、シーケンス番号を取り付けて送信するが、受信する側は、送信する側の電文のシーケンス番号が順番に来ているかチェックして、順番通りになっていないとエラーが発生したとみて、エラーが回復するまで電文受信を拒否する。

3.3.トランスペアレントな電文のレスポンスの場合。
 通常の電文のレスポンスの場合は、「ACK」、「NAK」であるが、「DLE」コードを使ったトランスペアレントな電文のレスポンスの場合は、「DLE」+「ACK」、「DLE」+「NAK」のコードを使うらしい。

この記事へのコメント

この記事へのトラックバック