トップページ⇒tech
1001コメント319KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2012/10/31(水) 17:05:08.29
主にソケットに関しての質疑応答スレッドです。

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辺り
足りなかったら適当に付け足してね

前スレ
ネットワークプログラミング相談室 Port28
http://toro.2ch.net/test/read.cgi/tech/1334736934/

関連スレ
ネットワークプログラミング雑談
http://toro.2ch.net/test/read.cgi/tech/1235800707/
0757デフォルトの名無しさん2014/06/13(金) 14:33:38.70ID:XjONkcPz
>>755
ごめん、>>756は>>754に対してです
書き込み時間がかぶってしまいました
0758デフォルトの名無しさん2014/06/13(金) 20:30:15.17ID:w1vYKm0h
>>754
> ところで相手がデータ受けとる前にcloseしたら

この行のclose操作は送信側で起きるんだよね?
(受信側はrecvで待ち続けているのだから....)
もしそうだとしたら、

> 相手がデータ受けとる前にセッション切られてしまうという誤解、

のような話は聞いたことがない
というか、TCPコネクションが双方向のパイプ(バイト・ストリーム)として
モデル化されることを理解していれば、誤解など起きるはずもない
実際、>>746のケース(1)は、送信側が任意のタイミングでclose操作が
起きることを想定しているけど、これはUNIXのパイプと同じだから、
一部でもデータが喪失することを発想してしまうのは信じ難いな....
0759デフォルトの名無しさん2014/06/13(金) 20:54:45.67ID:cTbIwDgy
>>758
世の中にはその辺あんま理解してない子が結構いるのよ
0760デフォルトの名無しさん2014/06/13(金) 20:58:09.95ID:Wxssly4Y
読む気がしないが分かっていなさそうなのは分かる
0761デフォルトの名無しさん2014/06/14(土) 21:34:42.63ID:BuWNtkHZ
WSAAsyncSelectを使用して非同期通信をしています

通信経路はクライアント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:BuWNtkHZ
TCPですすみません
0763デフォルトの名無しさん2014/06/14(土) 22:01:22.78ID:DYTXSKWp
TCPですすまないならUDPでやれば
0764デフォルトの名無しさん2014/06/14(土) 22:08:43.87ID:z28CrNoH
順序は保証されてるでしょ
分割の切れ目がどこになるか保証されないだけで
0765デフォルトの名無しさん2014/06/14(土) 22:20:09.59ID:BuWNtkHZ
>>764
つまり分割されたとしてもデータAを受信し終わってからデータBを受信開始なんですね
ありがとうございました
0766デフォルトの名無しさん2014/06/15(日) 00:05:02.11ID:LTwXYkm1
あらやだ
0767デフォルトの名無しさん2014/06/15(日) 00:24:56.25ID:oWCenAVd
>>764
Bになりえるだろバカ
0768デフォルトの名無しさん2014/06/15(日) 01:52:52.97ID:MXV8DDuP
バーカ
0769デフォルトの名無しさん2014/06/15(日) 04:08:33.04ID:M5otKvxk
>>761
TCPスタックから見ればパケットが届く順はBになりえるけど、
アプリケーションの作り方として、最初にacceptしたコネクションから
全データをreadするまで別のコネクションはacceptしないとか、
acceptはしても最初のコネクションの分割メッセージを全部受信し切るまで
別コネクションのデータはreadしないとかにすればAになるかな
0770デフォルトの名無しさん2014/06/15(日) 06:43:01.77ID:Rg7+Zgkt
アプリケーション側での受信順のためにわざわざそんな変な造りにするのは本末転倒な気がする。
0771デフォルトの名無しさん2014/06/15(日) 08:25:20.91ID:9Vq05/27
A:煙草吸ってもよろしいですか?
B:どうぞ。ところで一日に何本くらいお吸いに?
A:ふた箱くらいですね。
B:喫煙年数はどれくらいですか?
A:30年くらいですね。
B:なるほど。あそこにベンツが停まってますね。
A:停まってますね。
B:もしあなたが煙草を吸わなければ、
C:ちくわ大明神
B:あれくらい買えたんですよ。
A:あれは私のベンツですけど。
B:誰だ今の
0772デフォルトの名無しさん2014/06/15(日) 08:50:36.80ID:U90s9FoP
最近は馬鹿が出没してるらしいですわよ、気をつけなきゃ
0773デフォルトの名無しさん2014/06/15(日) 08:57:05.82ID:0kRzHgJN
そうわよ(便乗)
0774デフォルトの名無しさん2014/06/15(日) 18:18:26.97ID:XcHbJsG3
>>761
正解は「C, 挙動は非決定的であり事前に予測できない」になる

つまり A かもしれないし B かもしれないし、その他の挙動が起きるかもしれない
たとえば「0A1B2C3....」もあれば、最悪のケースだと「ABCDEFG12345...」もありえる
あるアプリケーションがsend操作を発行して全データを送信し終えたとしても、
それはあくまでソケットAPIへの送信要求が完了しただけであって、
そのデータを相手側アプリケーションが「いつ」受信するかを事前には予測できない

一般にデータ受信側アプリケーションでは、バッファ上でメッセージを組み立てる
つまりメッセージの終端に到達するまでselect+recv操作を反復してバッファに保存し、
終端に到達したタイミングでバッファからメッセージを取り出して受信手続きを実行する
サーバでは、この一連の手順を各クライアントごと並行に処理することになる
0775デフォルトの名無しさん2014/06/15(日) 18:22:01.25ID:QaOmTGzv
ここで後だし
0776デフォルトの名無しさん2014/06/15(日) 22:09:55.41ID:9Vq05/27
A:かもしれないし
B:かもしれないし
C:ちくわ大明神かもしれないということですよ
0777デフォルトの名無しさん2014/06/15(日) 22:30:55.41ID:e0YOs29w
>>776
正解はBだが、Cのちくわ大明神は現れない場合もあることを想定する必要がある。
TCPの場合、ちくわ大明神が現れなくてもリトライしてはいけない。
なぜならばTCPの中の人がちくわ大明神を呼び出してるから。
0778デフォルトの名無しさん2014/06/16(月) 01:27:25.37ID:Hr3juoVp
中だし
0779デフォルトの名無しさん2014/06/16(月) 01:55:14.21ID:Yg1Vykl/
UDPでパケットの到着順序は保証されないけど
実際に順序ひっくり返してみたいんだけど
どういうふうに試験環境用意すればいいかな。
0780デフォルトの名無しさん2014/06/16(月) 03:23:40.68ID:OlFzGfst
>>779
再現困難だから、実際にひっくりかえして送信(しても耐えられるかどうか)をするのがいいのでは?
0781デフォルトの名無しさん2014/06/16(月) 08:56:38.07ID:qCCwIaT2
dummynetみたいなやつでエミュレートする
0782デフォルトの名無しさん2014/06/16(月) 19:23:49.43ID:VjJmHSFF
accept 後の
それぞれのソケット(A, B) からみれば
ソケットA 「0123456789」 ←これが細切れになるやもしれない
ソケットB 「ABCDEFG」 ←これが細切れになるやもしれない
こういうことでないの?
0783デフォルトの名無しさん2014/06/16(月) 19:34:24.31ID:lmeB/Wgi
パケットの分割自体はサーバー側で織り込み済みだ
いつまで引っ張る
0784デフォルトの名無しさん2014/06/16(月) 20:15:57.07ID:4xh696zJ
socketでサーバを作成し、Teraterm(クライアント)から接続したのですが、
Telnetと同じように1文字ずつ、入力のたびにパケット送信したいのが、
Enter押したときにしかパケットが送信されません。
Teratermで 1文字入力する毎にパケット送信するためにはどうしたらよいでしょうか。
0785デフォルトの名無しさん2014/06/16(月) 20:59:22.15ID:qCCwIaT2
適切な板とスレッドを選択して質問する
マニュアルを読む
ソースを読む

好きなのをどーぞ
0786デフォルトの名無しさん2014/06/16(月) 23:01:22.79ID:H3LgDS+r
>>782
ソケットAとBから同時にサーバーに送信した場合の話をしてるんだが
ソケットAを受信し終わる前にソケットBの断片が届く可能性はある
0787デフォルトの名無しさん2014/06/17(火) 09:19:18.20ID:aobUuG6A
>>786
そんな話をしていたのかよ
そんな順序誰も保証してないよ
0788デフォルトの名無しさん2014/06/17(火) 09:38:20.34ID:AXTqfFKW
とんでもねー後出し
0789デフォルトの名無しさん2014/06/17(火) 10:50:08.08ID:LnB6vTqT
>>787
>>761に書いてあるだろ

後出しでも何でも無いわ
0790デフォルトの名無しさん2014/06/17(火) 11:36:35.90ID:v0ZbhD0U
>>789
わりー、どっちでもねーわ
0791デフォルトの名無しさん2014/06/17(火) 18:49:57.60ID:7NsOcMoU
>>786
ソケット違うんだからデータが混ざったりしないし
順番なんてどうでも良いんじゃないのかい?
0792デフォルトの名無しさん2014/06/17(火) 18:52:25.29ID:kfNgSsa5
ど素人なのだろ、ほっとけ
0793デフォルトの名無しさん2014/06/17(火) 19:38:55.74ID:LnB6vTqT
>>791
どうでもよくないから>>761は聞いてるんだろ?
0794デフォルトの名無しさん2014/06/17(火) 19:58:35.02ID:7NsOcMoU
>>793
WSAAsyncSelect()の第一引数を無視してるから混ざると困るって事だろねw
0795デフォルトの名無しさん2014/06/17(火) 20:03:30.59ID:Kpke8le7
>>793
ファイルを2つオープンして、それらからデータをリードしている
ここで、2つのファイルのデータが混ざってしまう事を
心配しているのが>>786,791なんだよなあ

まあ、彼らのようなプログラミングの初心者にとって
複数ファイル処理は難しい課題なのかもしれないけど、
もしも>>761がそのレベルの課題を質問したいのなら
「ネットワークプログラミング」というスレの主旨から外れるから、
別の初心者スレで遊んでほしい
07967952014/06/17(火) 20:05:55.36ID:Kpke8le7
アンカをミスっていたので、訂正

X: 心配しているのが>>786,791なんだよなあ
O: 心配しているのが>>786,793なんだよなあ
0797デフォルトの名無しさん2014/06/17(火) 20:14:48.16ID:7NsOcMoU
>>795
WSAAsyncSelect()を使った場合、ソケット毎に別の格納用のデータ構造が必要だって
のはネットワークプログラミングの範疇じゃないのかい?

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
>>795
元はクライアントA→サーバー→他クライアントへって処理だから
FD_READで同じ処理させればいいだけなんだし
ソケット分岐する必要があればソケット別に処理させて
ソケット分岐する必要がなければそこらへん意識せず処理するだけで終わるだろ

ファイルとか例えが下手すぎる
0800デフォルトの名無しさん2014/06/17(火) 20:28:42.17ID:Kpke8le7
>>797
ファイル処理では、ファイル毎にファイル記述子を格納する
変数が必要なのは、常識ではないのか?
そんな常識すら知らない初心者に手取り足取り教えるのが
このスレの主旨だとは、少なくとも自分は思わない
0801デフォルトの名無しさん2014/06/17(火) 20:37:08.33ID:Kpke8le7
>>799
デバイスの抽象化という概念を知らない素人が口出ししても
恥をさらすだけ
0802デフォルトの名無しさん2014/06/17(火) 20:45:51.47ID:LnB6vTqT
>>801
何が気に障ったのかわからんが論点ずらさんでも
玄人は初心者とか素人って言葉使わないんだけどな
自惚れてる人が良く使う

>>761に対しては
Aが受信終わる前にBのデータが割り込む可能性があるから
ソケット毎にデータを処理するべきで終わってた話だろ
0803デフォルトの名無しさん2014/06/17(火) 20:54:06.90ID:Kpke8le7
>>802
その終わっていた話に対して、わざわざボケをかましたのが>>793だろ

というか、ID:LnB6vTqT の理解レベルが、他と比べて低すぎる
無知は決して恥ではないけれど、無知であると自覚できないのは無能だ
0804デフォルトの名無しさん2014/06/17(火) 20:57:59.06ID:7NsOcMoU
>>800
ファイルストリームではSelect()のように同じ所に返って来たりしないからな。
世の中には、ファイルストリームがストリームソケットになっただけで同じものなのに
わからなくなるヤツが居るのさ。

ま、言いたいことは分かるがそんなに目くじら立てるな。
0805デフォルトの名無しさん2014/06/17(火) 21:02:48.63ID:7NsOcMoU
Winsockを使うのなら >>1 の2つ目のリンク先くらい見ておかないとね。
古いんで今では正しくない部分もあるがかなり参考になると思う。
0806デフォルトの名無しさん2014/06/17(火) 21:15:24.83ID:Kpke8le7
>>784
ソケットオプション TCP_NODELAY を試せ
TCP_NODELAY でググると情報が見つかる

たとえば WinSock 向けなら、こんなのが:
・Winsock と TCP 経由で小さなデータ セグメントを送信する
  http://support.microsoft.com/kb/214397/ja
0807デフォルトの名無しさん2014/06/17(火) 22:00:07.12ID:LnB6vTqT
>>803
話の流れ見てから言え
発端の前提をぶっ壊して話されてもな
エスパーでもないのに俺のレスのどこで理解レベルがわかるんだよ
>>761が危惧してた事を言ったまでだぞ

とりあえず誰かを見下したいなら他行け
0808デフォルトの名無しさん2014/06/17(火) 22:17:12.70ID:Kpke8le7
>>807
見下すも何も、2つのファイルや2つのソケットを扱う処理で、
それらのデータが混ざってしまうことを危惧しているのは
ID:LnB6vTqT、ただ一人だけ

他の連中はクライアントを識別するはソケット記述子で判断できるという
常識を前提にして議論しているのに、ID:LnB6vTqTは知らなかったんだろ?
だから>>793みたいにトンチンカンなボケをかます

誰でも成長の過程で間違いをおかすことはあるんだから、
それを素直に認めたほうが前向きな生き方だと思うよ
0809デフォルトの名無しさん2014/06/17(火) 22:32:15.32ID:LnB6vTqT
>>808
サーバー側が受信するデータの順番で言うと
データAとBが「01234」「ABC」「56789」「DEFG」と交互にくる可能性があるか聞いてるんだろ
つまり混ざるかどうか

>>808が言う所の混ざるとはrecv1回のデータの中にデータAとデータBが同時に存在するかどうか しないわな
>>761が危惧してるのは同じデータ領域を使用して末尾に受信したデータを連結した場合混ざるかどうか ソケットで分けたら解決
ここの認識がずれてるぞ

で>>761がそういう危惧してるから>>761は聞いてるんだろって話

話の流れと質問者の意図を汲み取れよ
0810デフォルトの名無しさん2014/06/17(火) 22:36:12.06ID:KLoAGEx3
汲み取りやてんの、下水が普及してないのか
0811デフォルトの名無しさん2014/06/17(火) 22:43:50.79ID:7NsOcMoU
>>809
お前は何もわかっとらんのぅ。
0812デフォルトの名無しさん2014/06/17(火) 22:50:23.25ID:m9diWqqq
A:FD_READ (recv:Aすれば 01234
B:FD_READ (recv:Bすれば ABC
A:FD_READ (recv:Aすれば 56789
B:FD_READ (recv:Bすれば DEFG

recv:A で得られたものと recv:B で得られたものを
1つのバッファに連結するという発想に陥っているのだろうか?

それとも、、recvの際にソケット識別子を(渡ってきたものを使わずに)自前解釈で決め撃ちしてるのか? 
0813デフォルトの名無しさん2014/06/17(火) 22:56:27.88ID:LnB6vTqT
>>811
どこがや

>>812
ソケット毎に分けるという発想が>>761の時点で無いから
ソケットAもBも同じFD_READ・recvでやる前提と思うぞ
だからソケットAの受信が終わってからソケットBの受信開始なら現状維持でいいけど
recv1回目はソケットAのデータ、recv2回目はソケットBのデータってなる可能性があるなら変更しないといけないから聞いたんだろ
0814デフォルトの名無しさん2014/06/17(火) 23:00:25.44ID:7NsOcMoU
>>813
複数コネクション張っておいてソケット識別子を使わないという発想はなんなんだ?

だったら、1コネクションしか受付け無いようにしとけば一挙に解決!
0815デフォルトの名無しさん2014/06/17(火) 23:10:21.03ID:LnB6vTqT
>>814
受け取ったソケット識別子を使ってたとしても
受信順がソケットAが終わってからソケットBなら開始終了だけ知ってデータ格納先は1つでもいいけど
受信順がソケットAが終わる前にソケットBも来るならデータ格納先をソケット毎に用意しないといけないから
それで聞いてたんだろ
0816デフォルトの名無しさん2014/06/17(火) 23:10:21.69ID:Kpke8le7
>>813
>ソケット毎に分けるという発想が>>761の時点で無いから

なぜ>>761にはソケット毎に分けるという発想が無いと断定できるのか?
もしかすると ID: LnB6vTqT はエスパーなのかもしれない(>>807)

あるいは「>>761 == ID: LnB6vTqT」だったりしてw
0817デフォルトの名無しさん2014/06/17(火) 23:11:09.44ID:m9diWqqq
なんとなくゲスパー

FD_READ 受けた後の記述は recv(渡ってきたsockを受けた変数, バッファ)
だから表面上は同じものに見えてる

渡ってきたsockを受けた変数の 値が 適宜切り替わっているということに思い至っていないので、
値(識別子)による分離にたどり着かないのか
0818デフォルトの名無しさん2014/06/17(火) 23:12:20.50ID:LnB6vTqT
>>816
また論点ずらしか?

ソケット毎に分けるという発想があったのなら
そもそもあんな質問出てこないだろ
0819デフォルトの名無しさん2014/06/17(火) 23:26:29.65ID:XW/lVFuD
素人と汲み取り
0820デフォルトの名無しさん2014/06/17(火) 23:33:34.68ID:7NsOcMoU
>>815
ソケット毎の格納領域を用意するのがそんなに手間なのかw
0821デフォルトの名無しさん2014/06/18(水) 08:12:17.54ID:mKlf65Kz
ある程度力がつくと周りを見下し始める
ある程度極まってくると印象を気にし出す
天狗のまま戻ってこれない奴も多いけど
0822デフォルトの名無しさん2014/06/18(水) 11:30:08.66ID:7tSp0AS9
0123456789が、01234, 56789に分割される程、フレームサイズの小さいL2プロトコルって何?
0823デフォルトの名無しさん2014/06/18(水) 12:08:34.89ID:mKlf65Kz
例えに突っ込むアホ?
0824デフォルトの名無しさん2014/06/18(水) 13:34:53.47ID:7tSp0AS9
最長データサイズの見積もり無しに、分割の可能性を心配する無能さをからかいたかっただけだよ。
0825デフォルトの名無しさん2014/06/18(水) 13:41:31.39ID:wX3j5DNp
>>824
空気抵抗をゼロとする、って問題文を読んで
「そんなことあるわけねーよプゲラ」
って言っちゃうタイプだよね
0826デフォルトの名無しさん2014/06/18(水) 13:56:58.19ID:7tSp0AS9
>>825
バカはたとえ話するな。空気抵抗必死で計算しようとしてるのが元質問者。
0827デフォルトの名無しさん2014/06/18(水) 14:01:36.18ID:mKlf65Kz
>>826の例えの方がわからんわ

そもそもデータ受信時に割り込みがあるかどうかなんだから
最長データサイズの見積もりの必要なんて無いだろ
0828デフォルトの名無しさん2014/06/18(水) 14:12:31.35ID:7tSp0AS9
L2のフレームサイズより小さければ分割は発生しないの
0829デフォルトの名無しさん2014/06/18(水) 14:33:45.09ID:wp/txwFE
ソケット識別子を知らなかっただけなのに
なぜここまで続くのか
0830デフォルトの名無しさん2014/06/18(水) 14:44:51.76ID:Djkr0MFk
>>828
MSSもWindow SizeもReveive Bufferも全否定かよ
0831デフォルトの名無しさん2014/06/18(水) 14:49:21.45ID:mKlf65Kz
>>829
そうじゃなくね
Aなら受信データ格納先を1つで出来るが
Bなら受信データ格納先を複数用意する必要があるから聞いてたんだろ
0832デフォルトの名無しさん2014/06/18(水) 14:57:04.79ID:DTSE9n1l
>>830
覚えたばかりの言葉を使いたいのはわかるけど、
意味を理解してから使いましょうね、ぼくちゃん
0833デフォルトの名無しさん2014/06/18(水) 15:43:47.55ID:qLWFP7Um
IDが導入されて本当に良かった
0834デフォルトの名無しさん2014/06/18(水) 19:59:12.10ID:CilgVW0U
>>829
Select系のAPIを使って居るのにソケット識別子を知らないのは痛過ぎるから
0835デフォルトの名無しさん2014/06/18(水) 20:49:29.47ID:K2PaBBH0
>>824
TCP/IPの背景にあるインターネットワーキングとは、
不均質なサブネットワークが相互接続される世界である
ここで不均質(heterogeneous)とは、L1プロトコル、
転送速度、フレーム長等が混在している様相を指す
従って一般的な原則として、TCP/IPアプリケーションの
設計において特定のL2/L1プロトコルを前提にすべきではない

いいかえると、最長データサイズを事前に見積もりできるとする
発想のほうが初歩的な誤りであって、(>>761のように)任意のバイト境界で
データの分割や組み立てが起こりうることを想定して設計する姿勢が正しい
つまり、この件に関して言えば、
無能は>>761(ID: LnB6vTqT)ではなく、>>822(ID:ID: 7tSp0AS9)のほうだ

>>755や>>822は、素人がネットワークを勉強して知識を得たけれど、
それをプログラミングへ生半可に適用させて火傷を負う典型的なケース
水平軸における対向するレイヤ間のプロトコルと
垂直軸における上位レイヤへ提供するサービス(インターフェイス)という
交差する2つの概念をごっちゃにして理解しているように思われる
0836デフォルトの名無しさん2014/06/18(水) 21:05:08.89ID:YZhktGU/
IPoAC か
0837デフォルトの名無しさん2014/06/18(水) 22:13:46.39ID:msRy+nk0
>>835はタコでおk?
0838デフォルトの名無しさん2014/06/18(水) 22:46:16.44ID:CilgVW0U
>>837
ネットワークスレだけにオクトパスか
0839デフォルトの名無しさん2014/06/18(水) 23:11:37.86ID:mKlf65Kz
>>834
>>761の疑問はソケット識別子を知ってるかどうかは関係無いだろ
0840デフォルトの名無しさん2014/06/19(木) 01:24:12.03ID:AKnufCCZ
>>837
お前>>822か。 いい加減しつこいな。
0841デフォルトの名無しさん2014/06/19(木) 07:35:31.24ID:ryr/zveK
タコがエスパー失敗
0842デフォルトの名無しさん2014/06/19(木) 09:04:54.78ID:T3v2xG5Y
>>837
あらゆる可能性を想定出来ない奴がプログラミングとか趣味でやるだけにしとけ
0843デフォルトの名無しさん2014/06/19(木) 09:22:39.74ID:WpG/iKEP
あらゆる可能性を想定してプログラミングを書くやつはタコ
仕様も知らん奴は趣味でプログラムするだけにしとけ
0844デフォルトの名無しさん2014/06/19(木) 09:40:15.71ID:pZASkYhq
>>835
struct pkt {
int32_t size;
char data[*];
};
こんなパケットの先頭のsizeを読むときも
if (read(s, &size, sizeof(size)) != sizeof(size))
error();
としないのか、大変だな。頑張ってくれ。
0845デフォルトの名無しさん2014/06/19(木) 10:08:45.11ID:T3v2xG5Y
>>843
え

>>844
発現しにくいバグ生むだろそれ
0846デフォルトの名無しさん2014/06/19(木) 10:47:52.19ID:pZASkYhq
>>845
> 発現しにくいバグ生むだろそれ
意味不明
0847デフォルトの名無しさん2014/06/19(木) 10:51:52.22ID:T3v2xG5Y
わからないならそのままでもいいんじゃね
0848デフォルトの名無しさん2014/06/19(木) 10:54:39.08ID:D9TTjhOo
>>846
理解できるようになるまで勉強しろ
0849デフォルトの名無しさん2014/06/19(木) 13:37:52.71ID:iC2KP732
>>845
仕様です。
って一言が、これほど上手く使えるとは。
0850デフォルトの名無しさん2014/06/19(木) 13:54:43.05ID:T3v2xG5Y
>>849
おいw
0851デフォルトの名無しさん2014/06/19(木) 18:46:15.77ID:BRW9+QBS
>>842
>あらゆる可能性を想定出来ない

「想定外です」霧
0852デフォルトの名無しさん2014/06/19(木) 18:48:43.70ID:mP63aYGC
>>847
4バイト来ることを想定しちゃいかんって事かな?
あと、バイトオーダーも無視してるし
08538352014/06/19(木) 20:24:00.87ID:oi99l3rA
>>844
学校の演習課題で書くプログラムや個人の趣味プロジェクトであれば、
そのコードでもかまわないと思う
あるいは社会人であっても、研究職で研究対象としてのプログラミングなら許される
ただし、24時間365日の連続稼働という設計品質を要求される開発の最前線であれば、
コード設計の実装バグとしてレビューで指摘される

想像してみよう、銀行間で数十万件の取引レコードを転送している時、
偶然にもsizeの途中でデータが途切れてエラーとなったので
転送ジョブが異常終了してしまった
さて、この障害連絡に対して>>844はどう返答する?
「sizeの途中で途切れるなんて予測の想定外でした、私は間違っていません」
などと国会答弁の政治家のような言い訳をするのだろうね、たぶん

では「じゃあ、どうやって実装するのよ?」という想定質問について、
解決策は状況に応じていくつか考えられるけど、
最も汎用的なステートマシンを使う方法を過去スレPort24の類似質問に対して
疑似コード付きでレスしているので、まずはそちらを一読してもらいたい

 http://pc12.2ch.net/test/read.cgi/tech/1246895188/931-968

この過去スレの#318が自分のカキコになる
0854デフォルトの名無しさん2014/06/19(木) 20:25:55.76ID:qy6t50nu
タコが釣れたぞ
0855デフォルトの名無しさん2014/06/19(木) 20:44:46.89ID:mP63aYGC
>>853
今時は、全銀手順の手組なんてしないしw
ライブラリー使いましょ。

>>854
ネットワークスレなんだからオクテット足が釣れたと言いましょ
0856デフォルトの名無しさん2014/06/19(木) 20:47:19.72ID:qy6t50nu
>>853
銀行で徹夜したことについて謝罪と賠償を請求する
■ このスレッドは過去ログ倉庫に格納されています