0

問題 - ストリーミング サーバーで作業していて、次を使用してノンブロッキング ソケットを作成しました。

flag=fcntl(m_fd,F_GETFL);
flag|=O_NONBLOCK;
fcntl(m_fd,F_SETFL,flag);

サーバーは、コードを使用してメディア ファイルの内容を送信します。

bool SendData(const char *pData,long nSize)
{
    int fd=m_pSock->get_fd();
    fd_set write_flag;
    while(1)
    {   
        FD_ZERO(&write_flag);
        FD_SET(fd,&write_flag);
        struct timeval tout;
        tout.tv_sec=0;
        tout.tv_usec=500000;

        int res=select(fd+1,0,&write_flag,0,&tout);
        if(-1==res)
        {
            print("select() failure\n");
            return false;
        }
        if(1==res)
        {
            unsigned long sndLen=0;
            if(!m_pSock->send(pData,nSize,&sndLen))
            {
                print(socket send() failure\n");
                return false;
            }
            nSize-=sndLen;
            if(!nSize)
            return true;    //everything is sent
        }
    }
}

上記のコードを使用して、200 秒の音声ファイルをストリーミングしています。これは、サーバーが利用可能な全帯域幅 (スロットル オフ) を使用して 2 ～ 3 秒でストリーミングすることを期待していますが、問題は、サーバーがストリーミングに199 ～ 200 秒かかっていることです。完全な内容。デバッグ中にコメントしました

m_pSock->send()

セクション & ファイルをローカルにダンプしようとしました。ファイルのダンプには1 ～ 2 秒かかります。

質問 - NonBlocking TCP ソケットを使用している場合、send()に時間がかかるのはなぜですか?

  • データは常に利用可能であるため、select()はすぐに戻ります (ファイルのダンプ中に見たように)。send()はクライアント側のrecv()の影響を受けるということですか?

これに関する情報は役に立ちます。クライアントの行動は私たちの範囲外です。

4

3 に答える 3

1

クライアントは、ネットワークのジッターを避けるためにバッファリングを行っている可能性がありますが、オーディオ ファイルをリアルタイムで再生している可能性があります。したがって、ファイル転送速度は、クライアントがデータを消費する速度に一致します。200秒の音声ファイルですので、転送完了まで約200秒かかります。

于 2012-07-06T06:31:44.047 に答える
0

問題は、クライアント側がブロッキング TCP を使用している場合に加えて、ファイルの「プレーヤー」までバッファ/キューなどを使用せずに単一のスレッドですべてのデータを処理している場合、非ブロッキングである側がTCP/IP プロトコル スタック バッファ、NIC バッファなどがいっぱいになるまで速度を上げます。その後、最終的には、クライアント側がデータを消費するのと同じ速さでしかデータを送信できなくなります. TCP は信頼性の高いポイント ツー ポイント プロトコルであることを忘れないでください。

テストでは、クライアント コードはどこから来たのですか? 誰かが書いた単純なテスト クライアントですか?

于 2012-07-06T06:44:21.143 に答える
0

TCP の出力バッファと入力バッファはおそらくオーディオ ファイルよりもはるかに小さいため、受信アプリケーションの読み取り速度によって送信速度が遅くなる可能性があります。

送信側の TCP 出力バッファと受信側の入力バッファの両方がいっぱいになると、送信側の TCP スタックは送信側からデータを受信できなくなります。そのため、空きができるまで送信はブロックされます。

受信側が TCP ストリームを読み取る場合、再生にはデータと同じ速度が必要です。その後、転送には約 200 秒かかります。または少し少ない。

これは、受信側でアプリケーション層のバッファリングを使用することで回避できます。

于 2012-07-06T06:40:49.263 に答える