開発メモ: 50行のC++コードでWebサーバを実装する
「Kyoto Tycoonの設計 その四」改め、50行でWebサーバを書く方法を解説する。前回実装した「多重I/Oマルチスレッド汎用TCPサーバ」の上にHTTPの処理を行う層をつけて、「多重I/Oマルチスレッド汎用HTTPサーバ」を司るクラスを実装してみたので、それを使ってちょちょいとやる。 URLクラス HTTPと言えばURLが使えないと始まらない。URLは単なる文字列として扱ってもよいのだが、様々なシーンで分解や加工が必要になり、その処理はなにげに複雑で面倒なので、予めクラスとして導出しておいた方がよいだろう。 class URL { public: // 文字列のURLを解析して内部構造を作る void set_expression(const std::string& expr); // スキーム要素を設定する void set_scheme(const std::string&
開発メモ: ヒット率が低いDBMを効率的に管理する方法
表題のことについてtwitterに書きなぐっていたら幾人かの方々からレスポンスをいただいたので、せっかくだから自分の考えをまとめてみる。 背景 レコードをファイルに保存しているデータベースがあったとして、個々のレコードを参照する度に毎回ファイル入出力を行うと効率が悪いから、オンメモリのキャッシュ機構を用いるのが普通である。その実装には以下のことが求められる。 よくアクセスされるレコードのキーと値の対応関係を連想配列に入れて、高速に参照できる キャッシュにない場合、ファイルを探して、見つかればそのレコードの情報をキャッシュに載せる あまりアクセスされないレコードの情報は、LRUなどの尺度で判定してキャッシュから追い出す ダーティな（キャッシュ内で更新された）レコードはファイルに書き込む 上記の方法で大抵の場合はうまくいくが、弱点もある。キャッシュにもファイルにも存在しないレコードを探すことが
開発メモ: UTF-8とUCS-4の変換メモ
UTF-8とUCS-4の相互変換をC/C++で書いた時のメモ。たぶんまた自分で読むので。 背景 文字のちょっとした正規化などの処理をしたいがiconvやICUなどの巨大なライブラリは使いたくないということがたまにある。嚴密な文字列処理をしたい場合にはそれらのライブラリを使った方が安全だし確実であることは言うまでもないが、ちょっとしたユーティリティを作るのにはちょっとオーバースペックである。 一方で、UTF-8文字列に対してはASCII用正規表現ライブラリを使えば検索や置換などの大抵の操作ができるので、自分でゴリゴリと変換処理を書かなければいけないことはあんまりない。 ただ、たまに自分で書きたくなることもある。ヨーロッパ系言語のアクセント記号を外したり、半角片仮名を全角片仮名にしたり、漢字の異体字表記を常用漢字に統一したりといった処理を一気にやりたい場合とか。そんな場合、各文字が可変長バイト
開発メモ: 辞書検索システムを作ろう （機能編）
英和辞書や和英辞書などの辞書データは、検索文字列をキーとして使って、その値である説明文を取得するための連想配列である。Kyoto Cabinetを使うと非常に簡単に辞書検索システムを実装できることを2回に渡って示したい。これを読めば、英辞郎やWordNetのデータを使って自分の好みの辞書検索システムを簡単に作れるようになるはずだ。第1回目は、辞書検索システムの仕様策定と実際の機能について説明する。 デモ WordNetを使った英英辞書の検索システムを設置したので、まずは使ってみて欲しい。前方一致検索や完全一致検索はもちろん、曖昧検索や正規表現検索もできるスグレモノである。そして、早い。このサーバは、さくらVPSの一番安いプランで動作させているのだが、それでも大抵の動作がほぼ一瞬で完了するのがおわかりいただけるだろう。 http://fallabs.com/kyotocabinet/dict
開発メモ: memcachedプロトコルでメッセージキューを実現する
前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定
Kyoto Tycoon: a handy cache/storage server
Overview Kyoto Tycoon is a lightweight database server with auto expiration mechanism, which is useful to handle cache data and persistent data of various applications. Kyoto Tycoon is also a package of network interface to the DBM called Kyoto Cabinet. Though the DBM has high performance and high concurrency, you might bother in case that multiple processes share the same database, or remote proc
開発メモ: Kyoto Tycoonのプロトコル再設計
HTTPベースで任意のRPCコールができるように、プロトコルを汎用化したい。KT以外のユースケースでも、パラメータ等の解析部分は同じコードを使いまわしたい。その考察。 動機：実装を簡単にしたい 前回述べたHTTPServerクラスを作ったことで、HTTPベースのサービスを作るのが非常に容易になった。そしてその目的は、Kyoto Cabinetのデータベースを操作する各種メソッドをRPCで操作することである。でも、まてよ、「RPCで操作する」ってとこだけ抜き出してもう一段抽象化した方が、実装が簡単になるし、後々のメンテナンス性が良さそうだ。そうしよう。 RPCといっても処理の流れが同期なのか非同期なのかとか、データの受け渡しがブロックなのか、エラーの返却はどうするのかといった決定の組み合わせによって多様性があるわけだが、今回は最も単純な組み合わせを選択する。すなわち、リクエスト受信からレスポ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fallabs.com