本の虫

著者:江添亮
ブログ: http://cpplover.blogspot.jp/
メール: boostcpp@gmail.com
Twitter: https://twitter.com/EzoeRyou
GitHub: https://github.com/EzoeRyou

アマゾンの江添のほしい物リストを著者に送るとブログ記事のネタになる

筆者にブログのネタになる品物を直接送りたい場合、住所をメールで質問してください。

500マイル以上離れた場所にメールが送れないのだが

http://web.mit.edu/jemorris/humor/500-miles

From: Trey Harris <trey@sage.org>

今から私が書く話は、起こりようのない問題についてだ。この話を広く一般に公開してしまうのは惜しい。というのも、いい酒の話のネタになるからだ。この物語は、退屈な詳細や問題を隠すために、多少事実を変えていて、物語を面白く脚色している。

数年前、私はキャンパスのメールシステムを保守する仕事をしていて、統計学部の学部長から電話を受けた。

「大学の外にメールを送るのに不具合が発生しているのだが」
「どんな問題でしょう?」と私はたずねた。
「500マイル以上メールを送れないのだよ」と学部長は説明した。

私はラテを吹き出した。「何だって?」

「ここから500マイル以上離れた場所にメールを送信できないのだよ」と学部長は繰り返した。「実際は、もう少しあるのだが。520マイルぐらいだろうか。とにかく、それ以上は無理なのだ」

「えっと・・・メールはそういう風には動かないのですが・・・普通」と、声の調子をできる限り抑える努力をしながら、私は言った。学部長と話すときは、興奮した声を出さないものだ。たとえそれが、統計学部であったとしてもだ。「なぜ500マイル以上メールを送れないと考えているのですか?」

「私の考えではないのだよ」と学部長は答えた。「つまり、この問題に気がついたのは、数日前のことだが・・・」

「数日も我慢したのですか?」と私は遮った。声が抑えられかった。「それで何日もメールが送れなかったのですか?」

「メールは送れたよ。ただその範囲が・・・」

「・・・500マイルというわけですね」と私は続けた。「わかりました。しかし、なぜもっと早く言ってくれなかったのです」

「うむ、さっきまで現状を把握するために十分なデータを収集できずにいたわけであるからして」。なるほど、彼は「統計」部門の学部長である。「とにかく、私は地球統計学者に問題を見てくれるよう頼んで・・・」

「地球統計学者・・・」

「そうだ。彼女は、我々がメールを送れる距離は500マイルをわずかに超える程度の半径であると地図上に図示してくれた。その半径内にも送れない場所はいくつかあり、あるいは散発的に送れるところもあるが、この半径の外には絶対に送れないのだ」

「なるほど」、と私は言った。そして頭を抱えた。「いつ問題が起こったのですか? 数日前とさっき言っていましたが、何かシステムに変更はありましたか?」

「そうだな。業者がやってきてサーバーにパッチをあててリブートした。業者に連絡してみたが、メールシステムには触っていないとのことだった」

「わかりました。見てみます。後ほどまた連絡します」と私は言った。自分でも会話について行けたのが信じられないくらいだ。今日はエイプリルフールではない。私は誰かにジョークの借りがあったかどうか思い出そうと試みた。

私は、その学部のサーバーにログインして、いくつかのテストメールを送ってみた。ここはノースカロライナにある研究室で、私のメールアカウント宛のメールは問題なく届いた。リッチモンドとアトランタとワシントンに送ったメールも同様だ。プリンストン(400マイル)に送ったメールも届いた。

だが、メンフィス(600マイル)にメールを送ろうとすると、失敗した。ボストン、失敗。デトロイト、失敗。私はアドレス帳を引っ張りだして、範囲を絞り込んでみた。ニューヨーク(420マイル)は届いた。プロビデンス(580マイル)は失敗だ。

果たして私は正気で物を見ているのだろうか。私はノースカロライナに住むが、ISPはシアトルにある友人にメールを送った。ありがたいことに、失敗した。もし、問題がメールサーバーではなく、人間の受け取り手の地理に左右されるのであれば、私は泣き出していたことだろう。

信じられないことに、報告された問題は事実であり、再現性があることが確認できた。私はsendmail.cfファイルを確認した。通常通りのように見える。実際、とても見覚えがある。

私はホームディレクトリにあるsendmail.cfとdiffを取ってみた。改変されていない。私が書いた通りのsendmail.cfだ。私は"FAIL_MAIL_OVER_500_MILES"のようなオプションを有効にしていないことは確かだ。わからなくなってしまったので、私はSMTPポートにtelnetしてみた。サーバーはSunOS sendmailバナーを返してきた。

ちょっとまてよ・・・SunOS sendmailバナーだと? その当時、SunはまだOSにSendmail 5をつけて出荷していた。すでにSendmail 8が安定しているというのにもかかわらずだ。良きシステム管理者である私は、Sendmail 8を使っていた。またもや良きシステム管理者である私は、sendmail 5の暗号のような記号文字ではなく、sendmail 8に追加されたわかりやすいオプションや変数名を使ってsendmail.cfを書いていた。

パズルはまさに解けた。そして、私は再び、もはや冷えてしまったラテを吹き出した。業者が「サーバーをパッチした」時、どうやらSunOSのバージョンをアップグレードしたようだ。そうするにあたって、sendmailがダウングレードされてしまったのだ。アップグレードはバージョン違いのsendmail.cfをそのまま残したのだろう。

たまたまだが、Sunの出荷したSendmail 5は、改変がなされていて、Sendmail 8のsendmail.cfに対応していて、ほとんどのルールはそのまま残った。しかし、新しい長い設定オプションは、ゴミとみなされて、無視された。そして、sendmailのバイナリはほとんどのオプションにデフォルト値を指定されていなかったつまり、sendmail.cfに該当な設定がみつからないために、ゼロに設定されていたのだ。

ゼロに設定されていたオプションの一つに、リモートSMTPサーバーに接続するタイムアウトがあった。ちょっと実験してみた結果、この環境と通常の負荷におけるゼロタイムアウトは、3ミリ秒を少し上回ると、切断されるようだ。

当時のキャンパスのネットワークの変わった機能として、100%スイッチされていたということがある。外向きのパケットはPOPを叩いて相手側のルーターに到達するまで、ルーターのディレイがなくなる。そこで、負荷の少ない近辺のネットワークのリモートホストへの接続は、ルーターのディレイよりも、光速の到達時間に左右される。

やや期待しながら、私はシェルを以下のように打ち込んだ。

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
        * 558.84719
        / 0.0017893979

「500マイル、実際はもう少しあるのだが」

Tery Harris

面白い話だ。ところで、unitsというコマンドを初めて知ったが、便利なものだ。

ドワンゴ広告

この記事はドワンゴ社内で書かれた。そろそろ次のC++標準化委員会の文書集が公開されても良さそうなものだが。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0