ネットワークプログラミング相談室 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/
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/0837デフォルトの名無しさん
2014/06/18(水) 22:13:46.39ID:msRy+nk00838デフォルトの名無しさん
2014/06/18(水) 22:46:16.44ID:CilgVW0Uネットワークスレだけにオクトパスか
0839デフォルトの名無しさん
2014/06/18(水) 23:11:37.86ID:mKlf65Kz>>761の疑問はソケット識別子を知ってるかどうかは関係無いだろ
0840デフォルトの名無しさん
2014/06/19(木) 01:24:12.03ID:AKnufCCZお前>>822か。 いい加減しつこいな。
0841デフォルトの名無しさん
2014/06/19(木) 07:35:31.24ID:ryr/zveK0842デフォルトの名無しさん
2014/06/19(木) 09:04:54.78ID:T3v2xG5Yあらゆる可能性を想定出来ない奴がプログラミングとか趣味でやるだけにしとけ
0843デフォルトの名無しさん
2014/06/19(木) 09:22:39.74ID:WpG/iKEP仕様も知らん奴は趣味でプログラムするだけにしとけ
0844デフォルトの名無しさん
2014/06/19(木) 09:40:15.71ID:pZASkYhqstruct 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え
>>844
発現しにくいバグ生むだろそれ
0846デフォルトの名無しさん
2014/06/19(木) 10:47:52.19ID:pZASkYhq> 発現しにくいバグ生むだろそれ
意味不明
0847デフォルトの名無しさん
2014/06/19(木) 10:51:52.22ID:T3v2xG5Y0848デフォルトの名無しさん
2014/06/19(木) 10:54:39.08ID:D9TTjhOo理解できるようになるまで勉強しろ
0849デフォルトの名無しさん
2014/06/19(木) 13:37:52.71ID:iC2KP732仕様です。
って一言が、これほど上手く使えるとは。
0850デフォルトの名無しさん
2014/06/19(木) 13:54:43.05ID:T3v2xG5Yおいｗ
0851デフォルトの名無しさん
2014/06/19(木) 18:46:15.77ID:BRW9+QBS＞あらゆる可能性を想定出来ない
「想定外です」霧
0852デフォルトの名無しさん
2014/06/19(木) 18:48:43.70ID:mP63aYGC4バイト来ることを想定しちゃいかんって事かな?
あと、バイトオーダーも無視してるし
0853835
2014/06/19(木) 20:24:00.87ID:oi99l3rA学校の演習課題で書くプログラムや個人の趣味プロジェクトであれば、
そのコードでもかまわないと思う
あるいは社会人であっても、研究職で研究対象としてのプログラミングなら許される
ただし、24時間365日の連続稼働という設計品質を要求される開発の最前線であれば、
コード設計の実装バグとしてレビューで指摘される
想像してみよう、銀行間で数十万件の取引レコードを転送している時、
偶然にもsizeの途中でデータが途切れてエラーとなったので
転送ジョブが異常終了してしまった
さて、この障害連絡に対して>>844はどう返答する？
「sizeの途中で途切れるなんて予測の想定外でした、私は間違っていません」
などと国会答弁の政治家のような言い訳をするのだろうね、たぶん
では「じゃあ、どうやって実装するのよ？」という想定質問について、
解決策は状況に応じていくつか考えられるけど、
最も汎用的なステートマシンを使う方法を過去スレPort24の類似質問に対して
疑似コード付きでレスしているので、まずはそちらを一読してもらいたい
http://pc12.2ch.net/test/read.cgi/tech/1246895188/931-968
この過去スレの#318が自分のカキコになる
■ このスレッドは過去ログ倉庫に格納されています