問題タブ [tcp]

accept()単純なサーバーを実行していて、クライアントからの接続を編集したとしましょう。

クライアントがいつ切断されたかを知る最善の方法は何ですか? 通常、クライアントはクローズ コマンドを送信することになっていますが、手動で切断したり、ネットワーク接続を完全に失ったりした場合はどうなるでしょうか。サーバーはこれをどのように検出または処理できますか?

私はこれに頭を悩ませようとしています。私はビジネス固有のメッセージングアプリケーションを作成しています.5000〜10,000台のマシンをWCF経由でデータセンターに接続します（vpnなし、ネット全体）。これは主にアラート用であり、特定のクライアントにメッセージを直接送信できるようにする必要があります。WCF を使用すると、デュプレックス コントラクトを使用してこれらすべてを実行できますが、これだけ多くのクライアントを使用すると、 65535 ポート。

すべてのインバウンド接続は、選択したポートを介して着信すると仮定しますが、クライアントへのアウトバウンドはそれぞれ 1 つのポートを使用します。WCF ポート共有サービスがこの問題を解決するために何かを行っているのか、それとも 65535 ポートだけが IP アドレスに接続されているのか知りたいです。さらに言えば、MSN Messenger などはこの状況にどのように対処しているのでしょうか。確かに私はそこにたどり着けないかもしれませんが、少なくとも領域には入っています。

または、サービス エンドの WCF 二重契約は、クライアントの期間中、コールバック用にポートを開いたままにしますか?それとも解放しますか?

自作の XMPP サーバーがあり、サーバーの MSL (Maximum Segment Lifetime) を尋ねられました。
それはどういう意味ですか、どうすれば入手できますか? Linuxの/procTCP設定に何かありますか？

全て、

そこで、クライアントがサーバーと通信するために使用したい単純なプロトコルを作成することを発明しました。これは典型的な（私が思うに）三相レイアウトです：

• 接続の確立（最終的には機能のネゴシエーションが含まれます）
• 実際のデータ交換-パケットは楽しく行き来し、それに応じて動作するそれぞれの受信者によって解釈されます
• 接続のティアダウン-一方の側は「これ以上したくない」と言い、もう一方の側は「そうなる」と言います（最終的には、会話を閉じるだけでなく、完了するまでもう一方の側がデータを送信できるようになります）

フレームワークは単純なセットアップです。サーバーはjava.net.ServerSocket.accept（）を実行し、クライアントによる着信接続を処理するスレッドを開始します。これにより、サーバーが存在するホスト/ポートへのjava.net.Socket（）が作成されます。が待っています。双方がjava.io.InputStreamとjava.io.OutputStreamを使用し、互いにデータを吐き出し、送信メッセージを組み立て、受信メッセージを解析します。これまでのところ、問題ありません。

これまでのところ、プロトコルはハードコーディングされています。接続の確立とティアダウンはほとんど問題ありませんが、データ交換の部分（私は全二重になりたい）はかなり混乱しています。

それで、私は考えます。これを良い方法で行い、同じ名前のデザインパターンを使用してステートマシンをセットアップしましょう。サーバーとクライアントのそれぞれの状態、遷移が発生するために発生する必要のあるイベントの種類、および遷移が発生したときに実行する必要のあるアクションについては、かなり明確です。それはよさそうだ-紙の上では、つまり。実際には、紙では解決できないいくつかの質問に悩まされてきました。

特に、ステートマシンの入力は...少し多様です。どうすれば、データの書き込み、データの読み取り、接続の確認（接続が閉じているか、切断されている可能性があります）を同時に行うことができますか？また、第1フェーズと第3フェーズでは、応答の待機時間が無限になる可能性を回避するためにタイマーを取得する必要があります。

ですから、理論ステートマシンとコードステートマシンの間のギャップを埋める助けに感謝します。

ところで、私はC / C ++ / C＃も読むことができます-Javaに翻訳する必要はありません（これは私が使用しているものです）。

Windows XP では、Microsoft はそれ以降の Service Pack でハーフ オープン接続の数を制限する決定を下しました。tcpip.sys にパッチを当てると、これが修正されると噂されていました。そのような制限は Windows 2008 に存在しますか? もし存在する場合、それは構成可能ですか?

ループバックインターフェイスへのTCP接続が終了するTIME_WAIT（ソケットがSO_DONTLINGERsetで閉じられる）のに、別のホストへの同一の接続が終了しないTIME_WAIT（すぐにリセット/破棄される）のはなぜですか？

説明するシナリオは次のとおりです。

（A）クライアントとサーバーの2つのアプリケーションが、両方とも同じWindowsマシンで実行されています。クライアントは、サーバーのループバックインターフェイス（127.0.0.1、ポートxxxx）を介してサーバーに接続し、データを送信し、データを受信し、ソケットを閉じます（SO_DONTLINGER設定されています）。

接続が非常に短命であるため、クライアントアプリが毎秒多数の接続を確立および破棄しているとしましょう。最終的に、ソケットはTIME_WAITになり、クライアントは最終的に最大数のソケットを使い果たします（Windowsでは、これはデフォルトで最大3900であり、この値はレジストリで変更されないと想定しています）。

（B）シナリオ（A）と同じ2つのアプリケーションですが、サーバーは別のホスト上にあります（クライアントは引き続きWindowsで実行されています）。接続は、127.0.0.1宛てではなく、代わりに他のIP宛てである点を除いて、すべての点で同一です。ここでは、クライアントマシンの接続はに移行せTIME_WAITず、クライアントアプリは無期限に接続を継続できます。

なぜ矛盾があるのですか？

私のコードが同じ FTP または HTTP サーバー上でいくつかのファイルのアップロードとダウンロードを同時に実行することになっているプロジェクトに割り当てられています。速度が測定され、これからいくつかの結論が下されています。

さて、問題は、高速接続ではスループットに関してかなり期待通りの結果が得られていることですが、低速接続 (理想的なCDMA 1xRTT リンクと考えてください) では、逆方向を犠牲にしてダウンロードまたはアップロードのどちらかが優先されることです。私は、CDMA 1xRTT 接続が対称的であり、したがって、このリンクで同等の速度 (各方向で約 100 kbps) でデータ転送を実行できるはずであると確信している「より高いボディ」を持っています。

私の測定では、バッファ サイズとデータ リンク スロットリングに関してコードを大幅に調整しない限り、前述の条件で同じ速度を実現することは不可能であることがわかりました。マルチスレッド コードを試し、Windows の ftp.exe を自動化してデータ転送を実行する単純なバッチ ファイルも作成しましたが、結果は同じでした。

問題は、低速の対称リンクで同等の速度でデータ転送を実行できるかどうかです。「ハイヤーボディ」は期待通りでしょうか？はいの場合、そのようなスループットを達成するためにコードで何をすべきかについて何か提案はありますか?

PS。質問を完全に書き直したので、このサイトに属していることは明らかです。

OpenLDAP クライアント ライブラリを使用して LDAP サーバーに接続しています。問題は、しばらくアクティビティがない場合、サーバー (または途中のファイアウォール) が TCP 接続を切断することです。

「キープアライブ」の現在の実装は、時々 baseDN を検索するだけです - 何か良いアイデアはありますか?

SIO_FLUSH ソケット ioctl を Windows 環境 (ユーザー空間) で使用すると、どうなるか混乱します。これは、(1) TCP/IP 送信キューからブラック ホールにデータを完全に破棄するか、(2) キューに入れられた送信データをバッファが空になるまで接続全体にプッシュするか、または (3) 他の何かですか? ありがとう！

TCP ポートに接続されているすべてのクライアントで定期的にデータを送信する方法を探しています。私はツイスト python を見ていますが、reactor.callLater を認識しています。しかし、それを使用して、接続されているすべてのクライアントに定期的にデータを送信するにはどうすればよいですか? データ送信ロジックは Protocol クラスにあり、必要に応じてリアクターによってインスタンス化されます。リアクターからすべてのプロトコルインスタンスに結び付ける方法がわかりません...