TCP/IP エラー処理 connect 編
connect(2) のエラー TCP において connect(2) 呼出し時に発生する可能性のあるエラーは以下の通りです。 タイムアウト RST 受信 EHOSTUNREACH また ENETUNREACH シグナル受信 その他 まず、connect(2) 時の正常な流れをしっかり覚えておいてください。 (connect(2) を呼んで) SYN を送る SYN+ACK が返ってくる (ここで connect(2) から戻る) ACK を送る タイムアウト もし仮に、SYN を送ったものの、相手側から SYN+ACK が返ってこない場合は、 (ローカルの TCP スタックが) しつこく SYN を再送します。何度 SYN を送っても SYN+ACK が返ってこない場合はあきらめてタイムアウトします。 「SYN+ACK が返ってこない」というのは、例えば以下のようなケースが考えられます。
Programming UNIX Sockets in C - Frequently Asked Questions: クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問
Previous Next Table of Contents 2. クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問 2.1 相手側のソケットが閉じられたことをどうやって知ることができますか? Andrew Gierth 氏 ( andrew@erlenstar.demon.co.uk) より: 私の知る限り… 相手側が (SO_LINGER を使ったややこしいことをしないで) close() するか終了したとすると、こちらの read() の呼び 出しは 0 を返すはずです。同じ場合で、write() 呼び出しで何が 起こるかは、もうちょっとわかりづらいです。直後の呼び出し時ではな く、その次の呼び出し時にEPIPE が返るでしょう。 もし相手が再起動するか l_onoff = 1, l_linger = 0 を設定して から閉じたとすると、read() からは(
ソケット通信メモ(Hishidama's TCP/UDP Socket Memo)
TCPソケット サーバータイプとクライアントタイプの両方のアプリケーションを作らないといけないなら、サーバータイプから作るべきだろう。 （クライアントタイプだけ先に作っても動かせないから。まぁサーバータイプだけ動かしても、待ってるだけであまり意味無いけど(苦笑)） でも仕組みはクライアントタイプの方が簡単。 TCPを使う場合は、通信の最初にコネクションの確立を行う必要がある。 サーバーでlisten・accept、クライアントでconnectが成功すればコネクションが確立したことになる。 どのポート番号を使うかについては、サーバー側はアプリケーションの作成者が決める必要がある。[/2007-06-16] クライアント側のポート番号は、ソケットライブラリがそのマシンで使っていない番号を自動的に割り振ってくれるので、気にしなくてよい。 IANAの基準では、1～1023は「よく知られたポート（w
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
