スキップしてメイン コンテンツに移動

投稿

ラベル(code)が付いた投稿を表示しています

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 i...

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 the LAMP stack. However 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 by that trend since it's not tied to any applications and can be used for NoSQL solutions. Tor  is another use case of libevent. libevent is crucial for its cross-platform availability. One of the developers of libevent is Nick Mathewson who is also the key person behind the Tor project. My interest in libevent stems from my own project, the  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. Even though it works flawlessly in its current state, replacing it with a decent OSS library can be a good chance to make it more robust an...

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関数オブジェクトが実行される...

新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ライクな、しかしより構造化された分散キー管理により、トラッカーがダウンしていても目的のリソースを保持するピアのリストを得られる。ネットワークの単一障害点を無くすという建前だが、違法にアップロードされたデータを配布するトラッカーが検挙さ...

Quid Pro Quo

One thing that I don't like about scripting languages is usage of bizarre identifiers. Statically 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 +{ : @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 embedde...

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: Testability. DI makes testing easy by enabling loosely coupled components that are easily replaced with mock objects. 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 y...

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

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

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

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 ...

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 minimalisti...

はてな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として存続している。

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 AppD...

サーバプッシュの現在 - 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ページが位置透過的・自律的にサービスを提供していたら?

C++ and C#/.NET Interoperability for RSA Public-key Cryptography andAES 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 cryptogr...

How to Programmatically Create Self-signed Certificate and Key PairAssociation for SSL Communication with Microsoft Windows SSPI

In late 2001 when I started the development of the DICE , a multi-protocol network server, one of the planned features was secure authenticated connection across the web for remote server administration. I implemented it with SSPI (Security Support Provider Interface Architecture) found in Microsoft Platform SDK. SSPI is an abstraction framework through which you can control 3 (or more) different secure authentication/communication protocols including SSL (Secure Sockets Layer). Among the protocols supported in SSPI, I chose SSL because others (NTLM and Kerberos) were useless in my context over the internet without ActiveDirectory and related mess. But SSL in SSPI has some caveats before use - Since SSL is an inefficient streamed protocol unlike others and the abstraction by SSPI is not in high-level, your code starts to look nasty if you attempt to make it conform to the streaming nature of the protocol. It gets worse especially when your application is constructed arou...

Template Metaprogramming For Dummies

テンプレートメタプログラミングと呼ばれるテクニックがC++のコードに意識的に用いられ始めたのは1995年頃にまで遡るらしい(C++ による科学計算のためのライブラリ Blitz++ を作った T. Veldhuizenの記事 )。Alexander StepanovがテンプレートをANSI/ISOのC++委員会に提案したのがそれを遡ること2年前、1993年である。科学計算の分野で最も高速に動作するプログラムを構成するにはC言語ではなくFortranが最適であるという周知の事実に対し、C++言語でテンプレートを積極的に用いて、Fortranによる場合と同水準のパフォーマンスと、より見通しの利くオブジェクト指向を採用したプログラム構造とを両立させようという試みのもとに、このテクニックは開発されてきた。広く一般の認知を受けたのは、2001年のAndrei Alexandrescuによる著作 Modern C++ Design によってである。以来、 Modern C++ Design で解説されたジェネリックプログラミングとテンプレートメタプログラミングのテクニックを収めたライブラリ Loki 、 Boost ライブラリに収められているテンプレートメタプログラミングのためのフレームワーク MPL を通じて、その利用は徐々に広がりつつある。

Windows C++ マルチスレッドアプリケーション デバッグ法

1. はじめに 2. Windowsのマルチスレッド設備 3. 同期オブジェクトの保護対象 4. マルチスレッドの病理 5. マルチスレッドデバッギング - 実行時テストによる 6. マルチスレッドデバッギング - クラッシュダンプの分析 7. 広義のカーネルオブジェクトとしてのCRITICAL_SECTION 8 . おわりに はじめに Intel Corp.による Hyper-Threading Technology 導入により、マルチスレッドアプリケーションがMicrosoft Windows®上で効力を発揮する機会がさらに増えることが予想される。Windowsにおける従来のメインストリームとしての、デスクトップでの個人利用を前提としたGUIアプリケーションでは、マルチスレッドといってもせいぜいワーカスレッドを作業の度に生成してシングルユーザに対するユーザイン ターフェイスの応答性を担保するといったきわめて局所的な利用に留まる場合が多かった。こうした、共有メモリの中での割り込みを主目的とするような限定的で単純な利用では、マルチスレッド固有の問題が生起する確率は当然低い。

DICE Technical Notes II

前回 は、 DICEの初めての配布に際して、近年のIRC周辺の状況と、DICEに実装するIRC機能セットの選択基準について述べた。ただし観念的なバックグラウンドから具体性のあるデザインを抽出し計画を整形する過程の最中で書き留めたものであり、曖昧な部分が数多く存在した。当時の実装は、着手してから半年経過し最初のベータテストに臨んだばかりの段階で、一応のIRC/opennapサーバ機能は備えたとはいえ不安定で、明らかに改善の余地を残していた。現在では、さらに半年の検証と調整を経て、長期運用と数千の同時接続に実際に耐えることができる初めての正式バージョンのリリース(DICE v. 0.1)に至っている。そこで今回は、DICEの汎用ネットワークサーバとしての側面、バージョン0.1リリースに至るDICEの方向性の変更、また opennap準拠サービス(VirtualDirectory)の実装の詳細など、経験に基づいた視点をより多く加えつつ、現時点でのDICEの特性とその背後の意図を解説してここまでの記録としたい。

Early DICE Design Notes

About 2 years ago, I opened an IRC channel on a small IRC network. I'd been hanging out in EFnet , Undernet , or DALnet , but the accessibility to those large networks from Japan was not decent and not much improvement is seen even today. In some networks you are just kicked because you are from the .jp domain. As a consequence, I chose a small but reliable place for the new channel among many networks. It had nickserv and chanserv. One of the largest networks known in Japan, IRCnet, lacked those services.

ComponentID

Win32のUUID(GUID)構造体のラッパークラス。VS.NET2003付属STLのhashコンテナ(hash_map/hash_set /hash_multimap/hash_multiset)用比較関数、SGI系STLのhashコンテナ用ハッシュ関数オブジェクト付き。システムの用意した構造体を継承してクラスを作るというのは割とよくやる方法で、継承した場合vtableが無ければメモリレイアウトの先頭に継承元が入るので、後ろに追加のデータをペイロードとして付けた上で、親の構造体を引数とするAPIの引数に使えるという利点がある。換言すれば、templateと、template policyを利用したmix-inによって、C++における継承は、Java等のクラスライブラリに顕著な、現実世界やデザインパターンとして観念されるモデルのマッピングに近いカテゴリ概念の素朴な具体化のための道具というよりは、本来の意味でのデータ抽象/アルゴリズム抽象に向けての手段として、あるいはCOMのバイナリ仕様の表現として活用(exploit)される箇所しか出る幕が無くなってしまった。