0

5秒ごとに数バイトを書き込むクライアントTCPソケットがあり、サーバーはバイトをすぐにエコーバックします。

Connect()とwrite()は正常に機能し、サーバーのエコーを通知する IP レイヤーにコールバックがあります。これは、送信間で確実に発生します。

しかし、ソケットからエコーを読み取るのに問題があります。

select()を使用して、着信エコーを通知しようとしました。奇妙なことに、ソケットを閉じるまでコールバックは呼び出されませんでした。ただし、これらの呼び出しのそれぞれについて、read()は -1/WOULD_BLOCK を返しました。

私の 2 番目のアプローチは、IP レイヤーが着信データを通知したときにread()を非同期的に呼び出します。同様に、read()は -1/WOULD_BLOCK のみを返します。read()がデータをソケット層に打ち負かす可能性があることは理解していますが、うまくいけば、次の書き込み後にさらに読み取ることを意味するだけです。

私は IP/ソケット初心者であり、select アプローチの動作が非常に奇妙だったので、どういうわけか API を誤用していると思う傾向があります。

ほぼ同じコード パスが UDP モードで完全に機能するため、これはばかげたバグではありません。唯一の違いは、UDP の場合、DATAGRAM モード、sendto()、および recvfrom() を使用することです。TCP の場合、STREAM モード、write()、および read() を使用します。

4

1 に答える 1

-1

サーバーは TCP エコー アプリケーションがクラッシュした状態にあったようですが、UDP エコーは問題なく、TCP レイヤーはまだトラフィックを処理できていました。

したがって、私のアプリは着信 TCP の IP から通知を受け取り、読み取るエコーがあると信じますが、ソケット層でデータを見つけられません。これは、API の使用または IP とソケットの間のレイヤーに問題があることを意味すると予想していました。いいえ、通知はエコーではなくサーバー ACK に対するものでした。これは TCP レイヤーで処理されるため、ソケットに到達することはありませんでした。

于 2011-11-29T01:12:05.467 に答える