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/

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で終わってるかぐらいはチェックしないとね

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を超えています。これ以上書き込みはできません。