2006/03/08

送信するデータの形式

俺は、昨日の自分と今日の自分は別人だと思っている。等と書くとメンヘルな奴だと思われるかもしれない。だが、そう思っていることは事実だ。俺が東大卒であることと同じぐらい確かな事実だ。

で、結局何を言いたいのかというと、それは、以前の俺の考えに今日の俺が必ずしも賛同するとは限らないということだ。具体的にいうと「主筆」の通信部分に関連する設計の話だ。

クライアントないし主筆からサーバに対してコマンド(指示やイベントの通知など)を送信する際、今までは文字列の値を使用していた。4バイトのデータ長と、その後に続く文字列をバイト配列に変換して、doorやパイプを通じて相手に叩きつけていた。ところが昨日の夜、やる気をなくして漫然とプログラムを眺めていたときに愕然と気が付いた。頭の中に電撃が走った。

よく考えてみると、このコマンドに文字列を使用しなければならない理由が一つもないのだ。別に文字列でなくとも、単純な数値でも何の不自由もないのだ。そういうことで、倉木麻衣が「お~べいべ~べいべ~」と歌うのを聞きながら、今まで文字列を使用していた部分を全部数値を使用するよう、プログラムを修正してみた。

が、修正した後にまたしても愕然と気がついた。頭の中でゴキブリがフラダンスを踊った。実は文字列にしたのは、数値のデータ型(intやlong)のビット幅があいまいで、確固としていないからだ。

ANSIの規格では、shortが16bit、longが32bit、intはshort以上long以下のシステムにとって最も都合にいいbit幅と決められている。ところが、一般に64bitでコンパイルすると、longが64bitでintは32bitのままだ。で、何でこの問題が仕様に影響を与えるのか。風船爆弾が戦局に何らの功も奏さなかったのと同様、気にするべき問題ではないのではないか。

実は、クライアント・サーバ・主筆の三者は、必ずしも常に同じアドレス幅であるとは限らないのだ。少なくとも、アドレス幅が一致していなければならない理由はないのだ。なにせこの三者はdoorやパイプを通じて通信しているだけなのだ。銃で果し合いをするのに国籍は関係ない。そうすると俺の性分としては、この三者のアドレス幅が一致していなければならないと言う制約が出ないようにしたくなる。風船爆弾的固執といえばそれまでなのだが。

ところが、通信するデータにintやlongを使用すると、アドレス幅に制約が生じてきてしまう。つまり、送信するデータの要素のバイト数にsizeof( int )とかsizeof( long )が使えなくなるのだ。そんな下らないことで、不要な制約を設けたくない。

そんな様なことを思って、結局俺は、コマンド爆撃に文字列を使うことになったのだ。だが、よく考えると、というかまったく考えるまでもなく、この考えはおかしい。なにせ、文字列の先頭に文字列長として数値を使用しているのだ。もうね、俺はアホかバカかと。無駄なことをしている上に、風船爆弾的固執は破綻してるし。

と、いうことで最初の話に戻る。数日前の俺は俺ではなかった、と。あれは俺の皮をかぶった別人だったのだと。黄泉から帰った戦士たちの中は人間だと。

心理機制はどうでもいいとして、今そこにある危機はどうしたらいいのか。俺の風船爆弾はどこへ行けばいいのか。まぁ、こんな瑣末な問題、どうとでもなるのだろうが逆にどうするのが一番いいのか、判断に迷う。一番美しい解答はなんだろうか。単純に思いつくところでは、10進数ないし16進数で文字列化するという方法だが…

まぁ、後で気が向いたら考えることにしよう。他のするべきことが山積しているのだから。

0 件のコメント: