ネットワークプログラミング相談室 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/
0737デフォルトの名無しさん
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の際にソケット識別子を（渡ってきたものを使わずに）自前解釈で決め撃ちしてるのか？
0813デフォルトの名無しさん
2014/06/17(火) 22:56:27.88ID:LnB6vTqTどこがや
>>812
ソケット毎に分けるという発想が>>761の時点で無いから
ソケットAもBも同じFD_READ・recvでやる前提と思うぞ
だからソケットAの受信が終わってからソケットBの受信開始なら現状維持でいいけど
recv1回目はソケットAのデータ、recv2回目はソケットBのデータってなる可能性があるなら変更しないといけないから聞いたんだろ
0814デフォルトの名無しさん
2014/06/17(火) 23:00:25.44ID:7NsOcMoU複数コネクション張っておいてソケット識別子を使わないという発想はなんなんだ？
だったら、１コネクションしか受付け無いようにしとけば一挙に解決！
0815デフォルトの名無しさん
2014/06/17(火) 23:10:21.03ID:LnB6vTqT受け取ったソケット識別子を使ってたとしても
受信順がソケットAが終わってからソケットBなら開始終了だけ知ってデータ格納先は1つでもいいけど
受信順がソケットAが終わる前にソケットBも来るならデータ格納先をソケット毎に用意しないといけないから
それで聞いてたんだろ
0816デフォルトの名無しさん
2014/06/17(火) 23:10:21.69ID:Kpke8le7>ソケット毎に分けるという発想が>>761の時点で無いから
なぜ>>761にはソケット毎に分けるという発想が無いと断定できるのか？
もしかすると ID: LnB6vTqT はエスパーなのかもしれない(>>807)
あるいは「>>761 == ID: LnB6vTqT」だったりしてw
0817デフォルトの名無しさん
2014/06/17(火) 23:11:09.44ID:m9diWqqqFD_READ 受けた後の記述は recv(渡ってきたsockを受けた変数, バッファ)
だから表面上は同じものに見えてる
渡ってきたsockを受けた変数の 値が 適宜切り替わっているということに思い至っていないので、
値(識別子)による分離にたどり着かないのか
0818デフォルトの名無しさん
2014/06/17(火) 23:12:20.50ID:LnB6vTqTまた論点ずらしか？
ソケット毎に分けるという発想があったのなら
そもそもあんな質問出てこないだろ
0819デフォルトの名無しさん
2014/06/17(火) 23:26:29.65ID:XW/lVFuD0820デフォルトの名無しさん
2014/06/17(火) 23:33:34.68ID:7NsOcMoUソケット毎の格納領域を用意するのがそんなに手間なのかw
0821デフォルトの名無しさん
2014/06/18(水) 08:12:17.54ID:mKlf65Kzある程度極まってくると印象を気にし出す
天狗のまま戻ってこれない奴も多いけど
0822デフォルトの名無しさん
2014/06/18(水) 11:30:08.66ID:7tSp0AS90823デフォルトの名無しさん
2014/06/18(水) 12:08:34.89ID:mKlf65Kz0824デフォルトの名無しさん
2014/06/18(水) 13:34:53.47ID:7tSp0AS90825デフォルトの名無しさん
2014/06/18(水) 13:41:31.39ID:wX3j5DNp空気抵抗をゼロとする、って問題文を読んで
「そんなことあるわけねーよﾌﾟｹﾞﾗ」
って言っちゃうタイプだよね
0826デフォルトの名無しさん
2014/06/18(水) 13:56:58.19ID:7tSp0AS9バカはたとえ話するな。空気抵抗必死で計算しようとしてるのが元質問者。
0827デフォルトの名無しさん
2014/06/18(水) 14:01:36.18ID:mKlf65Kzそもそもデータ受信時に割り込みがあるかどうかなんだから
最長データサイズの見積もりの必要なんて無いだろ
0828デフォルトの名無しさん
2014/06/18(水) 14:12:31.35ID:7tSp0AS90829デフォルトの名無しさん
2014/06/18(水) 14:33:45.09ID:wp/txwFEなぜここまで続くのか
0830デフォルトの名無しさん
2014/06/18(水) 14:44:51.76ID:Djkr0MFkMSSもWindow SizeもReveive Bufferも全否定かよ
0831デフォルトの名無しさん
2014/06/18(水) 14:49:21.45ID:mKlf65Kzそうじゃなくね
Aなら受信データ格納先を1つで出来るが
Bなら受信データ格納先を複数用意する必要があるから聞いてたんだろ
0832デフォルトの名無しさん
2014/06/18(水) 14:57:04.79ID:DTSE9n1l覚えたばかりの言葉を使いたいのはわかるけど、
意味を理解してから使いましょうね、ぼくちゃん
0833デフォルトの名無しさん
2014/06/18(水) 15:43:47.55ID:qLWFP7Um0834デフォルトの名無しさん
2014/06/18(水) 19:59:12.10ID:CilgVW0USelect系のAPIを使って居るのにソケット識別子を知らないのは痛過ぎるから
0835デフォルトの名無しさん
2014/06/18(水) 20:49:29.47ID:K2PaBBH0TCP/IPの背景にあるインターネットワーキングとは、
不均質なサブネットワークが相互接続される世界である
ここで不均質(heterogeneous)とは、L1プロトコル、
転送速度、フレーム長等が混在している様相を指す
従って一般的な原則として、TCP/IPアプリケーションの
設計において特定のL2/L1プロトコルを前提にすべきではない
いいかえると、最長データサイズを事前に見積もりできるとする
発想のほうが初歩的な誤りであって、(>>761のように)任意のバイト境界で
データの分割や組み立てが起こりうることを想定して設計する姿勢が正しい
つまり、この件に関して言えば、
無能は>>761(ID: LnB6vTqT)ではなく、>>822(ID:ID: 7tSp0AS9)のほうだ
>>755や>>822は、素人がネットワークを勉強して知識を得たけれど、
それをプログラミングへ生半可に適用させて火傷を負う典型的なケース
水平軸における対向するレイヤ間のプロトコルと
垂直軸における上位レイヤへ提供するサービス(インターフェイス)という
交差する２つの概念をごっちゃにして理解しているように思われる
0836デフォルトの名無しさん
2014/06/18(水) 21:05:08.89ID:YZhktGU/■ このスレッドは過去ログ倉庫に格納されています