Beaglebone Black でMOOS-IvPを実行しようとしています
MOOS データベースを実行しようとすると、継続的に例外がスローされます
「リッスン ループで例外がスローされました: ソケットのリッスン中にエラーが発生しました。操作はサポートされていません」
このソフトウェアは Raspberry Pi で動作します
問題の可能性があるアイデアはありますか?
Beaglebone Black でMOOS-IvPを実行しようとしています
MOOS データベースを実行しようとすると、継続的に例外がスローされます
「リッスン ループで例外がスローされました: ソケットのリッスン中にエラーが発生しました。操作はサポートされていません」
このソフトウェアは Raspberry Pi で動作します
問題の可能性があるアイデアはありますか?
Ubuntu 14.04 を実行している BeagleBone Black で作業しているときにも、このエラーが発生しました。ただし、リクエストを 2 回実行するという解決策は機能しませんでした。さらにトラブルシューティングを行った結果、別のプロセスが UDP ソケットを開いた後に、TCP ソケットであるはずのソケットが開かれたことがわかりました。によって返される構造体はgetprotobyname()
、呼び出しごとに変化しない静的な場所へのポインターですが、プロトコルの詳細で更新されます (別の Unix OSについてはこちらを参照してください)。したがって、別のプロセスによる 2 回目の呼び出しにより、元の詳細が上書きされます。
これは、 のコンストラクターでのソケット作成中にテストさXPCSocket
れ、TCP ソケットである必要がある場所に UDP ソケットが作成されます。_sProtocol
これはおそらく、この関数にロックを追加することで修正できますが、構造体で返されるものの代わりに、コンストラクターが () で呼び出された文字列を使用して、要求されたプロトコルを初期化するノンブロッキング アプローチを採用しましたsocketProtocol
。さらにXPCGetProtocol
、プロトコル番号をメンバ変数に格納するようにクラスを変更しました。この変数は、以降の の呼び出しでは変更されませんgetprotobyname()
。
私の変更はここにあります。
問題を見つけて修正しました。
ソケットを作成するときは、TCP である必要があります。ただし、XPCGetProtocol クラスで getprotobyname(_sName) を呼び出して /etc/protocols で正しいプロトコル番号を検索すると、前回呼び出されたときの値、つまり UDP ソケットがセットアップされたときの値が返されます。
それを修正するために、関数を 2 回呼び出しただけで、2 回目は正しい値を返しました。
初めて間違って返される理由はわかりませんが、これは機能します!