問題タブ [recvfrom]

目盛りベースの間隔で動作するバークレー C ソケットを使用して、C/C++ でリアルタイム ネットワーク システムをプログラミングしています。ティックごとに、クライアント プログラムは recvfrom() を使用してソケットからデータを読み取ります。

問題は、サーバーがデータを送信しなかった場合、クライアントはソケットで送信された最後のデータを読み取ることです。

たとえば、クライアント (疑似コード)

そしてサーバー：

その後、クライアントは「こんにちは」を印刷し続けますが、私は一度だけ印刷する必要があります。

これは、この質問recvfrom re-reading data on socketに似て いますが、答えがよくわかりません。問題をより一般的に解決しているようです。

データはネットワードカードのバッファに保存されていると思いますが、その場合、1回の読み取り後にバッファをクリアする方法はありますか? 私が考えている別の方法は、パケットに番号を付けて新しいものだけを読み取ることですが、すべてのタイプは有限であるため、よりクリーンな方法があることを願っています。

クライアントが受信したデータを一度だけ読み取るようにするにはどうすればよいですか?

速度が絶対的に重要なアプリに取り組んでいます。専用のwifi（パブリックインターネットなし、同じ部屋のwifi）を介したUDP接続を使用します。

一般に、Wi-Fi 接続は 512 バイトのパッケージを 1 ミリ秒以内に配信できる必要があります。何らかの理由で、私たちの場合、recvfrom はパッケージを取得するまでに 2.5 ～ 4.5 ミリ秒かかります。

接続設定を可能な限り最適化するために、すべての調査と調査を行いました。（受入基準等）

誰かが同様の問題を経験したり、これに対処する方法を知っていますか? スマートフォンとして、ネットワークレベルで多くのことが起こっていることを認識していますが、この場合、機内モードを試しても同じ問題が発生しました.

私は RAW ソケットに切り替えたいと思っていますが、Apple はそれを許可していないので、それを回避する必要があります。

どんなアイデアにも感謝します！

ベスト、ラルフ

私はPythonでソケットプログラミングに取り組んでいます。ESP pythonを使用して、サーバーへのソケットを作成し、リクエストを送信しました（APIパケット形式で、サーバーコードに従って応答します）。ソケットを受信する際に、データを確認する必要があります(データを受信した場合は、次の操作に進む必要があります。そうでない場合は、もう一度リクエストを送信する必要があります)。送信は大丈夫です。受信ソケットで、データを受信して​​いない場合、次の命令に進まない..助けてください。

コード：

データの送信:

受信時:

上記の受信ステートメントで、データが取得されない場合、次の操作recvfrom()を確認して戻す方法.または解決策である場合、これらの使用方法..recvpacksocket.settimeout()socket.setblocking()

初めて UDP をコーディングする準備として、ここからコピーして軽く変更したクライアントとサーバーのコードの例をいくつか試しています。recvfrom() によって返される値が、読み取ったバイト数ではなく常にバッファーのサイズであることを除いて、すべてが機能しているようです (バッファーサイズを変更して再コンパイルすると、報告された受信バイトは新しいバッファーサイズに一致するように変更されますが、送信されるバイトは、すべてのテストで同じ 10 バイトです)。

このコードに問題を説明するエラーが見られる人はいますか (簡潔にするために、ここでは一部のエラー チェックを削除しています)。参考までに、Yosemite 10.10.5 を実行している Macbook Pro のターミナル ウィンドウで bash をコンパイルして実行しています。

Windows の recvfrom 関数に問題があり、解決できません。
私が書いたコードの次の部分を参照してください。Linux と Windows でこのコードを実行すると、udp ビットレート値で異なる結果が得られます。

Cygwin を使用して Windows でコンパイルすると、Ubuntu と同じ結果が得られます。これを参考ツールと比較しました。

MinGW を使用して Windows でコンパイルすると、更新ビットレート値が小さくなります。これは、1 秒間の while(1) ループの反復回数が少ない (カウンター変数) ことと、関連するもの - 1 秒間にキャプチャされるデータの量が少ない (data_in_1_sec) ことが原因です。変数）。MinGW を使用した Windows での recvfrom 関数は、最も遅く、udp データをスキップするようです。
ビットレートが約 0.200 Mbps の場合、MinGW を使用した場合、両方の OS で同じ結果になることに注意してください。問題は、UDP ビットレートが約 20 Mbps のデータで見られます。

残念ながら、このコードはスタティック ライブラリとして Python コードに読み込まれるため、MinGW を使用する必要があります。CygWin dll を使用すると、Python でこの関数を実行しているときにアクセス違反が発生します。

これに対処する方法は？

Windows 7 Professional 64 を使用しています。

私が使用するコード：

Windowsの場合、このコードの結果:

同じデータのUbuntuの出力

次の動作を実装する必要があります。サーバーの起動時に、ブロードキャストを使用して既存のサーバーをチェックする必要があります。その後、回答を待ちます。

しかし、待機のタイムアウトを設定する方法は?

REUSEADDR/REUSEPORT を使用すると、マシン内の同じアドレスとポートにバインドされた 2 つの同一のソケットを作成できます。2 つのソケットで同じデータを受信することは可能ですか?

私の場合は、定義された udp ポート番号がネットワーク上でデータを生成するということです。私のマシンでは、2 つのスレッドにプロトコルの 2 つの実装があり、そのデータをソケット API から直接消費できるようにしたいと考えています。

ありがとう

よろしくトーマス

私は自分自身の他のコピーにパケットを送信するプログラムをいじっていましたが、recvfrom は完全には理解できない方法で動作していました。プログラムの各インスタンスは、異なるポートに設定されます (他のインスタンスのポート番号は dictMap ディクショナリに既に格納されています)。このプログラムのいくつかのインスタンス (たとえば 8 つ) を起動した後、すべてのインスタンスが 1 秒間に 3 回 (MINI_UPDATE_INTERVAL) 互いに ping を実行する必要があるという考えです。

ただし、インスタンス全体の実行中にインスタンスの 1 つを閉じると、プログラムはすべて「醜い切断が検出されたなど」と出力し続けます。切断されたインスタンスが 1 回しか切断されていない場合でも、複数回。この背後にある理由は何ですか? 私のコードの一部は以下のとおりです。

編集: この問題は、Windows でのみ発生するようです (WSAECONNRESET は、切断後に常にポップアップし続けます)。私のコードは最終的には Linux を対象としているので、大したことではないと思います。

たとえば、大きな違いや良い/悪い習慣があるかどうかを知りたい

このようにする：

そしてこのように：

これは、ソケットを使用してアプリケーション間の一時的なプロセス間通信を作成するためのテストです。これらのアプリケーションは、後でカスタマイズされた組み込み通信システムを使用して別のシステムで実行されますが、現時点では後者は利用できません。その結果、これらのアプリケーション間のプロセス間通信を実装するための迅速な (おそらく少し汚れた) C++ の方法を探しています。アプリケーションはいくつかの文字列を送信します (あまり凝ったものではありません)。

オープンサウンドコントロール用のメッセージパッシングを実装するために利用するoscpackに出くわしました。udpを使用して共有オブジェクトとしてgcc4.7.1を使用してLinuxでコンパイルしましたmake lib。-fPICのCOPTS変数にオプションを追加する必要があることに注意してくださいMakefile。

共有ライブラリを用意して、小さな概念実証アプリケーションを作成しました。このアプリケーションは、メッセージのリスニングに別のスレッドを使用し、メイン スレッドで何らかの文字列を待機しstdinて、それを他のアプリケーションに転送します。このアプリケーションの 2 つの非常によく似たインスタンスを実行します。2番目のインスタンスで、PORT_RCVとのPORT_SND数字を交換しただけです。

実際の問題はここから始まります：

私が直面している問題は、受信側でosc::UdpSocket::ReceiveFrom()(最終的に recvfrom() を実行する) への呼び出しがブロック解除されると、ゼロ (0) に等しい読み取りバイトの戻り値を取得することです。また、char * dataポインターはまだゼロを指しています。そのため、recvfrom() が適切なタイミングでブロック解除されたにもかかわらず、本質的に送信側アプリケーションから文字列を受信して​​いません。

マニュアルページから、送信者が接続を閉じたときに recv と recvfrom が値 0 を返す可能性があることを読みました。しかし、この場合の送信者は udp を使用しています。

netcat対応するポートでudpメッセージをリッスンし、少なくとも送信側が機能することを確認するために使用しようとしました。確かにnetcat -u -l -p <sender port of the running instance>、私は入力したメッセージを受け取ります。したがって、問題はおそらく受信側に関連している可能性があります。

問題は、recvfrom を正しく使用していますか?

プロセス間通信テスト アプリケーション (実際には全二重メッセンジャー) にコードが添付されていることを確認してください。そのうちの 2 つを実行するには、まずライブラリをダウンロードしてライブラリとしてコンパイルしoscpackます。PORT_RCV次に、以下のソースを 2 つのファイルにコピーし、2 つ目のソース ファイルのとPORT_SND番号を入れ替えます。

次に、それぞれを次のようにコンパイルします。

次に、それらを実行して単語を入力し、Enter キーを押して、それが他のアプリケーションに表示されることを期待します (表示されません)。