jj1bdx: Erlang memo

2009-11-22

Erloungeという宴会

Erlang愛好者のパーティをErloungeという.いわゆるlightning talkなんかが前置きとしてあって,その後は宴会になだれこむ,というのが典型的なErloungeの進め方らしい.といっても,世界各地それぞれの流儀で行っていることなので,特に決まりはないようだ.でも,Erloungeでの話は,一般の飲み会同様秘密だとか :)

Erlang User Conference 2009の写真はこんな感じだ.

http://www.flickr.com/photos/erlang-consulting/4119700138/

ところで,日本でも来月12月末には id:cooldaemon 主催の第1回 Erlang 基礎勉強会,そして来年の2月(3月になるかも)には第4回Erlang分散システム勉強会(aka Tokyo Erlang Workshop #4)が開かれるようだ.これらの勉強会の後には多分Tokyo Erloungeが開かれるだろう.興味のある人はぜひ参加を.

トラックバック - http://erlang.g.hatena.ne.jp/jj1bdx/20091122

2009-09-15

Erlangの速読

Erlangの文法は他の言語と違って独特なので,CやJavaの文法に慣れた人には読みにくいようです.しかし,コツをつかんでしまえば,案外早く読めます.

厳密ではありませんが,大まかなヒントとして

  • 各文は , (comma) / ; (semicolon) / . (period) のどれかで終わる
  • , (comma) では,関数節は終わらない.続いていく.
  • ; (semicolon) では,関数のパターンマッチングごとの節は終わるが,関数定義は別のパターンマッチングに続いていく.同様にcaseやreceiveなど複数の節を取る構文の場合は、文全体の終了記号は end であるため、文の終了を意味しない。
  • . (period) で,文と,関数定義は終了する.
  • 行頭が - (hyphen) で始まるものは,文ではなく,指示(directive)を示す.
  • % から先は行末まではコメントなので読み飛ばしていい.

というのがあります.

もちろんcaseやtry/catch/throw,fun(...) -> ... endなど,必ずしもこの規則に厳密に従わない文法はありますが,少なくとも . (period) に関する原則は徹底しています.このような句読点の打ち方は,英語やフランス語ドイツ語など,複文や同格表現を多用する言語と同様であると考えれば良いでしょう.一方,形式的なブロック構造にこだわっていると,読みにくいままかもしれません.

以上,最近コードを読み進めていた時の雑感でした.

トラックバック - http://erlang.g.hatena.ne.jp/jj1bdx/20090915

2009-08-22

ErlangとDNS

DNSはインターネットの各種基本プロトコルの中で最も扱いにくいもののひとつ.本当に高速な処理(=100kqueries/sec or faster)が要求される局面では,たぶんErlangのように一度VMが間に入る言語システムでは間に合わない.しかし,Erlangは並行処理が書き易いという利点は,DNSの各種サブシステムでは役立つと思う.ちょっとしたキャッシュサーバ,コンテンツサーバなどには向いているだろうし.もしErlangで何かDNS関連のアプリケーションを作るなら,yawsやMochiwebみたいなものを目指すべきだろうと思う.

DNSの研究開発というのは実は非常に難しくて,

  • ステークホルダーが多く,彼等の大多数は変化を望まない(特にISP)
  • ドメイン名自身が商標ビジネスの一部になっているため,技術論だけでは動かない
  • 明文化されていない約束事が多く,それらを知らないと簡単に開発できない
  • 何かやろうとすると影響範囲が大きく,通信量やセキュリティ脆弱性(フィッシングなどを含む)などの問題にすぐにぶつかってしまう
  • 過去のアプリケーション実装を無視した実験は実運用では事実上できない

などの問題がある.

そして,日本でDNSの研究開発を本気でやるなら,

  • JPRSでそういう仕事をする
  • WIDEのm.root-servers.netの仕事をする
  • ISPやレジストラで運用にかかわる

という,実はコーディングよりも,運用のスタミナが要求される非常に厳しい道以外にないんだろうと思う.残念ながら,私は上記のどれにも関われない状態のまま,挫折したけど.

個人であれば,神明達哉さんのように渡米してISCでBINDの開発にかかわる,という直球勝負をする方法もある.しかしこれはこれで生活を賭けなければいけないことで,そう簡単に誰でもできるわけではない.

ただ,DNSは研究開発だけじゃなくて運用や解釈も難しいので,DNS自身に関する知識や技はインターネットで何かやろうとする限りはついてまわるし,覚えておいて損はないと思う.Erlang R13B01なら,まず lib/kernel/src/inet_dns.erl を読むことから始めるべきだろう.

そして,DNS自身は,実装は今とは大きく変わる可能性があるけど,世界からドメイン名が消えてなくなる時が来るまでは残るシステムだろうと思う.

以上,つらつらとTwitterに書いたことをこちらにも.

トラックバック - http://erlang.g.hatena.ne.jp/jj1bdx/20090822

2009-08-17

[rants] 学習が進まず,上達しない

20年前Cを勉強していたころに比べると,コーディング以外の雑事がどうしても増える.ろくに時間が取れていない.

そんなことを理由にしてはいけないのだが,Erlangの学習とコード書きが上達しない.正直,焦っている.id:Voluntasid:kuenishiid:cooldaemonはてなidのみなさんは敬称略)そしてたけまるさんやMikageさんのコードにはとてもとても及ばない.

もう1年半もやっているのだから,もうすこしマシなものが書けても良さそうなものである.できない理由はいくらでも考えつくが,そんなことを議論している暇があったら少しでも手を動かさなければ.

…そんなことを思いながら,夏が終わるのと戦っている.

VoluntasVoluntas2009/08/18 00:43焦る必要は特にないと思います:-) 自分が出来ないことの沢山を力武さんは知っていらっしゃいますし、出来るので。ほとんどはコードは書いて読んだ量に質が比例すると思っているので、あとは地味な作業が続くだけなのかなっておもってます。

自分は力武さんに電離層のネタがいつか触れる日を夢見てますw

cooldaemoncooldaemon2009/08/18 18:57な・・・なにを、おっしゃいますか。
私は、erlang + ssl なんてサッパリ解りませんよ orz

kuenishikuenishi2009/08/18 23:51僕自身にとっては、Erlangは手段というかおもちゃでしかなくて、何か別のやりたいことがあって、そのための便利な道具だと思うことにしています。道具の使い方なんて慣れだけですし(慣れる速度に個人差があって当然)、Erlangだけではどうしようもなくて、それこそRFCが読めるとかthe Internetの関連技術をどれだけ知っているかとか、そういうことの方がむしろ重要だと思います。そもそも、そういうバックグラウンドがないとマシどころかロクなものができませんから。
僕もErlangに注目し始めてそろそろ2年になるのですが、もうすこしマシなものが書けてもよさそうだろ、とか、他の人のコードを見て溜め息をついていたりします:'(

jj1bdxjj1bdx2009/08/19 00:35みなさまありがとうございます.締切が迫っているのにうまくコードが書けない状態なので,つい弱音を吐いてしまいました.また進展があったらここに書きます.御礼まで

トラックバック - http://erlang.g.hatena.ne.jp/jj1bdx/20090817

2009-08-14

Erlang R13B01のssh moduleをaes128-cbc対応にする

R13B01のssh_transport.erlを見るとわかりますが,ストリーム暗号化は3des-cbcにしか対応していないのですね.RFC4253 Section 6.3では3des-cbcはREQUIRED,aes128-cbcはRECOMMENDEDとなっています.

すでにAESが2001年にNIST標準 FIPS-197になって8年も経過しているのに,Erlangssh moduleでサポートされていないのは単純に悲しいと思い,コードを書いて対応できるようにしました.すでにAES CBCモードの基本的な関数はcrypto moduleにありますし,ssl moduleを見てみるとAESのCBCモードが使われています.

この作業でハマったのは,ssh_transport:unpack/3という関数が,MAC以外の内容がなくなった時点でIV抽出用の関数に<<>>(ヌルバイナリ)を渡そうとするため,その関数で落ちるという問題があったためです.RFC4253 Section 6のBinary Packet Formatを見るとわかりますが,padding lengthがゼロというパケットも当然あり得るため,その時のエラー処理が不十分だったものと思います.以下で変更したのは"case SshLength of"の部分だけですが,これで無事処理できるようになりました.

%% Erlang R13B01 lib/ssh/src/ssh_transport.erl より該当する関数だけ抽出
unpack(EncodedSoFar, ReminingLenght, #ssh{recv_mac_size = MacSize} = Ssh0) ->
    SshLength = ReminingLenght - MacSize,
    %%?dbg(?DBG_CRYPTO,
    %%     "unpack: EncodedsoFar=~p SshLength=~p ReminingLenght=~p MacSize=~p ~n",
    %%     [EncodedSoFar, SshLength, ReminingLenght, MacSize]),
    {NoMac, Mac, Rest} = case MacSize of
                             0 ->
                                 <<NoMac0:SshLength/binary,
                                  Rest0/binary>> = EncodedSoFar,
                                 {NoMac0, <<>>, Rest0};
                             _ ->
                                 <<NoMac0:SshLength/binary,
                                  Mac0:MacSize/binary,
                                  Rest0/binary>> = EncodedSoFar,
                                 {NoMac0, Mac0, Rest0}
                         end,
    %%?dbg(?DBG_CRYPTO, "unpack: NoMac=~p Mac=~p Rest=~p ~n",
    %%     [NoMac, Mac, Rest]),
    {Ssh1, DecData, <<>>} = case SshLength of %% この部分でハマる可能性がある
                                0 ->                    %% 解読するものがないときは
                                    {Ssh0, <<>>, <<>>}; %% ヌルバイナリを返すようにした
                                _ ->
                                     ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0)
                            end,
    %%?dbg(?DBG_CRYPTO, "unpack: Ssh1=~p DecData=~p Rest=~p Mac=~p ~n",
    %%     [Ssh1, DecData, Rest, Mac]),
    {Ssh1, DecData, Rest, Mac}.

あとはcrypto moduleにAESのIV抽出用関数を1つ,そしてssh moduleにaes128-cbc用の処理コードを書き加えればOKです.この方法で他の暗号方式にも対応できるでしょう.

パッチの詳細については

http://www.erlang.org/cgi-bin/ezmlm-cgi?3:mss:449:200908:jocpkoflfkoikpmnfcnj

を参照してください.

トラックバック - http://erlang.g.hatena.ne.jp/jj1bdx/20090814