0

Firefox拡張機能を介してピアツーピア（UDP）通信を確立しようとしています。コマンドラインで動作するPythonプログラムがあります。私はそれを使用してxpcomコンポーネントを構築しました。しかし、驚くべきことに、コマンドラインのpythonプログラムからしかメッセージを受信できませんでした。

私たちは次のことを試みました（すべてlocalhostで動作しています）：

送信者としてのFirefoxXPCOMコンポーネント->受信者としてのFirefoxXPCOMコンポーネント -が機能しませんでした

送信者としてのPythonコマンドライン-> 受信者としてのfirefoxxpcomコンポーネント -動作

送信者としてのFirefoxxpcomコンポーネント -> 受信者としてのPythonコマンドライン -が機能しませんでした

送信者としてのPythonコマンドライン->受信者としてのPythonコマンドライン -動作

Wiresharkを使用してパケットを観察したところ、いくつかの違いがありました-

Firefoxxpcomからpythonコマンドラインおよびfirefoxxpcomからfirefoxxpcom（これは機能しませんでした）には、次のようなパケットレコードがあります

によって生成されたそのようなタイプのパケット（非番号としてマークされた送信元ポート）

Winsock（C ++）

XPCOMコンポーネント

C＃

...UDP  Source port: timbuktu-srv2  Destination port: 30000

pythonコマンドラインからpythonコマンドラインおよびPythonコマンドラインからXPCOM（これは機能しました）には、次のようなパケットレコードがあります

... UDP Source port: 30000  Destination port: 30000

ネットワークについてはよくわかりませんが、マークされたレコードが..Source port: timbuktu-srv2..宛先に到達できません。

私はPython、C ++（Winsock）、C＃を使用してp2p通信を試してきましたが、Pythonでしか成功できませんでした。違いは、Pythonでのそのようなタイプの特定のレコードです。

一部のネットワーキングの達人はその上に懐中電灯を当てることができますか？

4

1 に答える 1

0

表示されているのtimbuktu-srv2は、Wiresharkが既知のサービスのリストに対して実際のポート番号を検索した結果です。IANAが割り当てたポート番号のリストを確認すると、次のエントリが表示されます。

timbuktu-srv2   1418/udp   Timbuktu Service 2 Port

...つまり、アプリケーションが送信したUDPパケットの送信元ポートとして1418を使用したことを意味します。ローカルサービスデータベースにそのポート番号のエントリがないため、30000はテキストサービス名に変換されません。

これだけでは問題を説明できません。実際、サーバー側は、必要なソースポートを使用してクライアントを受け入れる必要があります。ただし、この場合、受信者側は送信元ポートが30000のパケットのみを受け入れている可能性があります。これを実現するには、INADDR_ANYパケットを送信する前に、ソケットをローカルアドレスとポート30000にバインドする必要があります。

于 2009-09-28T00:40:45.887 に答える