問題タブ [tcp]

TCP/IP ポートをリッスンするアプリを開発する場合、既定のポートを選択するにはどうすればよいでしょうか? このアプリが多数のコンピューターにインストールされ、ポートの競合を回避する必要があるとします。

動的に割り当てられた新しいオープン TCP ポートを使用して、WCF サービス呼び出し用の新しい net.tcp://localhost:x/Service エンドポイントを作成したいと考えています。

特定のサーバーへの接続を開くと、TcpClient が新しいクライアント側ポートを割り当てることを知っています。

.NET で次に開いている TCP ポートを見つける簡単な方法はありますか?

上記の文字列を作成できるように、実際の番号が必要です。その文字列を別のプロセスに渡す必要があるため、0 は機能しません。これにより、その新しいチャネルでコールバックできます。

TCP/IP は、同じパケットの複数のコピーが宛先に到達するのを防ぎますか? それとも、その上に冪等性ロジックをレイヤー化するのはエンドポイント次第ですか?

可能であれば、TCP/IP 仕様の特定の段落を参照してください。

サーバーとのtcpソケット通信をカプセル化するクラスがあります。サーバーに送信されるコマンドメッセージごとに、サーバーは常に応答コード（OK、失敗）を含む応答メッセージを送り返します。私のクラスを使用すると、各コマンドはsyncまたはasyncのいずれかで実行できます。

発生する可能性のある例外には、基本的に2つのタイプがあります。切断またはその他の回復不能なエラーによって引き起こされる「障害」と、「バッファがいっぱいです」などの予期しない例外です。障害が発生した場合、接続が再確立されるまで、コマンドを続行したり、再試行したりすることはできません。応答が失敗した場合、または例外が発生した場合でも、コマンドを再試行できます...

したがって、現在、私のsyncコマンドメソッドは、OK、Fail、Faultの値を持つことができる列挙型を返します。例外が発生した場合は、（syncコマンドで）呼び出し元のスレッドに発生します。非同期コマンドの場合、Resultプロパティの列挙値に追加の値（OK、Fail、Fault、またはException）を含めることができ、コールバックはコマンドオブジェクトのExceptionプロパティを介して実際の例外オブジェクトにアクセスできます。

この戦略についてどう思いますか？同期コマンドに対して例外をまったく発生させず、内部で例外をログに記録し、代わりに4番目の列挙値を返すようにしたいと思います。とにかくどのような場合でも例外を実際に処理するのはそれだけだからです...または、使用しないでください結果コードはすべて、障害も含めてすべての場合に例外を発生させますか？

ありがとう。

Socket#close()リモート側のソケットで呼び出されたかどうかをどのように検出しますか?

問題が発生している Windows 2003 サーバーに展開された WCF サービスがあります。構成は使用wsHttpBindingしており、IP アドレスを指定しています。サービスは、Windows サービスによってホストされています。

サービスを開始すると、ほとんどの場合、間違った IP アドレスが取得されます。数回、正しいアドレスにバインドされただけで、そのバインドがドロップされ、しばらく処理した後、NIC にバインドされた別のアドレス (2 つあります) に移動しました。

現在、ポート 80 を使用しています (IIS を 経由で 1 つのアドレスのみにバインドするように構成しましたhttpcfg) が、別のポートを使用して試してみましたが、結果は同じでした。

Windows サービスが WCF サービスのホストを開始すると、プロパティはそれが正しいアドレスにバインドされていることを示します。ただし、tcpview は、実際には正しくないアドレスでリッスンしていることを示しています。

以下は、baseAddress を設定する構成の一部です。バインドされるものは、.9 ではなく .4 になります。

• 設定する必要がある他の構成はありますか?
• これが間違ったアドレスにバインドされている場所を追跡するのに役立つツールはありますか?

最近の質問のフォローアップとして、Javaでは、TCPソケットで読み取り/書き込みを試行せずに、ソケットがピアによって正常に閉じられたことを検出できないのはなぜでしょうか。Socketこれは、pre-NIOとNIOのどちらを使用するかに関係なく当てはまるようSocketChannelです。

ピアがTCP接続を正常に閉じると、接続の両側のTCPスタックがその事実を認識します。サーバー側（シャットダウンを開始する側）は状態FIN_WAIT2になり、クライアント側（シャットダウンに明示的に応答しない側）は状態になりCLOSE_WAITます。基盤となるTCP接続が終了したかどうかを確認するためにTCPスタックにクエリを実行できるSocketメソッドがないのはなぜですか？SocketChannelTCPスタックがそのようなステータス情報を提供しないということですか？それとも、カーネルへのコストのかかる呼び出しを回避するための設計上の決定ですか？

この質問に対する回答をすでに投稿しているユーザーの助けを借りて、問題がどこから来ているのかがわかると思います。接続を明示的に閉じない側は、最終的にTCP状態になりますCLOSE_WAIT。つまり、接続はシャットダウンの過程にあり、側が独自のCLOSE操作を発行するのを待ちます。isConnected戻っtrueたりisClosed戻ったりするのは十分公平だと思いますfalseが、なぜそのようなものがないのisClosingですか？

以下は、NIO以前のソケットを使用するテストクラスです。ただし、NIOを使用しても同じ結果が得られます。

テストクライアントがテストサーバーに接続すると、サーバーが接続のシャットダウンを開始した後でも、出力は変更されません。

大量のメッセージを (.NET 非同期) TCP サーバーに送信する .NET TCP クライアントがあります。

サーバーにメッセージを送信し続ける必要がありますが、TIME_WAIT のためにクライアントのポートが不足しています。

使用可能なすべてのポートを使用せずに、プログラムが継続的かつ確実にメッセージを送信するにはどうすればよいでしょうか?

同じソケットを再利用し続ける方法はありますか。Disconnect() と REUSEADDRESS ソケット フラグを見てきましたが、それらの使用の良い例が見つかりません。実際、ほとんどのソースは、Disconnect は低レベルで使用するため (つまり、ソケット ハンドルのみをリサイクルするため) 使用しないと述べています。

UDP に切り替えるか、C++ と IOCP を使用する方法があるのではないかと考えています。

クライアント/サーバーの TCP 接続が実際にどのくらい持続すると予想できますか?

永続的に接続したままにしたいのですが、問題が発生したため、クライアントは再接続する必要があります。外部機器に問題があるのではなく、コードに問題があると言うのはどの時点ですか?

ユーザーがNATのポートをC++アプリのローカルマシンに簡単に転送できるようにしたいと思います。これをOSXとWindowsで動作させたいです。Linuxは大きなボーナスですが、Linuxユーザーはおそらく手動でポートを転送する方が快適なので、それほど心配する必要はありません。LGPLタイプコードは問題ありませんが、ストレートGPLのものは使用できません。

この分野で誰かが持っている考えや経験を聞きたいのですが、いくつかの具体的な質問が思い浮かびます。

• UPNPに最適なライブラリとして認められていますか？MiniUPNPクライアントは機能するように見えますが、他に何かありますか？
• Bonjourはどうですか？OSXコンピューターで信頼できますか？
• すべての大きなbittorrentアプリはこれに対処する必要があるので、それらがどのようにそれを行うかについての既存の調査はありますか？Skypeはどうですか？