コージィコーンモテル

読書とRPGを趣味とするエンジニアのblog

byte(バイト)とoctet(オクテット)は違うよ

ネットワークプロトコルの話をしていると、よくoctet(オクテット)という単語が出てきます。8bit(ビット)のことです。

ん?8bitはbyte(バイト)じゃないの?同じ意味の単語?分野が違うだけ?

これ、たまに聞かれます。

コンピュータサイエンスの分野では常識ですし、どこにでも書いてあることなんですが、一応書きます。書く癖をつけるために。(つまり自己満)

1 byte == 8 bitsではない

結論からいうと、1byteは必ずしも8bitとは限らないのです。

Byteという単位はそもそも今でこそ 1byte = 8bits が主流ですが、もともとは「bitの集まり」という意味しかないんですね。厳密には、「1文字をエンコードするためのbit数」だったのが、それが理由で「メモリの最小単位」という意味になったようです(そう考えると、「マルチバイト文字」ってなんか違和感がしますね)。

余談ですが、byteは英語のbite(噛む)からきています。bitに「噛むの過去形」という意味があるのと、biteにも「ひとかたまり」という意味があるのでぴったりですね。biteだと、bitと間違うことがあるのでbyteにしたという話は有名です。さらに余談ですが、byteの半分の単位にnybbleというものも存在します。nibble(かじる)からきていることは明らかですが、こういうのを見てると計算機科学のネーミングってとてもフリーダムな感じで面白いなあと思います。マウスとポインタの動きの比の単位にMickeyがあるのとかね。話が逸れた。

話を戻しますが、昔は8bitエンコーディングが主流ではなかったとのことです。記号が少ないころは6-7bitで足りていましたし。8bit以上のシステムもいくつもあったようです(世代が違うので自分は馴染みはありませんが)。

それとは別に厳密な8bitを意味する単語が必要になりました。プロトコルからしたら、ホストのメモリの単位なんざ知らん!ってことになりますので、byteは使えません。これがoctetです。

つまり、定義としてはoctetが正しい8bitの単位となります。

なので、たまに人が「8ビットだから、1バイトですね」といったことを口にすると、ちょっと違和感を感じます(もちろん、「1byte=8bitのシステム上で」という前提を考えてなさそうなときだけですが)。

以上です。当たり前のことをながながと書いてしまった。久々に更新できたからよしとしよう

疑似体験による教訓のインプリンティング

かの有名な湯川秀樹さんの著書、 『目に見えないもの』を通学・通勤中に少しづつ読んでます。

9割ほど読み終えたところなのでここまでの正直な感想を言うと、物理学者とは思えない(失礼かも)表現の豊かさと引き出しの多さに驚いています。前半はがっつり物理学の話で、内容としては高校や大学で聞いたことのある程度なんですが、独特な切り口が本当に面白い。宗教や哲学と織り交ぜながら考えることで、教科書・参考書で読んだときは無機質だった話が妙に彩られて頭に入ってきます。

人って様々なエリアを熟知するほど、共通点・比較点が見えてきたり、新しい視点が生まれたりして理解が深まるけど、湯川さんのそれは達人の領域。物理学という学問を何百もの方向から考えてきた人のみがなせる技なのではと思います。

ここまでべた褒めですが、3部ある中の1部目を読み終わると、湯川さんの自叙伝のような第2部に入るんですね。面白い物理学の話が突然おじさんの思い出話に変わるので、一度うろたえます。「物理の話はまだかな?」とか思いながらちょっと我慢して読み進めることになります。

ところが、気づくとこの本で一番心に残ってるのはこの第2部だったりするんですね。

生前父は私どもに別に訓戒めいたことはいわなかった。しかし父が折りに触れて人に語った言葉の幾つかが、いつとはなしに私の心に沁みこんでいる。父はよく「そんな杓子定規なことではいかん」といった。私は小さい時分には、なんでも細かいところまできちんとしなければ気が済まないたちであった。成長するに従って、こんなに小さなことに一々拘泥していては、とても大成出来ないと感じだした。そしていつも父の言葉を思い出しては、時分の気持にゆとりを与えることに努力してきた。それは同時に思考方法に融通性と柔軟性を賦与することを意味していた。自分の研究の行き詰まりの打開にも、これが始終役立ったのである。

「どうでも良いことにこだわるな」というどこにでもありそうな教訓なんですが、この本を読んだ後だと重さが違い、まるで自分で体験したかのように身に沁みます。こういった格言とか教えとかって、今の情報社会のそこらじゅうに蔓延していて、言ってることはもっともだと感じても、重みが全くないんですよね。結局実体験を通して痛感するまで身につかない。でもなるほど、こうやって描写されると、すごくしっくりきます。

適当な結論

形式にこだわりすぎてリファクタで1日を無駄にしないように。無理に完成された記事を書こうとして下書きばっかり積み上げないように、ということですね。

Curb使ってみる

とあるStack Overflowの質問でCurbというgemを使っていたので解決できるかなーと思ってインストールしてみた。

Curbって?

libcurlのrubyバインディングです。

cURLを使ったことがあれば、それと同じ機能をrubyスクリプトから呼び出すためのものと考えて大丈夫。 使ったことがない人は、万能なデータ転送ツールなのでいじっておくべきかも。

OSXなら初期装備だし、Linuxも、メジャーなディストリビューションで、ミニマル設定とかでなければ入ってると思います。 なくても、おそらく全てのパッケージマネージャでらくらくインストールできるはず。

試してみましょう。

curl www.example.com

HTMLがズラ〜と出力されたら成功です。

詳しい使い方を説明してると夜が明けてしまうので、日本語ドキュメントを見てください。 多分なんでもできます。驚くほど高機能です。

環境つくる

既存環境を汚したくないので、ローカルでやります。適当にディレクトリを作って、Bundlerを設定します。

mkdir curb_test
cd curb_test
bundle init

これでGemfileが作成されるので、今回使うgemを記入します

# A sample Gemfile
source "https://rubygems.org"

gem "curb"
gem "sinatra"

書いたらローカル環境にgemをインストールします。

bundle install --path=vendor/bundle

これで準備はOK。

サーバつくる

Curbを試すため、Sinatraを使ってAPIサーバとも呼べなさそうなものを作ってみます。

質問では、CookieSESSIONIDなる文字列を格納しつつユーザ名とパスワードをPOSTしてログインという感じだったので、一応偽ユーザ&パスワードチェックを入れてます。Cookieはめんどいので単にコンソールに出力して確認できるだけにしました。本当に役に立たないですがあくまでCurbが主役なので。

# server.rb
require 'sinatra'
require 'json'

post '/' do
  content_type:json

  # just show cookies on console
  p request.cookies

  # fake username&pass check
  if params['user'] != 'user' || params['pass'] != 'pass'
    return {"status":"failed"}.to_json
  end

  {"data":[{"value":2.74}],"status":"success"}.to_json
end

それぞれの行が何をしてるか、一目瞭然なのがrubyのいいところ

bundle exec ruby server.rb

書けたらこれでサーバが立ち上がります。デフォルトではlocalhostの4567番ポートにあがるはず。

cURLでテスト

クライアントを書く前に、cURLを使ってコマンドラインからテストしてみましょう

curl -X POST -d "user=user&pass=pass" -b "SESSIONID=123" localhost:4567

"status":"success"を含むJSONが返ってくれば成功。"failed"ならユーザ名かパスワードが間違ってます。 また、サーバ側で{"SESSIONID"=>"123"}と表示されるはずです。

クライアント作る

いよいよCurbを使います。上記のコマンドを同じことをやってから、結果をパースするクライアントを書いてみます。

# client.rb
require 'curb'
require 'json'

url = 'localhost:4567'
params = {'user':'user','pass':'pass'}
cookie = 'SESSIONID=123'

# generate http request
post = Curl.post(url,params) do |curl|
  curl.cookies = cookie
end

# parse response
res = JSON.parse(post.body_str)

puts res["status"] if res["status"]

gem名はCurbですがモジュール名は普通にCurlなので注意。

Curl.postにURLとパラメータを渡してます。その他の設定はブロックにまとめて渡します。結果はCurl::Easyインスタンスで返ってきますが、基本的にはbody_strメソッドを知ってればレスポンスを受け取れるのでOK。他のメソッドドキュメントを読みましょう。

"success"が出力されれば成功。簡単ですね。

所感

Curbを初めて使ってみました。扱ったのはかなりプリミティブな例でしたが、とても書きやすい(気がする)。

で、これをCurbでやる必要はあるのか?という問いに対しては、ピュアなrubyで書かれているNet::HTTPよりも、Curbの方が速いんですくらいしかまだ言えません。同じlibcurlを使用しているTyphoeusとの違いは?とか聞かれると、ちょっと厳しい。これはいろいろいじってみないとわからないですね。

結論

1日1アウトプット

こうは書いたものの、そう簡単に考えは熟成されず、下書きだけが積み重なっていくので、ちょっとやり方を変えます。 これから毎日最低一つ、どんなに短くてもいいので、何かについて書こうと思います。その間に、温めてたものがまとまってきたら、出力する感じで。

一応、毎日知的なことはしているつもりなので、大丈夫だと思います。書く習慣をつけるために、ちょっと実験

追記

無理そうです。笑

ブログを書く

書きます。

なぜか?

メモとして

面白い発想が浮かんだら、それがパァーと蒸発してしまう前に書き留めておかないともったいない。 良いアイディアって絞っても絞っても出てこないと思いきや、本当にどうでもいいときにわっさわさ湧いてきたりするので、メモする習慣の有無って生産性に直結するのでは、としみじみ思います。

アイディアの調理場として

熟成させたり調理しないと意味がないアイディアっていっぱいあると思うんです。ブログだと、アイディアを文字に起こすときにある程度頭の中を整理する必要がある。こういうときに気づくこともあるし、綺麗にレイアウトしてくれるので、後で自分の文章を見て考えが熟成されてることに気づくこともある。そういう意味では適当にメモ帳に書きなぐるよりもずっと良い環境なのではと考えてます。

自分が普段考えてることに意味を持たせる手段として

良いアイディアが浮かんでもすぐに実行に移せないことはよくあります。また、面白くても今の自分には関係がなかったりして、頭の中で生まれて、頭の中で完結してしまう発想って多いと思うんですね。

出力を持たない関数があってもしょうがないし、一度も使われないプライベートメンバはなかったことになっちゃうので、せっかくだからなんとか意味を持たせたい。やっぱり物事を考える時間も有限なので、無駄なことはしたくないわけです。こういったものが、米粒ほどでも影響力を持ってくれると嬉しい。

(余談ですが、Stack OverflowにPeople Reachedなる指標があります。これってこういう欲が満たされて素晴らしいですよね。自分の書いたちょっとした答えが、2万何千人って人に読まれているって考えるとなんかちょっと嬉しいです。)

どんなに使えなさそうな思想でも、こういう形で現実世界にぽーいと放り投げれば、誰かが拾ってくれるかもしれないので、「ああ今日も意味あることをしたなあ」って気持ちになるわけです。この気持ちのために書きます。

意気込み

がんばります。