TCP/IPの教科書：設計と実装

1990年代後半くらいから世界のネットワークはTCP/IPを主軸に展開されています。それ以前からTCP/IPは存在したし、今日でもTCP/IP以外のネットワーク・プロトコルは存在します。しかし現代社会では、ネットワークを専門にしていない普通の人達にとって、インターネットは欠かすことのできないインフラになっていると思います。

TCP/IPを勉強するために多くの書籍がありますが、中でも有名なのが次のシリーズでしょう。どちらも3巻シリーズとなっていて、第1巻が設計、第2巻が実装、第3巻がアプリケーションです。また和訳もありますが、原著の最新版に追いついていないし、値段も安いとは言えません。

• TCP/IP Illustrated
• Internetworking with TCP/IP

以前から買おうと思っていましたが、和訳本は中古でも高価なので、二の足を踏んでいました。原著は英語なので、読むのに苦労しそうですが、中古なら安価に入手できます。IT関係の情報を得るためには英語は避けられません。苦手意識はあっても、取り組んでいくべきなのでしょう。

原著の中古本を買うとして、どちらのシリーズにしようか迷いました。それぞれに記述スタイルに違いはあるかもしれないし、重視するところが違っているかもしれません。しかしTCP/IPであることには変わりないので、どちらを読んでも同じような事が書いてあるだろうと予想されます。迷った挙句、中古本なら安価なので、両シリーズの第1巻（設計編）を買うことにしました。読んでみると、案の定、説明の仕方がに違いがありますが、両者を読み比べることで、理解が進むような気がします。

両シリーズとも第2巻は実装編です。TCP/IPの実装なら、FreeBSD/NetBSD/OpenBSDやLinuxのソースコードが入手可能ですから、それを見れば良いのではないかという考え方もあるでしょう。しかしカーネルのソースコードを何の予備知識もないままに見たところで、飲み込まれるだけです。そういうわけで第2巻（実装編）も中古本で入手することにしました。

第2巻は両シリーズでアプローチが大きく異なっていました。一方はBSDのNet2を参照していますし、他方はXINUの実装を参照しています。さらに説明の詳しさも大きく違います。Net2の解説は1000頁以上もありますが、XINUの解説は500頁程度です。

これで両シリーズの第1巻（設計編）と第2巻（実装編）を手に入れた訳ですが、今後は何かの折に辞書的に参照するような使い方になるのではないかと思います。

FreeBSDのpackageでPython3が重複する

自宅では中古のノートPCにFreeBSD/amd64を入れて使用しています。以前にFreeBSD/i386を使っていた頃は、アプリケーションを自前でコンパイルしていましたが、今はコンパイル済みのバイナリを入れるだけになりました。以前もそうでしたが、依存関係にあるアプリケーションは勝手にインストールしてくれるので、それが有り難かったり、困ったものだったりして、単純に嬉しいとは言い難いところです。

最近Python3が異なるマイナーバージョンで入ったことに、ふとしたことで気付きました。

> pkg info -a | grep '^python'
python27-2.7.18                Interpreted object-oriented programming language
python36-3.6.10                Interpreted object-oriented programming language
python37-3.7.7_1               Interpreted object-oriented programming language

Python3を明示的に入れた覚えはないので、何かのアプリケーションの依存関係にあって、インストールされたのだと思います。それは良いのですが、アプリケーションが期待するPython3のマイナーバージョンが決め打ちになっていたのではないかと思います。それで複数のマイナーバージョンが入ってしまったのではないかと思います。

このような現象は他にもあって、LLVMについても複数バージョンが入っているのに気付いたりします。今の時代は昔と違ってディスク容量に余裕があるので、複数バージョンが入っていても気にしなくても良いのかもしれません。

しかしながら、Python2とPython3が入っているのは許容できなくもありませんが、Python36とPython37が入っているのは、なんとかならないかと思います。

ドライイースト（カメリヤ vs サフ）

昔から朝食はパンでした。過去にはスーパーで食パンを買っていましたが、約10年前にホームベーカリーを購入したので、それからは自宅で焼くようになりました。食パンさえ焼ければ十分で、しかも材料には拘りがありません。

Webで情報を探すと、小麦粉やイーストの銘柄の違いを云々する記事が見当たります。材料を変えることで、出来上がる食パン自体に違いが出るとは思います。しかし出来上がりの違いは材料の違いだけではないだろうと思っていて、いかに「厳選」された材料を取り揃えようとも、それだけで自動的に「最高」の食パンが出来上がるわけでもないのではないかと考えています。

焼きあがった食パンを食べてみれば「美味しい！」と思うかもしれませんが、それは「厳選」された材料を使っているからとは限らず、自分が手間をかけた事を知っているという心理的なバイアスの効果かもしれません。

こういう訳で（極端に言えば）材料は何でも良いと思っているのですが、COVID-19の影響により、スーパーの店頭から強力粉やドライイーストが姿を消しました。報道によると、外出自粛により自宅でパンを焼こうとする人が増えていて、売り切れるスーパーが増えているようです。いつも行っているスーパーの店頭でも、ドライイーストや強力粉が置いてある棚だけがガラガラでした。

まだ自宅に手持ち分があるので、それほど焦る必要はないのですが、この状況が何時まで続くか不明なので、長期化した場合に備えて、買える時には買っておこうかと考えていました。いつも行くスーパーで取り扱っているドライイーストが「カメリヤ」だったので、これまで長い間にわたってカメリヤを使っていました。ふと別の店でドライイーストを探して見たら「サフ」を見つけました。

サフのドライイーストは、Web記事で言及している事があるので、知ってはいましたが、現物を見たのは初めてでした。カメリヤよりは高価ですが、購入を諦めるほど高価という訳ではありません。たまには別のドライイーストを使ってみるのも興味深いかと買ってみようかとも思いましたが、いつも行くスーパーでドライイーストの供給が増えたらしくカメリヤが店頭に並ぶようになったので、結局サフは買わずじまいです。

Web記事によると、サフを使うと、食パンの膨らみが良くないことがあるとか、焼きあがった食パンがしっとりしているとか、数々の感想を読むことができます。これらは多分に主観的な表現なので、いざ自分がサフを使って食パンを焼いたとしても、カメリヤとの違いが出るか、さらに気付くかということは、なんとも言えません。

食パンの主たる材料は「小麦粉」です。他にもバターとか砂糖とか、小麦粉以外の材料が必要となりますが、ドライイーストも主役ではないだろうと思います。ドライイーストが、ただの端役なのか、主要な（?）脇役なのか、その役割の大きさは不明です。いつもと同じ廉価な強力粉を使っていながら、ドライイーストをサフに変えただけで、ほっぺたが落ちるような（!）美味しさに、劇的に変化するとも思えません。

ホームベーカリーで焼いた食パンが、美味しいか否かということは主観的に判断することになるので、Web上の記事を何百本読もうとも、結局は自分がどう感じたかということに過ぎません。自分で使ってみて、Web記事に書いてあった通りだと思うかもしれないし、そうは思わないと感じるかもしれません。

そういう訳で、手持ちの（カメリヤの）ドライイーストを使い切ったら、サフを使ってみて、自分自身で体験してみようと思います。

Ganglia Monitoring Systemにおけるpythonメトリックのname属性

マシン環境をモニターするためのOSSとして「Ganglia Monitoring System」があります。標準的な構成を何も変更しないでインストールして利用しても構いませんが、独自にメトリックを作成してマシン環境を参照する事もできます。独自メトリックを自作するにはpythonを使用しますが、作成の仕方のコツを掴めば、作るのはそれほど難しくありません。

メトリックの処理はpythonで組みますが、メトリックの構成を規定するためにディスクリプタを初期化時に返す必要があります。その中には属性「name」があり、これが作成しているメトリックの名前となります。その名前規約として認められる文字長や文字種が明白に定義されている訳ではないようなので、時として問題が起きる場合があります。

名前に半角の英数字を使っているだけなら、別に問題は起きないと思います。また、記号類として、下線文字やハイフンを使う程度なら、差し支えないでしょう。

しかしながら記号類として「/」を使おうとしたら、問題が起きました。属性「name」で指定された文字列は、内部的にはRRDデータベースのファイル名として使われるようです。このために属性「name」において文字「/」が使われると、RRDデータベースのファイル名においてパス名が狂ってしまうようです。

他にも属性「name」に文字「%」が使われるのも、問題を起こす原因となり得るようです。GangliaのWebインターフェイスでは、属性「name」の情報がURLの中に現れます。その時に文字「%」があり、その文字の直後にある2文字が「16進数」を表す文字にマッチしてしまうと、URLエンコードにより別の文字として扱われてしまいます。

これ以外にも問題となる文字があるのか、もうこれだけなのかは、分かりません。しかも、今回問題となった文字が、Gangliaの内部構造の変更により、将来的には問題とならない可能性もあります。OSSはドキュメント類の不備をソースコードを参照する事で補う場合があるので、問題があれば調査して原因を突き止めることは（原理的には）可能です。しかし問題が本来どうあるべきかを知ることは容易ではないでしょう。OSSを利用する際には、そのような事も意識する必要があるのではないかと思います。

Don't catch a cold.

The Japan Times Alphaで連載されているコラム「Odds & Ends」の2020年4月17日号のタイトルは「Health 3 Getting sick」でした。この中では、日本人は「Don't catch a cold.」とよく言うと書かれています。しかし英語圏ネイティブでは、このような表現をすることはなく、「Take care of yourself.」と言うのだと書かれています。さらに次のようにも書かれています。

Whenever I hear "Don't catch a cold," it reminds me of a mother talking to her small child.

コラムの著者も気付いているようですが、日本人が「Don't catch a cold.」という表現をするのは、日本語で「風邪を引かないで」とよく言うからです。日本人が日本語でそのような表現をすることは別に構わないのですが、日本人は英語で「Take care of yourself.」という表現を使うことを知らないのです。知らないから、日本語を英語に直訳したような表現になってしまうのです。その英語表現が、英語として破綻しているなら誤りに気付くところですが、英語でもそのような表現をしないわけではないようなので、単純な正誤の問題として考えることはできません。

よく笑い話になることですが、日本人は「お疲れ様です」のような表現をつかいますが、これを英語に直訳して「You must be tired.」と表現する人がいるようです（本当に居るのかどうかはわかりませんが）。この表現も英語構文的には誤りではないかもしれませんが、英語圏ネイティブが耳にすると、あまりの違和感にギョッとするようです。

日本語と英語の関係に限らず、自国語と外国語の翻訳においては、「意図の変換」をおこなう必要があるだろうと思います。

「空間」と「時間」という感性の形式

NHKで放映されている番組「100分 de 名著」の2020年6月のテーマは「カント 純粋理性批判」です。当初の予定では2020年5月に放映されるハズでしたが、COVID-19で制作が影響を受けたようで1ヵ月延期となりました。

NHK出版から出ているテキストでは、34頁に次のような記述があります。

「空間」と「時間」という感性の形式（感性にもともと備わった二つのフレーム）を抜きにして、事物を捉えることはできません。

「純粋理性批判」というのはイマヌエル・カント（1724～1804）の代表作で、難解な著作としても有名です。もっともこの書籍に限らず、哲学の書籍は、どれも難しいという印象を持つ人が多いでしょう。

話を戻して、「純粋理性批判」の解説の中で「感性の形式（空間と時間）」という説明が現れた事には驚きました。「空間と時間」というキーワードから思いつくのはアインシュタイン（1879～1955）による相対論における4次元空間（3次元空間+時間）の事です。

私たちが生きている世界は「3次元空間」なので、次元を落として「2次元空間（平面）」とか「1次元空間（直線）」を理解することは容易です。しかし次元を上げることは直観として理解できないし、図示することも不可能です。しかし相対論では「3次元空間」の次元を上げると「時間」を加えて「4次元空間」で理論を組み立てています。

カントは哲学であり、アインシュタインは物理学です。両者は時代が違いますし、学問分野も全く違うので、双方に交流があったとも思えません。そうでありながら、「空間」と「時間」を組み合わせることに自然な繋がりをみていることには、驚きを感じます。

お好み焼き（Japanese pizza）

The Japan Times on Sundayの2020年2月16日号に掲載されているエッセイ「Big in Japan by Mark Schreiber」のタイトルは「New outlets weigh whether new virus will affect Olympics」でした。その本旨から離れますが、文章の最後付近に次のような記述がありました。

127,000 tons of frozen processed foods such as okonomiyaki (Japanese pizza) and fried chicken parts (annual figures for 2018).

この文を見て気付いたのは、「お好み焼き」を「Japanese pizza」と訳していることです。

翻訳において訳語の選択は難しい問題だとは思います。世界中どこにでもあるようなものであれば、日本語で使われているある単語を英語で使われているその単語に置き換えることができるでしょう。しかし日本独自のもの（ここでは「お好み焼き」のようなもの）であれば、対応するものが英語圏に存在しないので、ローマ字（「okonomiyaki」のように）するしかないでしょう。多分それでは英語読者にとっては何のことか分からないだろうから「Japanese pizza」のように補足するのでしょう。「Japanese pizza」が適切な補足になっているかどうかは議論のあるところかもしれませんが、そのような表現で説明するという発想は新鮮でした。