ネットワークプログラミング相談室 Port24
■ このスレッドは過去ログ倉庫に格納されています
0001lmtp
2009/07/07(火) 00:46:28Programming 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/
0048デフォルトの名無しさん
2009/07/17(金) 12:07:05004941
2009/07/17(金) 14:39:57それも考えたのですが、接続が2本連続で来たとき
・listen()で待ち受け開始
・1本目接続
・2本目接続
・accept()で1本目
・listenポートをclose()
とすると2本目の人がかわいそうかなーって。
>>45
うまく動作すればcloseよりはスマートっぽいので試してみる
0050デフォルトの名無しさん
2009/07/17(金) 15:54:49http://msdn.microsoft.com/en-us/library/ms739168(VS.85).aspx
> If the listen function is called on an already listening socket,
> it will return success without changing the value for the backlog parameter.
> Setting the backlog parameter to 0 in a subsequent call to listen on a listening socket
> is not considered a proper reset, especially if there are connections on the socket.
0051デフォルトの名無しさん
2009/07/18(土) 03:43:110052デフォルトの名無しさん
2009/07/18(土) 19:41:200053デフォルトの名無しさん
2009/07/18(土) 19:57:12Windows じゃ、やろうとか思ったことないけど、相手側の事言ってるんだったら
accept() の返りとか, getpeername() とかで何とか何ないの?
# Winsock 中の getpeername の有無はしらん
0054デフォルトの名無しさん
2009/07/18(土) 20:14:270055デフォルトの名無しさん
2009/07/18(土) 20:28:110056デフォルトの名無しさん
2009/07/18(土) 21:10:38最近あちこちにいるぞ。
0057デフォルトの名無しさん
2009/07/18(土) 22:10:16005852
2009/07/18(土) 23:18:060059デフォルトの名無しさん
2009/07/19(日) 10:10:04C/C++の宿題片付けます 129代目
0060デフォルトの名無しさん
2009/07/19(日) 14:51:13strData
{
int Count;
int Param;
}
上記のような構造体を送信し、受信できるところまで確認したのですが、
文字列も送信したいと思っています。
strData
{
int Count;
int Param;
CString Text;
}
そこで上記のようにCStringデータを追加したのですが、
CString部のデータのみ正しく受信できません。（送信しできているかも怪しいです）
そもそも上記のようなCStringを含んだ構造体は送受信可能なのでしょうか？
0061デフォルトの名無しさん
2009/07/19(日) 14:56:19VCスレで聞いたほがいいんじゃない・・・
0062デフォルトの名無しさん
2009/07/19(日) 15:00:460063デフォルトの名無しさん
2009/07/19(日) 16:15:00構造体ってのはサイズが固定されてるという大前提がある形の定義で
固定されてるからこそ価値がある存在だから可変するような使い方は出来ない
その場合CStringのポインタが割り当てられるだけ
送信側のポインタを相手に渡しても相手には中身は分からない
006460
2009/07/19(日) 17:27:37CStringの本体を送信しているのではなく、ポインタを送信してる訳ですか。
可変長の文字列を送信する場合は構造体に含めず、別途送信する必要があるんですね。
解りやすいご回答ありがとうございました。
0065デフォルトの名無しさん
2009/07/19(日) 17:28:57まあおれのことだが
0066デフォルトの名無しさん
2009/07/20(月) 13:27:26サーバ用EXE, クライアント用EXEとか分けずに、一つのEXEで対応したい。
その場合、クライアントとして起動したEXEはまあいいとして、
サーバとして起動した場合、自分のデータはサーバに送る必要がないから云々と処理するよりも、
すなおにサーバソケットとクライアントソケット両方つくって、
サーバスレッドとクライアントスレッドを両方動かすほうがいいよね？
クライアントは常に127.0.0.1に接続する感じで、
「自分のデータをサーバに送信、サーバから結果をクライアントに送信」をひとつのEXE内ですませるような。
0067デフォルトの名無しさん
2009/07/20(月) 14:40:52詳しくはWSAAsyncSelectでｇｇｒ
0068デフォルトの名無しさん
2009/07/20(月) 14:58:58結局 WSAAsyncSelect とおなじこと。。だよね？
0069デフォルトの名無しさん
2009/07/20(月) 15:00:240070デフォルトの名無しさん
2009/07/20(月) 16:26:430071デフォルトの名無しさん
2009/07/20(月) 17:15:08telnetとか？
0072デフォルトの名無しさん
2009/07/21(火) 01:49:00（この関数は成功し、すぐに処理が戻ってくる）
サーバ用ソケットは別スレッドで作ってあって、そのスレッドの中で recv でずーっと待ってる
（関数から制御が戻ってこない状態）んだけど、
クライアントから send されたデータがいつまでたっても recv できないんです。
で、懲りずに何回かクライアントから send してると、1, 2秒ぐらいたってから思い出したように
全部まとめて recv するみたいなんですが、
そもそも同一マシン内で送受信しているのになぜここまで時間がかかるのでしょう？
なにか思い当たるフシはありますか？
0073デフォルトの名無しさん
2009/07/21(火) 02:24:030074デフォルトの名無しさん
2009/07/21(火) 08:32:53送信側で毎回PSHフラグを立てればいいと思う
http://support.microsoft.com/kb/411582/ja
0075デフォルトの名無しさん
2009/07/21(火) 14:25:07PSHフラグって、実際に転送されるパケットの中身を直接操作する必要がありますよね？？
どうやるのでしょう？それともフラグをたてるための関数が...?
0076デフォルトの名無しさん
2009/07/21(火) 17:00:13>>74のリンク先を途中でやめないで最後まで読むといいよ
0077デフォルトの名無しさん
2009/07/21(火) 17:02:350078デフォルトの名無しさん
2009/07/21(火) 17:37:22受信側の処理と送信側の処理は分けて考えないと。
レジストリの変更が必要なのは、PUSHフラグのないパケットを受信側でなんとかする場合。
送信側での遅れを減らすには setsockopt() で TCP_NODELAY をセットすればいいので
レジストリを変更する必要はない。
0079デフォルトの名無しさん
2009/07/22(水) 08:26:58フラグが何も入ってないデータ入りパケットもやってくる場合がある
って解釈でいいですか？
0080デフォルトの名無しさん
2009/07/22(水) 10:05:50SEGMENT ARRIVES に書いてあるだろ。
読みにくいなら状態遷移図起こせ。
0081デフォルトの名無しさん
2009/07/22(水) 10:59:15この用語の説明がなくてわけが判らなかった
テキスト＝データってことか
0082デフォルトの名無しさん
2009/07/22(水) 11:30:41ESTABLISHED後はフラグ無しデータパケットの受信を
「期待している」というのが適切な表現だと思う。
フラグ無しデータパケットというのは、
要はユーザデータ(socketとのsend/recvで渡されるデータ)のことね。
で、(closeを発行することで)FINフラグの立ったパケットを受信すると
コネクション解放手続きが始まると。
0083デフォルトの名無しさん
2009/07/22(水) 13:45:070084デフォルトの名無しさん
2009/07/22(水) 15:02:470085デフォルトの名無しさん
2009/07/23(木) 01:56:26疲れました
0086デフォルトの名無しさん
2009/07/23(木) 03:17:04種癌で言うとザフトの要塞にザフトカラーのメビウスが大量に押し寄せてくる感じ。
0087デフォルトの名無しさん
2009/07/23(木) 17:29:02別スレッドで close してもブロックしたままなんだけ
ど、これって select 介さないと駄目なんだっけ?
0088デフォルトの名無しさん
2009/07/23(木) 17:31:09どんなキーワードでぐぐったらいいのかな
mmo,fps,ネットワーク,ラグ,同期あたりでググってるんだけど
まともに見つかったのは↓くらいで・・
sourceエンジンのネットワークの資料らしい
ttp://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking:jp
0089デフォルトの名無しさん
2009/07/23(木) 18:12:23そのへんの仕様は知らないけど、自分宛にダミーのパケット送ってやれば
ブロッキング解除されるんじゃないか
0090デフォルトの名無しさん
2009/07/23(木) 18:16:36ということはモニタ変数みたいなのが必要なわけね…
0091デフォルトの名無しさん
2009/07/23(木) 18:25:09>別スレッドで close してもブロックしたままなんだけ
>ど、これって select 介さないと駄目なんだっけ?
volatile fd;
0092デフォルトの名無しさん
2009/07/23(木) 18:38:59blocking-recv から制御返って来てないのにそれ関係無いでしょ
009388
2009/07/23(木) 19:05:340094デフォルトの名無しさん
2009/07/23(木) 19:14:29volatileに何を期待してるんだ
0095デフォルトの名無しさん
2009/07/23(木) 19:17:06ntp
0096デフォルトの名無しさん
2009/07/23(木) 19:58:19マスタ・スレーブ(親子)の関係にあるのかな？
もしそうならマスタスレッドは(ソケットのcloseではなく)
単純にスレーブスレッドを殺せばいいんではないかと。
0097デフォルトの名無しさん
2009/07/23(木) 20:25:340098デフォルトの名無しさん
2009/07/23(木) 20:46:04質問の仕方が悪かった
今考えてるのはCSで
クライアント上の描画がなるべく自然に公平になるような
それでいて同期が取れているような仕組みがないものかなーと
例えば格ゲーで攻撃されたときにのけぞったりするけど
そのパケットが届くころには実際は攻撃された場所にはいなかったりで
とんでもないところでのけぞったりするわけで
こういうのはどういう仕組みで解消されてるのか説明されてるサイトなり
資料なりないものかと・・
0099デフォルトの名無しさん
2009/07/23(木) 20:50:290100デフォルトの名無しさん
2009/07/23(木) 20:58:32納得した。ありがとう
なんとかごまかしごまかしやってみる
0101デフォルトの名無しさん
2009/07/23(木) 21:02:43大抵は上手く動いてるように見える
pingが短くて大量に送りつけられるクライアントが有利なのは仕方が無い
0102デフォルトの名無しさん
2009/07/23(木) 21:25:16うまくいった。shutdown() 試したつもりだったけどバグってたわ(w
0103デフォルトの名無しさん
2009/07/23(木) 23:47:22以下のようにすると、全てのデータがクイラアントに届かないことがある。送るたびにデバッカーで止めると届くんだが、解決策がわからない。いい方法がないか教えてほしい。
//ほかのユニットがいることを伝える
foreach(KeyValuePair<string,Session> kv in _sessions)
{
if (kv.Value.socket.isconnected() == false || kv.Value.using_char == false) continue;
units.enumUnit(0, 0, _maps[str[1]].m.width, _maps[str[1]].m.height, (uid, u) =>
{
if (uid == kv.Value.player.id) return;
kv.Value.socket.send("SpawnUnit," + uid + "," + u.x + "," + u.y + "," + (int)u.dir + "," + (int)u.type + "," + u.sprite + "," + u.name + ";");
});
}
0104デフォルトの名無しさん
2009/07/24(金) 02:10:07全部の入力を見て、演算して送り返す頃には十分遅延している。
自分だけはリアルタイムで処理。周りは鯖経由で遅延した情報で処理で誤摩化すしか。
0105デフォルトの名無しさん
2009/07/24(金) 09:58:47socketのsendはすべてのデータを送るとは限らない。sendの戻りを確認すべし。
010688
2009/07/24(金) 10:17:00当たり判定自体はsourceエンジンのラグ補償の考え方を適用する
例えばAがBにスタンしたとすると
サーバー側がAとのレイテンシを考慮して
Aの画面でBへのスタンがちゃんと当たってるか計算する
これはレンテンシが一定の場合はBの位置情報を送ってるのがサーバーなので
正常に計算できるはず
で、問題なのはここからでBはどこでスタンすべきか。色々思いつくものを・・
①Aの画面でスタンしたBの位置（情報はAが送る）
②Aの画面でスタンしたBの位置（サーバー側で送った位置情報から取得）
③Aがスタンしたというパケットをサーバー側が受け取った時点のサーバーが保持するBの位置
④BがスタンされましたというパケットをBに送り、その時点の位置をBからサーバーに送ってもらう
⑤BがスタンされましたというパケットをBに送り、Bに届いたとサーバー側で推測される時点のBの位置
0107デフォルトの名無しさん
2009/07/24(金) 10:28:28また①～③はAの画面で激しくゴムヨーヨー現象やワープが起きるのでこれもあまりやりたくない
となると残りは⑤
⑤は分かりにくいのだが当たり判定自体は攻撃者のAの画面を優先し（ラグ補償）
位置情報自体は被攻撃者のBの画面を優先する。
デメリットはAから見てスタン後にすべること
サーバーからAへのレイテンシがta(ms)、Bへのレイテンシがtb(ms)だとする
⑤の方法はAの画面でスタンをぶちかました時点を0とすると
サーバーにその情報がたどり着くのがta（ここで当たり判定確定)
さらにBへ届くのがta+tb（Bの移動はここまで有効）
ta+tbまでのBの移動情報がサーバーに届くのがta+tb*2（この時点までサーバーはBの移動パケットを許容する）
さらにAにBの移動情報が届くのが(ta+tb)*2
このとき初めてBがスタンしたのをAは見ることができるが
BはAの画面でスタンを発動した位置からta+tbの間に動ける距離離れた場所でスタンする
まぁ・・なんてややこしんだろう
要するに当たり判定は攻撃者視点、位置情報は被攻撃者視点を優先した場合ってことで
ゲームによって優先すべきものが違うと思うが
今回のわたしのゲームはこれでやってみます
ping高いプレイヤーがいるとすべりまくるね。ワープしまくりとどっちがいいのか・・
0108デフォルトの名無しさん
2009/07/24(金) 10:50:02見たとこ、受信側も悪い
送ったデータはブツ切りで届くことがあるから、
1行の区切り文字が来るまでバッファに溜めておかないとだめ
0109デフォルトの名無しさん
2009/07/24(金) 12:46:14確認してみたのですが、全て送られてました。
0110デフォルトの名無しさん
2009/07/24(金) 12:53:11TCPなら 1回の send で送れた量 != 1回の recv で得られる量 なので
受信側はバッファリングして 終端記号や ヘッダ＋サイズ で切り出さないといけない
0111105
2009/07/24(金) 13:05:540112103
2009/07/24(金) 14:04:26ログをとってみたら、見事にまとめられていました。なので、受信する部分をこのようにしてみました。ですが、NPCの出現を10以上にするとでなくなります。
private void recive(string remoteip,byte[] bytes, int len)
{
string str = Encoding.Unicode.GetString(bytes,0,len);
//区切り文字まで届いてるか確認する
if (str.IndexOf(';') == -1)
return;
string[] line = str.Split(new string[] { ";" }, StringSplitOptions.RemoveEmptyEntries);
for (int i = 0; i < line.Length; i++)
{
string[] splitted = line[i].Split(new string[] { "," }, StringSplitOptions.None);
_scm.broadcastNotify(new object[] { ScreenRequst.RECEIVE_PACKET, splitted });
}
}
追記
アップしているほうも更新しておきました。URLは103と同じです。
0113デフォルトの名無しさん
2009/07/24(金) 14:10:52ｿｰｽ見てないけど
1回の受信で
[まとまり][まとまり][半端
もあるわけで、recve 後 "[半端" を次の recv 時に付け足す
FIFOﾊﾞｯﾌｧを想定しないとまずいんじゃないかな？
0114デフォルトの名無しさん
2009/07/24(金) 14:17:50区切り文字まで届いてないからって、そのデータを捨ててはいけない
どこかに取っておいて、次に来たデータと合わせて処理する (次は、前の続きからのデータしか来ない)
届いてた場合も、最後に残った半端な行は次に来るデータと合わせるために同じように取っておく
例えば "ABC", "DEF", "GHI" という3つのデータをsendしたとすると、
recv側は "ABC", "DEF", "GHI" と受け取るかもしれないが、
"AB", "CDEFG", "HI" と受け取るかもしれないし、
"ABCDE", "FGHI" と受け取るかもしれないし、
"A", "B", "C", "D", "E", "F", "G", "H", "I" と受け取るかもしれない
どこで分断・結合されても対処できるようにしないといけない
0115デフォルトの名無しさん
2009/07/24(金) 15:56:16ソース見てないけど、自分でrecv関数を操作するよりも、
C標準ライブラリのfdopenでソケットをFILE *にした後、
fgetsやfscanfで読み込んだ方が簡単にプログラミングできるよ。
改行コードが届くまで受信プロセスをブロックしてくれるから。
0116デフォルトの名無しさん
2009/07/24(金) 15:57:091536byteくらい？
0117デフォルトの名無しさん
2009/07/24(金) 16:45:21今のところはチマチマ考えず、ドッカーンと確保すればいい。
たとえば想定される「最大メッセージ長 * 2」を数kbyte単位で切り捨て。
4kbyte(4096byte)くらい用意しておけばいいんじゃね。
今回のは実験、演習、あるいはホビーのプログラミングなんでそ？
0118デフォルトの名無しさん
2009/07/24(金) 17:55:14おそらくネトゲを作ってるんだろうからブロッキングでは済まないんだと思われるよ。
0119デフォルトの名無しさん
2009/07/24(金) 19:23:59んー、確かにLAN内なら無問題だけど、Internet環境だと
パケット遅延があるから、>>115の方法だと、
1行を組立てる間に数百msのブロックが発生する可能性があるね。
格ゲーだったら大問題になる。
ただ、今はまずプログラムを「論理的に正しく動かす」ことが先じゃないかと。
想定される問題は忘れないように検討課題としてメモしてブロッキングの話は
(今は)置いておき、どんどん前進すべきじゃないかと思う。
後から(C標準ライブラリに代わる)非ブロッキング入力対応の論理に変更するのは、
状態「初期/組み立て中/完了」を持つステートマシンを設計すれば(設計できれば)
比較的容易に実装できるだろうし。(>>113の言うFIFOバッファの実装の事ね)
たぶん、ネトゲなら1プロセス内で各プレーヤを疑似マルチタスク
(今時の言葉ではファイバー(?))として実装させることになると思うから、
その時一緒に。
もちろんマルチスレッド構成で実装するのなら、各スレッドはブロックされても
かまわないわけだし。
0120デフォルトの名無しさん
2009/07/24(金) 21:32:19失念してました。
.NET Frameworkの非同期ソケットを使ってます。
0121115
2009/07/24(金) 23:10:29勝手にC言語だと思い込んでいました。あぁ恥ずかしや....。
こちらこそ失礼しました。
.NETは知識がありませんが、ソケットからデータを読み込み、
もし改行コードがあれば(1行分の組み立てが完了したなら)、
それを解読してメッセージ受信というイベントを
(プレーヤの?)タスクへ通知するという基本的な考え方は共通だと思います。
後は他の人にまかせて、漏れは落ちます。デハ、サラバ
0122デフォルトの名無しさん
2009/07/24(金) 23:42:56>>82
少なくともACKが入ってないと破棄対象になる。
0123デフォルトの名無しさん
2009/07/25(土) 00:52:01FINとかACKのパケット大量に送りつけるだけで沈黙しそうだが。
0124デフォルトの名無しさん
2009/07/28(火) 17:58:30UDPで大きなデータグラムが送られてくるとき、
recvfrom側では分割受信することはできないのでしょうか？
たとえば、3000バイトのデータグラムを受信するのに、
100バイトのバッファで全データを受信したいのですが
GetLastError()では234(0xea データがさらにあります。 )となってしまい、
続けてrecvfromを行うとブロックしてしまいます。
0125デフォルトの名無しさん
2009/07/28(火) 18:03:27全体を格納できるバッファを用意するしかない。
はみでた分は捨てられる。
続けて行うとブロックするのは次のデータグラムを待ってるだけ。
0126デフォルトの名無しさん
2009/07/28(火) 19:18:22最大の大きさが分かってるんだから、分割する必要は無い。
普通のetherのパケットだと1500バイトくらいまでしか送れないよ。
0127デフォルトの名無しさん
2009/07/28(火) 19:26:030128デフォルトの名無しさん
2009/07/28(火) 19:35:13ありがとうございます。
UDPは送られてくるパケットが到達しないことがあるという前提に乗っかって、
GetLastError()で234がきたら、そのパケットは無視してバッファを倍増する
みたいな実装はスマートじゃないですよね？
どんな実装をするのが良いのでしょうか。やっぱりTCPですか？
0129デフォルトの名無しさん
2009/07/28(火) 19:45:39UDPということだから一切受けないという方法もある
0130デフォルトの名無しさん
2009/07/28(火) 19:53:37いえ、実際にはsendが50kbくらいで、recvが10kb程度を想定してました。
バッファをスタックにとっていたのでサイズを気にしていたのですが、他ではあまりスタックを使わないので大して意味のないこだわりだと思います。
0131デフォルトの名無しさん
2009/07/28(火) 20:20:14受信バッファサイズとパケットの(必ず相手に届くという)送達保証とは
別々に検討しなさい。
ユーザデータ長がEthenetフレーム(>>126が言うように1KBちょっと)を
越えるようであれば、(UDPではなく)TCPを使うのが定石。
もし(組み込み機器などで)リソースに制限があり、TCPドライバが
実装できないためにUDPを使用せざるをえない場合には、
(UDPの上位にある)アプリケーション層で送達確認機能を実装する。
具体的にはTFTPが参考になる。(もちろん受信バッファサイズは固定。)
でもWindowsなんでしょ？であれば素直にTCPで設計しなさい。
0132デフォルトの名無しさん
2009/07/28(火) 21:15:39＞普通のetherのパケットだと1500バイトくらいまでしか送れないよ。
んな訳あるかい。df立てない限りフラグメントされる。
0133デフォルトの名無しさん
2009/07/28(火) 23:39:110134デフォルトの名無しさん
2009/07/28(火) 23:42:580135デフォルトの名無しさん
2009/07/29(水) 03:42:52ADSLとか非力NASとか。
0136デフォルトの名無しさん
2009/07/29(水) 03:54:36んな訳あるかい
0137デフォルトの名無しさん
2009/07/29(水) 09:12:15フラグメントがどのレイヤで発生するのか、勉強し直せ。
0138デフォルトの名無しさん
2009/07/29(水) 10:14:200139デフォルトの名無しさん
2009/07/29(水) 19:41:39サーバ側マシン命令を送って（例えば move とか）
サーバ側マシン上においてOpenGLで描画されている3DCGを動かす
プログラムを作りたいと思っています。
この場合，サーバ側は，マルチスレッドにするしか方法はないのでしょうか？
クライアントから命令がくる→OpenGLに反映
はマルチスレッドじゃないとむりぽ！？
えろいひと、よろしくおねがいします。
0140デフォルトの名無しさん
2009/07/29(水) 19:49:25OpenGLをマルチスレッドで動かすほうが面倒じゃね？
0141デフォルトの名無しさん
2009/07/29(水) 20:00:35シングルプロセス/シングルスレッド構成でも実現できると思うが、
想定している言語(C/C++/Java/Ruby/ObjC)や
プラットフォーム(Win/Linux/MacOSX)を明記してくれないと
アドバイスのしようがない。
0142デフォルトの名無しさん
2009/07/29(水) 20:04:58早速のご回答ありがとうございます。
iPhone上のOpenGL ESで描いたCGを母艦マシン(MacOSX)から
操りたいと考えています。
そのため，仕様言語はObjective-Cになります。
スレッド・プロセスまわりの話しに詳しくないので
何が最適なのか戸惑っています。
もうしわけありませんが、ご教示いただければ幸いです。
0143デフォルトの名無しさん
2009/07/29(水) 20:05:25結局は何もつくれないに一票
0144デフォルトの名無しさん
2009/07/29(水) 20:18:56Rubyがお勧め。標準でdRuby(分散オブジェクト)があるし、
OpenGLはRuby-GNOME2で実装されている。
プロジェクトが構想段階なら検討してみては？
0145デフォルトの名無しさん
2009/07/29(水) 20:28:470147デフォルトの名無しさん
2009/07/29(水) 20:55:45■ このスレッドは過去ログ倉庫に格納されています