ネットワークプログラミング相談室 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/
0782デフォルトの名無しさん
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が自分のカキコになる
0854デフォルトの名無しさん
2014/06/19(木) 20:25:55.76ID:qy6t50nu0855デフォルトの名無しさん
2014/06/19(木) 20:44:46.89ID:mP63aYGC今時は、全銀手順の手組なんてしないしw
ライブラリー使いましょ。
>>854
ネットワークスレなんだからオクテット足が釣れたと言いましょ
0856デフォルトの名無しさん
2014/06/19(木) 20:47:19.72ID:qy6t50nu銀行で徹夜したことについて謝罪と賠償を請求する
0857デフォルトの名無しさん
2014/06/19(木) 21:30:03.44ID:lQ+uiTbF日本は銀行間取引はRTGSで日銀経由でしている事を
知らない部外者だよ
0858デフォルトの名無しさん
2014/06/19(木) 21:50:09.29ID:Oxl/97Kx0859デフォルトの名無しさん
2014/06/20(金) 00:17:58.19ID:ZdNYCSgz0860デフォルトの名無しさん
2014/06/20(金) 06:36:54.81ID:JSi28Lkjますます意味不明
ネットワークプログラミング相談室 Port24
http://pc12.2ch.net/test/read.cgi/tech/1246895188/931-968の#318
> 318 ： デフォルトの名無しさん[sage] 投稿日：2009/08/12(水) 17:18:44
> >>315
> あー、そうか
> ローカルポートの情報も持ってないとだめですね
318で検索しても他にはないしなあ
0861デフォルトの名無しさん
2014/06/20(金) 07:14:16.63ID:kSpxa/vAhttp://pc12.2ch.net/test/read.cgi/tech/1246895188/950-952
だろう
正直こんなくどいことせず１バイトずつ読めばいいと思うが、
レスもなんかくどいし、まあそういう人なんだろう
0862デフォルトの名無しさん
2014/06/20(金) 07:33:26.53ID:JSi28Lkj> さて、この障害連絡に対して>>844はどう返答する？
error();
の中で処理する。
>>861
#318ではなく#938の可能性微レ存だが、銀行間の数十万件の取引レコードを
処理するプログラムを書く御仁がこんな単純な間違いをしたと、決めつける
のは良くない。本人の釈明を待つことにする。
0863835
2014/06/20(金) 09:20:27.39ID:fiYVjyLm指摘ありがとう、レス#の間違いに気が付けなかった....
X: この過去スレの#318が自分のカキコになる
O: この過去スレの#938が自分のカキコになる
具体的な疑似コードは、過去レス(>>853)の #947 と #950-952
0864デフォルトの名無しさん
2014/06/20(金) 10:59:08.88ID:JSi28Lkjプログラムがここで寝ている時に通信障害の連絡やってきた。
さて、>>853はどう対処する?
銀行間の数十万件の取引レコードの転送の場合は当然
switch (tlv.type) {
default:
error();
brreak;
}
なんて事はしないんだよな。 w
0865デフォルトの名無しさん
2014/06/20(金) 11:05:28.51ID:JSi28Lkj> 質問の意図に沿って「非同期I/Oを前提(だよね？)」とした場合、最も外側のTLV構造の処理は、
> ステートマシン(状態管理処理)と一体になる。疑似コードだと、こんな感じ。
こっちの場合も
while (buf.size() > 0)
buf.size() == 0で抜けてしまうんだが、
while (buf.size() > 0) {
}
if (state != STATE_COMPLETE)
error();
なんて事はしないんだよな。銀行間の数十万件の取引レコードの転送の場合は ｗ
0866835
2014/06/20(金) 11:57:20.19ID:fiYVjyLm「寝ている」とはプロセスがブロック(or スレッド)された状態を意味するのかな？
もしそうなら、過去スレ#950の冒頭で述べているように：
・マルチスレッド構成でTCPコネクション単位に
スレッド処理する設計ならば、ブロックには何の問題も無い
新たに受信データ断片が到着すればスレッドのブロックが解除され、
次のtype別処理を再開できるのだから
・シングルスレッド構成でイベント駆動処理を前提に設計しているのならば、
過去スレ#947の疑似コードは不適切だから
代わりに#950の疑似コードを使えばいい
>>865
バッファが空である(buf.size() == 0)ならば
現時点で到着していた受信データ断片の処理は終わったのだから、
ステートマシンの状態を保持したまま
すみやかにコールバック関数をリターンし、
次の受信イベント発生を待ちうけるべき
こんなのはイベント駆動プログラミングの基本だけど、
>>865はどんなエラー処理を期待しているのかな？
0867デフォルトの名無しさん
2014/06/20(金) 12:21:42.37ID:JSi28Lkj0868デフォルトの名無しさん
2014/06/20(金) 12:58:00.74ID:ZdNYCSgz途中でエラーになるんだから
安全を取って、その電文はエラーログに落として破棄、
ランプ光らせつつ再送に期待じゃない？
0869デフォルトの名無しさん
2014/06/20(金) 13:01:45.74ID:FGk8LmcM0870デフォルトの名無しさん
2014/06/20(金) 13:06:50.29ID:5fUr2YwOselectとnon blocking I/Oを使うんだぞ
それから実装はどうであれSOCK_STREAMのsocketからreadしたとき
何バイト読めるかは保証されていないぞ
0871835
2014/06/20(金) 13:42:16.97ID:fiYVjyLm言われた事しかできません、という「ゆとり世代」かな？
しかたないから、面倒だけど疑似コードから実装コードへ落とし込む方法を
手取り足取り教えてあげよう
（実際に、要領の悪い新人さんを指導しているような気分になりつつあるw）
・イベント駆動を前提にした疑似コード#950であれば、
OSやフレームワークからコールバックされた直後に
readやreceiveシステムコールを発行してソケットから受信バッファに読み込み、
それから#950の状態遷移関数 recv_acceptor をコールする
（状態遷移関数内ではメモリ上のバッファだけを処理するから通信障害は無視できる）
また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
その部分で適切に通信障害発生時のエラー対応処理を実装する
・スレッドのブロックを前提にした同期プログラミングの疑似コード#947では、
TLVリーダのget操作の中のシステムコール発行時に通信障害発生を判定する
ただし、get操作がコードの複数箇所に拡散してしまうから、
例外を投げるとかC言語ならlongjmpで大域脱出するとかして一ヶ所にまとめ、
その部分で適切に通信障害発生時のエラー対応処理を実装する
（もちろんget操作がエラーリターンするよう変更してもいいけど、可読性は落ちる）
0872デフォルトの名無しさん
2014/06/20(金) 13:46:29.95ID:UaHzai/N0873デフォルトの名無しさん
2014/06/20(金) 13:48:20.34ID:+KfxKSN30874835
2014/06/20(金) 13:51:26.94ID:fiYVjyLmそのとおりで、TCP通信がバイト・ストリームであることを理解していれば、
保証されないことは当たり前なんだけど、それを保証するコード設計なんて
面倒くさくてやってられない、というのが>>844君の主張
>>844のコードだと、保証処理を放棄して、通信エラーとして扱うつもりでいる
0875デフォルトの名無しさん
2014/06/20(金) 14:02:40.97ID:JSi28Lkj> その部分で適切に通信障害発生時のエラー対応処理を実装する
銀行間の数十万件の取引レコードの転送の場合は、通信障害でTCPの切断が起こっ
た事と通信終了でreadが0を返した事を判別できるのか?
それはビックリだよ。ｗ
0876835
2014/06/20(金) 14:56:31.68ID:fiYVjyLmまだ続けたいの？
しかたないね、新人教育を続けよう
・ここで扱っている受信メッセージ組立て処理の場合、
メッセージ組み立て中の状態でreadが0を返せば、
それは通信障害によるコネクション切断と判断する
それ以外の状態、すなわち連続するメッセージ間で
readが0を返した場合には判別できないから、
単純に上位へコネクション切断を通知する
・上位のトランザクション処理ではトランザクション処理中に
コネクション切断が通知されたなら通信障害と判断する
ここで、トランザクションとは、たとえばHTTPサーバなら
リクエスト受信開始からレスポンス送信完了までの期間を、
SMTPであればHELLOコマンド受信開始からQUITコマンドに対する
応答送信完了までの期間を指す
それ以外の状態、すなわち連続するトランザクション間で
コネクション切断が通知されたなら正常な通信終了と判断する
ビックリって、何を驚いているのかな？
もしかすると、こういった判定も面倒だからという理由で設計していなかったのね
まあ確かに、一般にネットワークプログラミングはエラー処理のかたまりだから、
慣れない素人さんや学生さんが最初にとまどってしまうのは無理もないのかな
0877デフォルトの名無しさん
2014/06/20(金) 15:01:21.09ID:JSi28Lkj> それは通信障害によるコネクション切断と判断する
後出し仕様 ｗｗｗｗ
> また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
> その部分で適切に通信障害発生時のエラー対応処理を実装する
下位レイヤーが上位レイヤーの状態を知ってるんですかあ? 銀行間の数十万件の取引レコードの転送の場合は。ｗｗｗｗ
0878835
2014/06/20(金) 16:00:42.03ID:fiYVjyLm> 後出し仕様 ｗｗｗｗ
もともと過去レスの疑似コードでは、
readシステムコールを発行する詳細コードを抽象化し、
TLVリーダやバッファといった用語を書いている
そして、その実装は各自で考えてもらえばいいと思っていたけど、
ID:JSi28Lkj君が「僕には実装方法が分かりません」と言い出したから
丁寧に教えてあげているだけだよ
> 下位レイヤーが上位レイヤーの状態を知ってるんですかあ?
知らないから、下位の受信メッセージ組立て処理では
「単純に上位へコネクション切断を通知」して
上位のトランザクション処理に判別を委ねると、
>>876で述べている
もう少し冷静になって文章を読んだほうがいいと思うよ
こちらでは技術関連は指導できても、日本語の読解能力までは面倒みれないから
0879デフォルトの名無しさん
2014/06/20(金) 16:10:48.55ID:ix5aqk/e0880デフォルトの名無しさん
2014/06/20(金) 17:15:41.46ID:fmtXRHPg通信障害は-1が返ってくるし
0881デフォルトの名無しさん
2014/06/20(金) 17:37:38.06ID:qd8xX9Tw> TCP通信がバイト・ストリームであることを理解していれば、
> 保証されないことは当たり前なんだけど
このスレの住人なら、例外を除いてそんなの常識だし、君が力説してるようなことも常識。
それを上から目線で、さもお前らが知らないことを教えてやろう的なレスするから嫌われる。
■ このスレッドは過去ログ倉庫に格納されています