2018年10月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

カテゴリー

ブログパーツ

無料ブログはココログ

« シェーキーの体内ネットワークを考える(その2) | トップページ | ドライブサーバをテストする »

2010年2月15日 (月)

シェーキーの体内ネットワークを考える(その3)

ロボット作ろう:シェーキー製作記

今回はネットワークの通信制御を考えます。

体内ネットワークの通信路は1本なので、すべてのネットワーク機器はこれをシェアして通信することになります。他の機器が使っているときには自分のメッセージは流せません。そのため、常に通信路をモニターして、使用状態をチェックしている必要があります。使用中のときは、そのメッセージの送信が終わるまで待たなければなりません。

さらに、通信路が空いたからといって、すぐさまメッセージを送信するのは考え物です。他の機器も送信を待っているかもしれないからです。どの機器が優先的に待機中のメッセージを送るかのルールも必要です。

ここではとても簡単なルールを設定することにします。それはこれ↓です。

■メッセージを送信する前に通信路の状態をチェック、使用中なら送信を待機する

■待機中のメッセージは、通信路が空いた後、IDms経過してから送信する

機器はすべて異なったIDを持っているので、待機メッセージの送信タイミングが同じになることはありません。ID2とID3の機器が待機メッセージを待っているとき、通信路が空くとID2が1ms早く送信を開始します。ID3の機器はそのメッセージの終了を待って(さらに3ms待ってから)自分の待機メッセージを送信します。

これでOK!のように見えますが、実は本質的な問題をひとつ抱えています。それは、ほとんど同じタイミングで複数の機器が送信を開始する場合です。このネットワークシステムは非同期なので必ず発生します。発生確率はシステムのデザインしだいで高くも低くもなります。

コレが起こると、信号の論理和が取られるので、メッセージは完全に化けてしまいます。自分が送信したメッセージを受信し、元のメッセージと比較することで、競合が起こったことを判断できるので、再送信することが可能です。そのため次のルールを追加します。

■送信時、モニターしたメッセージがオリジナルと異なる場合、そのメッセージを再送信する

実際やってみるといろいろありそうですが、机上ではなんとかこれでいけそうですね。

« シェーキーの体内ネットワークを考える(その2) | トップページ | ドライブサーバをテストする »

ロボット作ろう」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1140145/33394437

この記事へのトラックバック一覧です: シェーキーの体内ネットワークを考える(その3):

« シェーキーの体内ネットワークを考える(その2) | トップページ | ドライブサーバをテストする »