同時性の情報量

さぁ電波の季節がやってきました。

春ですネ。

今年もビンビン電波を発振しましょう。

今日は非同期通信の話です。

サーバとクライアントが通信するとします。クライアントはサーバに問い合わせをしてデータを取得し、これを利用します。おそらくユーザに提示するのでしょう。データのカタマリを構造体なりパケットなりにして、通信するわけですね。

ファイル単位でよいなら、FTPを流用したって構いませんね。わざわざ自前でプロトコルから実装するなんてばかばかしい。あなたが少しでも標準規格の将来に目を向けるなら、そしてWebDAVをご存じならHTTPも捨てがたいですね。

というわけで一単位のデータをファイル(リソース)単位でやりとりすることにしました。これをファイルと呼ぼうがレコードと呼ぼうが構いやしません。

さて、クライアントが複数のファイルの取得をおこなうとき、問題が生じます。サーバの提供するデータが動的なときです。

クライアントがファイル1とファイル2を連続して要求したとします。サーバがファイル1を提供し、クライアントが取得完了するまでの間にファイル2の内容が変化してしまう可能性があります。

ここで、ファイル1とファイル2が全然関係の無いものであれば別にどうということはありません。しかし、ファイル1が今月の売上リストで、ファイル2が売上集計だとしたらどうでしょうか。

ファイル1に含まれていない売上がファイル2の集計にはふくまれてしまうようなことが簡単に起こります。

それでは、と依存関係のあるデータを取得するための一括取得のための仕組みを作りこんだらどうでしょうか。一括取得の開始時にサーバ側で排他をおこない、一貫性のあるデータをクライアントに提供するのです。

これは結局サーバとクライアントで同期機構を備えたリモートな共有メモリを実装しているのと同じになります。

通信経路がなんであるかは関係なく、クライアントは常に一貫性のあるデータへのアクセス手段を必要とし、それを邪魔しないで内容を書き換えるための手段をサーバが必要とするのです。

ftpやhttpは、その一貫性をファイルやリソース単位でしか提供してくれません。この点に常に注意を払う必要があります。

フィールドバス系のプロトコルなどを見てもわかりますが、結局必要なのは、リモート共有メモリです。一貫性がデータのグループごとに必要ならグループ数の分だけ共有メモリを持つことができれば充分です。

何十年も前に作られたものは動的なものにうまく対応できていません。

この種の問題をTCP/IPに対する無知やプロトコルに対する無知で片付けてはいけません。イーサネットなんて、所詮は静的データのやり取りにしか使えないものなんです。

その上で動くプロトコルも同じです。ルーティングテーブルの仕組みを御覧なさい。動的に変化するネットワークトポロジに対応することなんてできないじゃないですか。

もっともらしいプロトコルは誰にでも作れますが、まともに使い物にはなりません。それは時刻情報を含まないからです。

どのデータとどのデータが一貫性を持っているか、という情報が欠落しているのです。

これに対応するには
・同時性を保証する

・同時性を補償する
どちらかしかありません。保証するのはサルでもできます。全データを一括取得する仕組みだけ用意すれば宜しい。そして読み書きにガチガチに排他をかける。ただそれだけです。当然ですが、複数のクライアントが読みに行くと、サーバはデータの更新がぜんっぜんできなくなります。まぁトレードオフですがね。

同時性を補償するための方法論はまだ確立されていません。時刻情報+アルファを補うことで、時差のある情報、現在は「一貫性が無い」ためにクソとしか扱うことができないデータから一貫性のあるデータを抽出するための手段があるはずです。

それは誤り訂正と同じく、ごくありふれた理論の組み合わせで堅牢に実現できるはずです。ただマイナーで、ごみためまんが見つけられないだけなのです。