docker を使用して、完全な例を実行してみましょう。3 つのターミナルを立ち上げ、docker をインストールする必要がありますが、これはすべて 1 つのホストで実行できます。3 つの端末を「ドメイン」、「サンドボックス」、「ホスト システム」と呼びます。
ドメイン ターミナルで、新しい redhawk 2.0.2 インスタンスを起動します。
docker run -it --name=domain axios/redhawk:2.0.2 bash -l
サンドボックス ターミナルで、別の redhawk 2.0.2 インスタンスを起動します。
docker run -it --name=sandbox axios/redhawk:2.0.2 bash -l
docker に慣れていない場合、これら 2 つの docker インスタンスには固有のファイル システム、メモリ、およびネットワークがあります。を実行してifconfig、それぞれの IP アドレスを確認し、書き留めます。それらは同じサブネット上にあり、互いに ping できることに注意してください。
互いに到達できない 2 つの新しいネットワークを作成することで、10GigE ポートをエミュレートできるようになりました。ホスト ターミナルで docker を使用して 2 つの別個の偽のネットワークを作成し、それらをコンテナー インスタンスに割り当てます。
docker network create -o "com.docker.network.bridge.host_binding_ipv4"="1.1.1.1" bad_net_1
docker network create -o "com.docker.network.bridge.host_binding_ipv4"="2.2.2.2" bad_net_2
docker network connect bad_net_1 domain
docker network connect bad_net_2 sandbox
ドメインとサンドボックス ターミナルに戻って再実行ifconfigすると、ドメインとサンドボックス インスタンスの eth1 が一意のサブネット上にあり、通信できない eth0 と eth1 インターフェースがあることに注意してください。
あなたのIPアドレスは異なるかもしれませんが、私にとっては次のとおりです。
ドメイン：
eth0: 172.17.0.2
eth1: 172.19.0.2
サンドボックス:
eth0: 172.17.0.3
eth1: 172.20.0.2
ここで、ドメインを omniNames ホストになるように構成し、omniORB 接続タイムアウトを設定して、corba 呼び出しでハングしないようにし、間違った IP アドレスがアドバタイズされるようにエンドポイントを不適切に構成します。
ドメイン マシンで次の手順を実行します。
sudo tee /etc/omniORB.cfg << EOF
InitRef = NameService=corbaname::172.17.0.2:2809
supportBootstrapAgent = 1
InitRef = EventService=corbaloc::172.17.0.2:11169/omniEvents
endPoint = giop:tcp:172.19.0.2:
serverCallTimeOutPeriod = 5000
clientConnectTimeOutPeriod = 5000
clientCallTimeOutPeriod = 5000
EOF
サンドボックス マシンで:
sudo tee /etc/omniORB.cfg << EOF
InitRef = NameService=corbaname::172.17.0.2:2809
supportBootstrapAgent = 1
InitRef = EventService=corbaloc::172.17.0.2:11169/omniEvents
endPoint = giop:tcp:172.20.0.2:
serverCallTimeOutPeriod = 5000
clientConnectTimeOutPeriod = 5000
clientCallTimeOutPeriod = 5000
EOF
ドメイン マシンで omniNames とイベントを開始しますcleanomni。これにより、古い状態もクリアされます。
cleanomni
サンドボックス マシンで実行nameclt listして、omniORB オブジェクトを表示します。ドメインにアドバタイズされたエンドポイント アドレスが間違っているため、機能しないことに注意してください。経由で /etc/omniORB.cfg にログインするtraceLevel=40と、メッセージに間違った IP アドレスが表示されることさえあります。
omniORB: inputMessage: from giop:tcp:172.17.0.2:2809 236 bytes
omniORB:
4749 4f50 0100 0101 e000 0000 0000 0000 GIOP............
0400 0000 0000 0000 0000 0000 2a00 0000 ............*...
4944 4c3a 6f6d 672e 6f72 672f 436f 734e IDL:omg.org/CosN
616d 696e 672f 4269 6e64 696e 6749 7465 aming/BindingIte
7261 746f 723a 312e 3000 0000 0100 0000 rator:1.0.......
0000 0000 9400 0000 0101 0200 0b00 0000 ................
3137 322e 3139 2e30 2e32 0000 23ae 0000 172.19.0.2..#...
0e00 0000 ff00 bb05 0a58 0100 003c 0000 .........X...<..
0002 0000 0400 0000 0000 0000 0800 0000 ................
0100 0000 0054 5441 0100 0000 1c00 0000 .....TTA........
0100 0000 0100 0100 0100 0000 0100 0105 ................
0901 0100 0100 0000 0901 0100 0300 0000 ................
1600 0000 0100 0000 0b00 0000 3137 322e ............172.
3137 2e30 2e32 0000 f90a 0000 0354 5441 17.0.2.......TTA
0800 0000 bb05 0a58 0100 003c .......X...<
ドメイン ターミナルで、vim または emacs を使用して /etc/omniORB.cfg のエンドポイントを修正し、実行cleanomniして古い参照をすべて消去し、オムニ サービスを再起動します。サンドボックス ターミナルから適切に実行できるようになりましたnameclt list。
ドメイン ターミナルで を使用してドメインを起動しnodeBooter -D、サンドボックス ターミナルから python 経由でドメインに接続し、期待どおりに操作できることを確認します。
>>> from ossie.utils import redhawk
>>> dom = redhawk.attach('REDHAWK_DEV')
>>> dom.name
'REDHAWK_DEV'
>>> fs = dom.fileManager
>>> fs.list('.')
これまでのところ、サンドボックスからドメインへの呼び出しのみを行っているため、ドメイン マシンのアドバタイズされたエンドポイントのみが重要であることに注意してください。「start」や「stop」などの呼び出しは、ユーザーからコンポーネントに向けて行われますが、pushPacket などの呼び出しは、コンポーネントからユーザーに向けて行われます。これは、ドメイン マシンの SigGen をサンドボックス マシンの HardLimit に接続することで確認できます。現在、ドメイン マシンは適切に構成されていますが、サンドボックス マシンは正しく構成されていません。
ドメイン マシンでドメインを停止し、次のコマンドを実行して波形をインストールし、GPP でドメインを起動します。
sudo yum install -y rh.basic_components_demo
nodeBooter -D -d /var/redhawk/sdr/dev/nodes/DevMgr_12ef887a9000/DeviceManager.dcd.xml
Python のサンドボックス マシンに戻ります。
from ossie.utils import redhawk, sb
import time
dom = redhawk.attach('REDHAWK_DEV')
app = dom.createApplication('/waveforms/rh/basic_components_demo/basic_components_demo.sad.xml')
siggen = app.comps[0]
siggen.start()
hardlimit = sb.launch('rh.HardLimit')
sink = sb.DataSink()
hardlimit.connect(sink)
siggen.connect(hardlimit)
sb.start()
time.sleep(1)
sink.getData()
サンドボックス マシンによって間違ったエンドポイントがアドバタイズされるため、シンクでデータを取得することはできません。Python を終了し、Sandbox インスタンスの endPoint を修正して、この実験を再実行します。今回は、両方のエンドポイントが適切に構成されているため、データを取得します。
最後に、endPoint をまったく設定しないとどうなりますか? (私が想像しているように) omniORBサンプル構成ファイルから:
デフォルトでは、endPoint 構成は定義されていません。この場合、ORB は、構成ファイルで endPoint = giop:tcp:: という行が指定されているかのように、tcp エンドポイントを 1 つだけ作成します。
と
host および port パラメータはオプションです。いずれかまたは両方が欠落している場合、ORB は空白を埋めます。たとえば、"giop:tcp::" を指定すると、ORB は任意の tcp ポートをエンドポイントとして選択し、ホストの 1 つの IP アドレスをホスト アドレスとして選択します。
そのため、非常に奇妙な動作が発生する可能性があります。願わくば、この例が役に立ち、誰もが簡単に実行/再現できるようになったことを願っています。
完了したので、docker インスタンスと docker ネットワークを次のようにクリーンアップできます。
docker rm -f domain sandbox
docker network rm bad_net_1 bad_net_2