ネットワークプログラミング相談室 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/
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通信がバイト・ストリームであることを理解していれば、
> 保証されないことは当たり前なんだけど
このスレの住人なら、例外を除いてそんなの常識だし、君が力説してるようなことも常識。
それを上から目線で、さもお前らが知らないことを教えてやろう的なレスするから嫌われる。
0882デフォルトの名無しさん
2014/06/20(金) 17:40:23.44ID:JSi28Lkj> 知らないから、下位の受信メッセージ組立て処理では
>>876には
>・ここで扱っている受信メッセージ組立て処理の場合、
> メッセージ組み立て中の状態でreadが0を返せば、
> それは通信障害によるコネクション切断と判断する
下位レイヤーが、上位レイヤーがメッセージ組み立て中の状態である事を知ってるっ
て書いてありますが。ｗｗｗ
0883デフォルトの名無しさん
2014/06/20(金) 17:48:20.00ID:JSi28Lkjメッセージ境界が保存されないTCPでも
write(s, &v, sizeof(int));で書かれたvは
read(s, &v, sizeof(int));で読める。全然問題ない。
問題あると騒いでるバカはすべてのプログラムのreadをと書き換えろ。
(sがソケットになる可能性が0ではないから)
int nread(int s,char *buf, size_t sz)
{
int cc, l;
for (l = 0; l < sz; l += cc)
if ((cc = read(s, buf + l, sz - l)) < 1)
return 0;
return l;
}
0884835
2014/06/20(金) 18:28:03.97ID:fiYVjyLmいや、通信障害という業界用語は、データリンク・レベルのエラー(回線障害)から
アプリケーション間プロトコルのエラーまで、幅広いエラーを含んでいる
そして>>876で書いたように、システムコールが正常終了しても
通信サービスとしてはエラーとして扱うケースもあるから、
read/recvのリターン値 -1 だけでは、すべての通信障害を検出できない
>>881
わかった、では自分は落ちるから、後の >>883(ID: JSi28Lkj)の世話、よろしくたのむ
>>882
君への最後のレスを返す
受信メッセージ組立て処理(下位)とトランザクション処理(上位)という
２個のモジュールがあるという構成を理解できていないのかな？
これ以上は面倒だし、後の世話は>>881にまかせたので、説明は止めとく
0885デフォルトの名無しさん
2014/06/20(金) 18:52:29.32ID:fmtXRHPgブロッキングI/Oだと無限にループから抜け出せない可能性があるし
ノンブロッキングI/Oだとデータ受信が間に合わないときにエラーが
返ってくるので0復帰してしまう
100点満点中10点だな
0886デフォルトの名無しさん
2014/06/20(金) 20:05:21.58ID:JSi28Lkj> 受信メッセージ組立て処理(下位)とトランザクション処理(上位)という
> ２個のモジュールがあるという構成を理解できていないのかな？
> これ以上は面倒だし、後の世話は>>881にまかせたので、説明は止めとく
ぷぷぷっ また後付け。
> また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
> その部分で適切に通信障害発生時のエラー対応処理を実装する
システムコール発行直後でエラー処理を行うとはっきり書いてあるわけだが。
>>885
最後だと言っときながら、余計な事書いて恥の上塗り。みっともないねえ。
> ブロッキングI/Oだと無限にループから抜け出せない可能性があるし
ねーよ。バカ。ｗｗｗ
> ノンブロッキングI/Oだとデータ受信が間に合わないときにエラーが
バカには分からないらしいが、ブロッキングI/Oで書いてあるのは一目瞭然。ｗｗｗ
0887デフォルトの名無しさん
2014/06/20(金) 20:12:22.25ID:fmtXRHPgブロッキングI/Oでreadすると、通信遮断で返ってこなくなるよ
経験のなさがもろに出てるね
0888デフォルトの名無しさん
2014/06/20(金) 20:15:02.16ID:5fUr2YwOとか言ってみる
0889デフォルトの名無しさん
2014/06/20(金) 20:19:43.47ID:JSi28Lkj> 通信障害は-1が返ってくるし
はい、ダウト。 ｗｗｗ
TCPの切断では-1は返ってこない。このバカこの程度の知識で偉そうにしてて大爆笑だわ。
0890デフォルトの名無しさん
2014/06/20(金) 20:20:15.90ID:nPXPLHY10891デフォルトの名無しさん
2014/06/20(金) 20:22:24.13ID:JSi28Lkj最後と言ってたのにやっぱり出てきた。バカ見苦しいぞ。ｗｗｗ
> 無限に
> 無限に
> 無限に
> 無限に
> 無限に
0892デフォルトの名無しさん
2014/06/20(金) 20:25:18.42ID:OK+lAQ+1わっかんねー
0893デフォルトの名無しさん
2014/06/20(金) 20:25:51.90ID:9kUUzjJLちゃんとしたヤツならソケットオプションでタイムアウトを設定するでしょ。
>>888
blocking I/Oに複雑怪奇で挙動不審なスレッド実装
何も分かっていない素人ほど複雑な実装をする
0894デフォルトの名無しさん
2014/06/20(金) 20:28:16.42ID:JSi28Lkj0895デフォルトの名無しさん
2014/06/21(土) 00:24:24.12ID:mv9//OJ7そっから>>824,835,844,853,860と流れ
>>860はID:JSi28Lkj
>>886で>>883で書いた処理は「ブロッキングI/Oで書いてあるのは一目瞭然。」
という墓穴を掘り
しかも
>>844の
> if (read(s, &size, sizeof(size)) != sizeof(size))
> error();
>>883の
> if ((cc = read(s, buf + l, sz - l)) < 1)
> return 0;
まだ何も理解していないらしい
0896デフォルトの名無しさん
2014/06/21(土) 00:32:58.75ID:q5PhIp9u非同期とノンブロッキングの違いを知らないバカは引っ込んでいなさい。
0897835
2014/06/21(土) 01:48:01.43ID:nSPSSkcc>>>860はID:JSi28Lkj
>>860カキコは、自分(>>853)のアンカ間違いが原因
>>860が間違いを指摘してくれたので、>>863で訂正した
■ このスレッドは過去ログ倉庫に格納されています