1 / 36

Object Migration in an Ad-hoc Network Topology

Object Migration in an Ad-hoc Network Topology. B4 弘中 健. 現在の課題. Mobile object の実装例は数多くある Emerald, Amber, Thor, d-smalltalk, JavaParty, dJay… しかしすべて「静的」なネットワークを想定している ノードの増減がない All-to-All connection 可. 問題設定. Programmer から透過に見える migration 既存の Program を大幅に変更せずに済む Node 数は動的に変化しても良い

woody
Download Presentation

Object Migration in an Ad-hoc Network Topology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object Migration in an Ad-hoc Network Topology B4 弘中 健

  2. 現在の課題 • Mobile objectの実装例は数多くある • Emerald, Amber, Thor, d-smalltalk, JavaParty, dJay… • しかしすべて「静的」なネットワークを想定している • ノードの増減がない • All-to-All connection可

  3. 問題設定 • Programmerから透過に見えるmigration • 既存のProgramを大幅に変更せずに済む • Node数は動的に変化しても良い • ただし、脱退は勿論ややこしいが • コネクションはall2allを想定しない • 必要なら中間nodeがroutingをする • つまり、ad-hoc networkでのmobile objectを想定している • 「許される範囲内」でのmessage数で

  4. Mobile Object実現には • リモートオブジェクトのref.を取得する方法が必要 • Reference acquisition mechanism • そのrefから、位置が定かでなくても一意にremote objectをアクセス出来るシステムが必要 • Object location mechanism • Ad-hoc環境で、msgを効率にforwarding出来るメカニズムが必要 • Ad hoc network routing argorithm

  5. Related Work • 単純にmigration srcがreference forwardingをする • Forwarding chainが長くなる • Forwarding nodeは脱退出来ない • 全てのobjの居場所を管理するcentral server • Single-point of failure • 負荷が集中する(scaleしないと思われる) • 勿論central serverは脱退出来ない

  6. Object Location • Reference Acquisition • Ad-hoc Network Routing

  7. Object Locationの提案手法 • どのように動くオブジェクトをアクセスするか？

  8. Object Locationの提案手法 • 動く回るobjectを一意に決めるには、location-independent nameが必要 • 動いても変わらない • ここでは、Unique IDは以下のタプル • Obj creation元のprocess id • IP address, Port # • Obj creation元のunique local id

  9. Object Locationの提案手法 • オブジェクトをレファレンスする時には • <UID, dst, seq. #> • Dst:今有ると思われるnodeの住所 • ディフォルトではUIDの先頭にある場所 • Seq #:情報の「新しさ」を意味する • 数が大きいほど新しい • Objectがmigrateするたびにincrementされる

  10. Migration(1) • src -> dstへのmigration • srcがdstにobjectのコピーを送る • dstが受け取り、ACKをする

  11. Migration(2) • Migrationをatomicに行う • 各remote objectにFLAGをつける • PRESENT • ARRIVING • LEAVING • PRESENT以外の時のアクセスはブロックする

  12. Migrationの様子 OBJ. EFFECTIVENESS PRESENT → LEAVING SEND OBJ. CREATE OBJ. ENTITY ARRIVING ACK BROADCAST CHANGE ARRIVING → PRESENT OBJ. EFFECTIVENESS BROADCAST CHANGE DELETE OBJ. ENTITY

  13. BROADCAST CHANGE • Objectがmigrateすると、srcとdstで変化をbroadcastをする • この際、seq.#は+1する • <UID, new location, seq#> • ただし、全体へのbroadcastではない • MessageにTTLを付けて、neighborhoodのnodeにのみ通知する • TTLはsrc-dst間のhops数に比例させる

  14. TTLの意味 • Distance effect • 動きは、近くにあるノードほど大きく感じる • Speed • 速度が大きいほど変化を強く感じる • 変化を感じない場所に通知する必要はない

  15. Object Location • すべてのreferenceは最新情報を持っているわけじゃない • Routingでカバーする • 各nodeはremote object routing tableを持つ • Broadcastで通知された情報 • Localにあるオブジェクトの情報 • 過去のアクセスで得た情報

  16. Object Location • Accessにはまず、refに書いてあるdstへのnexthopを行く • <UID,dst,seq#> • 受け取りNodeではrouting tableのUIDエントリと比較する

  17. Object Location • Referenceとtableのconflictが起きると • Sequence #の大きいほうを優先する • reference又はrouting tableを書き換える • Referenceに書いてあるdstのnexthopへ飛ぶ • dstが自分のノードだと勿論そこで処理が行われる

  18. Node B Node C Node A Node D

  19. Node B Node C Node A B(1) B(1) B(1) B(1) B(1) B(1) B(1) B(1) B(1) B(1) B(1) Migration:A→B HOPS=2 BROADCAST TTL=2 Node D

  20. Node B Node C Node A C(2) C(2) C(2) B(1) C(2) B(1) C(2) B(1) B(1) B(1) B(1) Migration:B→C HOPS=1 BROADCAST TTL=1 Node D

  21. Node B Node C Node A C(2) C(2) C(2) B(1) C(2) B(1) C(2) B(1) B(1) B(1) B(1) Node D: Access to Object A(0) A(0) Node D

  22. Node B Node C Node A C(2) C(2) C(2) B(1) C(2) B(1) C(2) B(1) B(1) B(1) A(0) B(1) B(1) A(0) Node D

  23. Node B Node C Node A C(2) C(2) C(2) B(1) C(2) B(1) C(2) B(1) B(1) B(1) B(1) B(1) B(1) A(0) Node D

  24. Node B Node C Node A C(2) C(2) C(2) B(1) B(1) C(2) C(2) B(1) C(2) B(1) B(1) B(1) B(1) B(1) A(0) Node D

  25. Node B C(2) Node C Node A C(2) C(2) C(2) B(1) C(2) B(1) C(2) B(1) B(1) B(1) B(1) B(1) A(0) Node D

  26. Object Location • Reference Acquisition • Ad-hoc Network Routing

  27. Reference Acquisition • Pass-by-argument • ObjectがRMIされた時に、引数として渡される • Public Name List • Remote objectを「公開」する時、ある名前で登録する • この名前を指定すればそのobjectにreferenceが作られる • 分散的にリストを管理する

  28. Public Name List • 各プロセスは手元にPublic Name Listを持つ • ある名前を検索し、なかった場合は要求をBroadcastする • Broadcastして返事がないと、エラーになる

  29. なぜbroadcastでいいか？ • 名前は一回登録されたら変更されない • 常に同じobject UIDに対応する • レファレンス生成時にのみ行われる • 一回こっきり • 一回broadcastが起きると、全てのノードがその知識を共有する • つまり、一つの名前に付き一回broadcastが起きるだけ

  30. Object Location • Reference Acquisition • Ad-hoc Network Routing

  31. Ad-hoc Routing • Object locationで、あて先から”nexthop”を割り出すという作業 • つまり、object locationを下で支える手法

  32. 基本的な手法 • Proactive • 常に最新のrouting tableを • トポロジーに変化があった場合に、積極的にupdate msgを交換する • eg:DSDVなど • Reactive • 必要になったらrouting tableを更新する • アクセス時に正しい場所を皆で調べる • eg:simple broadcast, AODV, TORAなど • Hybrid • 各ノードを中心とした“zone”を定義する(数ホップ内のエリア) • このzone内ではproactiveに、その外ではreactiveに

  33. それぞれの問題点 • Proactive • Msg数がO(N*N)で増加する • Reactive • アクセスが遅くなる • Hybrid • “zone”の範囲はどうする？ • 動的に伸縮する手法もあるが、そのheuristicsもかなり怪しい

  34. 中間発表後の方針 • Routingはまだ未決定 • 取りあえずは、proactive/reactiveな手法で実装して見る • ベターなroutingアルゴリズムを考える • Mobile ad-hoc networkよりは制約は緩いはず • この制約の緩さを旨く使ったアルゴリズムを考えていきたいです

  35. 求めているもの • 基本的には、nodeに繋げる時は直接繋ぎに行く • 繋げないという万が一の時のためにroutingが必要 • そのためにO(N*N)のアルゴリズムを使うのは勿体ない • ノードの増減を許す

  36. 最後に • コメント・アドバイス大歓迎です • 実装処理系の名前も募集中です • Mudpy(ダメ、使われている) • Muddy? • Dsoapyはありきたりすぎかもしれません。。。

More Related