プロトコルの怪

現場の製品固有アプリケーション層プロトコルが物凄い糞に見えて散々悪態ついたんだけど、今更変えることも出来ないちゅう結論で、とりあえずご破算。ちゅうか、ちょいと自己レスしてみてもいまいち確固たるものが見えてこないので考えてみる。
そもそも、そのプロトコルだがキャラクタベースの其で、別にキャラクタをやりとりすることもないので、バイナリベースで良いじゃん？浮動小数データを指数フォーマット変換したキャラクタで投げることないじゃん？馬鹿じゃん？てな感じになっていて、まぁ、5億歩下がってキャラクタベースで良いとしてもハンドシェイクな発想が全くなくて、ダダ漏れなプロトコルなんで糞って言っていた訳。
キャラクタベースプロトコルで少し納得するのは、HTTPとかPOP3とかキャラクタをデータとして扱うプロトコルで、そのコマンド体系もキャラクタじゃないと、統一性がないとか制御コードが云々ていう理屈も分からぬ訳でもないけど、SMTPとかでデータ送信時\n.\nがデリミタとかのプロトコルはちょいと納得いかない。別にバイナリベースでも、データ長さえ通知すれば済む問題じゃない？キャラクタベースにした利点て何？と疑問が湧きあがる。そうだ、キャラクタベースの利点が明確に見えてないから、こういう疑問にぶち当たるんだよな。
と言うのも、今まで業務で制定したり利用したりしていたプロトコルはすべてバイナリベースだった経緯があって、キャラクタベースという発想がまずなかった。つまり、私もバイナリベースがスタンダードだと思い込んでいた節もあるし、SMTP/POP3を利用する開発時は古来プロトコルなんで疑うことさえしなかった(やり辛いとは思ったけど)。
関係ないけど、以前プロトコルが仕様通りじゃない！とか騒いでいたのでプロトコルの仕様書を見たら、データの構造にパディングという概念が入っていなくて、4バイトバウンダリビルドしているもんだから、構造体とプロトコルデータにミスマッチが生じていた事件があったな(素直にバイトバッファでR/Wしてオブジェクト化すれば良いという話もあるけど)。プロセス間でのデータのやりとりをする時は、こういうことにも注意しておかないと大恥じかくんだなぁと。
で、結局、こちらが新プロトコル提示しても工数の関係や、革新的な成果が得られないちゅうことでご破算になったんだけど、確かに改変しても利益があがる訳でもないし、余計なお世話だなぁと私も大人しくしておきました。糞な会社は所詮、糞なままって訳だ。デリミタチェックしながらポーリングする論理書いていると、物凄く虚しくなってきたので、コメントに糞なプロトコルだなって埋め込んでおきました。
私だけが糞だと思っているんだとしたら、それこそ改心ちゅうかそういう面で勉強しなくちゃいけないとも思いましたけどね。相方さん曰く「こういう企業固有プロトコル多いですよ。プログラミングする方からするとやり難いんですけどね。。」だとさ。
もっともっと色々な経験したいと思います。