ISDNの全銀手順 解決だぁ！ その１

正確には、全銀手順TCP/IPという。
だいたいの手段としては、ISDN TAとサーバーセットとし、サーバーからISDNに着信接続を待機させる。
相手のサーバーが電話番号をダイヤルして接続、その後VPN接続を行い、プライベートネットワークを構築、そしてTCP/IP通信を行う、という流れ。
つまりは、ISDNにとどまらず、TCP/IP通信出来るようにすれば、全銀受信は使えるのだ。
さて、このTCP/IPに何か決まったフォーマットがあるのかと思うと、
別になくて、TCP./IPの制御に一任しているとのこと。

つまり、不具合が発生する原因は、全銀のシステムにあらず、
WindowsとUnixベースのVPNに起因するものと思われる。
この辺から調査を開始して、2つのキーワードにたどり着く。
Nagleアルゴリズムと遅延ACKだ。
The small-packet problemという1バイトだけ送ろうとすると、
ヘッダがついて21バイトになったりする。
本来は、20バイトしか送らないはずなのに、1バイト20回送ると、21*20=410バイトになったりする。
それが100人ぐらいアクセスすると、410000となり、410KBに膨れ上がったりする。
これを解消するために、ある程度バッファに貯めてから一気に送信する方法を取るのが
Nagleアルゴリズムだと考えてください。
こいつの悪いところはバッファが溜まりきるまで送信しない、タイムアウトになるまで200〜500msまで待ってから送信を行う。
そこで遅延が発生する。ただ、これはまだマシなほうで、
遅延を許容してくれればOKなのだが、時々遅延を許容してくれないソフトウェアがいる。
全銀もそれっぽくて、300ms以上になると、TCP/IP通信を放棄するような動作を見せる。
だから伝送異常になる。
それとはまた別に遅延ACKもある。こいつも凶悪なのだが、その前の大前提の話が存在する。

ISDN回線の品質だ。
うちの回線は色々な方法を使って、最低限の遅延で繋がるようになっている。
ただ向こうのネットワークがかなり遅い。
普通のpingを送ると120ms、300バイトで送ると合計600バイト帰ってくる時間が350ms、1500になると600msまで行ったりするのだが、
帰ってくるのはまだマシで、けっこう信号が消失してたりする。
10回注2回信号が消えたりする。タチが悪い。
この消失フラグメントを解決するために、ACK送ったりしているのだが、そのACKすら消えているように見える。
結果、伝送異常となる。

上記の問題はけっこう深刻で、相手の会社に言っても、意味不明と返されるパターンが多い。
なので、こっちのアプローチである程度制御できないかを確認して、それを相手に認識させようと思った。

次回に続く。