トップページ⇒tech
1001コメント360KB

ネットワークプログラミング相談室 Port24

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001lmtp2009/07/07(火) 00:46:28
主にソケットに関しての質疑応答スレッドです。

Programming UNIX Socket FAQ (日本語訳)
　http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
　http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

関連リンクは>>2-10辺り
足りなかったら適当に付け足してね

前スレ
ネットワークプログラミング相談室 Port23
http://pc12.2ch.net/test/read.cgi/tech/1230466044/
関連スレ
ネットワークプログラミング雑談
http://pc12.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
http://pc11.2ch.net/test/read.cgi/tech/1086238859/
0809デフォルトの名無しさん2009/09/15(火) 21:55:06
デバッグ中のプロセス止めるとか日常茶飯事だけど、変な挙動起こしたことは無いな。
0810デフォルトの名無しさん2009/09/15(火) 22:03:30
>>805
斧は待ち行列じゃないよ
排卵と精子の関係だお
0811デフォルトの名無しさん2009/09/15(火) 22:20:33
>>808
たぶんないな。
システムが割り当てたWSA系のリソース開放でしょ
だとすれば最悪メモリリーク起こすぐらいで挙動に大きな問題を抱えるものじゃないと思う。
0812デフォルトの名無しさん2009/09/15(火) 23:35:31
>>798
どういう意味？
0813デフォルトの名無しさん2009/09/16(水) 10:23:26
クライアントからサーバーに対してUDPパケットを送信した場合、サーバーはポートが解放されているから受信出来るとして
その後、サーバーからクライアントに返信した場合、クライアントアプリケーション側で受信できるのって

クライアントからサーバーに送信した地点で一時的にポート解放されてるから？
ファイアウォール等で受信拒否していてもつながるのも同じ理由なんだろうか

もしそうだとしたら、サーバーと通信中の２つのクライアントにお互いのIPとポートを教えて
お互いに何度かパケットを送信すれば何回目かで届き、
一度サーバーを経由するけど、そんな感じでP2Pネットワークを構築することってできる？

ためしにサンプルプログラムを組んでみたらうまくいったんだが、理論的にはどうなんだろう。
ルーターとかネットワーク環境によってはだめなんかな・・・

長文すまそ
あとスレチだったらすまそ
0814デフォルトの名無しさん2009/09/16(水) 10:45:16
全然違うから。ファイアーウォール調べ直しな。
0815デフォルトの名無しさん2009/09/16(水) 11:20:09
ああ、ファイアウォールはなかったことにしてくれ
0816デフォルトの名無しさん2009/09/16(水) 12:29:54
なら、無かった事にして質問まとめなおせ。
0817デフォルトの名無しさん2009/09/16(水) 12:46:42
>>813
セッションハイジャックとかしらべてみたらどうかな

0818デフォルトの名無しさん2009/09/16(水) 13:05:00
>>817
サーバーとの接続は公開鍵方式で、その後クライアント同士の接続はサーバーが指定した
秘密鍵で行う予定なのでその辺は問題ない…と思う

セキュリティー云々は置いといて、ファイアウォールはアプリケーション許可してもらう前提で
これで一般家庭でつながらないことは無いのかな？と思ったまでです
0819デフォルトの名無しさん2009/09/16(水) 16:04:15
winsockいじるようになってから画面右下のインターネットのアイコンが光りっぱなしになったんですがどうしてですか？
0820デフォルトの名無しさん2009/09/16(水) 16:05:20
気のせいです
0821デフォルトの名無しさん2009/09/16(水) 16:08:25
そこを何とかお願いします・・・
何か垂れ流してるみたいで気持ちが悪い
0822デフォルトの名無しさん2009/09/16(水) 16:20:02
バカか？
0823デフォルトの名無しさん2009/09/16(水) 16:23:26
バカですお願いします
0824デフォルトの名無しさん2009/09/16(水) 16:31:09
1.winsockが本気出した
2.液晶画面の局所的なフレネル反射の本気
3.819が光過敏性てんかんになった
4.ソケットを開いたプロセスが終了しきれずに生きている
5.知らね
0825デフォルトの名無しさん2009/09/16(水) 16:34:40
再起動してネット接続してもすぐに症状が出ます・・・
0826デフォルトの名無しさん2009/09/16(水) 16:37:46
6. 実は前から光りっぱなしだったが、これまでは気にしていなかった
0827デフォルトの名無しさん2009/09/16(水) 16:40:41
いえ、4日前からです。送信40kbps/受信4kbps位
0828デフォルトの名無しさん2009/09/16(水) 16:54:18
7.気になるならパケットをキャプチャすればいーじゃん
0829デフォルトの名無しさん2009/09/16(水) 20:00:09
バカさ加減酷すぎワロタｗｗｗ
Wiresharkも回せないのか？
0830デフォルトの名無しさん2009/09/17(木) 09:07:17
俺的には「インターネットのアイコン」てのが気に入った。
なんでそういう単語を照れもなく使っちゃうレベルの人が
Winsock なんかに手ぇ出すかなあ。
0831デフォルトの名無しさん2009/09/17(木) 18:38:25
いつの間にか1Gbpsで繋がるようになった
0832デフォルトの名無しさん2009/09/17(木) 20:38:44
クライアントがInternets Explorerなんだけど
こいつにレスポンスコード302返したらどうなるん？
0833デフォルトの名無しさん2009/09/17(木) 21:03:23
期待通りに動く。
0834デフォルトの名無しさん2009/09/17(木) 21:36:18
IEの場合クッキー情報は一時的にTemporary Internet Filesフォルダにあると思ったのですが
セッションクッキー情報はTemporary Internet Filesに作られないのでせうか？
0835デフォルトの名無しさん2009/09/17(木) 21:49:58
あるだろ。
0836デフォルトの名無しさん2009/09/17(木) 22:40:05
セッションクッキーは永続的である必要が無いからファイルに持つ必要無いだろ。
0837デフォルトの名無しさん2009/09/18(金) 03:01:40
Firefoxだと作られるよ
0838デフォルトの名無しさん2009/09/18(金) 15:55:07
winsockについて質問です。

サーバープログラムに、クライアント数制限をつけたいと思っています。
例えば、10人までしか接続が確立できない。という類です。

FD_ACCEPTが呼ばれた際、acceptをします。
定員を超えていたら、次の行でacceptから帰ってきたSOCKET（正常なもの）をshutdownし、closesocketしました。
そうしたところ、どうやらクライアントに切断したことが伝わらないようで、クライアントのrecvがSOCKET_ERRORを返してくれません。

FD_ACCEPTを抜けた後、別の場所（メインループなど）でshutdown & closesocketした場合は伝わるようです。

・FD_ACCEPT内でclosesocketしてはダメなのでしょうか？
・そもそも上限に達していたら、acceptしないという方法はないのでしょうか？

ご教示よろしくお願いいたします
0839デフォルトの名無しさん2009/09/18(金) 16:20:07
・recvは0を返してるんじゃない？
・recvが0を返したら、通信終了でいいんじゃない？

> ・そもそも上限に達していたら、acceptしないという方法はないのでしょうか？
それぞれのクライアントに対する処理は非同期で動作してる前提で話すけど、
acceptする前に、セマフォとかで調停する。
0840デフォルトの名無しさん2009/09/18(金) 16:35:28
>>839
お返事ありがとうございます。なるほど。SOCKET_ERRORではなく、recvの返り値が0の場合も切断なのですね。
調べてみたところ、recvが0を返すのは「正常な終了」が行われた時とありました。
どうもありがとうございます。
0841デフォルトの名無しさん2009/09/18(金) 16:40:43
>>839
aaceptする前に既にクライアントには受理されたことになってしまうので
http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-3.html#ss3.3
acceptする前に調停しても、クライアントには伝わらないんじゃないかな。

acceptしないだけだと、たぶんクライアント側をしばらく待たせることになるので
それよりは一旦acceptだけしてから切断するほうが親切じゃないかな。
0842デフォルトの名無しさん2009/09/18(金) 17:07:45
>>841
ありがとうございます。
最初から拒否しておく。ということはできないのですね。
意外でした。

・FD_ACCEPTの中で切断しても大丈夫
・上記の結果、クライアント側のrecvの返り値が0になる
のが確認できました。
0843デフォルトの名無しさん2009/09/20(日) 19:01:52
listenって接続くるまで実行が停止状態になるんだよね？
既に接続が確立されてる相手からの送信データを待ちつつ
新たな接続が無いかどうかチェックするにはどうしたらいいの？
0844デフォルトの名無しさん2009/09/20(日) 19:47:02
listenはすぐ戻るやろ、接続がクルまでブロックされるのはaccept

acceptでブロックされたくないなら
該当descriptorをselect/pollすりゃいい
0845デフォルトの名無しさん2009/09/20(日) 19:47:03
C/C++でのソケットだと仮定して答えると、

接続待ちになるのはacceptね。

> 既に接続が確立されてる相手からの送信データを待ちつつ
> 新たな接続が無いかどうかチェックするにはどうしたらいいの？
接続が確立した相手用に新しいスレッド起こすか、
select使って複数のソケットに対してデータ待ちするか。
Windowsなら他の方法もあったかもしれない。
0846デフォルトの名無しさん2009/09/20(日) 19:47:20
素人でしゃばんな
0847デフォルトの名無しさん2009/09/20(日) 20:06:14
>>844
select/pollのとこでフリーズしてしまいましたが。。
0848デフォルトの名無しさん2009/09/20(日) 20:30:14
>>846
別に>>844,845は、特に変な事は言っていないと思うけどな。

>>845に細かすぎる指摘(改善)すると、以下のようになるけど。

>select使って複数のソケットに対してデータ待ちするか。
　==>select使って複数のソケットに対してデータ受信と接続を同時に待つか。

文句付けるなら、自分ならこうだ！ってのをレスしたほうがいいと思われ。
0849デフォルトの名無しさん2009/09/20(日) 20:30:42
>>848
素人でしゃばんな
0850デフォルトの名無しさん2009/09/20(日) 21:15:37
>>847
それは使い方が悪いからだろう。たぶん。
0851デフォルトの名無しさん2009/09/21(月) 02:17:11
>>849
夏厨は土に返ったはずであるが？
にーとさんかな？
0852デフォルトの名無しさん2009/09/21(月) 07:09:59
なにファビョってるんだ？
0853デフォルトの名無しさん2009/09/21(月) 12:58:08
馬鹿にはソケットは無理。
0854デフォルトの名無しさん2009/09/21(月) 14:22:25
馬鹿にも使える(ばかちょんで高パフォーマンス)ソケットというか、ネットワークライブラリ欲しいけど、
言語とかトラフィックパターン依存になるから、
プリミティブなソケット以上の共通化は不可能なのかね。
スレッドプールの共通インターフェイスが先か。
0855デフォルトの名無しさん2009/09/21(月) 15:57:50
大学はまだ夏休みだぜ
0856デフォルトの名無しさん2009/09/21(月) 16:24:00
>>847
俺のとこじゃフリーズしなかった
0857デフォルトの名無しさん2009/09/21(月) 18:27:22
>>856
select/pollのとこで止まってしまって先に進まなくなるのです。
0858デフォルトの名無しさん2009/09/21(月) 19:13:01
accept可能になるのってreadableだったかwritableだったか忘れた・・・
0859デフォルトの名無しさん2009/09/21(月) 19:19:50
readable
0860デフォルトの名無しさん2009/09/21(月) 21:17:27
クライアント側のconnectはwritableだっけ
0861デフォルトの名無しさん2009/09/21(月) 22:26:20
>>854
どこまでライブラリに機能を提供させるかという、境界線を引くのが難しい気がする。
トラフィックパターンが一方向の要求/応答に限定できるならRPC(JavaならRMI?)あるいは
HTTPライブラリで済むけど、わざわざソケットに手を出すのは、それ以外のパターンが
必要になる、ある程度複雑な(高機能な)アプリケーションを開発するケースだと思う。
ただ、そうなると、メッセージの衝突/送信権、分割/連結、優先制御/流量制御なども、
ライブラリが提供すべき機能要素として要求される(要求する人もいる)だろう。
またマルチスレッド/マルチプロセス/ファイバに関しても、どこまでライブラリで
対応させるべきか、人によって意見は分かれるはず。

だから、最終的には必要最低条件を満たしたソケットで落ち着いてしまうのだと思う。
個人的にはレコード指向(TCPのメッセージ境界対応)で全二重な機能だけを提供し、
あとは上位レイヤのプロトコル(アプリケーション)の実装にまかせる、軽いライブラリが
あってもよさげだと思うんだけどね。
0862デフォルトの名無しさん2009/09/22(火) 15:55:58
>>857
よかったね。
コード見せてくれないとわからんがな
0863デフォルトの名無しさん2009/09/23(水) 16:30:48
相手がcloseしたかどうか知るには？
0864デフォルトの名無しさん2009/09/23(水) 16:35:36
>>863
「readして読んだバイト数が0の場合」ってのじゃなくて、なんかのひっかけ？
0865デフォルトの名無しさん2009/09/23(水) 16:35:44
recvが0を返すかどうかを見る
0866デフォルトの名無しさん2009/09/23(水) 16:51:05
recvがエラーを返した場合も
0867デフォルトの名無しさん2009/09/23(水) 16:55:47
>>866 状況によるだろ?
Unix 系の EBADF, ENOTCONN, EINTR, EFAULT は
相手がクローズするしないに関わらず発生する
0868デフォルトの名無しさん2009/09/23(水) 19:07:23
>>867
EINTR以外はプログラムバグじゃないの？
0869デフォルトの名無しさん2009/09/23(水) 19:24:59
>>868
そうだけど、そんなん言ったらECONNRESETだけじゃないか
明示的にエラーになってクローズされてるのは
0870デフォルトの名無しさん2009/09/23(水) 21:32:37
>>869
ですな〜
でも、recvが想定外なエラーを返した時点でそのソケットは捨てるしかないけど。
0871デフォルトの名無しさん2009/09/24(木) 14:51:00
一つのUDP同期ソケットで、スレッドAではrecv待機しスレッドBではsendするのって危ない？

一つのソケットでrecvとsendしたい場合はやっぱり非同期にするしかないのか・・・
0872デフォルトの名無しさん2009/09/24(木) 15:23:51
>>871
危なくはないと思うが。shutdown/closeさえ気をつければ。
ただ、recvとsendを別スレッドにすると、スレッド間でデータの共有が
必要になって面倒だから、普通はシングルスレッドで作るんじゃねえか？
完全にスレッドが分離してるんなら、別々でも無問題だろ。
0873デフォルトの名無しさん2009/09/24(木) 15:24:47
>>871
すくなくとも *nix は大丈夫なもよう
08748712009/09/24(木) 15:46:39
>>872-871
レスありがとう

Winsock中級者向けの議論からも次の様な一文を発見

一方のスレッドが send() を呼び出し、別のスレッドが同一のソケットに対して recv() を呼び出すのは安全である、という伝説があります。
しかし私はこれを確認したことはありません。より堅固な情報やデモンストレーション用のコード、さらなる伝説などがあれば、教えていただけると幸いです。

まあとりあえず大丈夫だろうってことですね
0875デフォルトの名無しさん2009/09/24(木) 15:50:58
>>872-873
安価ミス
0876デフォルトの名無しさん2009/09/24(木) 22:21:00
>>871
Solarisは不定期にハングしてたよ
今はどうだかしらんけど・・・
0877デフォルトの名無しさん2009/09/25(金) 12:10:34
送信したらすぐcloseするもの作ってて
close後にレスポンス着てるみたいなんだがshutdownしないとだめ？
0878デフォルトの名無しさん2009/09/25(金) 12:17:15
こっち側で何やっても、レスポンス来るのは抑止できない。
0879デフォルトの名無しさん2009/09/25(金) 12:19:31
>>877
送信スレッドと受信スレッドが別とかって話か？
必要なレスポンスなら何とかしてやるのが筋だろ？
送信側: SHUT_WR 送信で終了
受信側: 読込みバイト数0になるまでレスポンス読んで close
とか………
つか、プロトコル設計見直した方がええんちゃうか？
0880デフォルトの名無しさん2009/09/25(金) 13:55:05
Winsock2を使ってプロミスキャスなパケットモニタを作る場合
送信パケットもモニタできるようにするのは不可能ですか？

WinPcapドライバを使えば送信パケットもモニタできるのだけど・・
0881デフォルトの名無しさん2009/09/25(金) 21:03:37
>>880
できんことは無いけど、それを作り上げていくと
WinPcapドライバが出来てしまうわけで
意味無いよな
0882デフォルトの名無しさん2009/09/26(土) 20:27:52
recvってなんて読むの？
0883デフォルトの名無しさん2009/09/26(土) 20:46:56
>>882
あーるいーしーぶい
0884デフォルトの名無しさん2009/09/27(日) 01:52:41
れくぶ
0885デフォルトの名無しさん2009/09/27(日) 16:29:19
>>881
レスありがとうございます。
いろいろ調べてみた結果、
環境によって送信パケットをモニタできないことがあるみたいです。
別の環境だと普通に送信パケットもモニタできることを確認したので
問題を切り分けてる最中です。
詳しいことがわかりましたら報告させていただきます。
0886デフォルトの名無しさん2009/09/27(日) 21:56:18
WinPcapってずーっと前はpppは拾え無かったよな。今拾えるか知らない。
0887デフォルトの名無しさん2009/09/28(月) 11:40:55
uIPってUDPの単純送信関数無いのか・・・
その上何で今頃気づくんだろう俺orz
0888デフォルトの名無しさん2009/09/28(月) 17:24:01
>>882
やはり自民党清和会の下に結集し、日教組を壊滅させることでしょうね。
日教組の教師に｢労働者の権利｣などという左翼思想を吹き込まれた連中が義務も果たさずに
ｳﾘ達は無理矢理連れて来られて強制労働させられているﾆﾀﾞ、などと権利ばかり主張しています。
あとは残業代を要求して裁判を起こしてるような腐った輩を社会全体で徹底的に叩くことでしょう。
0889デフォルトの名無しさん2009/09/29(火) 04:19:15
それを省略するとアルファベット4文字になるのか。パネェ。
0890デフォルトの名無しさん2009/09/29(火) 22:54:09
ﾜﾛﾀ
0891デフォルトの名無しさん2009/09/29(火) 23:21:28
recv深いな・・・
0892デフォルトの名無しさん2009/09/30(水) 01:02:38
次スレのテンプレ入りかもしれな
0893デフォルトの名無しさん2009/10/01(木) 17:46:23
まあ日教組はゴミだけどな。
0894デフォルトの名無しさん2009/10/01(木) 18:13:22
ウヨは巣に帰れよ
0895デフォルトの名無しさん2009/10/01(木) 18:20:38
旧社会党系のうちの社長が俺が産経取ってるのを気にしているようだ・・・ってのはともかくとして。

uIPのUDPサポートが半端だからあれやこれや5種類くらいのスタックを参考にして自前で作ってるわ。
純組込系のスタックは金になるから公開しないのかなぁ。
0896デフォルトの名無しさん2009/10/02(金) 05:38:11
飯の種田氏な。
金払いたくない乞食はリナックスやバークレー辺りから適当にパクってくればいい訳で。その程度で困らないだろうし。
0897デフォルトの名無しさん2009/10/02(金) 11:55:16
でも、それもパクって来た奴だろ。
0898デフォルトの名無しさん2009/10/02(金) 14:59:55
>>895
> 純組込系のスタックは金になるから公開しないのかなぁ。
BSD のスタック移植することが多いかな
CPU の規模によっては、大昔 MIT が IBM PC に実装やつをモディファイ
して使ってる
0899デフォルトの名無しさん2009/10/06(火) 22:23:22
etherealの相談ってここでしてもいい？
0900デフォルトの名無しさん2009/10/06(火) 22:43:08
ええんちゃう？
0901デフォルトの名無しさん2009/10/06(火) 22:57:06
ソースの書き換えとかフィルタの作り方とかなら
0902デフォルトの名無しさん2009/10/06(火) 23:48:30
フィルタのかけ方を聞きたかったんだけど駄目っぽいな
やめておくわ
0903デフォルトの名無しさん2009/10/07(水) 00:25:58
じだいはwiresharkだ
0904デフォルトの名無しさん2009/10/07(水) 11:17:02
wiresharkの相談ってここでしてもいい？
0905デフォルトの名無しさん2009/10/07(水) 11:24:05
パケットキャプチャーとかすげーと思ってたけど
マイコンプログラミングと電子回路始めたら全然すごくないことが
わかった。
0906デフォルトの名無しさん2009/10/07(水) 14:20:19
同意
ケーブルを流れてる定常波から信号を取り出してるのはすごいと思うけどね
promisc自体はたいしたことやってない
ただのbitパターンマッチの繰り返し
0907デフォルトの名無しさん2009/10/07(水) 14:39:35
>>12
selectはヘヴィーロードサーバで、
bitmask処理がオーバーヘッドになる。
>>6辺りからそれを報告した論文を辿れる。
0908デフォルトの名無しさん2009/10/07(水) 20:57:33
wiresharkよりもethreal
レス数が900を超えています。1000を超えると表示できなくなるよ。