ネットワークプログラミング相談室 Port29
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2012/10/31(水) 17:05:08.29Programming 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辺り
足りなかったら適当に付け足してね
前スレ
ネットワークプログラミング相談室 Port28
http://toro.2ch.net/test/read.cgi/tech/1334736934/
関連スレ
ネットワークプログラミング雑談
http://toro.2ch.net/test/read.cgi/tech/1235800707/
0164デフォルトの名無しさん
2013/03/31(日) 18:56:08.59書籍は規制対象外なのを利用して、本として持ち出して、
スキャナで取り込むとかしたんだっけ？
0165デフォルトの名無しさん
2013/04/03(水) 00:05:18.98受信者がいなければ、行き場を失ったデータはどこへ行くのか?
一定数はキューみたいなものに保存されるのかしら?
それとも逐一消えていくのかしら?
前者の場合、リアルタイムシステムに悪影響を与えてしまうと思うけど、どうなんでしょう。
初心者でスマソ
0166デフォルトの名無しさん
2013/04/03(水) 00:10:51.440167デフォルトの名無しさん
2013/04/03(水) 00:18:11.89受信ソケットの話かルータのIPの話かわからないが破棄すればいいだろ。いないってなんだ。
0168デフォルトの名無しさん
2013/04/03(水) 00:35:39.78"1"というデータを送信、250msec待つ
次は"2"というデータを送信、待つ
…
という送信プログラムと、
特定のポートにアクセスしてデータを所得するプログラム
を書いてみたんだけど、送信プログラムをしばらく走らせてから受信プログラムを走らせても、
すでに消え去ったと思われる1というデータを取得してしまう。
0169デフォルトの名無しさん
2013/04/03(水) 00:40:59.53icmpで反応があることを期待してはいけない。
相手が生きているか死んでるかはっきりしないのが分散システムの基本。
0170デフォルトの名無しさん
2013/04/03(水) 01:06:41.67本当に受信者居ないの？
もしかしてパソコンの電源が入ってない？
0171デフォルトの名無しさん
2013/04/03(水) 11:19:05.08送信相手がいないと確定してるときって送信しないんだっけ？
UDPは気にせず送信しちゃうんじゃないの？
0172デフォルトの名無しさん
2013/04/03(水) 12:31:35.650173デフォルトの名無しさん
2013/04/03(水) 13:00:01.31気にせず送信すると思う。
>>172
プログラム側に問題があるのかな…
OS側のバッファのせいとしか思えない…
0174デフォルトの名無しさん
2013/04/03(水) 13:05:27.61捨てられるだけだよ
0175デフォルトの名無しさん
2013/04/03(水) 13:32:21.38試しに1じゃなくて送信時刻を送ってみては
0176デフォルトの名無しさん
2013/04/03(水) 14:19:03.340177デフォルトの名無しさん
2013/04/03(水) 19:24:47.39サンクス
5秒ほど遅れてた…
0178デフォルトの名無しさん
2013/04/03(水) 21:56:32.66受信プログラムを待機させている間にソケットにポート設定をしてたのが原因みたい
よくワカンネ
0179デフォルトの名無しさん
2013/04/04(木) 11:58:03.35ふざけんなよ！
＞送信プログラムをしばらく走らせてから受信プログラムを走らせ
って書いてたよな？ 適当なことを書きやがって
ポートをバインドした時点で受信は開始されます
カーネルにバッファされます
0180デフォルトの名無しさん
2013/04/04(木) 12:12:58.810181デフォルトの名無しさん
2013/04/04(木) 13:30:39.19死ねよおまえ
生きてる価値ねーよ
0182デフォルトの名無しさん
2013/04/04(木) 13:57:20.53なにが「よくワカンネ」だ
0183デフォルトの名無しさん
2013/04/04(木) 22:09:15.340185デフォルトの名無しさん
2013/05/13(月) 21:29:52.72ここ数年C#にどっぷりつかってたから、C++でコーディングするのが面倒だった。
実行環境のことを考えなくてよいなら、C#やJavaで作る方が簡単だな。
0186デフォルトの名無しさん
2013/05/13(月) 21:34:47.80Socket作るんだったらたぶんC#のほうが簡単そう。
0187デフォルトの名無しさん
2013/06/01(土) 23:20:34.89select(2)の第一引数には結局何を渡せば良いのん？
バークレーソケットの場合、FD_SETSIZEを渡しとけば機能的には問題無いらしいが、
これは例えばFD_SETSIZEが32768の環境なら、select()を呼ぶたびに
32768個のディスクリプタがチェックされることになるので無駄が生じている気がする…
あとWinsockではFD_SETした個数を渡せば良いというのは本当ですか
0188187
2013/06/01(土) 23:24:31.90ttp://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx
>nfds [in]
>Ignored. The nfds parameter is included only for compatibility with Berkeley sockets.
→ガン無視されるので0とか-1とか渡しても良い(適当)
バークレーソケットではどうなのですか
0189デフォルトの名無しさん
2013/06/01(土) 23:49:25.060190187
2013/06/02(日) 00:00:57.31レス㌧クス、
select(2)を呼ぶ時点でFD_SETされているのはソケット番号であってディスクリプタ番号ではなく、
ソケット番号がディスクリプタ番号と一致するとは限らないと思うのですが、それでも？
実はバークレーソケットでは一致するのでしょうか
（C標準ライブラリのIOBとかの実装と同じで、
ハンドル==配列の添え字、とする実装のが自然とは思えますが、仕様としてどうなの？）
0191デフォルトの名無しさん
2013/06/02(日) 00:15:20.65fdは全部数字。
「ソケット番号」という概念はない。
0192デフォルトの名無しさん
2013/06/02(日) 00:50:32.12レス㌧クス多分理解しました
バークレーソケットの場合は全部fdなので問題は無い、と、
ただ、サーバ側のプログラムでは、クライアントから新規接続cがあった場合、
listenしていたfdをaccept(2)に渡して接続c用の新規fdを取得する結果、
select(2)で待つべきfdが増殖していくと思うのですが、
ということは＜一番大きいfd+1 ＞というのはそのつど更新していくもの？
それとも、通信プロセスを起こすタイプのマルチスレッドサーバにすると問題無い（普通はそうする？）のでしょうか…
あと関連質問なのですが、
通信「スレッド」を起こすタイプのマルチスレッドサーバではどうすれば良いのでしょう…
子プロセスにfdを渡すのと異なり、親がfdを閉じるわけには行かない
しかし親だけがselect(2)するのでは通信「スレッド」を起こす意味がない
また、実情はともかく、仕様上はWinsockはスレッドセーフとは謳われていない
（Winsock互換の非スレッドセーフな実装が理論上は有り得る）
ので、どうプログラミングするのが正しいのかいまいちわからん…
0193デフォルトの名無しさん
2013/06/02(日) 03:49:28.43マルチスレッドサーバならselect(2)は使わなくていいでしょ。
いろいろな混合モデルもあるけど、最初は簡単なモデルで。
0194デフォルトの名無しさん
2013/06/02(日) 09:34:05.28mtuの値を取得してその値-フレーム分をreadするのでしょうか？
0195デフォルトの名無しさん
2013/06/02(日) 10:54:39.80ノンブロッキングモードにして適当に大きなサイズ (8KB とか 64 KB とか) で読めばいい
0196デフォルトの名無しさん
2013/06/03(月) 01:05:59.710197デフォルトの名無しさん
2013/06/03(月) 01:16:29.850198デフォルトの名無しさん
2013/06/03(月) 01:24:07.02ダウト
0199デフォルトの名無しさん
2013/06/03(月) 01:56:25.170200デフォルトの名無しさん
2013/06/03(月) 02:00:17.970201デフォルトの名無しさん
2013/06/03(月) 02:05:28.99しない
実験してみるといい
0202デフォルトの名無しさん
2013/06/03(月) 02:05:39.310203デフォルトの名無しさん
2013/06/03(月) 03:59:52.420204デフォルトの名無しさん
2013/06/03(月) 11:23:03.450205デフォルトの名無しさん
2013/06/03(月) 11:26:58.12受信データが1以上でバッファはデータ以上の大きさで読み込むと？
受信データが無いのに読み込むと？
0206デフォルトの名無しさん
2013/06/03(月) 11:33:03.050207デフォルトの名無しさん
2013/06/03(月) 11:41:45.210208デフォルトの名無しさん
2013/06/03(月) 12:12:09.020209デフォルトの名無しさん
2013/06/03(月) 23:50:05.470210192
2013/06/08(土) 23:51:12.09プロセスを起こすタイプのマルチスレッドサーバの現代版サンプル（他）↓
http://www.v6pc.jp/jp/upload/pdf/socket-sample-20121203.pdf
いとぢゅん氏が絡んでいたやつっぽいので多分信用に足る
で、Winsockにおいてプロセスにソケットを渡す方法↓
http://app.m-cocolog.jp/t/typecast/114340/102386/category/3335520
プロセスの終了を何の工夫も無くWaitForMultipreObjects()で待つと64プロセスが上限になるが、
そこはそれ、WaitForMultipreObjects()で64プロセス待つスレッドを64スレッド待つ、とかいう
多段構成が考えられる（いや知らんけど多分、
WinsockはGUIとの共存に適した非同期インタ──フェ──スも有するが、
とりあえずそこまでウィンドウズべったりにしなくとも、
select()かWsaPoll()だけでもマルチスレッドサ─バをなんとか構成できるのではないか（適当）
0211192
2013/06/09(日) 00:01:04.61socket()は平気でこれより大きいfd番号を返してくる
ていうか、現代のOSではLinuxだろうがWindowsだろうがFD_SETSIZEの制限に特に意味はなく、
FD_ISSET()の第一引数には 0..max{ socket()が返した値 } + 1 というの連番を与えるのではなくて、
socket()が返した数値（FD_SETSIZEより大きく成り得、かつ離散的）を配列かvectorにでもとっておいて、
その値を直接与えるのが正しいっぽい
上の現代版サンプルでもそうなっている（つまり>189のやり方は古い疑い有り）
0212デフォルトの名無しさん
2013/06/09(日) 07:07:01.750213デフォルトの名無しさん
2013/06/09(日) 07:21:28.43そこはそうだが、
http://x68000.q-e-d.net/~68user/net/c-echo-2.html
における
166: for ( i=0 ; i<FD_SETSIZE ; i++ ){
167: if ( FD_ISSET(i, &target_fds) ){
が、
http://www.v6pc.jp/jp/upload/pdf/socket-sample-20121203.pdf
の「複数の socket を生成するデュアルスタック対応サーバプログラム」では
for (i = 0; i < smax; i++) {
if (FD_ISSET(s[i], &rfd)) {
になってるねん（s[]にはsocket()が返した値が入っており、 smaxはs[]の要素数+1
0214デフォルトの名無しさん
2013/06/09(日) 09:30:05.98何を言いたいのか分からない
FD_SETSIZEを超えたらまずいというのならその通り。
下のURLの方は、
>> if (s[smax] >= FD_SETSIZE) {
でFD_SETSIZEを超えるものを除外してるから、
s[smax]がFD_SETSIZEを超えることはない
離散的だのベクターだのは意味不明
0215デフォルトの名無しさん
2013/06/09(日) 13:20:01.15話を込み入らせてしまって申し訳ないですが、
>> if (s[smax] >= FD_SETSIZE) {
これは少なくともWinsockでは不要ていうか、
>socket()は平気でこれ(FD_SETSIZE)より大きいfd番号を返してくる (211)
という事実があるので、削除して試した
実際、あるとgetaddrinfo()で列挙されたlisten可能ポート（うちの環境では
s[0] = 116, s[120]=120となった）が全てそのif文で除外され、
bind()やlisten()まで行き着かない。削除するとうまくいく（クライアントとつながり、"hello ::1"とか出る）
>FD_SETSIZEを超えたらまずいというのならその通り。
「何が」FD_SETSIZEを超えたらまずいのかいまいちどお考えいただきたい
FD_ISSET(a, b)の第一引数aが超えたらfd_set構造体をオーバーランするからまずい、というのが第一義だが、
しかし、>213の上のリンク先と、>213の下のリンク先では、第一引数に書かれている内容が異なるのですじゃ
0216215
2013/06/09(日) 13:22:58.77誤1： getaddrinfo()で列挙されたlisten可能ポート
正1： getaddrinfo()で列挙されたlisten可能ソケット
誤2: s[0] = 116, s[120]=120となった
正2: s[0] = 116, s[1]=120となった
0217214
2013/06/09(日) 17:26:56.22fd_set構造体をオーバーランしたらまずい、という理解で合ってる。
>>213 の上の引用と下の引用の第一引数は同じなので、何言ってるかわからない。
0218デフォルトの名無しさん
2013/06/09(日) 17:51:44.47> socket()が返した数値（FD_SETSIZEより大きく成り得、かつ離散的）を配列かvectorにでもとっておいて、
> その値を直接与えるのが正しいっぽい
> 上の現代版サンプルでもそうなっている（つまり>189のやり方は古い疑い有り）
根本的に理解してないな。
>>189と同じ事を言っておいて、古い疑いありとはw
仕様と仕様を満たすための実装方法の区別がつかない人みたい。
実装方法で考えないと仕様が理解できない。
0219デフォルトの名無しさん
2013/06/10(月) 11:24:49.530220デフォルトの名無しさん
2013/06/10(月) 11:30:49.490221デフォルトの名無しさん
2013/06/15(土) 12:03:09.61はいはい御託は>189をWinsockで動かしてから言ってね＆#9825;
BSDソケットでは、ファイルディスクリプタ番号がFD_SETを超えることは無いから>189のコードで良い
0～FD_SETまでの中に、必ずsocket()で作ったlisten中のソケットがある
Windsockでは違う
0222デフォルトの名無しさん
2013/06/15(土) 15:40:20.49> Windsock
ってのは, BSD ソケット API を Windows で実装したものって理解してたんだが違うのか?
つか,
> BSDソケットでは、ファイルディスクリプタ番号がFD_SETを超えることは無い
保証は何処にある?
0223デフォルトの名無しさん
2013/06/15(土) 15:58:13.05そんなもの使うのヤメレ
0224デフォルトの名無しさん
2013/06/15(土) 15:59:06.31しれっとウソつくなよ。>>221
0225デフォルトの名無しさん
2013/06/15(土) 16:46:01.43> > Windsock
> ってのは, BSD ソケット API を Windows で実装したものって理解してたんだが違うのか?
違う。似て非なるもの。意味不明の改変もある。
0226デフォルトの名無しさん
2013/06/15(土) 16:46:47.76>>221は馬鹿でよく分かってないので間違ったこと書くのは仕方ない。
0227デフォルトの名無しさん
2013/06/16(日) 12:00:56.260228デフォルトの名無しさん
2013/06/17(月) 12:46:20.671も2もどっちも嫌い
0229デフォルトの名無しさん
2013/06/23(日) 03:27:09.950230デフォルトの名無しさん
2013/07/03(水) NY:AN:NY.ANWinsockを使っています。
一度通信を終えた後に再度通信を行おうとすると、sendをacceptが認識してくれません。
bind,listen関数は正常に動作しています。
クライアント側は完全に再起動、サーバーはwhileで使いまわしています。
原因に心当たりのある人教えてください
0231デフォルトの名無しさん
2013/07/03(水) NY:AN:NY.AN認識するわけなかろう
0232230
2013/07/03(水) NY:AN:NY.AN済みません。仰る通りでした。
connectの戻り値は0でクライアント側は繋がっていると認識しているようです。
サーバー側を消すとエラーが出てくるので間違い無いと思います。
サーバー側はacceptを使っているスレッドを消していない時は２つ以上の接続であっても、上手く動作します。
クライアント側が再接続する場合もちゃんと動きます。
しかしスレッドを再起動した時には一つ目の接続から認識しません。
変数は毎回初期化しています。
0233デフォルトの名無しさん
2013/07/03(水) NY:AN:NY.AN状況がよくわからんな
0234デフォルトの名無しさん
2013/07/03(水) NY:AN:NY.AN0235デフォルトの名無しさん
2013/07/03(水) NY:AN:NY.ANちゃんとListenしなおしてる？
0236デフォルトの名無しさん
2013/07/04(木) NY:AN:NY.ANしっぱなしでいいだろ
いちいち再listenとかどこのBASICモドキだよ
0237デフォルトの名無しさん
2013/07/04(木) NY:AN:NY.ANaccept の戻りのソケットは 接続発生毎に別物だから
変な使いまわしからすると 「接続は受けた けど クライアントとの通信が出来てない」 ってなことになる
0238230
2013/07/05(金) NY:AN:NY.AN考えてみればlistenしっぱなしで良かったです；
設定を弄る時に排他処理が必要かと思い、止めようとしてました
>>234,5
再lisetn,closeはしていると思います。
>>237
有用な情報ありがとうございます！
以下のような処理をしてるので大丈夫だとは思いますが、調べてみます。
listen(--);
-初期化処理-
while(1){
dstSocket[id] = accept(----);
if(-1 != dstSocket[id]){
--------
id = DecideNewId();
}
}
0239デフォルトの名無しさん
2013/07/09(火) NY:AN:NY.AN全体に意味不明だから、もう少し勉強してから出直すほうがいいと思う
0240デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.ANそもそも肝心なところがどこか判ってるプログラマはむしろバグらない
0241デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.ANすべて駆逐したい
0242デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.AN0243デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.AN0244デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.ANネットワークを利用するアプリの質が極端に下がった
退化しまくり
0245デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.AN0246デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.AN結局ブラウザのバージョン依存で地獄とか同じ過ちを繰り返してるとしか
0247デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.AN0248デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.AN基本が一対一の通信なのに全体で同じデータを受け取れるのはむずかしくないですか?
0249デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.AN>>248
P2Pで全体ってどういう事を言ってるのかしらんが
全体で同じデータを受け取る必要はないだろ
0250デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.AN0251デフォルトの名無しさん
2013/07/10(水) NY:AN:NY.ANでも企業面接でhttpの質問のみで落とされますた
0252デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.AN0253デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.AN0254デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.AN難しくは無い。
全体に同じデータを送る必要があるなら、全体に同じデータを送るだけ。
非常に単純な話だよ。
0255デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.ANhttp://ascii.jp/elem/000/000/712/712158/
0256デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.ANtcp6に採用されるような論文書かないと説得力全くない。
特殊な状況でしか効率良くないプロトコルじゃあ...
0257デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.AN多対多の通信を想定したプロトコルなんだから
0258デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.AN0259デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.AN0260デフォルトの名無しさん
2013/07/11(木) NY:AN:NY.AN言ってることが明らかにおかしい
0261デフォルトの名無しさん
2013/07/12(金) NY:AN:NY.AN無手順だから早いってだけでハマらんようにね
0262デフォルトの名無しさん
2013/07/12(金) NY:AN:NY.AN0263デフォルトの名無しさん
2013/07/12(金) NY:AN:NY.AN0264デフォルトの名無しさん
2013/07/12(金) NY:AN:NY.ANクライアント-プライマリサーバからはHEARTBEAT
の送信・応答があるんだけど、セカンダリサーバの
ほうってプライマリからのハートビートインフォメーションに
乗せるんじゃなくてセカンダリサーバからHEARTBEAT
返すことってSOCKOPTのパラメタ設定とかで可能？
■ このスレッドは過去ログ倉庫に格納されています