ryogrid

hoge

ryogrid

Rustでの実システムを想定したシミュレータでは何のロックを取ればよいのか

• リエントラントロックを使っている点には注意が必要
  • 各API呼び出しで起動されるスレッドは呼び出しごとに別々である。したがって、別ノードを中継して同じノードのAPIを叩いた場合は、実システムに合わせるならば2回目のロック取得はブロックされなければならない
  • ただし、同一ノード内ではAPI呼び出しという形はとれないはずなので、そういったケースでは同じスレッドが複数のAPIに対応する処理を行う場合もあるはずで、その際は同一のロックを複数回とれても問題ない 　
• ノードオブジェクト自体のロックを各オペレーション担当スレッドが持ち続ける必要はなく、持ち続けてはいけない
  • 他のスレッドは、そのオブジェクトをラップしたArRmRs型のオブジェクトをglobal_datasから得ることができるが、ロックをとってラップをはがすことができなくなる 　
• 現状、複数スレッドで触れるように排他できるのは、ChordNodeにArRmRs型のフィールドとして持たせている3つのクラス単位でしかないような気がする。。。しかし、それでいいような気もする。
• ★ただ、クリティカルセクション区間を設けようとした場合は別の仕組みの導入が必要なような★

ryogrid

/mnt/h/work/rust_kvs_win_rust_env/chord_sim_rust/src% find . -name "*.rs" | xargs grep -n "TODO:" | grep rust | ruby -pn
e '$_ = sprintf("%-35s", $_.strip.split("//")[0]) + "  # " + sprintf("%-50s", $_.strip.split("//")[1]) + "\n"' > /mnt/c/
Users/ryo/Desktop/chord_sim_TODO_comments_rust.sh
して出来たファイルをVS Codeで開いて Format Document して、あとズレてるところをちょこちょこいじる

./chord_node.rs:601:  #  TODO: (rust) 実際にKVSとしてデータのput、getを行うようになったらこのフラグは
./chord_util.rs:624:  #  TODO: (rust) 将来的にはNodeInfoのロックを保持し続けなくて済むように出力に必要な要素を各々引数に渡す形に
./endpoints.rs:121:   #  TODO: (rust) ダミー実装なので委譲処理が必要になったタイミングで対応すること
./main.rs:1169:       #  TODO: (rust) リトライ関連の処理は後回し
./main.rs:1202:       #  TODO: (rust) ひとまずjoin処理が成功していようがいまいが all_node_dictに追加してしまう

ryogrid

最新のTODOコメント全て（21/05/03 19:51）
/mnt/h/work/rust_kvs/chord_sim/modules% find . -name "*.py" | xargs grep -n "TODO:" > /mnt/c/Users/ryo/Desktop/chord_sim_TODO_comments.sh
./chord_sim.py:159:          # TODO: 実システム化する際は、リトライ処理は各オペレーションに対応するRESTインタフェースの呼び出し
./chord_sim.py:193:          # TODO: handle stabilize_successor at do_stabilize_successor_th
./chord_sim.py:388:          # TODO: gval.all_data_list は 検索のコストを考えると dict にした方がいいかも
./chord_sim.py:482:          # TODO: 対応する処理を行うスクリプトの類が必要 node_join_th
./chord_sim.py:489:          # # TODO: デバッグのために1000ノードに達したらjoinを止める。後で元に戻すこと!
./chord_sim.py:502:          # TODO: RESTでエンドポイントを叩くテストプログラムが必要 data_put_th
./chord_sim.py:511:          # TODO: RESTでエンドポイントを叩くテストプログラムが必要 data_get_th
./chord_sim.py:524:          # TODO: 適当に選んだプロセスをkillするスクリプトなりが必要 node_kill_th

ryogrid

% 分散KVSシミュレータ（Chordシミュレータ） & 分散KVS（Rust製の実システム）
理想的（いくらか恣意的）なノードの振る舞いを前提とした条件下で、put と get が DHT の枠組みで動作するところまで
シミュレーションが行えた後の記録。
以下より前の消化済みTODOは記録していなかったか、コード中のTODOコメントですましていた。

● joinとstabilizeとputとsuccessorを辿っていくget（実装する）を並行に動かしたときにワークするか確認
・【完】joinとstabilize_successorとstabilize_ftableを並列にに実行させる形で最初からノードを追加していく

・【完】getは見つからなかった場合にsuccessorを一定数辿るようにする（※）。
　これはつまり、ノード間でノード情報をやりとりする際に、実システムでも、アドレスだけでなくsuccessorの情報を併せて

ryogrid

CentOS6.1なVPSにdocker環境を構築して、公式イメージを立ち上げて、サンプルプログラムを動かしてみる。

[ryo@v133-18-203-78 ~]$ sudo yum install https://get.docker.com/rpm/1.7.1/centos-6/RPMS/x86_64/docker-engine-1.7.1-1.el6.x86_64.rpm
（略）
Resolving Dependencies
--> Running transaction check
---> Package docker-engine.x86_64 0:1.7.1-1.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

ryogrid

# coding: utf-8

# to execute this code, you must install 'numpy' and 'wave' pip packages
# translate GLSL to python code: https://www.shadertoy.com/view/4l3GD2
# explanation of above shadertoy page: https://qiita.com/notargs/items/be2fa153e62e3554a773

import numpy as np
import wave
import struct
import math

ryogrid

import time
import pysnmp.hlapi
import ambient
import traceback
import sys

SNMP_COMMUNITY = "xxxxxxxxx"
IP = "115.179.143.xxx"
PORT = 161
IF_IN_OCTETS_OID_PREFIX = "1.3.6.1.2.1.2.2.x.xx."

ryogrid

ryogrid

#!/usr/bin/python
import numpy as np
import scipy.sparse
import xgboost as xgb
import pickle
import talib as ta
from datetime import datetime as dt
import pytz

INPUT_LEN = 3