問題タブ [packets]

私はC＃のオンラインゲーム用の単純なプロキシ（より多くのパケットロガー）を書いています。すべてのパケットはプロキシによって受信されますが、一部はクライアントに送信されません（サーバーについてはわかりません）。例えば：

クライアント->サーバー：ログインパケット-私のプロキシはパケットを受信し、表示してサーバーに送信します。

サーバー->クライアント：接続済み！パケット-プロキシは再びパケットを受信し、それを表示してクライアントに送信します。

サーバー->クライアント：チャットチャネルパケット-プロキシが再びパケットを受信します。パケットも表示されますが、クライアントはパケットを受信しません。例外はありません。

私のコード： http： //lesderid.pastebin.com/Km7vT2jF

（これはここと同じプロジェクトです：なぜリスニングソケットに送信できないのですか？）

私は現在、高性能の Raw ソケット アプリケーションに取り組んでいます。

ReceiveFromAsync を使用してパケットを受信して​​います。これはばかげた質問のように聞こえるかもしれませんが、これは暗黙的にスレッド化されているのでしょうか? 現在のパケットを処理している間に追加のパケットをブロックしないようにするために、受信したパケットを取得して処理をスレッド化する必要があるかどうかはわかりません。ドキュメントは実際にはそれについて言及していません。3.5 ソケットのサンプル コードではスレッド化されていないため、暗黙的に処理されると最初に推測しました。

ありがとう

私はデバイスを持っています。それぞれがランダムな時間に特定のポートを介して（サーバーのIPアドレス）にデータを送信します。これは警報装置であり、複数の装置が同時に発火する可能性があるためです。データはXML形式です。

今、私はすでにデータをリッスンする小さなWindowsアプリケーションを手に入れましたが、いくつかの問題がありました

1. 問題は、アプリケーションがパケットをスニッフィングしていることです。TCPパケットでデータを取得できることを意味します....つまり、XMLをパケットに分割し、順番に（時間順に）取得しないことを意味します...これにより、XMLデータの読み取りが非常に困難になりますまたは整理して読んでください。デバイスからのデータを読み取り、XML形式で保存する必要があります。1つのデバイスを聴いている場合でも、パケットが順番に届かない

それを行う方法についてのアイデア。私はここで他のいくつかの質問を見ました、そして私はこのすべての答えを試しましたが、XMLファイルを読むことについては何も話していませんでした。この記事と同じコードを使用しています

http://www.codeproject.com/KB/IP/CSNetworkSniffer.aspx

完全なパケットを（フレームとともに）構築し、ネットワーク経由で送信するためのCの組み込みライブラリ関数について知りたいです...上記のことを行うCコードをアップロードできますか... :)

Winsock for C++ に代わる実行可能な代替手段はありますか? 私が必要とする理由は、Winsock の raw ソケットが適切に動作していないため (いいえ、これは修正できません。時間を無駄にしないでください)、WinPCAP はネットワーク トラフィックを監視することしかできず、実際にパケットを受信することはできません。IP、UDP、TCP ヘッダーなどを含む完全なパケットを受信できるものが必要です。そのようなものは存在しますか?存在しない場合は、なぜですか?

このシーケンシャル データを C で生成したい:

次

次は次の 8 文字の 16 進文字で、100 バイトなどです。どうすればいいですか？文字配列を使用してそれを行うことはできますか?

TeamSpeak3SDKを使用してVoIPアプリケーションを構築しています。サーバー/クライアントアプリケーションに出入りするUDPパケットを表示する方法はありますか？

USB デバイスのコードを書いています。USB ホストがデバイスからデータを読み取るために制御読み取り転送を開始し、要求されたデータの量 (セットアップ パケットの wLength) がエンドポイント 0 の最大パケット サイズの倍数であるとします。次に、ホストがすべてのデータを (最大サイズのデータ​​ パケットを含むいくつかの IN トランザクションの形式で) 受信した後、別の IN トランザクションを開始して、それ以上データがない場合でも、さらにデータがあるかどうかを確認しますか?

私が疑問に思っている一連のイベントの例を次に示します。

1. USB 列挙プロセス: エンドポイント 0 の最大パケット サイズは 64 と報告されています。
2. SETUP-DATA-ACK トランザクションは、コントロール リード転送を開始します (wLength = 128)。
3. IN-DATA-ACK トランザクションは、データの最初の 64 バイトをホストに配信します。
4. IN-DATA-ACK トランザクションは、データの最後の 64 バイトをホストに配信します。
5. 長さ 0 の DATA パケットの IN-DATA-ACK ? このトランザクションは発生しますか?
6. OUT-DATA-ACK トランザクションは、転送のステータス フェーズを完了します。転送が終了しました。

私はこれを自分のコンピューター (問題がある場合は Windows Vista) でテストしましたが、答えは「いいえ」でした。デバイスから送信されたすべてのパケットがいっぱいだったとしても、ホストはデバイスからこれ以上データを受信できないことを十分に認識していました (エンドポイント 0 で許可される最大サイズ)。十分に賢くなく、別の IN トランザクションを実行しようとして、長さゼロのデータ パケットを受信することを期待するホストがあるかどうか疑問に思っています。

usb.org から USB 2.0 および USB 3.0 仕様の関連部分を読んだと思いますが、この問題が解決されていませんでした。どちらかのドキュメントの正しいセクションを教えていただければ幸いです。

ホストが wLength で要求したよりも少ないデータをデバイスが送信することを選択した場合、長さ 0 のパケットが必要になる可能性があることはわかっています。

どちらの場合も処理できるようにコードを柔軟にできることはわかっていますが、そうする必要がないことを願っています。

この質問に答えられる人に感謝します！

クライアントが一定の速度でパケットを送信しているとします。現在、サーバーが一時的にダウンした場合、2つの状況が発生する可能性があります

（TCPプロトコルを使用しています）

1）パケットはサーバーに配信されません。その結果、回線内の他のパケットはサーバーが応答するのを待つ必要があります。そして、そこから通信を行うことができます。

2）パケットは配信されず、再試行されますが、他のパッケージはこのパケットの影響を受けません。

たとえば、パケットA、B、およびCが転送されます。パケットAを送信している間、サーバーが一時的にダウンします。パケットBとCは、最初にスケジュールされた時間に送信されるか、サーバーがAを受信すると送信されます。

非常に奇妙なバグがあります。

TCP/IPを介して通信する2つのアプリケーションがあります。

アプリケーションAはサーバーであり、アプリケーションBはクライアントです。

アプリケーションAは、100ミリ秒ごとに一連のfloat値をアプリケーションBに送信します。

バグは次のとおりです。アプリケーションBによって受信されたfloat値の一部が、アプリケーションAによって送信された値と同じでない場合があります。

当初、イーサネットまたはTCP / IPドライバに問題があると思いました（ある種のデータ破損）。次に、他のWindowsマシンでコードをテストしましたが、問題は解決しませんでした。

次に、Linux（Ubuntu 10.04.1 LTS）でコードをテストしましたが、問題はまだあります!!!

値は、送信される直前と受信された直後にログに記録されます。

コードは非常に単純です。メッセージプロトコルには、次のような4バイトのヘッダーがあります。

「orientation」というメッセージを受信すると、「azimuth」の値がサーバーから送信された値と異なる場合があります。

データは常に同じであるべきではありませんか？TCP / IPは、データが破損しないように配信することを保証しませんか？数学コプロセッサーの例外がTCP/IPスタックに影響を与える可能性がありますか？最初に少数のバイト（4バイト）を受信し、次にメッセージ本文を受信するのは問題ですか？

編集：

問題は、エンディアンスワッピングルーチンにあります。次のコードは、特定のフロートのエンディアンを交換してから、再度交換してバイトを出力します。

出力は次のとおりです。

7F 8A 26 BF 7F CA 26 BF

つまり、float割り当てはおそらく値を正規化し、元の値とは異なる値を生成します。

これに関するご意見をお待ちしております。

EDIT2：

返信ありがとうございます。問題は、スワップされたfloatが、「return」ステートメントを介して返されるときに、CPUの浮動小数点スタックにプッシュされることであるように思われます。次に、呼び出し元はスタックから値をポップし、値は丸められますが、それはスワップされた浮動小数点数であるため、丸めによって値が台無しになります。