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

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

レス数が900を超えています。1000を超えると表示できなくなるよ。
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/
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は、素人がネットワークを勉強して知識を得たけれど、
それをプログラミングへ生半可に適用させて火傷を負う典型的なケース
水平軸における対向するレイヤ間のプロトコルと
垂直軸における上位レイヤへ提供するサービス(インターフェイス)という
交差する２つの概念をごっちゃにして理解しているように思われる
0836デフォルトの名無しさん2014/06/18(水) 21:05:08.89ID:YZhktGU/
IPoAC　か
0837デフォルトの名無しさん2014/06/18(水) 22:13:46.39ID:msRy+nk0
>>835はタコでおｋ？
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
おいｗ
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
銀行で徹夜したことについて謝罪と賠償を請求する
0857デフォルトの名無しさん2014/06/19(木) 21:30:03.44ID:lQ+uiTbF
良く読め、銀行間取引って書いてあるだろう？
日本は銀行間取引はRTGSで日銀経由でしている事を
知らない部外者だよ
0858デフォルトの名無しさん2014/06/19(木) 21:50:09.29ID:Oxl/97Kx
タコはみずから足を出す　片山まさゆき
0859デフォルトの名無しさん2014/06/20(金) 00:17:58.19ID:ZdNYCSgz
今読んでもノー爆は面白いよな
0860デフォルトの名無しさん2014/06/20(金) 06:36:54.81ID:JSi28Lkj
>>853
ますます意味不明

ネットワークプログラミング相談室 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/vA
擬似コードって言ってるんだから
http://pc12.2ch.net/test/read.cgi/tech/1246895188/950-952
だろう

正直こんなくどいことせず１バイトずつ読めばいいと思うが、
レスもなんかくどいし、まあそういう人なんだろう
0862デフォルトの名無しさん2014/06/20(金) 07:33:26.53ID:JSi28Lkj
>>853
> さて、この障害連絡に対して>>844はどう返答する？
error();
の中で処理する。

>>861
#318ではなく#938の可能性微レ存だが、銀行間の数十万件の取引レコードを
処理するプログラムを書く御仁がこんな単純な間違いをしたと、決めつける
のは良くない。本人の釈明を待つことにする。
08638352014/06/20(金) 09:20:27.39ID:fiYVjyLm
>>860
指摘ありがとう、レス#の間違いに気が付けなかった....

X: この過去スレの#318が自分のカキコになる
O: この過去スレの#938が自分のカキコになる

具体的な疑似コードは、過去レス(>>853)の #947 と #950-952
0864デフォルトの名無しさん2014/06/20(金) 10:59:08.88ID:JSi28Lkj
> tlv = reader.get()
プログラムがここで寝ている時に通信障害の連絡やってきた。
さて、>>853はどう対処する?
銀行間の数十万件の取引レコードの転送の場合は当然
　switch (tlv.type) {
default:
error();
brreak;
　}
なんて事はしないんだよな。 w
0865デフォルトの名無しさん2014/06/20(金) 11:05:28.51ID:JSi28Lkj
非同期(950-951)の場合

> 質問の意図に沿って「非同期I/Oを前提(だよね？)」とした場合、最も外側のTLV構造の処理は、
> ステートマシン(状態管理処理)と一体になる。疑似コードだと、こんな感じ。
こっちの場合も
　while (buf.size() > 0)
buf.size() == 0で抜けてしまうんだが、
　while (buf.size() > 0) {
}
if (state != STATE_COMPLETE)
error();
なんて事はしないんだよな。銀行間の数十万件の取引レコードの転送の場合は ｗ
08668352014/06/20(金) 11:57:20.19ID:fiYVjyLm
>>864
「寝ている」とはプロセスがブロック(or スレッド)された状態を意味するのかな？
もしそうなら、過去スレ#950の冒頭で述べているように：
・マルチスレッド構成でTCPコネクション単位に
　スレッド処理する設計ならば、ブロックには何の問題も無い
　新たに受信データ断片が到着すればスレッドのブロックが解除され、
　次のtype別処理を再開できるのだから
・シングルスレッド構成でイベント駆動処理を前提に設計しているのならば、
　過去スレ#947の疑似コードは不適切だから
　代わりに#950の疑似コードを使えばいい

>>865
バッファが空である(buf.size() == 0)ならば
現時点で到着していた受信データ断片の処理は終わったのだから、
ステートマシンの状態を保持したまま
すみやかにコールバック関数をリターンし、
次の受信イベント発生を待ちうけるべき
こんなのはイベント駆動プログラミングの基本だけど、
>>865はどんなエラー処理を期待しているのかな？
0867デフォルトの名無しさん2014/06/20(金) 12:21:42.37ID:JSi28Lkj
通信障害が発生してもreadは0を返さないのかな? 銀行間の数十万件の取引レコードの転送の場合は ｗ
0868デフォルトの名無しさん2014/06/20(金) 12:58:00.74ID:ZdNYCSgz
通信障害が起きたのならヘッダ部だろうとボディ部だろうと
途中でエラーになるんだから
安全を取って、その電文はエラーログに落として破棄、
ランプ光らせつつ再送に期待じゃない？
0869デフォルトの名無しさん2014/06/20(金) 13:01:45.74ID:FGk8LmcM
そのためにタイムアウトがある
0870デフォルトの名無しさん2014/06/20(金) 13:06:50.29ID:5fUr2YwO
何を言い争ってるのか知らんけど、
selectとnon blocking I/Oを使うんだぞ
それから実装はどうであれSOCK_STREAMのsocketからreadしたとき
何バイト読めるかは保証されていないぞ
08718352014/06/20(金) 13:42:16.97ID:fiYVjyLm
>>867
言われた事しかできません、という「ゆとり世代」かな？
しかたないから、面倒だけど疑似コードから実装コードへ落とし込む方法を
手取り足取り教えてあげよう
（実際に、要領の悪い新人さんを指導しているような気分になりつつあるw）

・イベント駆動を前提にした疑似コード#950であれば、
　OSやフレームワークからコールバックされた直後に
　readやreceiveシステムコールを発行してソケットから受信バッファに読み込み、
　それから#950の状態遷移関数 recv_acceptor をコールする
　（状態遷移関数内ではメモリ上のバッファだけを処理するから通信障害は無視できる）
　また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
　その部分で適切に通信障害発生時のエラー対応処理を実装する

・スレッドのブロックを前提にした同期プログラミングの疑似コード#947では、
　TLVリーダのget操作の中のシステムコール発行時に通信障害発生を判定する
　ただし、get操作がコードの複数箇所に拡散してしまうから、
　例外を投げるとかC言語ならlongjmpで大域脱出するとかして一ヶ所にまとめ、
　その部分で適切に通信障害発生時のエラー対応処理を実装する
　（もちろんget操作がエラーリターンするよう変更してもいいけど、可読性は落ちる）
0872デフォルトの名無しさん2014/06/20(金) 13:46:29.95ID:UaHzai/N
とタコが申しております
0873デフォルトの名無しさん2014/06/20(金) 13:48:20.34ID:+KfxKSN3
銀行系は言われてないことをやるとクビになるよ
08748352014/06/20(金) 13:51:26.94ID:fiYVjyLm
>>870
そのとおりで、TCP通信がバイト・ストリームであることを理解していれば、
保証されないことは当たり前なんだけど、それを保証するコード設計なんて
面倒くさくてやってられない、というのが>>844君の主張

>>844のコードだと、保証処理を放棄して、通信エラーとして扱うつもりでいる
0875デフォルトの名無しさん2014/06/20(金) 14:02:40.97ID:JSi28Lkj
>　また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
>　その部分で適切に通信障害発生時のエラー対応処理を実装する
銀行間の数十万件の取引レコードの転送の場合は、通信障害でTCPの切断が起こっ
た事と通信終了でreadが0を返した事を判別できるのか?

それはビックリだよ。ｗ
08768352014/06/20(金) 14:56:31.68ID:fiYVjyLm
>>875
まだ続けたいの？
しかたないね、新人教育を続けよう

・ここで扱っている受信メッセージ組立て処理の場合、
　メッセージ組み立て中の状態でreadが0を返せば、
　それは通信障害によるコネクション切断と判断する
　それ以外の状態、すなわち連続するメッセージ間で
　readが0を返した場合には判別できないから、
　単純に上位へコネクション切断を通知する

・上位のトランザクション処理ではトランザクション処理中に
　コネクション切断が通知されたなら通信障害と判断する
　ここで、トランザクションとは、たとえばHTTPサーバなら
　リクエスト受信開始からレスポンス送信完了までの期間を、
　SMTPであればHELLOコマンド受信開始からQUITコマンドに対する
　応答送信完了までの期間を指す
　それ以外の状態、すなわち連続するトランザクション間で
　コネクション切断が通知されたなら正常な通信終了と判断する

ビックリって、何を驚いているのかな？
もしかすると、こういった判定も面倒だからという理由で設計していなかったのね
まあ確かに、一般にネットワークプログラミングはエラー処理のかたまりだから、
慣れない素人さんや学生さんが最初にとまどってしまうのは無理もないのかな
0877デフォルトの名無しさん2014/06/20(金) 15:01:21.09ID:JSi28Lkj
> 　メッセージ組み立て中の状態でreadが0を返せば、
> 　それは通信障害によるコネクション切断と判断する
後出し仕様 ｗｗｗｗ

>　また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
>　その部分で適切に通信障害発生時のエラー対応処理を実装する
下位レイヤーが上位レイヤーの状態を知ってるんですかあ? 銀行間の数十万件の取引レコードの転送の場合は。ｗｗｗｗ
08788352014/06/20(金) 16:00:42.03ID:fiYVjyLm
>>877
> 後出し仕様 ｗｗｗｗ

もともと過去レスの疑似コードでは、
readシステムコールを発行する詳細コードを抽象化し、
TLVリーダやバッファといった用語を書いている
そして、その実装は各自で考えてもらえばいいと思っていたけど、
ID:JSi28Lkj君が「僕には実装方法が分かりません」と言い出したから
丁寧に教えてあげているだけだよ


> 下位レイヤーが上位レイヤーの状態を知ってるんですかあ?

知らないから、下位の受信メッセージ組立て処理では
　　「単純に上位へコネクション切断を通知」して
　　上位のトランザクション処理に判別を委ねると、
>>876で述べている
もう少し冷静になって文章を読んだほうがいいと思うよ
こちらでは技術関連は指導できても、日本語の読解能力までは面倒みれないから
0879デフォルトの名無しさん2014/06/20(金) 16:10:48.55ID:ix5aqk/e
大型はハードウェアがなんでもやってくれる、らしい（適当）
0880デフォルトの名無しさん2014/06/20(金) 17:15:41.46ID:fmtXRHPg
>通信障害でTCPの切断が起こった事と通信終了でreadが0を返した事を判別できるのか

通信障害は-1が返ってくるし
0881デフォルトの名無しさん2014/06/20(金) 17:37:38.06ID:qd8xX9Tw
>>874
> TCP通信がバイト・ストリームであることを理解していれば、
> 保証されないことは当たり前なんだけど
このスレの住人なら、例外を除いてそんなの常識だし、君が力説してるようなことも常識。
それを上から目線で、さもお前らが知らないことを教えてやろう的なレスするから嫌われる。
0882デフォルトの名無しさん2014/06/20(金) 17:40:23.44ID:JSi28Lkj
>>878
> 知らないから、下位の受信メッセージ組立て処理では

>>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;
}
08848352014/06/20(金) 18:28:03.97ID:fiYVjyLm
>>880
いや、通信障害という業界用語は、データリンク・レベルのエラー(回線障害)から
アプリケーション間プロトコルのエラーまで、幅広いエラーを含んでいる
そして>>876で書いたように、システムコールが正常終了しても
通信サービスとしてはエラーとして扱うケースもあるから、
read/recvのリターン値 -1 だけでは、すべての通信障害を検出できない


>>881
わかった、では自分は落ちるから、後の >>883(ID: JSi28Lkj)の世話、よろしくたのむ


>>882
君への最後のレスを返す

受信メッセージ組立て処理(下位)とトランザクション処理(上位)という
２個のモジュールがあるという構成を理解できていないのかな？
これ以上は面倒だし、後の世話は>>881にまかせたので、説明は止めとく
0885デフォルトの名無しさん2014/06/20(金) 18:52:29.32ID:fmtXRHPg
>>883
ブロッキングI/Oだと無限にループから抜け出せない可能性があるし
ノンブロッキングI/Oだとデータ受信が間に合わないときにエラーが
返ってくるので0復帰してしまう
100点満点中10点だな
0886デフォルトの名無しさん2014/06/20(金) 20:05:21.58ID:JSi28Lkj
>>884
> 受信メッセージ組立て処理(下位)とトランザクション処理(上位)という
> ２個のモジュールがあるという構成を理解できていないのかな？
> これ以上は面倒だし、後の世話は>>881にまかせたので、説明は止めとく
ぷぷぷっ また後付け。

>　また、通信障害発生の判定はシステムコール発行直後の一ヶ所に限定できるから、
>　その部分で適切に通信障害発生時のエラー対応処理を実装する
システムコール発行直後でエラー処理を行うとはっきり書いてあるわけだが。

>>885
最後だと言っときながら、余計な事書いて恥の上塗り。みっともないねえ。

> ブロッキングI/Oだと無限にループから抜け出せない可能性があるし
ねーよ。バカ。ｗｗｗ

> ノンブロッキングI/Oだとデータ受信が間に合わないときにエラーが
バカには分からないらしいが、ブロッキングI/Oで書いてあるのは一目瞭然。ｗｗｗ
0887デフォルトの名無しさん2014/06/20(金) 20:12:22.25ID:fmtXRHPg
TCP通信はキープアライブのタイムアウトが非常に長いから
ブロッキングI/Oでreadすると、通信遮断で返ってこなくなるよ
経験のなさがもろに出てるね
0888デフォルトの名無しさん2014/06/20(金) 20:15:02.16ID:5fUr2YwO
blocking I/Oを使う時点で素人
とか言ってみる
0889デフォルトの名無しさん2014/06/20(金) 20:19:43.47ID:JSi28Lkj
>>880
> 通信障害は-1が返ってくるし
はい、ダウト。 ｗｗｗ

TCPの切断では-1は返ってこない。このバカこの程度の知識で偉そうにしてて大爆笑だわ。
0890デフォルトの名無しさん2014/06/20(金) 20:20:15.90ID:nPXPLHY1
ID:JSi28Lkj が哀れすぎ。見ててつらい
0891デフォルトの名無しさん2014/06/20(金) 20:22:24.13ID:JSi28Lkj
>>887
最後と言ってたのにやっぱり出てきた。バカ見苦しいぞ。ｗｗｗ

> 無限に
> 無限に
> 無限に
> 無限に
> 無限に
0892デフォルトの名無しさん2014/06/20(金) 20:25:18.42ID:OK+lAQ+1
ID:fiYVjyLm　＝　ID:fmtXRHPg　説なの？
わっかんねー
0893デフォルトの名無しさん2014/06/20(金) 20:25:51.90ID:9kUUzjJL
>>887
ちゃんとしたヤツならソケットオプションでタイムアウトを設定するでしょ。

>>888
blocking I/Oに複雑怪奇で挙動不審なスレッド実装
何も分かっていない素人ほど複雑な実装をする
0894デフォルトの名無しさん2014/06/20(金) 20:28:16.42ID:JSi28Lkj
ID:fで始まるバカが複数いるとは思わんかったわ。ｗ
0895デフォルトの名無しさん2014/06/21(土) 00:24:24.12ID:mv9//OJ7
発端の>>761は非ブロッキングの話
そっから>>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
>>895
非同期とノンブロッキングの違いを知らないバカは引っ込んでいなさい。
08978352014/06/21(土) 01:48:01.43ID:nSPSSkcc
>>895
>>>860はID:JSi28Lkj

>>860カキコは、自分(>>853)のアンカ間違いが原因
>>860が間違いを指摘してくれたので、>>863で訂正した
0898デフォルトの名無しさん2014/06/23(月) 12:37:22.72ID:XKl4yasN
>>893
TCPのタイムアウトはソケットオプションにないよ、
って思ったら、Linuxではちょっと前から追加になってるのね。
0899デフォルトの名無しさん2014/06/23(月) 13:07:02.22ID:HIGf9m9i
SO_SNDTIMEO, RCVTIMEO はどこに効くのかよくわからん
0900デフォルトの名無しさん2014/06/24(火) 00:37:23.49ID:6s1BpAfu
>>899
それぞれ送信、受信のタイムアウトだよ
0901デフォルトの名無しさん2014/07/22(火) 10:03:57.24ID:8Q3uJhWX
どうも AP経由だとTCPといえども
データが欠損してる気がする
ローミング時の挙動ってどうなんだろう？
0902デフォルトの名無しさん2014/07/22(火) 11:48:50.67ID:lgTh8/Jm
データが欠損って、歯抜けのパケットがあるってこと？
なら、欠損することについてはTCPもUDPも区別なく、IPパケットなら起こりうるよ
ただし、TCPはreceiverからACKがこなければsenderは再送するという
機能があり、データがちゃんと送信されることが保証されてる
TCPについてなにか勘違いしてないか？
0903デフォルトの名無しさん2014/07/22(火) 21:10:24.05ID:vNYu1ctv
>>901
>>902でおおむね正しいけどあえて補足すると、TCPはコネクション指向プロトコルだから
「TCPコネクション上での通信に限って」データ損失の無い事が保証されている
だから、ローミングであろうが「TCPコネクションさえ維持できていれば」
TCPレベルでのデータの欠落は起きえない(もし起きたらそれはTCPスタック実装のバグ)

しかしそれでもユーザから見ればデータが欠落しているとしか思えない現象が起きる事はある
これはアプリケーション設計の失敗であることが多い(もちろんTCPスタックのバグかもしれない....)
有線ネットワークとは異なり、無線ネットワーク上での通信は電波状況の変化によって
「頻繁にTCPコネクションが切断される」から、モバイル対応アプリ開発においては
この無線ネットワーク固有の状況に対応できるよう設計しなければならない

たとえば有線ネットワーク上で巨大なファイルを転送したい時には FTP が使われることが多いけど、
数分から数十分にわたるファイル転送処理中に一度でも電波状況が悪くなれば失敗するから、
無線ネットワーク上では役に立たないケースが多い
これの対処方法は定番から特殊なプロトコルまでいくつかあるけど、こういった検討課題に
気付かず設計された通信システムだと、データの欠落を原因とする障害は頻繁に起こりうる
0904デフォルトの名無しさん2014/07/22(火) 21:46:38.65ID:m2X37Pt+
で、結局何が言いたいんだ？
0905デフォルトの名無しさん2014/07/22(火) 21:59:21.87ID:zC8syPvs
途方も無くつまらない質問だなあ、と。
0906デフォルトの名無しさん2014/07/22(火) 22:00:41.38ID:gLVnM0Vt
ベネッセ万歳ですね
0907デフォルトの名無しさん2014/07/22(火) 22:08:10.13ID:/QF06o+e
やっぱ 状況によって欠損あり得るよな
ちなみに端末は悪名高きiPad
APメーカーが言ってたけど
APが相手に見えないように存在消してるのに
接続しにくるみたい

昔のTCPでも欠損する winsock思い出した
0908デフォルトの名無しさん2014/07/22(火) 22:35:12.36ID:/QF06o+e
>>903
ちなみに 1つ10万以上するAPを
そこそこの数使ってるから
切断は ほぼない(想定内のエリアなら)
チェックサム付けたけどデータ狂う
0909デフォルトの名無しさん2014/07/22(火) 22:49:56.54ID:hoMdn42a
>>901
TCP/IPとモバイルプロトコルが分かってないのだろう
0910デフォルトの名無しさん2014/07/23(水) 06:36:18.15ID:37asru4I
>>908
> 1つ10万以上するAPを

なんで、この手のアホは型番書かないんだろう...
0911デフォルトの名無しさん2014/07/23(水) 09:12:30.49ID:oA1ueuw9
過去、TCPで化けるんです、という事象には何回も遭遇したけど、
TCPやネットワークの問題だったことは一度もない。
たいていはsocketの使い方を間違えている。
0912デフォルトの名無しさん2014/07/23(水) 10:07:59.35ID:m2ygW4DO
欠損なんかしないよ
0913デフォルトの名無しさん2014/07/23(水) 18:47:22.83ID:EQ67YqPb
>>912
途中が欠損することはないが欠損以降が全く来ない事はある。
0914デフォルトの名無しさん2014/07/23(水) 19:08:27.52ID:SLj4nbIO
それはあれだよ
0915デフォルトの名無しさん2014/07/23(水) 20:39:00.57ID:vSOuwJl2
それ　はあれ　だよ
0916デフォルトの名無しさん2014/07/23(水) 20:42:09.93ID:Y8sMWbLm
携帯を折られたとき
0917デフォルトの名無しさん2014/07/24(木) 09:59:13.77ID:rCcZLsKC
携帯を折られたとき
0918デフォルトの名無しさん2014/07/24(木) 10:05:55.74ID:b1nwvn72
まねすんな
0919デフォルトの名無しさん2014/07/24(木) 10:41:06.80ID:f/H2aifY
折りたたみ携帯を折られたとき
0920デフォルトの名無しさん2014/07/24(木) 10:49:22.16ID:dgV+vw+i
逆パカされた時
0921デフォルトの名無しさん2014/07/24(木) 21:34:45.24ID:rO5lcI/m
>>913
ケーブル抜けてるよ
0922デフォルトの名無しさん2014/07/24(木) 22:28:02.03ID:6eyTGVml
雷で停電
0923デフォルトの名無しさん2014/07/25(金) 00:05:24.44ID:cQJQccdW
玄関あけたら2分で落雷
0924デフォルトの名無しさん2014/07/25(金) 00:38:37.79ID:JGW0iq/W
ダンボールとアルミ箔を用意します
0925デフォルトの名無しさん2014/07/25(金) 07:42:28.86ID:vg9xmyXR
圧電素子は？
0926デフォルトの名無しさん2014/07/25(金) 07:46:42.85ID:6iRU1OZj
ゼーベック効果
ペルチェ効果
ピエゾ効果
トムソン効果

>>925 に寄与するのはどれでしょう
0927デフォルトの名無しさん2014/07/27(日) 00:47:33.80ID:yUcSBAyV
>>907
ねえよ、バーカ
0928デフォルトの名無しさん2014/07/27(日) 14:27:54.75ID:A4exl8IK
今日はどこへ行こうかな〜
0929デフォルトの名無しさん2014/07/27(日) 15:01:46.62ID:yKnfO4Xf
酒買って来て
レス数が900を超えています。1000を超えると表示できなくなるよ。