サーバーと多くのクライアントを同時に含む単純なアプリケーションを作成しています。DataGramSocketを使用する必要があります。アプリケーションは、チャットのようにコンソールを介してメッセージを交換するだけです。しかし、in.readLine（）とds.receive（）の両方の操作がブロックされており、それらを別々のスレッドに配置しても、i/oをブロックするとスレッドもブロックされるため役に立ちませんでした。どんな体でも、nioなしでそれを行う方法を教えてもらえますか

私のアプリは、スレーブが（ローカル）イベントに基づいてマスターにメッセージを送信できるマスター/スレーブシステムであり、マスターはローカルイベントにも基づいてスレーブにメッセージを送信します。

どちらの場合も、着信メッセージに基づいて発信メッセージを送信できます。場合によっては、これらの応答が人間の対話の後にのみ送信されることがあります。すぐには送信されません (その間に接続が失われる可能性があります)。

マスターとスレーブの両方が、TCP を使用してインターネット経由で通信します。

これはデュプレックスの良いシナリオですか? それとも、単純に「ファイア アンド フォーゲット」(データグラム) メッセージを送信し、ビジネス ロジック (ビューモデル) レイヤー内でメッセージの進行/状態/ワークフローを処理する必要がありますか?

ありがとう！

PS。また、それぞれがいつ/なぜ適切であるかについての議論も役立ちます。

Objective:

To pass data from incoming UDP datagrams to 4 threads waiting on their respective queues. The application is supposed to work non-stop for pumping traffic to a DUT and process the incoming messages. This is what I am doing:

Problem:

The memory is continuously increasing. I suspect this is because it is waiting for GC to claim the unused memory. I wish I can allocate some static memory outside the infinite while loop. The problem I face if I do this is that the “receivePacket.getData()” returns a byte array and to work on the data, I need to convert it into a string. All the data is in text format (to be specific it is MGCP packets). Please suggest any way to make sure that the memory is not exhausted. I don’t want to manually call the garbage collector. I am not sure of the overhead for GC.

Thanks

私は現在、一種のVoIPクライアントであるプログラムを書いています。2つのクライアント間の接続を確立し、マイクから録音されたデータを送受信しようとしています。

私は現在ファイルを使用していますが、それはひどい実装のように見えます：

レコーダは一時ファイルへの記録を開始します。タイマーが作動し、レコーダーを停止し、ファイルサイズを確認してから、DatagramPacketを使用してコンテンツを送信します。

ひどく悪いようです。MediaRecorderクラスとMediaPlayerクラスには、それぞれファイルの出力と入力（つまり、DatagramSocket）としてUPDソケットを使用する方法があるのでしょうか。

ソケットからファイル記述子を使用できますが、ソケットはTCPを使用します。UDPを使用したかったので、DatagramSocketを推測しますが、MediaRecorderおよびMediaPlayerクラスでUDPを使用する方法が見つからないようです。

誰かがこれに対する良い解決策を持っていますか？

どうもありがとうございます

Java データグラムを使用して、サーバーとクライアント間のパケット ストリームを作成しようとしています。問題は、パケットが送信されているという確認を受け取りますが、設定したクライアント リスナーに到達する前にすべてが失われることです。私は今それを持っているので、実行するたびに5秒後にタイムアウトが発生します。

2 番目のクラスをスキップすることもできます。それらはほとんど同じで、server.send を client.receive に置き換えるだけです。また、このクラスは実際に重要なことを行うようには設計されていません。そのため、多くのコード (例外処理など) は非常に単純化して記述されています。

パケットの損失を防ぐためにできることはありますか? 私は自分のコンピューターでポートを転送しています（問題ではありません。あなたが疑問に思っている場合は、App.Localであるローカルホストを使用しています）。

あと、横質問。私はもともと、パケットを送信し、向きを変えてパケットを受信するようにコード化された単一のクラスとしてセットアップしていました。しかし、「ICMP ポートに到達できない」ため、例外がスローされました。なぜこれが起こるのか誰か知っていますか？

ストリームデスクトップをキャプチャして、Javaのデータグラムを介して（クライアントに）送信したいと思います。次の例でスクリーンショットを作成します。

Robotクラスも使用する必要がありますか？、ストリームを送信するにはどうすればよいですか？

手伝ってくれてありがとう。

よろしく！

ロギング DatagramHandler の Python ドキュメントに示されているサンプル コードを取得する際に問題が発生しています。以下に示すコードでは、受信したすべてのデータグラムで EOFError 例外が発生します。

ただし、このコードは機能しますが、アイデアはありません

よろしく

それらのパケットは単に消えていますか？それとも彼らは目的地を待ちますか？または、パケットが戻ってから例外がスローされますか?

また、Java では、DatagramPacket コンストラクターで、byte[] バッファーと長さの違いは何ですか?

ソケット (ストリーム) とソケット (データグラム) の違いは何ですか? なぜ一方を他方に使用するのですか？

現在、130688バイトのハード制限に達しています。1つのメッセージでもっと大きなものを送信しようとすると、ENOBUFSエラーが発生します。

、、、、、およびsysctlオプションを確認し、net.core.rmem_defaultそれらをすべて増やしましたが、これらはメッセージサイズではなく合計バッファーサイズを処理するため、効果はありません。net.core.wmem_defaultnet.core.rmem_maxnet.core.wmem_maxnet.unix.max_dgram_qlen

SO_SNDBUFおよびソケットオプションも設定しましたSO_RCVBUFが、これには上記と同じ問題があります。デフォルトのソケットバッファサイズは、とにかくデフォルトのソケットオプションに基づいて設定されます。

ソケットスタックで返されるカーネルソースを調べましたが、ENOBUFSどこから来たのかわかりませんでした。このエラーを返すように見える唯一の場所は、メモリを割り当てることができないことと関係があります。

最大サイズは実際には130688ですか？そうでない場合は、カーネルを再コンパイルせずにこれを変更できますか？