アプリ版:「スタンプのみでお礼する」機能のリリースについて

データ量が大きい場合1回のrecvfrom()で全て受け取れるとは限らないので
while( RecvSize < TotalSize )
{
----RecvSize += recvfrom();
}
とやると思います。
しかし、マルチスレッドの場合、仮に上のwhile文が5回まわって全データ受信できるとしたとき、
2回目が回り終ってからスレッドが切り替わり、
別の(全く同じ動きをする)スレッドに移った場合、そちらで残り3回分のデータが受信されてしまうのではないでしょうか?

A 回答 (5件)

>例えば、クライアント側が1000バイトのデータを送信した時にサーバー側では100%成功するとして、1000バイトを一発で受信できるのでしょうか?



環境に依存するのか?
というのは実際に確認していませんが……
参考URLによると、約64KBくらいは送れる…ようです。
ただし、大きいサイズのUDPパケットにした場合、途中で1バイトでもデータが化けると全て破棄されてしまいますが。
# TCPだと再送…でしょうね。

下位レイヤーのEhternetパケットサイズくらいにしておくのが、精神的に安心かも知れません。
# 参考URLによると、IPパケットレベルで分断したとしても大丈夫…らしいですが……試したことはありません。
まあ、ケータイとか使っていた場合だとパケットサイズがEhternetのパケットより小さい…場合もあるかも知れませんが。
# 課金の際に使われるパケットサイズがソレに相当するのかどうかは不明…。

参考URL:http://www.atmarkit.co.jp/fwin2k/network/baswinl …
    • good
    • 0
この回答へのお礼

なるほど。ありがとうございました

お礼日時:2013/04/18 21:02

>続きのデータを受信するにはどうしたらよいのでしょうか?



TCPと同じようにストリームになるように処理すればいいです。
送信するUDPのデータ部にシーケンス番号とかの情報を付与して受信済みだったら破棄する。
順番が入れ替わっていたら正しい位置に読み込むように処理する。
ある程度待ってもデータが受信できなかったら送信元に再送を要求する。
とかいう処理を組みます。
つまりTCPの再実装をすればいいのです。
# だったらTCP使った方がマシですが、要求がUDPでは仕方ないかと。

この回答への補足

例えば、クライアント側が1000バイトのデータを送信した時にサーバー側では100%成功するとして、1000バイトを一発で受信できるのでしょうか?

補足日時:2013/04/18 13:40
    • good
    • 0

そもそも…


>while( RecvSize < TotalSize )
>{
>----RecvSize += recvfrom();
>}
コレで続きのデータが受信できる保証は全くありませんよ。

別の経路を通ってきた同じデータかも知れませんし、
前後が入れ替わっているかも知れません。
また、どっかのルータで破棄されてしまっているかも知れません。
UDPはそういうプロトコルです。

この回答への補足

続きのデータを受信するにはどうしたらよいのでしょうか?

補足日時:2013/04/18 13:17
    • good
    • 0

ストリーム型と違い、UDPは相手の送信1回につき、


当方の受信1回です。複数回の受信で補完可能と
考えるのは間違いです。

この回答への補足

1度ですべて受信できるか、受信失敗かのどちらかなのでしょうか?

補足日時:2013/04/18 13:17
    • good
    • 0

そういうつくりにしてしまったらそうなってしまうでしょうね。

この回答への補足

ですよね

補足日時:2013/04/18 13:14
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!