質問編集履歴
10
f
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -29,7 +29,7 @@
|
|
|
29
29
|
これは、ウェイト中(状態は何でもよい)のソケットと同じローカルポートとアドレスにバインドできるようにするも。
|
|
30
30
|
これで作成したものは、当然リモート情報が空のため、ウェイト中のと完全一致しないため、仮にウェイト中に切ったはずの相手からパケットが届いても一意に流すソケットが決まる、なのでok
|
|
31
31
|
ローカルアドレスも✳︎で作れば、ウェイト中のacceptで作られたソケットのローカルアドレスは✳︎でなく一意になっている(188.88.22.81みたいな)ので完全一致とはならず、セーフ
|
|
32
|
-
また、リスンを再開できるし、ウェイト中以外のクラからの接続要求は呑める。
|
|
32
|
+
また、リスンを再開できるし、ウェイト中以外のクラからの接続要求は呑める(実際はクラ側はポートは使用されていないものを選択してくるので、ウェイト中のとは完全一致とはならないため呑める)。
|
|
33
33
|
|
|
34
34
|
同じウェイト中の相手からまた接続要求が来てacceptした場合は、作れてしまうと4つの情報が完全一致のソケットが生まれてしまうが故に流石にだめ、となる。
|
|
35
35
|
すぐにまた接続をするためにはウェイト時間を1秒とか(できるかはosに依存するが)
|
9
は
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -38,7 +38,8 @@
|
|
|
38
38
|
ウェイト中のソケットのポートが自動選択されることはないため、サーバ側のウェイト中のソケットのリモート情報が被ることはないため、
|
|
39
39
|
接続要求が通る。(自動選択ではなくbindした場合は、完全一致してしまうので先の問題が起きる。)
|
|
40
40
|
|
|
41
|
-
|
|
41
|
+
つまりSO_REUSEADDRは、
|
|
42
|
+
サービスのポートを固定しておく必要がある主にサーバ側に対するバインドエラーの回避措置
|
|
42
43
|
|
|
43
44
|
この辺りのことを整理できる頭がなく、ごちゃごちゃしており、申し訳ありません。
|
|
44
45
|
何かご指摘御指南頂けましたら幸いです。
|
8
な
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -36,7 +36,7 @@
|
|
|
36
36
|
に <するしかない> 。
|
|
37
37
|
といっても、クライアント側はconnect()の際に使われてないポートが自動選択されるため、
|
|
38
38
|
ウェイト中のソケットのポートが自動選択されることはないため、サーバ側のウェイト中のソケットのリモート情報が被ることはないため、
|
|
39
|
-
|
|
39
|
+
接続要求が通る。(自動選択ではなくbindした場合は、完全一致してしまうので先の問題が起きる。)
|
|
40
40
|
|
|
41
41
|
|
|
42
42
|
|
7
や
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -34,6 +34,9 @@
|
|
|
34
34
|
同じウェイト中の相手からまた接続要求が来てacceptした場合は、作れてしまうと4つの情報が完全一致のソケットが生まれてしまうが故に流石にだめ、となる。
|
|
35
35
|
すぐにまた接続をするためにはウェイト時間を1秒とか(できるかはosに依存するが)
|
|
36
36
|
に <するしかない> 。
|
|
37
|
+
といっても、クライアント側はconnect()の際に使われてないポートが自動選択されるため、
|
|
38
|
+
ウェイト中のソケットのポートが自動選択されることはないため、サーバ側のウェイト中のソケットのリモート情報が被ることはないため、
|
|
39
|
+
リスン中のソケットに接続要求してやりとり用ソケットが作られる。(自動選択ではなくbindした場合は、完全一致してしまうので先の問題が起きる。)
|
|
37
40
|
|
|
38
41
|
|
|
39
42
|
|
6
か
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -20,7 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
そして、ワイルドカードもない4つの情報全てが一致する構造体は絶対に同居できない。(そんなことが罷り通ると、来たパケットをどのソケットに流せばいいのかが判断できなくなる。)
|
|
22
22
|
|
|
23
|
-
** REUSEADDRの効果とは**
|
|
23
|
+
** SO_REUSEADDRの効果とは**
|
|
24
24
|
あるプログラムで、作成したリスン用のソケットとそれに従属するソケットをcloseした場合、
|
|
25
25
|
やりとり用の従属するソケットは終了ハンドシェイクなどが無事に終わっていればtime_waitする。
|
|
26
26
|
その後そのウェイト中に再度リスン用のソケットを作り、バインドしようとすると、ウェイトしているソケットのローカルアドレスとローカルポートは、今作ろうとしているものと一致してしまうため、エラーとなる。
|
5
は
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -27,7 +27,7 @@
|
|
|
27
27
|
ウェイト中の両者と無関係の接続用ソケットまで用意できないのはよくない。
|
|
28
28
|
これを回避するために、REUSEADDRを使う。
|
|
29
29
|
これは、ウェイト中(状態は何でもよい)のソケットと同じローカルポートとアドレスにバインドできるようにするも。
|
|
30
|
-
これで作成したものは、当然リモート情報が
|
|
30
|
+
これで作成したものは、当然リモート情報が空のため、ウェイト中のと完全一致しないため、仮にウェイト中に切ったはずの相手からパケットが届いても一意に流すソケットが決まる、なのでok
|
|
31
31
|
ローカルアドレスも✳︎で作れば、ウェイト中のacceptで作られたソケットのローカルアドレスは✳︎でなく一意になっている(188.88.22.81みたいな)ので完全一致とはならず、セーフ
|
|
32
32
|
また、リスンを再開できるし、ウェイト中以外のクラからの接続要求は呑める。
|
|
33
33
|
|
4
な
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -31,7 +31,7 @@
|
|
|
31
31
|
ローカルアドレスも✳︎で作れば、ウェイト中のacceptで作られたソケットのローカルアドレスは✳︎でなく一意になっている(188.88.22.81みたいな)ので完全一致とはならず、セーフ
|
|
32
32
|
また、リスンを再開できるし、ウェイト中以外のクラからの接続要求は呑める。
|
|
33
33
|
|
|
34
|
-
|
|
34
|
+
同じウェイト中の相手からまた接続要求が来てacceptした場合は、作れてしまうと4つの情報が完全一致のソケットが生まれてしまうが故に流石にだめ、となる。
|
|
35
35
|
すぐにまた接続をするためにはウェイト時間を1秒とか(できるかはosに依存するが)
|
|
36
36
|
に <するしかない> 。
|
|
37
37
|
|
3
な
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -29,6 +29,7 @@
|
|
|
29
29
|
これは、ウェイト中(状態は何でもよい)のソケットと同じローカルポートとアドレスにバインドできるようにするも。
|
|
30
30
|
これで作成したものは、当然リモート情報がからのため、ウェイト中のと完全一致しないため、仮にウェイト中に切ったはずの相手からパケットが届いても一意に流すソケットが決まる、なのでok
|
|
31
31
|
ローカルアドレスも✳︎で作れば、ウェイト中のacceptで作られたソケットのローカルアドレスは✳︎でなく一意になっている(188.88.22.81みたいな)ので完全一致とはならず、セーフ
|
|
32
|
+
また、リスンを再開できるし、ウェイト中以外のクラからの接続要求は呑める。
|
|
32
33
|
|
|
33
34
|
ただし、当然同じウェイト中の相手からまた接続要求が来てacceptした場合は、作れてしまうと4つの情報が完全一致のソケットが生まれてしまうが故に流石にだめ。
|
|
34
35
|
すぐにまた接続をするためにはウェイト時間を1秒とか(できるかはosに依存するが)
|
2
は
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
これを回避するために、REUSEADDRを使う。
|
|
29
29
|
これは、ウェイト中(状態は何でもよい)のソケットと同じローカルポートとアドレスにバインドできるようにするも。
|
|
30
30
|
これで作成したものは、当然リモート情報がからのため、ウェイト中のと完全一致しないため、仮にウェイト中に切ったはずの相手からパケットが届いても一意に流すソケットが決まる、なのでok
|
|
31
|
-
ローカルアドレスも✳︎で作れば、ウェイト中のローカルアドレスは✳︎でなく一意になっているので完全一致とはならず、セーフ
|
|
31
|
+
ローカルアドレスも✳︎で作れば、ウェイト中のacceptで作られたソケットのローカルアドレスは✳︎でなく一意になっている(188.88.22.81みたいな)ので完全一致とはならず、セーフ
|
|
32
32
|
|
|
33
33
|
ただし、当然同じウェイト中の相手からまた接続要求が来てacceptした場合は、作れてしまうと4つの情報が完全一致のソケットが生まれてしまうが故に流石にだめ。
|
|
34
34
|
すぐにまた接続をするためにはウェイト時間を1秒とか(できるかはosに依存するが)
|
1
や
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -18,14 +18,17 @@
|
|
|
18
18
|
ソケット2は、ソケット1(リスン用ソケット)からacceptにより従属するソケットとして作成されたものだが、✳︎は全てを含むので被っている。
|
|
19
19
|
なぜこれが許されるのかは、✳︎(ワイルドカード)はあと優先となるルールがあるため、ソケット2めがけて来たクラからのパケットはその条件により、ソケットを一意に決めて流すことができる。
|
|
20
20
|
|
|
21
|
-
そして、ワイルドカードもない4つの情報全てが一致する構造体は絶対に同居できない。(そんなことが罷り通ると、来たパケットを
|
|
21
|
+
そして、ワイルドカードもない4つの情報全てが一致する構造体は絶対に同居できない。(そんなことが罷り通ると、来たパケットをどのソケットに流せばいいのかが判断できなくなる。)
|
|
22
22
|
|
|
23
23
|
** REUSEADDRの効果とは**
|
|
24
24
|
あるプログラムで、作成したリスン用のソケットとそれに従属するソケットをcloseした場合、
|
|
25
25
|
やりとり用の従属するソケットは終了ハンドシェイクなどが無事に終わっていればtime_waitする。
|
|
26
26
|
その後そのウェイト中に再度リスン用のソケットを作り、バインドしようとすると、ウェイトしているソケットのローカルアドレスとローカルポートは、今作ろうとしているものと一致してしまうため、エラーとなる。
|
|
27
|
+
ウェイト中の両者と無関係の接続用ソケットまで用意できないのはよくない。
|
|
27
28
|
これを回避するために、REUSEADDRを使う。
|
|
29
|
+
これは、ウェイト中(状態は何でもよい)のソケットと同じローカルポートとアドレスにバインドできるようにするも。
|
|
28
30
|
これで作成したものは、当然リモート情報がからのため、ウェイト中のと完全一致しないため、仮にウェイト中に切ったはずの相手からパケットが届いても一意に流すソケットが決まる、なのでok
|
|
31
|
+
ローカルアドレスも✳︎で作れば、ウェイト中のローカルアドレスは✳︎でなく一意になっているので完全一致とはならず、セーフ
|
|
29
32
|
|
|
30
33
|
ただし、当然同じウェイト中の相手からまた接続要求が来てacceptした場合は、作れてしまうと4つの情報が完全一致のソケットが生まれてしまうが故に流石にだめ。
|
|
31
34
|
すぐにまた接続をするためにはウェイト時間を1秒とか(できるかはosに依存するが)
|