ネットワークプログラミング相談室 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/
0712703
2014/01/15(水) 16:18:14.90うむむ
この悩み多き子羊に悩みをふやすとは。
実は、Windowsベースで開発するか、Linuxベースで開発するか、JavaなのかC++なのか
悩み多き状態でありまするです。
bdb を別の目的で使っているのでなんとなく感動ですが、
変にブロッキングされないのであれば、どーーーんと大きな値をってやつですかね？
0713703
2014/01/15(水) 16:21:29.31非常に単純なコーディングの問題
大して適当な大きな値で問題なさそげなのに、なぜnfds + 1 なんだろうか？、と
#死んでもタイムアウトは使わんポリシーは維持しております四
この場合、fdsの値を計算で出すにしろ、もうっちっと適当な値でも問題ないのでは？と
そうするとコードが非常にシンプルになりまする
0714デフォルトの名無しさん
2014/01/15(水) 16:43:20.130716703
2014/01/15(水) 16:49:20.70ノイズにしなければよいかと思います。
>>707に
ttp://mattn.kaoriya.net/software/lang/c/20090114140035.htm
を読んだ感想を一言だけ言わせればよいのでは？と思う次第です。
0717デフォルトの名無しさん
2014/01/15(水) 17:01:03.05そんなところを悩みどころにしてるようじゃ、まともなプログラムなんて到底書けないから
仕様通りに書いても大して難しいコードにならないのに
0718デフォルトの名無しさん
2014/01/15(水) 18:16:58.47> ただ、最大値＋１で無くとも動くのになぜ、最大値＋１なのかに疑問が生じたから、とだけ言っておこう
だから知りたきゃコード読めば正解がわかるだろボケ
0719デフォルトの名無しさん
2014/01/15(水) 18:18:13.20>>706も707も俺だし
0720デフォルトの名無しさん
2014/01/15(水) 23:48:25.090721デフォルトの名無しさん
2014/01/27(月) 14:34:08.340722デフォルトの名無しさん
2014/01/27(月) 21:33:39.15どうしたらいいかな
0723デフォルトの名無しさん
2014/01/27(月) 22:42:26.60他の環境は知らん
0724デフォルトの名無しさん
2014/01/28(火) 00:57:44.05ありがとう！ これは素晴らしい
オレのインターフェースにSO_BINDTODEVICEしてもいいよ
ていうか、いつのまにこんなオプション出来てたんだろ・・・
ソケットってどんどんオプション増えてくな
0725デフォルトの名無しさん
2014/01/31(金) 02:48:10.75環境変数かなんかで見れたりする？
0726デフォルトの名無しさん
2014/01/31(金) 07:49:17.49奴らは街角で拉致られてタコ部屋に押し込められて強制労働させられてるのか？
自ら希望して派遣会社に登録したんじゃないのか？
まずそこをハッキリして貰いたいんだが。
0727デフォルトの名無しさん
2014/01/31(金) 11:23:34.570728デフォルトの名無しさん
2014/01/31(金) 16:43:15.950729デフォルトの名無しさん
2014/03/02(日) 00:01:59.17winsockライブラリを通して行われているの？
0730デフォルトの名無しさん
2014/03/02(日) 00:33:53.490731デフォルトの名無しさん
2014/03/02(日) 16:06:50.910732デフォルトの名無しさん
2014/03/02(日) 16:15:30.120733デフォルトの名無しさん
2014/03/13(木) 16:29:44.87ID:4dqOfNxjこれってこういうもんなんですかね？
0734デフォルトの名無しさん
2014/03/13(木) 16:54:51.16ID:dvaQTbQU0735デフォルトの名無しさん
2014/04/15(火) 11:58:23.72ID:FRZaT0200736デフォルトの名無しさん
2014/04/15(火) 12:32:59.42ID:WaetxQT90737デフォルトの名無しさん
2014/05/17(土) 23:03:21.87ID:gMQ/DgzWARPテーブルのMACを書き換えているのですが、
無線LANの場合、期待通りになりません。
原因わかりますでしょうか？
Windowsで最新WinPcapライブラリ使って
ARPパケットを投げています。
両マシンとも無線LANで同じネットワークです。
アクセスポイントの問題かな。
0738デフォルトの名無しさん
2014/05/17(土) 23:13:54.36ID:G8Lb2FJE0739デフォルトの名無しさん
2014/05/19(月) 23:06:58.53ID:8NVWe51Uなるほど、そういうことでしたか、納得。
0740デフォルトの名無しさん
2014/05/21(水) 21:05:00.89ID:e27UFOXqできればC#から使いたい
0741デフォルトの名無しさん
2014/05/21(水) 21:08:37.78ID:v/u6M3900742デフォルトの名無しさん
2014/05/22(木) 08:51:43.06ID:pX1Bpa+a0743デフォルトの名無しさん
2014/06/07(土) 14:27:22.26ID:8MnQl1RbLinuxでソケットを使ったプログラムを作っているのですが、少し大きめのデータを何個かsend,recvした後に
サーバ、クライアントでcloseするとconnection reset by peerが時々出るようになりました。
closeするタイミングによってまだ残っている処理(send,recv)が取り残されているように思うのです。
サーバとクライアントでcloseするタイミングを同期する方法はありますでしょうか？
よろしくお願いします
0744デフォルトの名無しさん
2014/06/07(土) 15:13:58.52ID:pYRByoGi通常はcloseしても送信しきる先に切られることは無いので
別のことが原因と思います
0745デフォルトの名無しさん
2014/06/07(土) 15:38:02.72ID:8MnQl1Rb有難う、もう少し探ってみます。
0746デフォルトの名無しさん
2014/06/07(土) 16:35:42.74ID:ZfdboDuT>サーバとクライアントでcloseするタイミングを同期する方法はありますでしょうか？
クライアントとサーバ上のアプリケーション間通信について、
以下のケースに応じて通信の終了に関する規約(プロトコル)を決める
(1) データ送信が必ず一方向のケース(例：パイプ)
送信側は任意にcloseできるが、受信側ではソケットからの
終了通知(データ長=0)を待ってからcloseしなければならない
(2) 要求/応答のペアからなるトランザクションが常に同一側で発生するケース(例：HTTP/FTP/SMTP)
要求メッセージ送信側は任意にcloseできるが、応答メッセージ送信側では
ソケットからの終了通知(データ長=0)を待ってからcloseしなければならない
(3) データ送信要求が任意の時点かつ双方の側で発生するケース
制御メッセージとして通信終了要求(例："QUIT")と通信終了応答(例："OK")を定義し、
正常に通信を終了させたい時は終了要求メッセージを送信し応答を待つ
要求を受信した終了受け入れ側では応答メッセージを送信して即座にソケットをcloseする
終了要求側では応答メッセージ受信を確認してからソケットをcloseする
(3)のケースは複雑な手順を踏まなければならないのだから、連動テストで問題が発生してから
解決策を悩むのではなく、上流の設計工程でアプリケーション間通信プロトコルの全体を
ステートマシンとして形式的に定義し、正当性を検証しておくことが望ましい
0747デフォルトの名無しさん
2014/06/07(土) 16:56:39.59ID:afR3dkD/このメッセージを送信したらcloseする、このメッセージを受信したらcloseする、とか
mibをダンプするコマンド（nstatとか）でTcpExtTCPAbortOnCloseがインクリメントされてたら、
>>743の推測通り、アプリケーションがメッセージを吸い上げる前にcloseが発行されてると思う
0748デフォルトの名無しさん
2014/06/07(土) 22:16:48.00ID:oYteh1Pa0749デフォルトの名無しさん
2014/06/07(土) 22:32:20.13ID:ZfdboDuT・単体テストであれば、スタブ側で電波途切れのエラーを返す
・有線で組み通信中にケーブルを引き抜き擬似的に現象を起こす
・金属ケースや地下室などの電波を遮蔽できる環境を用意する
頭を使えば、様々なアイデアがでると思うよ
0750デフォルトの名無しさん
2014/06/07(土) 22:39:04.87ID:D6sqOe5Qどのレベルのプログラムの話なんだ？
ドライバ？ネットワークスタック？アプリケーション？
0751デフォルトの名無しさん
2014/06/07(土) 22:49:51.34ID:yvNnNrOKノートPCを持って電波が途切れる所まで離れてみる
青歯で実際にやったことあるぞww
0752デフォルトの名無しさん
2014/06/07(土) 23:30:00.41ID:1rlrU+oI0753743
2014/06/12(木) 20:36:17.42ID:ahExhbNyレス有り難う御座います。
暫く調査をしていたら原因らしきものを特定出来ましたので報告します。
結果的にはネットワークプログラミングには関係無い所でした。
スレッドの動作状況を確認するカウンタみたいな変数を作ってアクセスしていたのが原因で、
mutexを使っていないのがいけなかった様です。 orz...
メモリの同時アクセス→何らかの例外が発生→何故かGlibmm-ERROR std::bad_allocが発生→
selectやらrecvやらでソケットが無効となる→相方のプロセスでconnection reset by peerとなる
という感じでした。
何らかの例外ってのがあやふやなのと、元々あまり発生しないエラーだったので本当に解消できたのか
不安なところはあります。お付き合い頂き有難う御座いました。
0754デフォルトの名無しさん
2014/06/13(金) 14:04:40.40ID:El4cLTno相手がデータ受けとる前にセッション切られてしまうという誤解、
これ広まったのはいつ頃からなんだろうか。
とても気になるな
0755デフォルトの名無しさん
2014/06/13(金) 14:25:16.96ID:3lbuf2Ok相手側はデータ受け取る前にセッション切られるんだよ
FINに対してFIN/ACKを返したときはrecvでデータ受けきることができるけど
RST受けたときはその時点で終わりという実装が多い
誤解というか最悪ケースってやつで、セッションは切られるかもしれない
前提で設計しないと、ひどい目にあうっていう話だね
0756デフォルトの名無しさん
2014/06/13(金) 14:31:08.01ID:XjONkcPzその広まってる誤解っての寡聞にして知らないんで、
具体的におしえてくれないかな？
とりあえずTCP？
0757デフォルトの名無しさん
2014/06/13(金) 14:33:38.70ID:XjONkcPzごめん、>>756は>>754に対してです
書き込み時間がかぶってしまいました
0758デフォルトの名無しさん
2014/06/13(金) 20:30:15.17ID:w1vYKm0h> ところで相手がデータ受けとる前にcloseしたら
この行のclose操作は送信側で起きるんだよね？
（受信側はrecvで待ち続けているのだから....）
もしそうだとしたら、
> 相手がデータ受けとる前にセッション切られてしまうという誤解、
のような話は聞いたことがない
というか、TCPコネクションが双方向のパイプ(バイト・ストリーム)として
モデル化されることを理解していれば、誤解など起きるはずもない
実際、>>746のケース(1)は、送信側が任意のタイミングでclose操作が
起きることを想定しているけど、これはUNIXのパイプと同じだから、
一部でもデータが喪失することを発想してしまうのは信じ難いな....
0759デフォルトの名無しさん
2014/06/13(金) 20:54:45.67ID:cTbIwDgy世の中にはその辺あんま理解してない子が結構いるのよ
0760デフォルトの名無しさん
2014/06/13(金) 20:58:09.95ID:Wxssly4Y0761デフォルトの名無しさん
2014/06/14(土) 21:34:42.63ID:BuWNtkHZ通信経路はクライアントAがサーバーへ送信してからサーバーがクライアントA以外のクライアントへ送信するようにしています
ここで質問なんですが
1, クライアントAがデータA「0123456789」を送信してサーバーがデータAを受信し終わる前にクライアントBがデータB「ABCDEFG」を送信して分割して受信された時の挙動は
A, データAの「01234」「56789」を受信し終わってからデータB「ABC」「DEFG」を受信
B, データAの途中でもデータBが届く場合がある「01234」「ABC」「56789」「DEFG」
どちらですか？
0762デフォルトの名無しさん
2014/06/14(土) 21:37:49.47ID:BuWNtkHZ0763デフォルトの名無しさん
2014/06/14(土) 22:01:22.78ID:DYTXSKWp0764デフォルトの名無しさん
2014/06/14(土) 22:08:43.87ID:z28CrNoH分割の切れ目がどこになるか保証されないだけで
0765デフォルトの名無しさん
2014/06/14(土) 22:20:09.59ID:BuWNtkHZつまり分割されたとしてもデータAを受信し終わってからデータBを受信開始なんですね
ありがとうございました
0766デフォルトの名無しさん
2014/06/15(日) 00:05:02.11ID:LTwXYkm10767デフォルトの名無しさん
2014/06/15(日) 00:24:56.25ID:oWCenAVdBになりえるだろバカ
0768デフォルトの名無しさん
2014/06/15(日) 01:52:52.97ID:MXV8DDuP0769デフォルトの名無しさん
2014/06/15(日) 04:08:33.04ID:M5otKvxkTCPスタックから見ればパケットが届く順はBになりえるけど、
アプリケーションの作り方として、最初にacceptしたコネクションから
全データをreadするまで別のコネクションはacceptしないとか、
acceptはしても最初のコネクションの分割メッセージを全部受信し切るまで
別コネクションのデータはreadしないとかにすればAになるかな
0770デフォルトの名無しさん
2014/06/15(日) 06:43:01.77ID:Rg7+Zgkt0771デフォルトの名無しさん
2014/06/15(日) 08:25:20.91ID:9Vq05/27B：どうぞ。ところで一日に何本くらいお吸いに？
A：ふた箱くらいですね。
B：喫煙年数はどれくらいですか？
A：30年くらいですね。
B：なるほど。あそこにベンツが停まってますね。
A：停まってますね。
B：もしあなたが煙草を吸わなければ、
C：ちくわ大明神
B：あれくらい買えたんですよ。
A：あれは私のベンツですけど。
B：誰だ今の
0772デフォルトの名無しさん
2014/06/15(日) 08:50:36.80ID:U90s9FoP0773デフォルトの名無しさん
2014/06/15(日) 08:57:05.82ID:0kRzHgJN0774デフォルトの名無しさん
2014/06/15(日) 18:18:26.97ID:XcHbJsG3正解は「C, 挙動は非決定的であり事前に予測できない」になる
つまり A かもしれないし B かもしれないし、その他の挙動が起きるかもしれない
たとえば「0A1B2C3....」もあれば、最悪のケースだと「ABCDEFG12345...」もありえる
あるアプリケーションがsend操作を発行して全データを送信し終えたとしても、
それはあくまでソケットAPIへの送信要求が完了しただけであって、
そのデータを相手側アプリケーションが「いつ」受信するかを事前には予測できない
一般にデータ受信側アプリケーションでは、バッファ上でメッセージを組み立てる
つまりメッセージの終端に到達するまでselect+recv操作を反復してバッファに保存し、
終端に到達したタイミングでバッファからメッセージを取り出して受信手続きを実行する
サーバでは、この一連の手順を各クライアントごと並行に処理することになる
0775デフォルトの名無しさん
2014/06/15(日) 18:22:01.25ID:QaOmTGzv0776デフォルトの名無しさん
2014/06/15(日) 22:09:55.41ID:9Vq05/27Ｂ：かもしれないし
C：ちくわ大明神かもしれないということですよ
0777デフォルトの名無しさん
2014/06/15(日) 22:30:55.41ID:e0YOs29w正解はBだが、Cのちくわ大明神は現れない場合もあることを想定する必要がある。
TCPの場合、ちくわ大明神が現れなくてもリトライしてはいけない。
なぜならばTCPの中の人がちくわ大明神を呼び出してるから。
0778デフォルトの名無しさん
2014/06/16(月) 01:27:25.37ID:Hr3juoVp0779デフォルトの名無しさん
2014/06/16(月) 01:55:14.21ID:Yg1Vykl/実際に順序ひっくり返してみたいんだけど
どういうふうに試験環境用意すればいいかな。
0780デフォルトの名無しさん
2014/06/16(月) 03:23:40.68ID:OlFzGfst再現困難だから、実際にひっくりかえして送信（しても耐えられるかどうか）をするのがいいのでは？
0781デフォルトの名無しさん
2014/06/16(月) 08:56:38.07ID:qCCwIaT20782デフォルトの名無しさん
2014/06/16(月) 19:23:49.43ID:VjJmHSFFそれぞれのソケット(A, B) からみれば
ソケットA 「0123456789」 ←これが細切れになるやもしれない
ソケットB 「ABCDEFG」 ←これが細切れになるやもしれない
こういうことでないの？
0783デフォルトの名無しさん
2014/06/16(月) 19:34:24.31ID:lmeB/Wgiいつまで引っ張る
0784デフォルトの名無しさん
2014/06/16(月) 20:15:57.07ID:4xh696zJTelnetと同じように1文字ずつ、入力のたびにパケット送信したいのが、
Enter押したときにしかパケットが送信されません。
Teratermで 1文字入力する毎にパケット送信するためにはどうしたらよいでしょうか。
0785デフォルトの名無しさん
2014/06/16(月) 20:59:22.15ID:qCCwIaT2マニュアルを読む
ソースを読む
好きなのをどーぞ
0786デフォルトの名無しさん
2014/06/16(月) 23:01:22.79ID:H3LgDS+rソケットAとBから同時にサーバーに送信した場合の話をしてるんだが
ソケットAを受信し終わる前にソケットBの断片が届く可能性はある
0787デフォルトの名無しさん
2014/06/17(火) 09:19:18.20ID:aobUuG6Aそんな話をしていたのかよ
そんな順序誰も保証してないよ
0788デフォルトの名無しさん
2014/06/17(火) 09:38:20.34ID:AXTqfFKW0789デフォルトの名無しさん
2014/06/17(火) 10:50:08.08ID:LnB6vTqT>>761に書いてあるだろ
後出しでも何でも無いわ
0790デフォルトの名無しさん
2014/06/17(火) 11:36:35.90ID:v0ZbhD0Uわりー、どっちでもねーわ
0791デフォルトの名無しさん
2014/06/17(火) 18:49:57.60ID:7NsOcMoUソケット違うんだからデータが混ざったりしないし
順番なんてどうでも良いんじゃないのかい？
0792デフォルトの名無しさん
2014/06/17(火) 18:52:25.29ID:kfNgSsa50793デフォルトの名無しさん
2014/06/17(火) 19:38:55.74ID:LnB6vTqTどうでもよくないから>>761は聞いてるんだろ？
0794デフォルトの名無しさん
2014/06/17(火) 19:58:35.02ID:7NsOcMoUWSAAsyncSelect()の第一引数を無視してるから混ざると困るって事だろねw
0795デフォルトの名無しさん
2014/06/17(火) 20:03:30.59ID:Kpke8le7ファイルを２つオープンして、それらからデータをリードしている
ここで、２つのファイルのデータが混ざってしまう事を
心配しているのが>>786,791なんだよなあ
まあ、彼らのようなプログラミングの初心者にとって
複数ファイル処理は難しい課題なのかもしれないけど、
もしも>>761がそのレベルの課題を質問したいのなら
「ネットワークプログラミング」というスレの主旨から外れるから、
別の初心者スレで遊んでほしい
0796795
2014/06/17(火) 20:05:55.36ID:Kpke8le7X: 心配しているのが>>786,791なんだよなあ
O: 心配しているのが>>786,793なんだよなあ
0797デフォルトの名無しさん
2014/06/17(火) 20:14:48.16ID:7NsOcMoUWSAAsyncSelect()を使った場合、ソケット毎に別の格納用のデータ構造が必要だって
のはネットワークプログラミングの範疇じゃないのかい？
WSAAsyncSelect()じゃなくてソケット毎に別のスレッドにすればそんな問題は発生
しなくなるがスレッドだとまた別の罠がある。
スレッドの罠はネットワークプログラミングの趣旨から外れるなw
0798デフォルトの名無しさん
2014/06/17(火) 20:25:05.41ID:m9diWqqq時間→
A "01234" "567" "89"
B "ABC" "DEFG"
Aが先に構築し始めてるけど
Aのメッセージ(123456789)が 完成する前に
Bのメッセージ(ABCDEFG) が完成することだってある
だから A用バッファ B用バッファ (>>797 でいうソケット毎に別の格納用のデータ構造） を用意し、
ハンドラで、A向けかB向けかを判断いたうえで、しかるべきデータ構造に詰んであげる必要がある
0799デフォルトの名無しさん
2014/06/17(火) 20:27:31.50ID:LnB6vTqT元はクライアントA→サーバー→他クライアントへって処理だから
FD_READで同じ処理させればいいだけなんだし
ソケット分岐する必要があればソケット別に処理させて
ソケット分岐する必要がなければそこらへん意識せず処理するだけで終わるだろ
ファイルとか例えが下手すぎる
0800デフォルトの名無しさん
2014/06/17(火) 20:28:42.17ID:Kpke8le7ファイル処理では、ファイル毎にファイル記述子を格納する
変数が必要なのは、常識ではないのか？
そんな常識すら知らない初心者に手取り足取り教えるのが
このスレの主旨だとは、少なくとも自分は思わない
0801デフォルトの名無しさん
2014/06/17(火) 20:37:08.33ID:Kpke8le7デバイスの抽象化という概念を知らない素人が口出ししても
恥をさらすだけ
0802デフォルトの名無しさん
2014/06/17(火) 20:45:51.47ID:LnB6vTqT何が気に障ったのかわからんが論点ずらさんでも
玄人は初心者とか素人って言葉使わないんだけどな
自惚れてる人が良く使う
>>761に対しては
Aが受信終わる前にBのデータが割り込む可能性があるから
ソケット毎にデータを処理するべきで終わってた話だろ
0803デフォルトの名無しさん
2014/06/17(火) 20:54:06.90ID:Kpke8le7その終わっていた話に対して、わざわざボケをかましたのが>>793だろ
というか、ID:LnB6vTqT の理解レベルが、他と比べて低すぎる
無知は決して恥ではないけれど、無知であると自覚できないのは無能だ
0804デフォルトの名無しさん
2014/06/17(火) 20:57:59.06ID:7NsOcMoUファイルストリームではSelect()のように同じ所に返って来たりしないからな。
世の中には、ファイルストリームがストリームソケットになっただけで同じものなのに
わからなくなるヤツが居るのさ。
ま、言いたいことは分かるがそんなに目くじら立てるな。
0805デフォルトの名無しさん
2014/06/17(火) 21:02:48.63ID:7NsOcMoU古いんで今では正しくない部分もあるがかなり参考になると思う。
0806デフォルトの名無しさん
2014/06/17(火) 21:15:24.83ID:Kpke8le7ソケットオプション TCP_NODELAY を試せ
TCP_NODELAY でググると情報が見つかる
たとえば WinSock 向けなら、こんなのが：
・Winsock と TCP 経由で小さなデータ セグメントを送信する
http://support.microsoft.com/kb/214397/ja
0807デフォルトの名無しさん
2014/06/17(火) 22:00:07.12ID:LnB6vTqT話の流れ見てから言え
発端の前提をぶっ壊して話されてもな
エスパーでもないのに俺のレスのどこで理解レベルがわかるんだよ
>>761が危惧してた事を言ったまでだぞ
とりあえず誰かを見下したいなら他行け
0808デフォルトの名無しさん
2014/06/17(火) 22:17:12.70ID:Kpke8le7見下すも何も、２つのファイルや２つのソケットを扱う処理で、
それらのデータが混ざってしまうことを危惧しているのは
ID:LnB6vTqT、ただ一人だけ
他の連中はクライアントを識別するはソケット記述子で判断できるという
常識を前提にして議論しているのに、ID:LnB6vTqTは知らなかったんだろ？
だから>>793みたいにトンチンカンなボケをかます
誰でも成長の過程で間違いをおかすことはあるんだから、
それを素直に認めたほうが前向きな生き方だと思うよ
0809デフォルトの名無しさん
2014/06/17(火) 22:32:15.32ID:LnB6vTqTサーバー側が受信するデータの順番で言うと
データAとBが「01234」「ABC」「56789」「DEFG」と交互にくる可能性があるか聞いてるんだろ
つまり混ざるかどうか
>>808が言う所の混ざるとはrecv1回のデータの中にデータAとデータBが同時に存在するかどうか しないわな
>>761が危惧してるのは同じデータ領域を使用して末尾に受信したデータを連結した場合混ざるかどうか ソケットで分けたら解決
ここの認識がずれてるぞ
で>>761がそういう危惧してるから>>761は聞いてるんだろって話
話の流れと質問者の意図を汲み取れよ
0810デフォルトの名無しさん
2014/06/17(火) 22:36:12.06ID:KLoAGEx30811デフォルトの名無しさん
2014/06/17(火) 22:43:50.79ID:7NsOcMoUお前は何もわかっとらんのぅ。
0812デフォルトの名無しさん
2014/06/17(火) 22:50:23.25ID:m9diWqqqB:FD_READ (recv:Bすれば ABC
A:FD_READ (recv:Aすれば 56789
B:FD_READ (recv:Bすれば DEFG
recv:A で得られたものと recv:B で得られたものを
１つのバッファに連結するという発想に陥っているのだろうか？
それとも、、recvの際にソケット識別子を（渡ってきたものを使わずに）自前解釈で決め撃ちしてるのか？
■ このスレッドは過去ログ倉庫に格納されています