tcpソケットが壊れたパイプエラーを直ちに報告できるかどうかを知りたいと思っています。現在、サーバーがダウンしたときにクライアント側でsigpipeシグナルを捕捉しています...しかし、私は、sigpipeシグナルが生成されたことがわかりました。 2番目のmsgがクライアントからサーバーに送信された後です。これは可能な理由は何でしょうか？他のソケットの終わりがダウンした場合、最初の送信はsigpipeを返さなければなりません。 この特殊な動作には何らかの説明がありますか？そして、これを回避するための可能な方法は？1回目の送信直後にSIGPIPEが生成されない
私はSO_KEEPALIVEオプションを使用すると、壊れたリンクの検出をスピードアップするかもしれないと思います。
「SO_KEEPALIVE」は、一般に2時間ごとに送信されます。私は、接続状態をチェックする方法としては推奨しません。 –
それは調整可能ですが、いいえ、私はそれを推奨していません、私はオプションをカバーしています:) –
それは調節可能です...しかし、私はそうすることを推測するので、すべてのTCP接続に影響します.. – Srinivas
TCPスタックは、何回かの再送信試行の後にのみエラーを送出します。 IIRCの場合、TCP再送信タイマーは数秒に初期化され、再送信の数は通常5〜10です。このプロトコルは、データ交換中に到達不能になったピアを検出する他の手段をサポートしていません（つまり、誰かがサーバの電源ケーブルでトリップした）。
* TCPスタックは、何回かの再送信試行の後にのみエラーをスローします。*そのエラーと何時にTCPがそのエラーをスローするかを教えてください。 – Srinivas
スローされるエラーは多岐にわたり、ECONNRESETまたはECONNABORTEDまたはETIMEDOUTが発生する可能性があります。どのようにサーバーとルーターが遠ざかり、いつバックアップを取るか、そしていつ、いつ、いつ、いつまでかに依存します。エラーが出るまでの時間はOS /構成に依存しますが、ほとんどのOSでは数十秒になるでしょう。どこかのルータが別の経路を確立しようとしている場合には、長い間待たなければなりません。モデムにダイヤルするか、またはマイクロ波リンク上のスロットを取得しようとしています。プロトコルは何とかデータを配信するのが非常に難しく、そうしようとする時間が与えられなければなりません。 –
は、私はその可能TCP用のソケットがすぐ
パイプのもう一方の端を、ネットワークを介して任意の壊れたパイプのエラーを報告するかどうかを知りたいです。そのネットワークは遅く、信頼性が低い可能性があります。だから、パイプの片端は即座にそのパートナーがまだそこにいるかどうかは分かりません。遅れはかなり長くなる可能性があるので、O/Sはまたバッファリングを行う可能性が高い。これらの考慮事項により、破損したパイプをすぐに検出することは事実上不可能になります。
そして、すべての可能なこの
を回避する方法しかし、なぜあなたがしたいですか？パイプはトランスミッション中いつでも破損する可能性があるため、とにかく一般的なケースを処理する必要があります。
すぐに実行されない場合、ASAPは..yesを実行しますが、一般的なケースは、2回目の送信後にsigpipeが返され、誰かがconfigコマンドを与えた場合、最後のconfig cmdを送信する直前にソケットが破損する可能性があります。彼はそれを逃したことを知っています.. – Srinivas
@Srinivas「最後の設定cmdを送信する直前に彼はそれを見逃していたと知っています」あなたの*本当の*興味は、送信者が 'SIGPIPE '受信機で受信されましたか？送信者は受信者がコマンドの送信を完了したかどうか本当に知りたがっているので、これはあまり役に立ちません。そのためには、TCP/IP上にプロトコルを構築する必要があります。これは、受信者が完了したコマンドの確認を送信することです。 – Raedwald
私はクライアントが自動的に再接続したいと思っています。これは、シグナルハンドラに依存してジョブを実行しています。受信者が正常に実行を完了した後、受信者から応答が返ってきます...しかし、最後のcmdのために、彼はそれがbrokedソケットに起因するか、またはcmdを完了するために受信機の無能のためにあったかどうかを知っていません... – Srinivas
私はどのようにして、サーバーがダウンした検出う –
...あなたはあまりにも多くを求めていると思いますか？どうやって落ちましたか？ – jpalecek
接続からの読み取りを試みると、クローズされた接続が通知されます。 –