Wander Alone Like Rhinoceros Horn

多忙な過去2年間が過ぎ、荷を降ろしてみると、見過ごしていた(あるいは故意に目を逸らしていた?)様々な事柄が眼に飛び込んでくる。そして、2年の月日は、諸々の事象を眺める私の眼そのものをも変容させていた。変容は、フィジカル、メタフィジカル、両面に及んでいる。回復された視力、衰えた肉体、削ぎ落とされた関心、獲得した視座。

過去に書いた文章を読み直すと、自分の変化と世界の変化が響き合うとともに軋み合い、交錯に眩暈を覚える。たとえば4年前にAJAXやFlashを題材にして書いた記事では、Webページがアプリになる可能性を考察していた。その可能性の一端は現在HTML5として実現している。ただし、HTML5には技術的に新しいことは何もなく、政治的理由により遅れてやってきた標準化にすぎない。また、同じく2006年に、今回と同じく過去を回顧している文章では、「無駄な部分を省いたコミュニケーションの需要は残るはずであり、むしろ参入障壁が十分に低ければシンプルなものがリッチなものを出し抜く可能性が十分にある」と書いており、こちらはTwitterとして顕在化してきた。しかし2006年の時点では、巨大なデータを合成してシンプルなインターフェイスに落とし込む処理を、自分では全くイメージできなかった。

8bit時代のビデオゲームは、表現能力を欠いたことにより洋の東西を問わない普遍性を獲得した。21世紀的なシンプルさの形式が普遍性を備えるには、世界中のユーザーの要求に即座に応答できるシステムを背後に組織化しなければならない。スマートフォン、クラウド… ハードウェアにいくつセンサーやプロセッサーが導入されようが、ソフトウェアデザインは本質的に自由だ。その広すぎる可能性の中から、有限の資源に応じた、核心を衝く着想が常に求められている。

この2年間は、専らWebブラウザーの発展に注目してきた。Jargon Fileにも載っている用語でwheel of reincarnation(輪廻)というものがある。ある処理に特化したプロセッサ(たとえばGPU)をCPUから分離した場合に、後年そのプロセッサの汎用計算性能が強化されるにつれ結局はCPU上でソフトウェア実装した方が効率的になり、再度CPUに吸収される…というサイクルが反復されることを指して輪廻と呼ぶ。Webブラウザーも、PCの本質的な機能であるということになれば、OSに統合されるのが望ましい。ところが、政治的事情からWindowsではそうはなっていない。iOSやAndroid、Chrome OSでは統合されているというのにWindowsではそうはなっていないというのは笑うしかない。どちらが望ましいのだろうか。一つだけ明らかなのは、私は自由なソフトウェアを支持するということである。つまり、iOSの現状が、競争を排除するようなものであるとすれば、私はそれを忌避するし、Apple社の製品は購入しない。私にとってのiPhoneとは、Androidの健全な発展を促す触媒でしかない。

Webブラウザーに関して、直近の動きで一番注目しているのはChromelessだ。XULがHTMLに溶け出している。自分が欲しかったコンセプトがそのままプロジェクトになっていて、嬉しかった。他に興味深かったのは、Beyond3Dで教えてもらった、EAによるPS3/Xbox360へのWebKit移植のベースに利用されていたOrigyn Web Browser。現在サイトが落ちているようなのでEA側のコードしか見ることは出来ない。EA側コードは、Paul Pedriana氏によるEASTL実装を含む(ドキュメントにはBoost.Intrusiveみたいなコンテナーが入っていると書かれているが見つからなかった)。

次に向けて、学ばなければならないことは山ほどある。

Dissecting WebKit2 Implementation as of October 2010

WebKit2 was first disclosed to the public in April 2010. Now half a year has passed, has there been any noticeable progress? This time I delve into the WebKit2 from the source-code point of view.

First let me recap what WebKit2 actually is and how it’s related to the current WebKit with the official high level design document as the reference.

For those who are not very familiar with WebKit, it may be confusing that WebKit as a whole contains a part that shares the same WebKit name. WebKit as the framework has 3 major components – WebKit, WebCore, and JavaScriptCore – as you see in the source directory. WebCore is the layout engine that parses an HTML5 web page into a DOM tree and renders a render tree created out of a DOM tree with CSS information computed on each node. In addition to the abstract or platform-agnostic parts, it contains platform-specific implementations such as graphics and I/O if necessary. JavaScriptCore is the JavaScript engine. Google Chrome swaps it with its own V8 engine whereas Safari uses JavaScriptCore under the name Nitro. JavaScriptCore/V8 bindings to DOM live in the bindings directory in the WebCore. A WebKit user controls WebCore through a high-level API set which is differently implemented for each platform. The WebKit directory contains such an API set. For example, the Windows version of Safari implements it by COM classes in C++ in the win directory while the Mac version does it with Objective-C in the mac directory. Due to some dependency on proprietary libraries owned by Apple found in the Windows implementation for Safari, WebKit embedders should try other API layer implementations such as Gtk+ or Qt unless adopting Chromium suits the need.

»Read More

Preliminary Look into libevent 2 for Windows

The libevent library is probably best known by its use in memcached. memcached is one of the key components of LAMP stack though the recent trend seems to instead highlight NoSQL solutions where typical RDBMS and memcached are replaced with more optimized and dedicated systems. The importance of libevent is not affected at all since libevent itself is not tied to applications that use it and NoSQL solutions can be constructed with libevent too. Other clients of libevent include Tor. libevent is crucial for its cross-platform availability. After all, one of the developers of libevent is Nick Mathewson who is also the head honcho behind the Tor project.

My interest in libevent comes from my own program, DICE. From the beginning of the development in 2002, its I/O is fully optimized to Windows and I/O Completion Ports (IOCP) without using any middleware or libraries. It’s old and not often updated, but works flawlessly. However, replacing it with a decent OSS library can be a good chance to make it more simple and robust. The concern from the performance point of view is the only obstacle left, but libevent 2 is supposed to come with the IOCP support. That was the news that let me start the evaluation.

The libevent version for this article is 2.0.7 RC. I built it with Visual Studio 2010 (VC10). Since I wanted to use the debugger to trace its flow, I built it as the debug version by changing the CFLAGS compiler options /Ox to /Od /MDd /Zi in the Makefile.nmake in the main directory and the test directory. ‘nmake -f Makefile.nmake‘ produces the libevent.lib static library.

Before building a project with libevent, you need to manually copy WIN32-Code\event2\event-config.h to include\event2\event-config.h. Then add libevent.lib to the linker input (if you use socket, ws2_32.lib too), and add libevent and libevent\include directories to the include directory.

Then I wrote a test code with its evhttp ‘Event-driven HTTP servers’ functions. It’s a simple Web server that shows requested URI and quits if /quit is requested. It listens to the port 8080.

»Read More

js-ctypes実装に見るlibffiの利用(& Windows-MSVCでのビルド法)

Firefox 3.6から入った、chrome権限のJavaScriptから外部バイナリコンポーネントのネイティブ関数を呼び出す機構であるjs-ctypesの実装が、libffiに基づいているということだったので、昔見たときはlibffiはVisual C++はサポートしてなかった記憶があったがFirefoxでビルドできるんだったら単体でもいけるよねーということでjs-ctypesのソースを追いつつ試してみた。

結果から先に述べると、若干手間を要するものの問題なくビルドでき、closureも利用できた。ここでいうclosureとは、呼び出された際にユーザー指定コールバック関数(元の呼び出しに使われたlibffiフォーマットの引数データが渡ってくる)を起動してくれる関数コードを、ユーザーが動的に指定したシグニチャで、ランタイムに実行可能メモリ上に構築してくれるlibffiのAPIが用意されているので、それを利用して作成したバイナリコードを指す。

js-ctypes実装の構造は至極直截的で、JSのオブジェクトとネイティブオブジェクトのバインダとしてのCTypesクラスと、dll/so/dylibみたいなバイナリコンポーネントのラッパーのLibraryクラスから成っている。Library::Declareでシンボルからバイナリ内の関数アドレスを得るときは、PR_FindFunctionSymbolを呼ぶ。これはNSPRの関数で、Windows上では、なんのことはないGetProcAddressが呼ばれる。なんでlibffiなんてものが必要かというと、荒っぽく言ってしまえば、Cでは関数ポインタを宣言しておけばコンパイラが良きに計らってくれるところ、動的言語で同じことをランタイムに行うために、その辺の呼び出し規約上のお膳立てをlibffiが整えてくれるというわけだ。

上述のclosureは、js-ctypesでは、ネイティブコード側にJavascriptの関数をコールバックとして渡す時に利用されている。Javascript関数オブジェクトに関連づけたclosureを作成し、それが呼び出された場合にはCClosure::ClosureStubが呼び出され、関連づけられていたJavascript関数オブジェクトが実行されるようになっている。closureは、コールバック用のプロキシとして働いており、この利用法自体は、libffiの実装内でffi_prep_closure_locの実体がFFI_INIT_TRAMPOLINE呼び出しで、closure用のメモリ領域が「トランポリン」と呼ばれていることからわかるように、想定の範囲内と言える。

Windowsアプリのメッセージハンドラ=ウィンドウプロシージャとしておなじみのWindowProcコールバックは、js-ctypesでは以下のように表現される。

var WNDPROC = ctypes.FunctionType(ctypes.stdcall_abi, ctypes.int, [ctypes.voidptr_t, ctypes.int32_t, ctypes.int32_t, ctypes.int32_t]).ptr;

Windows APIの呼び出し規約はWINAPI(__stdcall)なのでstdcall_abiが指定されている。これを元にしてlibffiがclosureを作成し、closureが起動されるとjs-ctypesが再度Javascriptの関数に戻して実行してやる。これが何を意味するかというと、js-ctypesがあればJavascriptでWindowsアプリのイベント駆動モデルすらも代替できる、つまりMFCとかイラネーよなということになる。これだけ強力なら、Firefox 4のGecko 2がfrozenインターフェイスを破棄してjs-ctypesを媒介にXPCOMを脱構築するという流れも必然であると納得できる。

Windows上でのVisual Studio 2010(VC10)を使ったlibffiのビルド手順としては、以下になる:

»Read More

新BitTorrentプロトコルµTPを実装するlibutpソースコードの概観

5月21日に、libutpソースコードがMITライセンスで公開された。libutpとは、µTP (Micro Transport Protocol)と呼ばれるプロトコルの実装ライブラリである(BitTorrent.orgではBEP 29として提案され、IETFではLEDBATとして提案された)。今回は、そのコードを見てみたい。

libutpを公開したのはBitTorrent, Inc.で、彼らが配布するBitTorrentクライアントμTorrentのバージョン1.8 betaがµTPを最初に実装した。BitTorrent, Inc.が元々持っていたオリジナルのBitTorrent実装(Mainline)は、Pythonで書かれたソフトウェアとして有名だが、μTorrentはC++で実装されたWindows用ソフトウェアである。μTorrentはスウェーデン人のLudvig Strigeus氏が開発したが、2006年にBitTorrent, Incに買収されている。μTorrentが登場したとき、備えている機能に比して、GUIアプリにしては(パックされている可能性を勘案しても)きわめて小さいバイナリサイズに感心した。プログラマの力量を誇示するかのようなコンパクトで尖ったソフトウェアだったので、後日の買収のニュースには、落ち着くところに落ち着いたなと感じたのを記憶している。

従来のBitTorrentによるファイル転送がTCPを経由して行われていたのに対し、µTPは、UDP上に構築されたプロトコルを用いる。既にDHTやトラッカーのプロトコルにはUDPが利用されていた(ただしμTorrentによる実装はかなり後になった)が、µTPは、トランスポートプロトコルとしてもUDP上に構築した独自プロトコルを利用する。

BitTorrentクライアントが実装したDHT(分散ハッシュテーブル)は、Kademliaというアルゴリズムの実装で、トラッカーに依存しないリソース探索が可能となった。Gnutellaライクな、しかしより構造化された分散キー管理により、トラッカーがダウンしていても目的のリソースを保持するピアのリストを得られる。ネットワークの単一障害点を無くすという建前だが、違法にアップロードされたデータを配布するトラッカーが検挙されつつあった情勢に対抗するものという見方もあった。

今回のµTP実装は、ネットワークの反応が悪くなってきた場合に、自動的に他のトラフィックに道を譲ることで輻輳を防ぐのが目的とされている。オンラインゲームなどのリアルタイム性が重視されるアプリケーションでは一定のレイテンシ以下にping値が収まっていることが要求されるが、TCPのFIFOキューではサイズの大きいP2Pパケットが転送される場合にジッターが発生しやすくサービスの品質に影響を及ぼす。現在のTCPでは、輻輳制御アルゴリズムとして、CUBIC TCP(Linux)、Compound TCP(Windows)が用いられている。µTPは、BitTorrentのアップロード時に起こりやすい輻輳を特に回避するという目的に適う制御アルゴリズムを、UDP上で実装したものということになる。現在、P2Pアプリケーションを対象としてISPによるトラフィックシェイピングが行われているが、これに対しての回答ともいえるだろう。

前置きは以上で、以下コードを見ていく。libutpは、Windows用のdllとして公開されており、VC9用のソリューションが添付されている。utp.defに公開されているCのAPI関数は以下である。

»Read More

Quid Pro Quo

One thing that I don’t like about lightweight languages (LL) is usage of bizarre identifiers. Compiled languages don’t care about verbose identifiers, but scripting languages often employ abbreviated names to gain run-time performance and typing speed.

my ( $x, $y ) = $self->invoke(
	+{
		METHOD => 'foo',
		PARAM => 'bar',
	},
	''
);

In this Perl snippet, I had no idea what “+{}” stands for. It looks like some kind of hash, but not sure. Googling it didn’t bring good results since Google doesn’t recognize a string made only of non-alphabetical characters such as braces and math operators.

To figure out its meaning I wasted so much time by trying many different words in Google. Anyway here’s the answer:

or to force an anon hash constructor use +{:

  1. @hashes = map +{ lc($_) => 1 }, @array # EXPR, so needs comma at end

to get a list of anonymous hashes each with only one entry apiece.

It’s embedded in perlfunc and I couldn’t find any other references in the official documents.

I had a hard time with Ruby too when the last argument for a method has an ampersand (&) prepended. In the Japanese version of the Ruby manual, it’s obscurely explained in a single line. It’s very hard to find since there’s no word for an ampersand in Japanese. It has no English version but The Ruby Programming Wikibooks has a related part which is a lot better with examples.

The ampersand (&)

The ampersand operator can be used to explicitly convert between blocks and Procs in a couple of cases. It is worthy to understand how these work.

Remember how I said that although an attached block is converted to a Proc under the hood, it is not accessible as a Proc from inside the method ? Well, if an ampersand is prepended to the last argument in the argument list of a method, the block attached to this method is converted to a Proc object and gets assigned to that last argument:

def contrived(a, &f)
     # the block can be accessed through f
     f.call(a)

     # but yield also works !
     yield(a)
 end

 # this works
 contrived(25) {|x| puts x}

 # this raises ArgumentError, because &f
 # isn't really an argument - it's only there
 # to convert a block
 contrived(25, lambda {|x| puts x})

Regarding manuals, MSDN is still the best place. Don’t know what “=>” means in C#? OK search it in the C# operators. It’s the lambda operator introduced in C# 3.0. Since I always code with a language specification on my side when it’s not C++, the quality of reference documents can be directly reflected in productivity.

C++ Dependency Injection (or the next best thing) on Windows

Dependency Injection (DI) is one of the recent buzz phrases within the design pattern community after Martin Fowler picked it up with another related concept Inversion of Control (IoC) in 2004. Since then, it became popular in Java lightweight frameworks where adding late binding was seen as a critical step for upping productivity.

The core value of DI is basically represented in these 2 points:

  1. Testability. DI makes testing easy by enabling loosely coupled components that are easily replaced with mock objects.
  2. Dependency control. When you deploy a DI framework instead of using the Factory Method pattern, dependency can be managed outside of components.

The first point is rather obvious. To understand the second point, I recommend you to browse the Google Giuce lightweight Java DI framework for its video presentation and documents. It illustrates the necessity of such a framework for Java in a straightforward way. Particularly, Giuce appears to be a neat implementation of DI where you don’t need to manage XML configuration files unlike other frameworks. Just like inner DSL, dependency is handled in type-safe Java code even though it ditches type-safe factories scattered in code.

But, as Ruby and other dynamic languages gets more attention, the relative mind share of DI seems to get smaller. In Ruby, you can swap methods of instances dynamically at the side of a test class. The dynamic nature of Ruby can enable whole other tricks dependent on it such as ActiveRecord.

So what about DI? Is it just a glorified abstract factory? Unfortunately, there still have to be environments where DI makes things a lot easier. Not just Java, but other static language, such as C++. Since my programming history is MS-Windows-centric, my interest toward DI is its applicability for Windows app development. DI is a lot discussed in the context of Java/.NET enterprise development, but its necessity would be even higher in C++ development on Windows as long as other requirements such as performance permit.

»Read More

Red Pill or Blue Pill

先月7月頭に、GoogleのChrome OSが発表された。Linuxカーネル + 軽量ウィンドウマネージャ + Google Chrome Webブラウザという構成を取るといわれるこのOSは、いわゆるシンクライアントを最低限のハードウェアリソースで実現するための環境となると推測される。ただし、従来の企業向け用途の単なるシンクライアントではなく、ビデオ再生や3Dなど、ハードウェアリソースを要求するリッチメディアがWeb上で当たり前のようにやりとりされている現在や近未来のパーソナルコンピューティング環境をも視野に入れていることは間違いないだろう。

これが、かつてOracleが提唱したネットワークコンピュータを越えていくものとなるかどうかは、実際のプロダクトの出来を見なければ、占うにはまだ早すぎるといわざるをえない。それでも、Google Chromeに続きChrome OSによって、Googleが考えるところの理想のクライアント環境を実現しようとする動きは、きわめて自然であるし、一貫性があるといえる。しかし、この一貫性は、単にGoogle内部で完結しているものではなく、歴史的な流れの中のある一点で、たまたまGoogleという企業が、マイルストーンとして一般に認知される発表を行うことを可能とするリソースや動機を有していた、という見方もできよう。

この仮想的な歴史をめぐる可能世界で、Chrome OSの前駆者として、またもう一つの可能性として念頭にあるのは、Microsoftの活動だ。今年の2月に発表されたGazelleは、プリンシパルベースのセキュリティという概念を主軸に置いて、Google Chromeより徹底したセキュリティアーキテクチャのWebブラウザを、OSをも巻き込んだ形で実装してしまおうという試みである。このアプローチは、Google Chrome実装の経緯と、興味深い鏡像関係を成している。Google Chromeの実装者らは、Windows上でセキュリティサンドボックスを実現するために、Windows XP SP2の実装に深く依存せざるを得なかった。市場を独占するOSのAPIや実装を管理できるというリソースを持ち合わせるMicrosoftにとっては、そのあたりの苦労は、技術的なものではなく、単に手続き的なものでしかない。そして、Gazelleが理論として存在したとしても、それが実際の製品に生かされるかどうかは、別の次元の話である。

Gazelleという試みと別の次元で並行して走る現実世界でのMicrosoftの問題は、法的な懸念である。1997年のInternet Explorer 4で、MicrosoftはOSのシェルとWebブラウザの統合を図った。その余波が、WebブラウザなどのコンポーネントをOSに同梱する際に紛糾するというヨーロッパでの今日的状況にまで及んでいる。この、法的な懸念をかわしつつ、MicrosoftがGazelleを実現しようとするならば、必要な機能のほとんどはOS側に盛り込んで、それを自社のWebブラウザからだけではなく他社からも利用できるようにすることになるだろう。Webブラウザというアプリケーションに固有の部分は、3層アーキテクチャでいえば、データの表示を司るいわゆるプレゼンテーション層や、Webブラウザ固有の操作に限定されたビジネスロジック層に限ったものとなり、データのやり取りを管理するデータ層は、OSが引き取ることになる。

ここで、Webブラウザの話に戻ると、Google Chromeの構成は、すでにそのような階層を前提としている。データのやり取りや管理を行うカーネルと、データの表示を行うレンダラーの分離は、Gazelle的なOSにおけるOSとアプリケーションの関係にそのままあてはまる。であれば、GoogleもまたOSに向かうのは当然の流れだろう。その意味で、Google Chromeとは、Windows等のOSの中に、Googleの植民地としての仮想OSを構築するという試みであったといえる。そして、仮想OSをOSに変えるには、ハードウェアとの仲立ちを行ってくれる層(たとえばLinuxカーネル)があればよい。

Webブラウザを仮想OSとしてとらえ、各々の機能を別プロセスに分けサンドボックス化してセキュリティを担保するという構成自体は、Google Chromeが初めてではない。2008年3月に発表されているOpus Palladianumは、まさにそのような実験だった。そこでの課題は、パフォーマンスである。データの流れに対して要所要所で監査が行われるため、そのためのレイテンシ増大が問題となっていた。これに対し、Google Chromeの場合は、機能分割の粒度を下げたり、各々の部品の最適化を進めることで、現実解を導いている。

いずれにせよ、ネットワークリソースのサンドボックス化、仮想マシン化、そしてクラウド化というトレンドは、最早後戻りのないポイントにまで進展してきている。このリアリティ(Red Pill)を受け入れ、積極的に生かすことができるか、もしくは幸福な幻想(Blue Pill)のもとに留まるか – 今後数年で、さまざまな選択と、その結果を目にすることになるのは間違いない。

Whisky-Tango-Foxtrot

芝公園にて、2009年4月3日

更新を再開しようかと思ったのだが、まだネタがないので仕方なくblog風に先日撮った写真(芝公園にて、2009年4月3日)で茶を濁す。

昨年も書いているように、サイト自体をCMSかblogツールにいい加減移行したいと本当は思っていて、そのくせ時間がないので踏み切れないでいる。

VS2008はやっと自分のPCにインストールしたところで、昨年書いた課題に取りかかる以前の段階で1年以上足踏みしてしまっている。その間に生活環境が変化したため、以前描いていた計画も、実装に取りかかる遙か以前の段階で既に再検討を余儀なくされている。具体的には、DICEに関して、ある部分のみC++/CLIを用いて.NET化することを考えていた。それというのも、ネイティブコードもそろそろ潮時かと考えて、C++を利用する部分を徐々に縮小させることを意図していたからであった。現在もその方針自体は誤りではなかったと考えているが、今それを為すべきか、そのための時間があるかということを熟慮すると、同じ時間を使うにしても他にやらなければならないことがあるのではないかというのが今回至った結論である。

また、去年計画・調査だけ行って結局頓挫したものとして、どのみち日の目を見ないだろうから忘れないうちに書いてしまうと、RTMPをDICEに実装することを考えていた。それというのも、抽象サーバーフレームワークであるDICEのプロトコル実装の試金石として商業的に意味のありそうなプロトコルを是非実装しておきたかったのと、Flashとの親和性を高めておきたかったという事情がある。サーバー用のソフトウェアスタック(と.NETで作った簡易クライアント)しかコントロールできない私にとって、Flash + JavaScriptはクライアントアプリ作成のためのRAD環境たり得た。ところが状況は変わり、C++の非常に有望なクライアント用ソフトウェアスタックが自由なライセンスの元で利用できることになり、今はそれをどう活かすかについて思案している。勘の良い諸兄ならそれが何かもうお分かりだろう。

WindowsにおけるC++へのPHP組み込み環境の構築

前回の記事では、C/C++コードへのPerlとRubyの組み込みを扱った。DICEへの組み込みの評価を兼ねていて、当時はPerlを使うことになった。一方で、DICEのWebサーバとしての側面をもっと強調せねばという課題が最近わりと念頭にあり、Webサーバを名乗るからには現在のWeb向けスクリプト言語No1としてのPHPをサポートしていないというのはいかにも心苦しい。PHPはApacheと関連付けて語られることも多い以上、Apacheの代替を目指しているわけではないDICEでサポートする意味も薄いと判断し敬遠してきたという経緯もあったものの、あまりにもPHPの勢いがありすぎるので仕方なくサポートに向けて舵を切ったというわけだ。特に海外では、VBulletinやWordPressといった代表的Webアプリケーションが利用できてようやくそれなりのWebサーバとしてユーザの検討の俎上に載せられることもあるだろう。
»Read More

Denial Ain’t Just a River in Egypt

久々にDICEの新バージョンをリリースすることが出来た。今回は互換性を破る変更もあったので、インクリメンタルに新バージョンをリリースするという以前の目標はひとまず措いて、必要な部品が全て入るまで待たざるを得なかった。ついでというわけではないが、自分のハンドルもKLからRyuKに変更した。KLでは短すぎるというのが主な理由だが、元のサイト名(KLassphere)をとある理由で変更したかったという動機が先に存在したかもしれない。そちらはryukwareへ変わっている。サイトのデザインもDICEのWeb UIで採用しているテンプレートを再利用して改装した。Webサイト自体も去年秋から新アドレスへ移転している。
»Read More

SSL Server with OpenSSL Memory BIO a.k.a. Prerequisite to Asynchronous OpenSSL

In the last article of mine about SSL-related programming, the API to handle SSL transaction for the DICE was the SSPI (Security Support Provider Interface) that is one of the standard API sets provided by Microsoft Windows. Though I outlined why I chose SSPI over OpenSSL in the article, recently I replaced SSPI with OpenSSL in the latest version of the DICE that was released with HTTPS implemented. The rationale behind the switch of the SSL engine was not so straightforward.

For me, the main concern about OpenSSL had been its putative close relationship with the BSD socket architecture that is not compatible with asynchronous sockets and I/O completion ports. Another concern was about OpenSSL’s vulnerabilities against security breaches. OpenSSL has been an active target by crackers and one of the most scrutinized library. Not that Microsoft’s implementation is any better, but as far as I know OpenSSL gets many security advisories about it through its update history.
»Read More

C++ Asynchronous Delegate for Microsoft Windows

Microsoft Windows 2000 and later have a very useful system function to make an asynchronous function call: QueueUserWorkItem. With this function and its thread pool that is aware of what Windows is actually doing at a given time, Windows takes care of all asynchronous function call complicatedness for you in the simplest form. This high-level function is a god-send for lazy programmers who would concentrate on what an application can do in a reasonable performance range rather than bothering about how it does things with the smallest performance hit.

But people can never be lazy enough, setting it up with context information each time will soon become a boring task especially when you want to asynchronously call a member function of a C++ object. But it’s not possible to make it completelly dynamic, either. You have to manually write a wrapper function, since QueueUserWorkItem is a mere C function that knows jack about C++. This article introduces a minimalistic toolkit AsyncDelegate.h that lends itself to solving this issue by using C++ templates.
»Read More

はてなWebサービスAPIを用いたPerl/Ruby Webアプリケーション2題

Webサービスというものが新しい技術として流行ったのは2001年頃だった。そこで語られていたビジョンというのは、WSDLで定義したWebサービスAPIをUDDIに登録し、それらがSOAPで通信しながらWeb上に広がるアプリケーションを構成するというようなものである。MS Windows的に言うと、レジストリに登録されたCOMコンポーネントのインターフェイス発見/呼び出しメカニズムのインターネット版ということにな る。ただし、Windowsの場合は、DCOMやCOM+といった、Windowsシステム同士のネットワークやWindowsシステム内部を一貫した分散オブジェクトRPCの文脈でとらえる仕組みを経て、一度レガシーを整理し、.NETに至る。このシステムをビルディングブロックとして利用することが宣伝されたHailstormというマイクロソフト提供のプラットフォームは、個人向けWebサービスをUDDI経由で提供するという触れ込みだった。その後Hailstormは、シングルサインオン認証をめぐる覇権争いに巻き込まれた挙げ句、開放された世界での商業的キーワードとしては消滅してしまった。他方、同時期にローンチして以来、コントロールされた閉鎖環境で運営されてきているシングルサインオンの理想型が、有料サービスXbox Liveとして存続している。
»Read More

Minuano

2006年は更新1回などと前回書きながらまたこのページを更新する。今回はつまらない作業のメモ。

MongrelというRubyのモジュールがあって、これはWebサーバの機能を持っている。似たようなモジュールとしてWEBrickというのがあるけれどもMongrelの方が新しくまたパフォーマンスも高いらしいというので昨日拾って中身を見てみるとmongrel(雑種)という名前に何か関係があるのかHTTPパーザの部分だけC拡張として実装してある。ソケット周りの部分をもCにしない理由は不明だが、大量のデータを処理するホットスポットをCにするという方針自体は正しい。
»Read More

Shonuff

去年は1回しかこのサイトを更新できなかったと述べているうちにすでに2006年も末で今年もこのDICE v0.86リリースに合わせての年1回の更新となる。書きためていた文章もいくつかアップロードした。サイトの全体的な改装なども行いたいけれどなかなか難しい。リンク切れの修正程度が精一杯だ。

Webサイトを公開し始めて7年、このサーバに移ってきてから4年経つ。DICEも4年が経ち、かなり大規模なアプリケーションになった。4種類のサーバが1つになっている上にGUIクライアントやWebアプリケーションのスクリプトなどが入って、一人でメインテナンスするには正直言ってかなり厳しいサイズになっている。ドキュメント類の更新だけでも一仕事だ。アプリケーションのライセンスであるとか、ソフトウェアにまつわる形式的な物事に対して自分で決定し細部まで凝るのが以前は楽しみだった。

プログラミングそのものについても一貫していて、DICEのデザインについてみると、自分がかつて書いた2本の記録を読み返してみても構築的な欲求や形式へのこだわりを強く感じる。ネットワークセキュリティにも強い興味があり、DICEの設計も偏執狂的にセキュリティを追及していた。IRCサーバというのは、他の種類のサーバに比べ、一つの独立した世界を創造するという側面が非常に強い。OSからハードウェアの抽象化という機能を抜いたような物だと考えれば案外近いかも知れない。セキュリティは、作り出した世界を確固としたものとするためには必須要件である。

また、DICEを作り始めた2001年頃には、デザインパターンやeXtreme Programming、RUP、アスペクト指向などの、ポストOOとでもいうべきソフトウェア工学のトレンドが旺盛に議論されていて、その頃は私もその関係の本やドキュメントを一生懸命追いかけていた。当時の自分のスタンスはどちらかというと保守的なもので、eXtreme Programmingのような教えは米国のソフトウェアコンサルタントの新しい飯の種にすぎない、自己啓発セミナーのようで胡散臭い、といった見方だった。また、色々なプログラミング言語を勉強したり、積極的に新しいプログラミングのトレンドを追いかけたりもした。C++のテンプレートなどもその一つで、自分の3年前の文章を見るに、当時はかなり興味を覚えていたようだ。余所余所しい書き方をするのは、関心が他に移っていったからに他ならない。その徴候はこのサイトの2004年4月28日の項に現れている。
»Read More

Perl, Ruby, Multithreading, Embedding

For the first half of this article the main topic is multithreading in the 2 scripting languages, Perl and Ruby. By writing a multithreaded download manager application in Perl and then porting it to Ruby, it’ll show you how to write a multithread application in the both languages and show you the difference of these 2 languages in this area. This section should be fairly easy and doesn’t require much knowledge about the scripting languages, but it’s expected that you have basic grasp of multithread programming.

The second half is for a bit more advanced programming topic; it’s about how to write a C++ application with an embedded Perl or Ruby interpreter. Simply embedding them is not rocket science, but using them in an effective manner is not a very easy task right now because of the implementations of these languages. If you are familiar with .NET you might know it’s embed-friendly with AppDomain and COM interfaces. On the other hand you have only raw C interfaces for these scripting languages, let alone scarce documents. As for Perl embedding, the sample code is based on the version I actually implemented in the web server of the DICE. Since it’s realized by the mixture of C++ code and Perl hack, it requires some knowledge of C/C++, advanced Perl programming, and Perl internals. But don’t be scared, I’ll annotate most lines in the code to make it useful for as many people as possible because it’s the very purpose of this article! Last but not least, the platform for those experiments is Microsoft Windows XP and Visual C++ 7.1. But due to the platform-neutral nature of these scripting languages most things should be applicable to any platforms.
»Read More

サーバプッシュの現在 – AJAXの辺縁

プッシュテクノロジと呼ばれる、Web通信をデータ放送に見立てた一連のWeb技術が1990年代後半に注目され、Webブラウザによる実装も試みられたことがあった。通常のHTTP接続はWebブラウザがリクエストをサーバに送りつけるとレスポンスを1つしか返さないのに対し、Content-type: multipart/x-mixed-replaceを利用したHTTP上でのサーバプッシュでは、クライアントのリクエスト無しで第二第三のメッセージが連続してサーバから送られてくるように見える。これを利用するとユーザの介入無く動的なページの表示が可能だった。ところがこの方法はNetscapeブラウザしか対応しておらず、Internet Explorerの台頭と共に完全に死滅することになった。

OSの最大シェアを握るMicrosoftの影響力はやはり強く、何年もアップデートされないIEがWebの進化を停滞させているという批判の一方で、画面遷移無しでWebページの内容を更新する手法としてのAJAXの基盤であるXMLHTTPRequestは、Microsoftが生み出したデファクトスタンダードとしてすんなりと世間に受け入れられた(ただしGoogleがその成果を非Microsoft化してしまった)。しかし、XMLHTTPRequestはクライアントがリクエストを一々発行するクライアントプル技術であり、サーバプッシュの真の代用にはなり得ない。

そもそもHTMLやHTTPというWebの標準がここまで貧しい設計でなければ特定ブラウザで動作するしないといった些細な事柄について無意味な議論を重ねる必要は生じなかったはずだ。HTMLベース技術の大半がプラットフォーム間の互換性の維持に労力を費やしている状況はある観点から見れば極めて寒々しい。例えばblogのデファクトスタンダードであるトラックバックという仕組みは、技術的なメリットではなくそれが標準として流布しているという政治的状況によって生かされているのである。その現状を一旦忘れ、例えば全てのWebページが別個のソフトウェアアプリケーションだったらどうだろうか。HTMLがチューリング完全なプログラミング言語で、自己が利用できるサーバまたはクライアント上の資源を理解しつつ全てのWebページが位置透過的・自律的にサービスを提供していたら?
»Read More

C++ and C#/.NET Interoperability for RSA Public-key Cryptography and AES Symmetric Cipher

When you have to write a secure network application, cryptography is one of the topics you can’t escape from. In most cases there are high-level packages such as SSL available, but it’s not always like that and you may have to go lower-level. Besides, even if you don’t program a custom security solution by yourself, it’s not a bad idea to know how these secure protocols actually work as it helps you to choose a right solution for your problem. This article provides a basic idea of secure communication by illustrating C++ and C# code examples. Also this article will be useful for those who writes a custom secure protocol between a C++ application and a C# application. (Disclaimer: but don’t use the example explained here as is in your mission-critical application! This article is only for the education purpose. Realworld secure communication libraries implement countermeasures against many kinds of known cryptographic attacks while this sample unfortunately doesn’t.)
»Read More

Thank You Falettinme Be Mice Elf Agin

DICEの更新日付を見たらなんと1年ぶりの更新だった。このウェブサイトについても同様である。実はDICE 0.85自体は去年の8月に完成していたのだけれど、それから色々あって手を付けることが出来なくなり、リリースそのものは今日に至ったという有様だ。書きたいことも多々あるが、しかしまたしても時間がない。後日に譲る。