今回は、前回の記事で話題に上った

『プロトコル屋としては、ネットワークミドルウェアは仕様通りに作ってあって正常に動いて当たり前で、その先に、相手の癖だったり使う環境だったりそういった「耐性」が重要だったりすると思っています。』

というところについて、前回までの記事とは別の「Centeの中の人」である私、菅野からスピンオフ・ストーリーをお届けします。

前記事の中でISDNルータ「MN128-SOHO」が話題に出ていましたが、当時はインターネットやWWWというものが一般家庭に降りてきて、回線はアナログからデジタルに、プロバイダも増え、そこにつなぐ機器も次々に新発売された時代でした。家庭向けISDNルータで言うとNTT-ME MN128-SOHOの他に、YAMAHA NetVolante、NEC Aterm、富士通 NetVehicleなどの名機がしのぎを削っていたことを思い出します。
私は実は、このMN128-SOHOのネットワーク部分のファームウェア開発の真っただ中に居ました。

さてさて、少し話を戻します。
組込機器のネットワーク部分のファームウェアを作っている会社（人）がそれぞれ違うのに、どうして「つなげる」「通信する」ことができるかというと、（当然ながら）みんな同じ仕様書を読んで実装しているからですね。PPP(Point to Point Protocol)にしろTCPにしろHTTPにしろ、ちゃんとIETFが公開しているRFCという文書シリーズにプロトコル仕様が規定されています。

RFC例）PPP　 https://datatracker.ietf.org/doc/html/rfc1661

　脱線話：　PPPプロトコルとか、HTTPプロトコルとか言っちゃう事ある人いませんか？最後のPはプロトコルですから、＊＊＊プロトコル・プロトコルって事ですからね！(笑)

最低限RFCで「MUST」（実装しなければならない）と記述されている仕様を実装しておけば「つなげる」「通信する」ことができます。。。できるはずです！
でも、昔は発表されたばかりのRFCでこんなことが起きました。

RFCの解釈に幅があり、解釈の違いで問題発生！
RFCに記述されていない部分の実装の違いで問題発生！
「SHOULD」（実装すべき）「MAY」（実装してもよい）の実装の有無で問題発生！

これが外から見ると機器の癖とか機器同士の相性として見える現象で、どちらが正しいということではありません。ただ、「こっちは悪くない」と突っ張っても機器を使いたいお客様が困るだけなので、我々としてはとにかくいろんな相手と接続試験を行って相手の癖を吸収するよう努力しました。ISDNルータの新製品が出たと聞けばすぐに購入・試験していたあの頃の社内は、さながらISDNルータ新製品の展示会場でした…

そんなバックグラウンドがあるためか、その後「ミドルウェア屋」となった我々は、自分たちが提供したプロトコルスタックが、それまで経験のない相手、新しい環境で「つながらない」という報告を受けた場合もすぐに調査・修正する体制をとっています。こういった継続メンテナンスや新環境対応がミドルウェアを提供する側の責務（我々の顧客の重要な目線）だと思っていて、もし、「Free沼」と言いつつも、Free環境でこれらが実現できているのであれば、例えばFreeRTOSがそこまで無償提供しており、相互接続性や不具合に対する対応がなされているのであれば、ミドルウェア屋としてその存在意義は薄くなってきたのかな、とあきらめかけていました。
しかし、実際にFreeRTOS環境を使って見えてきたことは、別の「Centeの中の人」が書いている記事の通り、顧客が開発したい組込機器とFreeRTOSが提供する環境の間には相当のギャップ（我々の言うFree沼）がある、ということの片鱗でした。なんとなく、AWSは同等以上の開発力を持っているエンジニアに向けて「こういうものをつくってみたので、あなたの開発に役に立つ部分があればご自由にご利用ください。」と言っている「だけ」なのではと感じます。

今日の閑話

RFCについて、一旦採番・公開された後も前述のような問題点を修正して新しい番号として採番・公開されていますし、最近のものは過去の経験から最初から十分留意されているので今は問題ないのかもしれません。私が必死に読んでいたRFCは20年以上前の1000番台、今はもう9000番台超えていますね…

そういえば、RFCの中には「ジョークRFC」と呼ばれる毎年4/1に発表される楽しいものもあります。伝書鳩にメモをつけて相手に届けるプロトコルRFC1149は最も有名かもしれません。Qiitaに解説記事を投稿している方がいらっしゃいますのでどうぞ。