ryukware

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

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

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

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

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

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.
続きを読む

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.
続きを読む

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

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

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

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

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 embedded-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.
続きを読む

プッシュテクノロジと呼ばれる、web通信をデータ放送に見立てた一連のWWW技術が1990年代後半に注目され、webブラウザによる実装も試み られたことがあった。通常のHTTP接続はwebブラウザがリクエストをサーバに送りつけるとレスポンスを1つしか返さないのに対し、Content- type: multipart/x-mixed-replaceを利用したHTTP上でのサーバプッシュでは、クライアントのリクエスト無しで第二第三のメッセージ が連続してサーバから送られてくるように見える。これを利用するとユーザの介入無く動的なページの表示が可能だった。ところがこの方法はNetscape ブラウザしか対応しておらず、Internet Explorerの台頭と共に完全に死滅することになった。webのデファクトスタンダードを握るMicrosoftの影響力はやはり強く、何年もアップ デートされないIEがwebの進化を停滞させているという批判の一方で、画面遷移無しでwebページの内容を更新する手法としてのAJAXの基盤である XMLHTTPRequestはすんなりと世間に受け入れられた(ただしGoogleがその成果を非Microsoft化してしまった)。しかし、 XMLHTTPRequestはクライアントがリクエストを一々発行するクライアントプル技術であり、サーバプッシュの真の代用にはなり得ない。

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