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

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

レス数が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/
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で終わってるかぐらいはチェックしないとね
0976デフォルトの名無しさん2014/10/30(木) 07:58:01.35ID:XUDk5/xR
「一行」の最大文字数に制限がないと
いつまでもCRLFを待つことになるな
メモリが足りなくなる
0977935じゃないが2014/10/30(木) 09:00:56.55ID:7Nbn+ucK
>>967
> で、ストリーム指向の本質的な特徴、言い換えるとブロック指向との決定的な違いは
> 論理メッセージに境界が存在しないこと（だから >>949 みたいな現象が生ずる）
分かってないのはお前。
バイトストリームと文字ストリームの違いを100字以内で述べよ。ｗ
0978デフォルトの名無しさん2014/10/30(木) 10:40:10.99ID:XcOLvYSq
バイトストリームと文字ストリームってなんだってググったら、Java用語か。
0979デフォルトの名無しさん2014/10/30(木) 11:37:05.82ID:1rX8nkrW
Javaからプログラミングに入った人とは話が合わないだろうな。
tcpipのプロトコルスタックすら知らなそう
0980デフォルトの名無しさん2014/10/30(木) 11:48:55.95ID:0o1hvduw
stream.Read ってのが
fgets みたいに改行(CRかLFかCRLFか) が来るまで or ﾊﾞｯﾌｧいっぱいになるまで
(タイムアウト付きで？)待ってくれるのけ？
0981デフォルトの名無しさん2014/10/30(木) 11:50:14.61ID:5HPq9xeF
実用性に乏しく自意識過剰だからな。
SとかAPLの住人みたく、村から出て来なければ良いのに
0982デフォルトの名無しさん2014/10/30(木) 12:18:20.05ID:7fc6WtHX
>>974
> UDP はデータを途中でちょん切ったりくっつけたりしないのですか？

しないよ、そもそも欠落したり順序入れ替わったりするのに、そんなことされたらどうしようもないし
0983デフォルトの名無しさん2014/10/30(木) 12:48:41.02ID:DI94Uq9B
>>980
.netにはStreamReaderクラスというのがあってSslStreamに「被せる」ことが出来る
そうすれば行単位で切り出すことは出来る（StreamReader.ReadLine）
ただIMAPの場合それだけじゃ解決にはならんみたいだけど
http://stackoverflow.com/questions/7743659/read-contents-from-sslstream
結局プロトコルが分かってないやつにまともなプログラミングは出来ない
0984デフォルトの名無しさん2014/10/30(木) 14:12:18.52ID:ptsqA+dw
>>976
バッファの拡張処理は(間違ってるけど)入ってるんだし、
今どきのPCの仮想メモリ領域を食いつぶすほど長い1行を返されるIMAPとか処理失敗で良いと思う。
0985デフォルトの名無しさん2014/10/30(木) 20:52:23.53ID:vmfUc9wP
>>972
ストリームプログラミングでは受信処理のバッファリング技法は常識だから、
>>965 の「読む」という単語を「バッファからのスキャン(=読み出し)」だと勝手に脳内変換していたよ
まさか初心者の質問主に対して1バイト毎にシステム関数 or システムコールを発行することを、
(手を抜くという)前書きも無しに提案するほどの馬鹿ではないと思ったからね
大変、失礼しました
0986デフォルトの名無しさん2014/10/30(木) 20:57:41.31ID:56wCgG0R
.netなんかいらない
0987デフォルトの名無しさん2014/10/30(木) 22:24:30.75ID:ok7EkcKd
あ
0988デフォルトの名無しさん2014/10/30(木) 22:28:06.87ID:vmfUc9wP
>>973
>>949 や 1) は >>967 で書いたストリーム指向の特徴である「論理メッセージ間に境界が無い」という話
で、2) は TCP というストリーム指向のトランスポート層プロトコル上で論理メッセージを実現するには、
アプリケーション層のプロトコル(今回のケースでは IMAP)で明示的に「論理メッセージ間に境界を与える」
機能を提供しなければならない(MUST)という話

両者の間には因果(原因と結果)という違いはあるけれど、問題の本質は同じだ
0989デフォルトの名無しさん2014/10/30(木) 22:35:08.76ID:vmfUc9wP
>>977
質問しているわけでもないし、そもそも今回の議論では IMAP を対象にしているのだから、
バイトストリームについて語る気はないよ
もし >>977 が知識自慢をしたいのなら、どうぞご自由にやってくれ

もしバイトストリームを対象にしたプログラミングに関心があるなら >>835 から解説しているから、
よく読んで勉強しなさい
0990デフォルトの名無しさん2014/10/30(木) 23:13:37.00ID:vmfUc9wP
>>974
>>982 のレスで正しくて、だぶん蛇足だと思うけど解説しとく

まず、UDP を利用するアプリケーションから見た「論理メッセージ」と
送信側/受信側の対向する UDP 間で転送される「データグラム」を混同しやすいので注意が必要

で、UDP 上の論理メッセージに関して「途中でちょん切ったりくっつけたり」することはない
ただし UDP は「順番が入れ替わったり取りこぼしが出る」信頼性の無いプロトコルだから、
たとえば送信側アプリが "123" と "456" という論理メッセージの送信を UDP へ要求した場合、
受信側アプリでは以下に示す４通りのパターンのいずれかになることが保証されている
　1) 正常な転送　　　　： "1234" "5678"
　2) 部分的な欠落（１）： "1234"
　3) 部分的な欠落（２）： "5678"
　4) すべて欠落　　　　： (* 何も受信しない *)
ここで、UDP は論理メッセージ間に境界が存在するブロック指向プロトコルだから、(ストリーム指向の TCP とは異なり)
"12" "34" "56" "78" と「途中でちょん切ったり」することはないし、"12345678" と勝手に「くっつけたり」することもない

次に UDP 間で転送されるデータグラムについては、分割(fragment)と組み立て(reassemble)が起きることがある
つまり送信側 UDP で１個のデータグラムが複数の IP パケットへと分割されてから転送され、
受信側 UDP によって複数の IP パケットが１個の データグラムへと組立てられることがある
その結果として「(UDP はデータグラムを)途中でちょん切ったりくっつけたり」することがある、と言える
ただし、アプリケーションからデータグラムの分割/組み立ては見えないから、一般にソケットプログラマが意識する必要はない
0991デフォルトの名無しさん2014/10/30(木) 23:19:41.98ID:LEQ9Vqbz
>>990
くっつくことあるんだ……
必ずくっつかないという前提のコード結構見るけど
あれ間違いなのか
0992デフォルトの名無しさん2014/10/30(木) 23:44:21.63ID:vmfUc9wP
>>991
UDP の 1) のケース "1234" "5678" は、recv 操作が必ず２回必要という意味だよ
つまり、たとえ１回目の recv 操作の時点ですでに２つの論理メッセージが到着していたとしても、
必ず "1234" だけが返される
そして２回目の recv 操作で、ようやく "5678" が返される

対して TCP では１回の recv 操作の時点で２つの論理メッセージが到着していれば、
それらを「くっつけて」"12345678" が返されることがある
だから、もし「必ずくっつかないという前提のコード」があれば、
それらは実行環境によっては動かなくなる可能性がある
言い換えると、アプリケーション層のプロトコルで
論理メッセージ間の境界を表現する仕様(たとえば CR/LF")を定義し、
アプリケーション層を実装するコードでは
その境界を意識した受信処理を実装しなければならない(MUST)

とは言っても、実際には >>980,983 が解説してくれているように、
多くの開発環境ではソケットと受信バッファ制御をカプセル化したモジュールが提供されているから、
それらを利用すればユーザアプリケーションのコードで境界を意識した実装の手間は最小限で済む

（おそらく質問者の >>935 にとっては、この一連の議論の中で、
　>>983 のレスが最も役に立ったのではないかと思われる）
0993デフォルトの名無しさん2014/10/31(金) 00:27:35.82ID:H/kqMfAT
>>990
> たとえば送信側アプリが "123" と "456" という論理メッセージの送信を UDP へ要求した場合、

> 　1) 正常な転送　　　　： "1234" "5678"

送ってもない 78 を受信しちゃうとか、アホの考えることはわからんわ w
逆転するケースも書いてないし、マジで知らん奴が見たら混乱するからアホは書くなよ

>>991
ID:vmfUc9wP は間違いだらけだし、わざとかどうかは知らんけど IP の話を混ぜてるから、スルーした方がいい
0994デフォルトの名無しさん2014/10/31(金) 00:42:53.89ID:uqHhdnYm
>>990 にミスがあったから訂正する（指摘ありがとう >>993）

まず最初にしょうもないタイプミスから

　X：たとえば送信側アプリが "123" と "456" という論理メッセージの送信を
　O：たとえば送信側アプリが "1234" と "5678" という論理メッセージの送信を


また、受信アプリのパターンに漏れがあったので、以下を追加する

　5) 逆転した転送　： "5678" "1234"
0995デフォルトの名無しさん2014/10/31(金) 05:19:26.68ID:mpqowuw2
うめ
0996デフォルトの名無しさん2014/10/31(金) 07:12:06.80ID:p/Rkb0jt
>>988
レイヤーの概念も理解できてないのか
本人がバカなのはいいけど、どや顔で間違ったこと書かれるのは迷惑でしかない
0997デフォルトの名無しさん2014/10/31(金) 07:19:05.04ID:H/kqMfAT
うめ〜
0998デフォルトの名無しさん2014/10/31(金) 07:36:43.50ID:PyU9LtcS
次スレ立ててから埋めろボケ

建てれなかった…
0999デフォルトの名無しさん2014/10/31(金) 07:59:10.66ID:2NZQQB6u
すまん、建てたよ〜

ネットワークプログラミング相談室 Port30
http://peace.2ch.net/test/read.cgi/tech/1414709836/
1000デフォルトの名無しさん2014/10/31(金) 08:21:00.63ID:PyU9LtcS
>>999
乙です

1000
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。