1001コメント360KB

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

■ このスレッドは過去ログ倉庫に格納されています

0001lmtp

2009/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/

0075デフォルトの名無しさん

2009/07/21(火) 14:25:07

TCP_NODELAYなんてフラグがあったんですね　試してみます。

PSHフラグって、実際に転送されるパケットの中身を直接操作する必要がありますよね？？
どうやるのでしょう？それともフラグをたてるための関数が...?

0076デフォルトの名無しさん

2009/07/21(火) 17:00:13

>>75
>>74のリンク先を途中でやめないで最後まで読むといいよ

0077デフォルトの名無しさん

2009/07/21(火) 17:02:35

あ、レジストリ変更しないとダメなんですね.... どうもありがとう！

0078デフォルトの名無しさん

2009/07/21(火) 17:37:22

>>77
受信側の処理と送信側の処理は分けて考えないと。

レジストリの変更が必要なのは、PUSHフラグのないパケットを受信側でなんとかする場合。
送信側での遅れを減らすには setsockopt() で TCP_NODELAY をセットすればいいので
レジストリを変更する必要はない。

0079デフォルトの名無しさん

2009/07/22(水) 08:26:58

TCPのRFC793読んでるんですが、ESTABLISHED後は、
フラグが何も入ってないデータ入りパケットもやってくる場合がある
って解釈でいいですか？

0080デフォルトの名無しさん

2009/07/22(水) 10:05:50

>>79
SEGMENT ARRIVES に書いてあるだろ。
読みにくいなら状態遷移図起こせ。

0081デフォルトの名無しさん

2009/07/22(水) 10:59:15

segment text(訳の方もセグメントテキスト)ってのがそうなんでしょうか？
この用語の説明がなくてわけが判らなかった
テキスト＝データってことか

0082デフォルトの名無しさん

2009/07/22(水) 11:30:41

>>79
ESTABLISHED後はフラグ無しデータパケットの受信を
「期待している」というのが適切な表現だと思う。

フラグ無しデータパケットというのは、
要はユーザデータ(socketとのsend/recvで渡されるデータ)のことね。
で、(closeを発行することで)FINフラグの立ったパケットを受信すると
コネクション解放手続きが始まると。

0083デフォルトの名無しさん

2009/07/22(水) 13:45:07

誰か>>82をガンダムでたとえてくれ

0084デフォルトの名無しさん

2009/07/22(水) 15:02:47

http://takeshima.2ch.net/test/read.cgi/news4vip/1248238158/l50

0085デフォルトの名無しさん

2009/07/23(木) 01:56:26

一応正常系はできた気がする
疲れました

0086デフォルトの名無しさん

2009/07/23(木) 03:17:04

FINフラグ付きパケットを大量に送りつける攻撃も有るぉ。
種癌で言うとザフトの要塞にザフトカラーのメビウスが大量に押し寄せてくる感じ。

0087デフォルトの名無しさん

2009/07/23(木) 17:29:02

FreeBSD で、UDP で blocking-recv してるソケットを
別スレッドで close してもブロックしたままなんだけ
ど、これって select 介さないと駄目なんだっけ?

0088デフォルトの名無しさん

2009/07/23(木) 17:31:09

FPSや格ゲーのネットワークの同期に関する資料って
どんなキーワードでぐぐったらいいのかな
mmo,fps,ネットワーク,ラグ,同期あたりでググってるんだけど
まともに見つかったのは↓くらいで・・

sourceエンジンのネットワークの資料らしい
ttp://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking:jp

0089デフォルトの名無しさん

2009/07/23(木) 18:12:23

>>87
そのへんの仕様は知らないけど、自分宛にダミーのパケット送ってやれば
ブロッキング解除されるんじゃないか

0090デフォルトの名無しさん

2009/07/23(木) 18:16:36

>>89
ということはモニタ変数みたいなのが必要なわけね…

0091デフォルトの名無しさん

2009/07/23(木) 18:25:09

>FreeBSD で、UDP で blocking-recv してるソケットを
>別スレッドで close してもブロックしたままなんだけ
>ど、これって select 介さないと駄目なんだっけ?

volatile fd;

0092デフォルトの名無しさん

2009/07/23(木) 18:38:59

>>91
blocking-recv から制御返って来てないのにそれ関係無いでしょ

009388

2009/07/23(木) 19:05:34

誰かしらんかなぁ・・・格ゲーとかどうやってんだろ

0094デフォルトの名無しさん

2009/07/23(木) 19:14:29

>>91
volatileに何を期待してるんだ

0095デフォルトの名無しさん

2009/07/23(木) 19:17:06

>>88
ntp

0096デフォルトの名無しさん

2009/07/23(木) 19:58:19

closeするスレッドとreceive-blockingしてるスレッドは
マスタ・スレーブ(親子)の関係にあるのかな？
もしそうならマスタスレッドは(ソケットのcloseではなく)
単純にスレーブスレッドを殺せばいいんではないかと。

0097デフォルトの名無しさん

2009/07/23(木) 20:25:34

多分、shutdown(s, SHUT_RD)で所望の動作が得られる。

0098デフォルトの名無しさん

2009/07/23(木) 20:46:04

>>95
質問の仕方が悪かった

今考えてるのはCSで
クライアント上の描画がなるべく自然に公平になるような
それでいて同期が取れているような仕組みがないものかなーと

例えば格ゲーで攻撃されたときにのけぞったりするけど
そのパケットが届くころには実際は攻撃された場所にはいなかったりで
とんでもないところでのけぞったりするわけで
こういうのはどういう仕組みで解消されてるのか説明されてるサイトなり
資料なりないものかと・・

0099デフォルトの名無しさん

2009/07/23(木) 20:50:29

解消されてない

0100デフォルトの名無しさん

2009/07/23(木) 20:58:32

>>99
納得した。ありがとう
なんとかごまかしごまかしやってみる

0101デフォルトの名無しさん

2009/07/23(木) 21:02:43

サーバに届いた時間と移動ベクトルとで予測時間で処理すれば
大抵は上手く動いてるように見える
pingが短くて大量に送りつけられるクライアントが有利なのは仕方が無い

0102デフォルトの名無しさん

2009/07/23(木) 21:25:16

>>97
うまくいった。shutdown() 試したつもりだったけどバグってたわ(w

0103デフォルトの名無しさん

2009/07/23(木) 23:47:22

http://www10.ocn.ne.jp/~mitinoie/RPGProject.zip

以下のようにすると、全てのデータがクイラアントに届かないことがある。送るたびにデバッカーで止めると届くんだが、解決策がわからない。いい方法がないか教えてほしい。

//ほかのユニットがいることを伝える
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:47

>>103
socketの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

>>103
見たとこ、受信側も悪い
送ったデータはブツ切りで届くことがあるから、
1行の区切り文字が来るまでバッファに溜めておかないとだめ

0109デフォルトの名無しさん

2009/07/24(金) 12:46:14

>>105
確認してみたのですが、全て送られてました。

0110デフォルトの名無しさん

2009/07/24(金) 12:53:11

108 の言うように
TCPなら　1回の send で送れた量 != 1回の recv で得られる量　なので
受信側はバッファリングして　終端記号や　ヘッダ＋サイズ　で切り出さないといけない

0111105

2009/07/24(金) 13:05:54

だったら、デバッグ実行でＯＫなところから見て、複数のsendがRecvでまとめられてる可能性もあるね。丁度、>>108と反対の現象もおきる。

0112103

2009/07/24(金) 14:04:26

>>111
ログをとってみたら、見事にまとめられていました。なので、受信する部分をこのようにしてみました。ですが、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

>>112
ｿｰｽ見てないけど
1回の受信で
　[まとまり][まとまり][半端
もあるわけで、recve 後 "[半端" を次の recv 時に付け足す
FIFOﾊﾞｯﾌｧを想定しないとまずいんじゃないかな？

0114デフォルトの名無しさん

2009/07/24(金) 14:17:50

>>112
区切り文字まで届いてないからって、そのデータを捨ててはいけない
どこかに取っておいて、次に来たデータと合わせて処理する (次は、前の続きからのデータしか来ない)
届いてた場合も、最後に残った半端な行は次に来るデータと合わせるために同じように取っておく

例えば "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

>>112
ソース見てないけど、自分でrecv関数を操作するよりも、
C標準ライブラリのfdopenでソケットをFILE *にした後、
fgetsやfscanfで読み込んだ方が簡単にプログラミングできるよ。
改行コードが届くまで受信プロセスをブロックしてくれるから。

0116デフォルトの名無しさん

2009/07/24(金) 15:57:09

バッファのサイズはどれくらいが適当ですか？
1536byteくらい？

0117デフォルトの名無しさん

2009/07/24(金) 16:45:21

>>116
今のところはチマチマ考えず、ドッカーンと確保すればいい。
たとえば想定される「最大メッセージ長 * 2」を数kbyte単位で切り捨て。
4kbyte(4096byte)くらい用意しておけばいいんじゃね。

今回のは実験、演習、あるいはホビーのプログラミングなんでそ？

0118デフォルトの名無しさん

2009/07/24(金) 17:55:14

>>115
おそらくネトゲを作ってるんだろうからブロッキングでは済まないんだと思われるよ。

0119デフォルトの名無しさん

2009/07/24(金) 19:23:59

>>118
んー、確かにLAN内なら無問題だけど、Internet環境だと
パケット遅延があるから、>>115の方法だと、
1行を組立てる間に数百msのブロックが発生する可能性があるね。
格ゲーだったら大問題になる。

ただ、今はまずプログラムを「論理的に正しく動かす」ことが先じゃないかと。
想定される問題は忘れないように検討課題としてメモしてブロッキングの話は
(今は)置いておき、どんどん前進すべきじゃないかと思う。

後から(C標準ライブラリに代わる)非ブロッキング入力対応の論理に変更するのは、
状態「初期/組み立て中/完了」を持つステートマシンを設計すれば(設計できれば)
比較的容易に実装できるだろうし。(>>113の言うFIFOバッファの実装の事ね)
たぶん、ネトゲなら1プロセス内で各プレーヤを疑似マルチタスク
(今時の言葉ではファイバー(?))として実装させることになると思うから、
その時一緒に。

もちろんマルチスレッド構成で実装するのなら、各スレッドはブロックされても
かまわないわけだし。

0120デフォルトの名無しさん

2009/07/24(金) 21:32:19

>>115
失念してました。
.NET Frameworkの非同期ソケットを使ってます。

0121115

2009/07/24(金) 23:10:29

そう言われて>>103,112を見たら、明らかにCじゃありません。
勝手にC言語だと思い込んでいました。あぁ恥ずかしや....。
こちらこそ失礼しました。

.NETは知識がありませんが、ソケットからデータを読み込み、
もし改行コードがあれば(1行分の組み立てが完了したなら)、
それを解読してメッセージ受信というイベントを
(プレーヤの?)タスクへ通知するという基本的な考え方は共通だと思います。

後は他の人にまかせて、漏れは落ちます。デハ、サラバ

0122デフォルトの名無しさん

2009/07/24(金) 23:42:56

今更だけど、
>>82
少なくともACKが入ってないと破棄対象になる。

0123デフォルトの名無しさん

2009/07/25(土) 00:52:01

このネトゲで不正をやらかすにはどうすれば良いか考えたほうが楽しそうだ。
FINとかACKのパケット大量に送りつけるだけで沈黙しそうだが。

0124デフォルトの名無しさん

2009/07/28(火) 17:58:30

Winsock2を使っています。
UDPで大きなデータグラムが送られてくるとき、
recvfrom側では分割受信することはできないのでしょうか？
たとえば、3000バイトのデータグラムを受信するのに、
100バイトのバッファで全データを受信したいのですが

GetLastError()では234(0xea データがさらにあります。 )となってしまい、
続けてrecvfromを行うとブロックしてしまいます。

0125デフォルトの名無しさん

2009/07/28(火) 18:03:27

できません。
全体を格納できるバッファを用意するしかない。
はみでた分は捨てられる。
続けて行うとブロックするのは次のデータグラムを待ってるだけ。

0126デフォルトの名無しさん

2009/07/28(火) 19:18:22

>>124
最大の大きさが分かってるんだから、分割する必要は無い。
普通のetherのパケットだと1500バイトくらいまでしか送れないよ。

0127デフォルトの名無しさん

2009/07/28(火) 19:26:03

V6でも?

0128デフォルトの名無しさん

2009/07/28(火) 19:35:13

>>125-126
ありがとうございます。
UDPは送られてくるパケットが到達しないことがあるという前提に乗っかって、
GetLastError()で234がきたら、そのパケットは無視してバッファを倍増する
みたいな実装はスマートじゃないですよね？
どんな実装をするのが良いのでしょうか。やっぱりTCPですか？

0129デフォルトの名無しさん

2009/07/28(火) 19:45:39

窓のくせになんでそんなバッファけちるわけ？
UDPということだから一切受けないという方法もある

0130デフォルトの名無しさん

2009/07/28(火) 19:53:37

>>129
いえ、実際にはsendが50kbくらいで、recvが10kb程度を想定してました。
バッファをスタックにとっていたのでサイズを気にしていたのですが、他ではあまりスタックを使わないので大して意味のないこだわりだと思います。

0131デフォルトの名無しさん

2009/07/28(火) 20:20:14

>>128
受信バッファサイズとパケットの(必ず相手に届くという)送達保証とは
別々に検討しなさい。

ユーザデータ長がEthenetフレーム(>>126が言うように1KBちょっと)を
越えるようであれば、(UDPではなく)TCPを使うのが定石。

もし(組み込み機器などで)リソースに制限があり、TCPドライバが
実装できないためにUDPを使用せざるをえない場合には、
(UDPの上位にある)アプリケーション層で送達確認機能を実装する。
具体的にはTFTPが参考になる。(もちろん受信バッファサイズは固定。)

でもWindowsなんでしょ？であれば素直にTCPで設計しなさい。

0132デフォルトの名無しさん

2009/07/28(火) 21:15:39

>>126
＞普通のetherのパケットだと1500バイトくらいまでしか送れないよ。

んな訳あるかい。df立てない限りフラグメントされる。

0133デフォルトの名無しさん

2009/07/28(火) 23:39:11

>>132 MTU変更を要求するアプリってかなり我侭だろ。

0134デフォルトの名無しさん

2009/07/28(火) 23:42:58

MTU変える必要ないだろ。

0135デフォルトの名無しさん

2009/07/29(水) 03:42:52

変えちゃってるユーザも多いから、動作しないと困るかもね。
ADSLとか非力NASとか。

0136デフォルトの名無しさん

2009/07/29(水) 03:54:36

>>133
んな訳あるかい

0137デフォルトの名無しさん

2009/07/29(水) 09:12:15

>>133
フラグメントがどのレイヤで発生するのか、勉強し直せ。

0138デフォルトの名無しさん

2009/07/29(水) 10:14:20

ビッグパケットとか想定してもしょうがないしなあ

0139デフォルトの名無しさん

2009/07/29(水) 19:41:39

クライアント側のマシンからネットワーク越し(TCPを想定)に
サーバ側マシン命令を送って（例えば move とか）
サーバ側マシン上においてOpenGLで描画されている3DCGを動かす
プログラムを作りたいと思っています。

この場合，サーバ側は，マルチスレッドにするしか方法はないのでしょうか？
クライアントから命令がくる→OpenGLに反映
はマルチスレッドじゃないとむりぽ！？

えろいひと、よろしくおねがいします。

0140デフォルトの名無しさん

2009/07/29(水) 19:49:25

別にマルチスレッドじゃなくてもいいと思うけど、
OpenGLをマルチスレッドで動かすほうが面倒じゃね？

0141デフォルトの名無しさん

2009/07/29(水) 20:00:35

>>139
シングルプロセス/シングルスレッド構成でも実現できると思うが、
想定している言語(C/C++/Java/Ruby/ObjC)や
プラットフォーム(Win/Linux/MacOSX)を明記してくれないと
アドバイスのしようがない。

0142デフォルトの名無しさん

2009/07/29(水) 20:04:58

>>140, >>141
早速のご回答ありがとうございます。

iPhone上のOpenGL ESで描いたCGを母艦マシン(MacOSX)から
操りたいと考えています。
そのため，仕様言語はObjective-Cになります。

スレッド・プロセスまわりの話しに詳しくないので
何が最適なのか戸惑っています。

もうしわけありませんが、ご教示いただければ幸いです。

0143デフォルトの名無しさん

2009/07/29(水) 20:05:25

>>141
結局は何もつくれないに一票

0144デフォルトの名無しさん

2009/07/29(水) 20:18:56

もしUNIX系(Linux/MacOSX)でプロトタイピングを作成するのであれば、
Rubyがお勧め。標準でdRuby(分散オブジェクト)があるし、
OpenGLはRuby-GNOME2で実装されている。
プロジェクトが構想段階なら検討してみては？

0145デフォルトの名無しさん

2009/07/29(水) 20:28:47

iPhoneでRubyは動かないんじゃね？

0146144

2009/07/29(水) 20:55:34

>>145
リロードしてなかった....orz

0147デフォルトの名無しさん

2009/07/29(水) 20:55:45

Pythonがお勧め。

0148デフォルトの名無しさん

2009/07/29(水) 22:03:03

>>142
iPhone向けの開発経験は無いけどReference Libraryを漁ってみた。

まずNSProx/NSConnectionで分散オブジェクトが簡単だろうと思ったが、
iPhoneOSのFoundation FrameworkにはNSConnectionクラスが見当たらない。
次にCFNetwork(Core Foundation)にはHTTP/FTP/Web Service向けのクラスは
存在するけど、どれもクライアント側のプロトコルしか実装されていない。

結論として、直にTCPソケット(CFStream)を操作して独自のプロトコルを
実装するしかないと判断する。(TCPコネクション確立はiPhone側から開始)
送受信メッセージのエンコーディングには、PropertyListを利用するのが
良いと思われる。(想定転送データ量によってバイナリ/XML形式の選択を決断)

で、最終的に質問のマルチスレッディングの要否についてだけど、
run loopにコールバック関数を登録する事で非同期I/Oが実現できるから、
結論として「マルチスレッディング無しで実装可能」と判断する。
iPhone Reference Libraryにある文書"CFNetwork Programming Guide"の
章"Preventing Blocking When Working with Streams"を参照してみてください。

実際に試した訳ではないので(すべて推測なので)、間違ってたらゴメソ

0149139

2009/07/29(水) 22:37:08

みなさまご回答ありがとうございます！

>>148
ここまで調べて頂きありがとうございます！
やってみます。

0150148

2009/07/29(水) 23:23:04

あと全体のアーキテクチャ設計について助言すると、
MacをクライアントそしてiPhoneをOpenGL表示サーバと位置づけ、
メッセージの対話形態としては「要求/応答/通知」方式にするのが良いと思う。
具体的には、Mac上のアプリケーションが表示メソッドを呼び出すと、
要求メッセージが送信され、iPhone上の表示サーバで要求された描画処理が
完了すると応答メッセージを返信する。またiPhone側からアプリケーションへ
イベントを発行したい場合(たとえば処理中断ボタンがタップされた)には、
通知メッセージを送信する。

おそらくX-Window Systemのコアプロトコルが参考になる。
意外にもWikipediaの文書が充実しているので、一読を勧めます。

ttp://ja.wikipedia.org/wiki/X_Window_System_コアプロトコル

RPCと分散オブジェクトを(Foundation Framework無しに)自力で実装する
わけですから、もしも汎用的な「リモートOpenGL表示システム」の設計を
目指すとしたら、かなり大変な作業になると思います。
でも、がんばって挑戦してみてください！！

0151デフォルトの名無しさん

2009/07/30(木) 11:51:42

「C言語で２ｃｈに書き込みたいのですが」からやってきたんですが、
2chに書き込めない原因がわかりません。誰か手伝ってくれますか？

http://www1.axfc.net/uploader/Sc/so/22688.zip

0152デフォルトの名無しさん

2009/07/30(木) 12:36:02

0153デフォルトの名無しさん

2009/07/30(木) 12:45:04

　　　　ヾミ || || || || || || || ,l,,l,,l 川〃彡|
　　　　　V~~''-山┴''''""~ 　　ヾニﾆ彡|　　　　　　　手伝う・・・・・・！
　　　　 /　二ー―''二　　　　　ヾﾆニ┤　　　　　　手伝うが・・・
　　　 <'-.,　　￣￣　　 _,,,..-‐､　〉ニﾆ|　　　　　　　今回　まだ　その時と場所の
　　　/"''-ﾆ,‐l 　　l`__ニ-‐'''""` /ニ二|　　　　　　　指定まではしていない
　　　|　==＝､!　　`＝====､　　l =ｌべ=|
.　　　| `ーﾟ‐'/　　 `ー‐ﾟ―' 　　l.=lへ|~|　　　　　　　そのことを
　　　 |`ー‐/　　　　`ー――　　H<,〉|=|　　　　　　　どうか諸君らも
　　　 |　　/　　　､　　　　　　 l|__ノｰ|　　　　　　　思い出していただきたい
.　　　| ／`ー　~　′　　＼　　　.|ヾ.ニ|ヽ
　　　 |ｌ　下王l王l王l王lヲ｜　　|　ヾ_,|　＼　　　　　つまり・・・・
. 　　 |　　　　≡　　　　　　　　　|　　 `l　　＼__　　　我々がその気になれば
　　　　!、　　　　　　　　　　 _,,..-'′ ／l　　　 |　~'''　そのzipを開くのが
‐''"￣|　`iｰ-..,,,＿,,,,,....-‐'''"　　／　 |　　　 |　　　 10年後　2chが無くなってからということも
　-―|　　|＼　　　　　　　　　／　　 |　　　　 |　　　可能だろう・・・・・・・・・・ということ・・・・！

0154デフォルトの名無しさん

2009/07/30(木) 12:52:01

まずクッキーの終わりに改行？

0155デフォルトの名無しさん

2009/07/30(木) 12:55:12

>>154
無かったね。218行目と357行目付近にWriteSz("\r\n");を追加。

0156デフォルトの名無しさん

2009/07/30(木) 13:30:43

for(it++; it != cookie.end(); it++)
{
wsprintf(buf, "; %s=%s", it->first.c_str(),
url_escape(it->second).c_str());
WriteSz(buf);
}

これって cookie.end() にもデータはあるんだろ？

do
{
・・・処理・・・
}while(it != cookie.end()); じゃね？

0157デフォルトの名無しさん

2009/07/30(木) 13:37:09

map::end()にはデータはないよ。
http://www.cplusplus.com/reference/stl/map/end/

0158デフォルトの名無しさん

2009/07/30(木) 13:40:09

そうか、じゃあ>>156はなしで

0159デフォルトの名無しさん

2009/07/30(木) 14:32:19

とりあえず、>>155とクッキーのパラメータのとこのurl_escapeを外したら書けるみたいよ

0160デフォルトの名無しさん

2009/07/30(木) 14:34:07

あーあとNAMEとMAILのクッキー書いてるの外したわ

0161デフォルトの名無しさん

2009/07/30(木) 14:35:19

まあ時間制限で書けなかったみたいだし関係ないとは思うが

0162デフォルトの名無しさん

2009/07/30(木) 16:06:02

おれが153のAA貼ったとたん優しくなりやがって
天邪鬼どもが

0163デフォルトの名無しさん

2009/07/30(木) 16:16:41

>>159-160
アップしてくれ

0164デフォルトの名無しさん

2009/07/30(木) 16:23:55

age

0165デフォルトの名無しさん

2009/07/30(木) 16:25:02

>>163
何でやねん、数行しか変わってないがな。
うまくいかんのならそう書けば。
そうそう、pc11.2ch.net を pc12.2ch.netに変えたりもしたけど。

0166デフォルトの名無しさん

2009/07/30(木) 16:43:23

馬鹿に凶器持たせるようなことすんなよ・・・

0167デフォルトの名無しさん

2009/07/30(木) 23:04:22

select() を使って recv() すると WSAEWOULDBLOCK って出ないはずですよね？

0168デフォルトの名無しさん

2009/07/30(木) 23:15:36

>>167
非同期系ではそういう幻想を持たないほうがいい。

0169デフォルトの名無しさん

2009/07/30(木) 23:20:34

>>168
そうなんですか。あるんですか。。
デバッグ中にブロックされていないはずの recv() が WSAEWOULDBLOCK を
返すところを見ちゃった気がするのですが気のせいだと思ってました。　orz

0170デフォルトの名無しさん

2009/07/30(木) 23:45:35

届いてたけど拾いにこないから捨てちゃったとか？
通常ありえないよ。
デバッガで止めてたからとか。

0171デフォルトの名無しさん

2009/07/31(金) 00:45:32

>>169
戻りを確認するifを入れて実際に起きるかどうか確認すればいい。

0172デフォルトの名無しさん

2009/07/31(金) 11:25:21

>>165
「ＥＲＲＯＲ：ブラウザを立ち上げなおしてみてください。」
て出てきてできなかった。

http://www1.axfc.net/uploader/Sc/so/23023.zip

0173デフォルトの名無しさん

2009/07/31(金) 22:26:18

>>170-171
確かにデバッガで止めてはいたのですが。。
色々調べてみるとWin9x系では起きるがNT系では起きないとか
select()はブロックされない事を完全には保証しないとか。

サンプルプログラム等をみるとselect()は非ブロックキングソケットを
使うのが前提となっているみたいですな。
ブロッキングされないのが保証されるのならブロッキングソケットでも
問題ないはずですが。

0174デフォルトの名無しさん

2009/07/31(金) 22:32:30

ブロッキングだからこそselect必須。
ブロックされないのが保証できないなら、インターネット動いてねーわ。

■ このスレッドは過去ログ倉庫に格納されています