Win32APIコミュのSocketについて

今ＬＩＮＵＸからＵＤＰで５４０Ｘ４８０の動画を５frame per secondで送信して、受信側は,VC++2008のWIN32アプリを作って受信しようとしています。
WireSharkで見ると、送信はできてるみたいなんですが、受信がうまくできないという問題にぶちあたっています。
そこで質問なんですが、ソケットが用意している受信バッファメモリの容量はどのくらいなんでしょうか？
ＬＩＮＵＸの側では１フレームのデータ量540x480x2バイト(YCbCr 4：2：2)をsendto()８回で一気に送信しています。はやすぎるでしょうか？０．２秒かけて送信すべきでしょうか？
WINDOWS側での受信も５４０ｘ４８０ｘ２バイトをrecv（）１回で受信しています。
何回かにわけて受信したほうが良いでしょうか？
以上よろしくお願いいたします。
ＯＳは、WINDOWS　ＸＰ
言語はVC++2008　ＷＩＮ３２アプリケーションでsocket2.hをインクルードしています。
目的はストリーミング再生です。
以上よろしくお願いします。　

コメント(6)

最初
全て
最新の40件

[1] mixiユーザー 01月21日 14:04

OSが持ってるバッファのサイズなんか知りませんが、普通はそんなものに依存しないようにプログラミングします。
つまり、recv()の返却値で何バイト受信したかわかるので、予定に達しなければループすれば良いだけです。（もしくはサイズ不明の場合は返却値が0になるまでループ。←こちらのほうが普通）

[2] mixiユーザー 01月21日 17:21

ありがとうございます。ソケットプログラムの常識がきけてありがたく思っています。
その関数の記述、ネット上にあったので、recievedの型宣言をいれてつかってみましたが、実行したらだまりこんでしまったので、ほっぽっていました。ほかのところに問題がありそうなので、メッセージボックス使ってデバッグしてみます。

[3] mixiユーザー 01月21日 17:27

以下の質問は、質問する場所を間違えてますがお許しください。Ｕstreamなどのストリーミングでは、パケットをどばっと送って、だまって、どばっと送って、だまってではなくて、時間的に均等な速度でパケットを送信しているんですよね？ＬＩＮＵＸ側の送信速度を均等にしてみる方法もためしてみます。

[4] mixiユーザー 01月21日 17:55

recv が 0 を返すのって、切断された時じゃなかったでしたっけ？　ブロッキングされるから、1 バイトでも届かないと止まっちゃったような……
だいぶ前の話なので、うろ覚えですが（＝ω＝；

[5] mixiユーザー 01月21日 20:03

ＭＳＤＮ苦手で、めったに読まないのですが、今回は読んだほうがよさそうです。recvが返す値をモニターできるようにがんばって改造してみます。

[6] mixiユーザー 01月22日 12:23

ネット上を調べてみると、sendto（）で送るバイト数がでかすぎるため、受信側でパケット廃棄がおきてるようです。そのため、予定のパケット数にみたないため、受信予定バイト数にみたないため、さらなる受信データをまっているためWIN32アプリがだまりこんでるようです。WINDOWS側のＭＴＵのサイズ以下のバイト数で、ＬＩＮＵＸ側でsendto()してやれば、うまくいきそうです。ありがとうございました。

ログインすると、みんなのコメントがもっと見れるよ