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

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

レス数が950を超えています。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/
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
酒買って来て
0930デフォルトの名無しさん2014/10/19(日) 09:09:45.23ID:y7reFn4b
LinuxでのSocketプログラミングについて教えてください。

・やりたいこと
IPエイリアスで複数アサインしたIPアドレス毎にU)ユニキャストとM)マルチキャストを送受信したい。
・試したこと
1) bind時にIPアドレスを指定(NO-2)
→M)マルチキャストが受信できない
2) UDPの場合はSO_REUSEADDRで同じポートを指定しても良い(NO-4)そうなので指定。
→M)マルチキャストが受信でき、希望通りの動作になった
★U)ユニキャストはNO-3で指定したインターフェースしか受信出来ないのは正しい動作か？

コードの概要は以下の通りです。
#define ETH0_IP "192.168.0.1"
#define ECH00_IP "192.168.0.2"

sock = socket(AF_INET, SOCK_DGRAM, 0);
#ifdef ANY_ADDR
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&opt, sizeof opt); // NO-4
#endif
addr.sin_family = AF_INET;
addr.sin_port = htons(3610);
#ifdef ANY_ADDR
addr.sin_addr.s_addr = INADDR_ANY; // NO-1
#else
addr.sin_addr.s_addr = inet_addr(ETH0_IP); // NO-2: eth0
#endif
bind(sock, (struct sockaddr *)&addr, sizeof addr);
mreq.imr_interface.s_addr = inet_addr(ETH0_IP); // NO-3
mreq.imr_multiaddr.s_addr = inet_addr("224.0.23.0");
setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char *)&mreq, sizeof mreq);

recvfrom(sock, buf, sizeof buf, 0, (struct sockaddr *)&from, &addr_len);
0931デフォルトの名無しさん2014/10/19(日) 10:34:01.70ID:rIEYfS5c
promiscuous
0932デフォルトの名無しさん2014/10/19(日) 21:12:24.57ID:y7reFn4b
>>930
> 2) UDPの場合はSO_REUSEADDRで同じポートを指定しても良い(NO-4)そうなので指定。
> →M)マルチキャストが受信でき、希望通りの動作になった
> ★U)ユニキャストはNO-3で指定したインターフェースしか受信出来ないのは正しい動作か？
今日試したらNGでした（昨日は何度も確かめたのですが）、、、

ANY_ADDRでない場合、マルチキャストを受信できるようにするにはどうしたらよいのでしょうか？

そもそも「addr.sin_addr.s_addr」には、受信（送信）したいIFのIP{アドレスを指定するのですよね？
以下のように指定してもマルチキャストが受信できるのは正しい動作なのでしょうか？

addr.sin_addr.s_addr = inet_addr("224.0.23.0");


ちなみにubuntu14.04 32bit版で試しています。
0933デフォルトの名無しさん2014/10/21(火) 07:44:23.09ID:KKrNe4lR
>>931
promiscuousはキャプチャ用途しか使ったことがないのですが、
promiscuousで受信して、送信は普通のsocket使えばよいのですか？

検索したらrecvmsg()を使う記事がありました。


とりあえず、ユニキャスト受信用のsocketとマルチキャスト受信用のsocketの2個使えば出来そうなことがわかりました。
＃マルチキャスト用のsocketを SO_REUSEADDR 指定
0934デフォルトの名無しさん2014/10/21(火) 17:54:02.03ID:QuOrKhyR
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
0935デフォルトの名無しさん2014/10/26(日) 20:22:36.66ID:RQyk7KlL
C#でグーグルメールの受信プログラムを書いています。
下記のプログラムを実行すると、データを末尾まで取得していないにもかかわらず、ループから抜ける事があります。
readByteCount == 0 のみをループの脱出条件にすると、Readで止まって（恐らくタイムアウト待ちになって）しまいます。
データを末尾まで確実に受取るにはどうすればよいのでしょう？

TcpClient client; // 接続処理、略
SslStream stream; // clientとの関連付け処理、略

byte[] command = Encoding.UTF8.GetBytes( ”__TAG__ FECTH ...略” );
stream.Write( command );

byte[] byteBuffer = new byte[ 256 ];
int offset = 0;

while ( true )
{
int readByteCount = stream.Read( byteBuffer, offset, byteBuffer.Length - offset );
offset += readByteCount;

if ( client.Available == 0 ||
readByteCount == 0 )
{
break;
}

if ( offset >= byteBuffer.Length )
{ // バッファの拡張処理 }

}
0936デフォルトの名無しさん2014/10/26(日) 21:15:04.04ID:kiy4PZ8g
>>935
お前にはいろいろな意味でムリだからプログラミングなんか止めてハローワークに行け
0937デフォルトの名無しさん2014/10/26(日) 21:20:17.41ID:RQyk7KlL
そこを何とかお願いします orz 。
0938デフォルトの名無しさん2014/10/26(日) 21:41:50.32ID:fx3FFnF6
>>935
・バッファに書き込んだ量がバッファと同じかより長いときにバッファの拡張処理って、バッファオーバーフローでも期待してんの？
　SslStream.Readに渡すバッファと、読み込んだデータを貯めこむバッファを分けるとかしとけ。
・TcpClient.AvailableってSSL使ってる時に読むものではないだろうし、そもそも終了処理に使うものでもない。
　読み込みのほうが早くてバッファが一時的に空になれば何時でも0になる。Stream.CanReadとかTcpClient.Connectedとかだったかな。

ストリームなんだし、その接続上で次の作業が出来る状態ならSslStream.Readで止まるのは正常。
受け取った内容を見てメッセージが揃ったら処理を行ってから次の受信をするとか、
自動で切断するような要求にするとかしとけ。具体的に何の通信してるかしらんからそこら辺までは知らん。
0939デフォルトの名無しさん2014/10/26(日) 21:50:44.31ID:RQyk7KlL
>>938
レス有難うございます。

取得している内容はIMAPコマンドのレスポンスです。
データをパースすれば末尾かどうか判断がつきますが、パースは受信後の処理と考えていました。
読み込みながらパース、ってプログラムが複雑になります。
サーバー側の送信が終わったかどうかを検知できればいいと思っていたのですが、不可能なのでしょうか。
0940デフォルトの名無しさん2014/10/27(月) 00:44:44.31ID:Ue/KzkP/
メッセージ長くらいは分かるんでないの？
0941デフォルトの名無しさん2014/10/27(月) 01:24:51.22ID:zpmVa3Ig
>>939
(接続ではなく)コマンドに対するタイムアウトを取った所で応答が遅いだけの場合と区別できない。
それにStreamReaderかなんかで行単位で読めるようにしとけば受信だけを先にやる必要も無いかと…
パースしながらレスポンス終わってないと判断したら次の行を読めば良い。

>>940
HTMLみたく行単位のテキストでデータ飛んでくるっぽいよ。
0942デフォルトの名無しさん2014/10/27(月) 02:08:45.10ID:zpmVa3Ig
HTMLじゃねぇ、HTTPとかSMTPだわorz
0943デフォルトの名無しさん2014/10/27(月) 07:38:19.67ID:WeE4lIts
どっちのﾌﾟﾛﾄｺﾙも
（行単位で送るとかの）パケットの単位は規定してない
0944デフォルトの名無しさん2014/10/27(月) 09:04:04.85ID:hLL1+/fU
ストリームでパースせずに判別できる通信の区切りって、
（分割や結合が発生するんだし）接続の切断だけじゃねーの？
0945デフォルトの名無しさん2014/10/27(月) 21:24:40.99ID:qcM8VoS/
たのしそーだね、プロトコル理解しないでプログラムするの
0946デフォルトの名無しさん2014/10/27(月) 23:13:55.86ID:lx3eJy35
>>944
なつかしいね
昔はSTXとかETXとか使ってたけど
0947デフォルトの名無しさん2014/10/28(火) 07:25:17.22ID:mh0S7TxZ
>>943
行単位で解釈するテキストデータだろ。
0948デフォルトの名無しさん2014/10/28(火) 13:34:10.13ID:Wloszx51
>>947
行という概念は、やってきた文字列を１文字づつパースして CR LF を検知しないと分からないよ
recv で得られるまとまったブロックとイコールにはならない
0949デフォルトの名無しさん2014/10/28(火) 13:38:17.97ID:Wloszx51
送信側が send で "1234[CR][LF]" と送っても
受信側は 1回の recv で "1234[CR][LF]" が得られるわけじゃない
"12" "34[CR]" "[LF]" と　ばらばらになることもある

送信側が send で "1234" の後に "[CR][LF]" と送っても
受信側は "1234[CR][LF]" と１つにまとまってしまうこともある
0950デフォルトの名無しさん2014/10/28(火) 18:00:46.57ID:s98vcxYO
>>949
どや顔で書いてるところ悪いけど、その手の話はこのスレだとほぼ常識だから、いちいち説明しなくていいよ。
0951デフォルトの名無しさん2014/10/28(火) 18:28:58.94ID:9LCIqjvU
なにこの頓珍漢な流れ・・・
みんなプロトコルスイートなんて糞食らえッて思ってるの？
0952デフォルトの名無しさん2014/10/28(火) 18:56:46.98ID:nE/DZDwO
>>950
ここは、2ch
そんな常識の通じないやつがうじゃうじゃ居るのさw
0953デフォルトの名無しさん2014/10/28(火) 20:38:47.51ID:kXG8DokC
>>950
それが分からん>>935がこの話題をスタートしたんだろうが
0954デフォルトの名無しさん2014/10/28(火) 21:25:31.88ID:lijd1TjR
>>950が一番良いドヤ顔だった。
0955デフォルトの名無しさん2014/10/28(火) 22:01:20.38ID:s98vcxYO
>>953
> それが分からん>>935がこの話題をスタートしたんだろうが

どこ見て >>935 がわかってないと判断してるんだ？
0956953ではない2014/10/28(火) 22:26:55.86ID:EyaGExbw
>>955
>>935 のコードと >>939 のレスを見れば、
TCPソケットがバイトストリームであることを分かっていないのは明らかだろ

だから、このスレに常駐している人にとっては常識であったとしても、
あえて >>949 が解説してあげたという判断は的確だったと思う
それをドヤ顔と解釈してしまう >>950 も、>>955 と同様に分かっていないのだろね
0957デフォルトの名無しさん2014/10/28(火) 22:26:57.65ID:kXG8DokC
>>955
あ、確かによく読まないでレスしちゃったｗ
これはパケット区切りの問題じゃなく、メッセージの終わりの判断をどうするかの問題だな
送信側のコネクション切断がどうなってるかも分からんし、受信タイムアウトをどう設定してるか知らんが（たぶんInfiniteのままなんだろうな）
0958デフォルトの名無しさん2014/10/28(火) 22:30:26.77ID:EyaGExbw
やっぱり >>957 は分かっていない、だーーめだこりゃ
0959デフォルトの名無しさん2014/10/28(火) 22:38:27.59ID:PVivPCTm
>>958
IDって知ってるか
0960デフォルトの名無しさん2014/10/28(火) 22:44:52.82ID:kXG8DokC
>>958
.netのSslStreamの仕様知った上でそれ言ってるの？
0961デフォルトの名無しさん2014/10/28(火) 22:52:35.49ID:EyaGExbw
,netうんぬん以前に、IMAP のプロトコル仕様を知らないんだろ？
というか、SMTP や POP も知らずにレスしているんだろなぁ....
0962デフォルトの名無しさん2014/10/28(火) 23:14:45.27ID:4+xiP14a
>>956
> >>935 のコードと >>939 のレスを見れば、

コードの while 文の意味もわかってないだろ
>>939 にはストリームに関する内容はないし
どこ見てるんだ？
コード見ればとか、曖昧なこと書かずに、具体的に指摘してみなよ
0963デフォルトの名無しさん2014/10/29(水) 00:15:55.98ID:bh+3tW1e
>>962
>>>939 にはストリームに関する内容はないし

えっ？！！
0964デフォルトの名無しさん2014/10/29(水) 00:40:42.10ID:xqvbqTHV
>>963
ストリームは言い過ぎだな
>>949 に関連した話にしとくわ
0965デフォルトの名無しさん2014/10/29(水) 03:03:23.01ID:rlFUUrRj
>>948
TCPは概念上はストリーム。「まとまった」というよりは「まとめた」という方が良いのでは？
実際1バイト毎に読んでCRLFを検知してもいいし…
たしかiriaだったかなんかのダウンローダでは1バイト毎に読んでたような気がする。
>>953>>956、>>962>>964
>>935はちゃんと連結してるしそこは分かってるっぽいよ、一応。
分かってないのはバッファの拡張とか処理単位をどう判別するかというプログラミングでの考え方。
0966デフォルトの名無しさん2014/10/29(水) 08:06:53.38ID:yXYfrv/j
.netか（笑）
0967デフォルトの名無しさん2014/10/30(木) 01:00:11.79ID:vmfUc9wP
>>965
>>>935はちゃんと連結してるしそこは分かってるっぽいよ、一応。

いや、分かっていないよ

通信プロトコルを分類する視点(切り口)の一つに「ストリーム指向」と「ブロック指向」がある
良く知られているように、TCP はストリーム指向で UDP はブロック指向に分類される
で、ストリーム指向の本質的な特徴、言い換えるとブロック指向との決定的な違いは
論理メッセージに境界が存在しないこと（だから >>949 みたいな現象が生ずる）

もしもこれを本当に理解しているなら：
・「データを末尾まで確実に受取るにはどうすればよいのでしょう？(>>935)」や
・「サーバー側の送信が終わったかどうかを検知できればいいと思っていたのですが、不可能なのでしょうか。(>>939)」
といった疑問には至らないはずだ

同様に「実際1バイト毎に読んでCRLFを検知してもいいし…(MAY)」も間違いで、
正しく理解していれば「実際1バイト毎に読んでCRLFを検知しなければならない(MUST)」と返答できる

>>950 によれば、このスレの住人であれば TCP がストリーム指向であることは常識らしいけど、
質問者(>>935)が知らないのは当然としても、回答者の中にもそんな常識を理解していないない人が
ゾロゾロいるってのは、いったいなんなんだろね？
0968デフォルトの名無しさん2014/10/30(木) 01:13:33.50ID:zL+DK8MX
>>967
子供じゃないんだから1バイトずつreadするとか
ドヤ顔で書くなよ
0969デフォルトの名無しさん2014/10/30(木) 01:20:33.96ID:vmfUc9wP
>>968
「読む」という言葉を「readシステムコールを発行する」にしか解釈できないお子様ですか？
0970デフォルトの名無しさん2014/10/30(木) 01:22:31.68ID:DI94Uq9B
CRLFを検出するのに1バイトずつreadする必要がある（MUST）とか言う人なんだから察してあげてください
0971デフォルトの名無しさん2014/10/30(木) 01:29:46.98ID:DI94Uq9B
SslStream.Readはreadシステムコールじゃないし
0972デフォルトの名無しさん2014/10/30(木) 01:50:35.24ID:ptsqA+dw
>>968
1バイトrecv(read)は(手を抜く)方法の一つに過ぎんと分からんあたり、
>>967も「プログラミングでの考え方」は苦手なのかもね。
0973デフォルトの名無しさん2014/10/30(木) 07:19:19.05ID:CP5oCMTU
>>967
いいかげんそろそろ
1) TCP がデータを途中でちょん切ったりくっつけたりする、のでアプリケーション側で必要に応じてデータを組み立てる必要がある
2) 行指向のプロトコルは CR/LF で区切って切り出す
の区別がつけられるようになれよ。
>>949 は 1) の話だし、>935 は状況がよくわからんが 2) の話と思われる。
0974デフォルトの名無しさん2014/10/30(木) 07:41:15.12ID:XUDk5/xR
UDP はデータを途中でちょん切ったりくっつけたりしないのですか？
順番が入れ替わったり取りこぼしが出るおまけ付じゃないんですか？
0975デフォルトの名無しさん2014/10/30(木) 07:55:13.99ID:UYNf/ZvJ
>935 のは　タイムアウト付き？受信＋受信データの連結で
終端の判断は、前者のタイムアウト付き？受信の受信バイト数でやってる

くみ上げた受信データが　CR/LFで終わってるかぐらいはチェックしないとね
レス数が950を超えています。1000を超えると書き込みができなくなります。