設計中… - sdyuki-devel

次期V-FIELD（仮）案 1

・ノードがたくさんいる。ただし上限200台くらい。数千台とか考えない

・ネットワークで分散されたmap（keyとvalueの組の配列）を提供する

・keyとvalueは固定長

・keyを1コ渡すと、そのkeyに対応するvalueが1コ出てくる

・開始keyと終了keyを渡すと、複数のvalueがくっついた配列が出てくる

・keyとバッファを渡すと、そのkeyに対応するvalueが書き換わる

・開始keyと終了keyとバッファを渡すと、その範囲に対応した複数のvalueが書き換わる

・書き換えのとき、ロックはできない

・書き換え中に読み込んだときに、書き換え前のvalueが出てくるか、書き換え後のvalueが出てくるか、書き換え後と書き換え前が混じったvalueが出てくるかは分からない

・keyの追加や削除はできない

・ノードが落ちたり追加されたりした場合は、keyが同じでも、あるノードが読み込んだvalueが、別のノードが読み込んだvalueと違うかもしれない。タイミングによって出てくるvalueが違うかもしれない
→書き換えを１回でも行った＋ノードの数が変わった→不整合が発生するかもしれない

・同じkeyに書き換えが同時に２カ所からあったら、そのkeyに対応するvalueは、混ざった値になってしまうかもしれない
→同じkeyに書き換えを同時に２カ所から行った→不整合が発生するかもしれない

・起動時には、ブートストラップノードのアドレス、ストアサイズ（数値）、ストアパス（ディレクトリへのパス）を指定する
ストアパスはtmpfsをマウントしたディレクトリにするとイイかもね！

・ストアパスに、ストアサイズ分の大きさのファイルが作られる

・書き換えは、mmap()+read()+msync(ASYNC)、読み込みは sendfile(O_NONBLOCK)

・シングルスレッドでEvent Driven

・ノードの追加

・ノードの状態
あるノードを知っている = そのノードのIPアドレスとポート番号と持っているkey範囲を知っている

・ノードの離脱
落ちればいいさ。

・UDPパケットの受信
UDPパケット=
　ノードが増えたよーのブロードキャスト or ユニキャスト
　ノードが落ちたらしいぞ！のブロードキャスト
　このkey持ってませんか？のブロードキャスト

増えたよー通知されたノードのことを知らなくて、そのノードが自分が持っているkey範囲と少しでも重複するkey範囲を保持しているなら、TCPで接続して自分を知らせる。

・TCPパケットの受信
ノード一覧+どのノードがどのkeyを持っているかをくれ！

私はこのkey範囲を持ってますよ！

このkeyに対応するvalueをくれ！

このkeyからこのkeyまでのvalueをくれ！

このkeyに対応するvalueをコレに書き換えてくれ！ > そのkeyを持っているノードのうちどれか１つへ送る

このkeyに対応するvalueをコレに書き換えてくれ！と頼まれたけど、おたくもこのkeyを持っているらしいので、回すよ。あとソレとドレも持っているらしいので、回しておいてね。

# このkeyに対応するvalueをコレに書き換えてくれ！と頼まれたけど、おたくもこのkeyを持っているらしいので、回すよ。あとドレも持っているらしいので、回しておいてね。

プロトコルを表現するには、「相手の話を聞こうとしない会話形式」が一番イイ！

まだいろいろ抜けている気がする。
まずは書き込みの信頼性は保証しない。これを保証するのは大変大変…

例のAIO Serverを作っていたら、Linux AIOがソケットに対応していないおかげで、とってもカオスな実装になりそうな予感…ファイルディスクリプタがファイルを指しているかソケットを指しているかで処理を分けないといけない。

Posix AIO+kqueueなら全部シンプルに書けそうな気が。FreeBSD向けにしようかな…

ところで、epollとio_geteventsは組み合わせられるらしい。io_geteventsでepollのファイルディスクリプタを監視できる。
http://osdir.com/ml/kernel.aio.general/2004-09/msg00009.html