|
>TCP ですか? それとも UDP ですか? TCPです。 >> パケットサイズを超えるデータ >パケットサイズって具体的に何のことを指していますか? send()/recv()での送信、受信レングスです。 この場合では、Recv時のレングスです。 >> 受信終了を示す返り値のlengs=0を受信できませんでした。 >送信側で close か shutdown しましたか? サーバー側でデータを送信し、終了したらshutdown/closeを行うべき なのでしょうか？ 確かにレングス０を受信できますが、その後に 送受信を必要な場合はどうすればいいのでしょうか？ httpサーバーにアクセスした時はレングス０が帰ってきたのですが、 shutdownしていたのでしょうか？ >> shutdown()では送信復帰ができないので、使えません。 >送信復帰って何ですか? 送信の終了を示す、レングス０を送るためにclose/shutdownを使うと、 その後にアクセスができなくなる。 shutodownしたソケットを再使用は危険とＭＳＤＮにでてます。 |
|
>>4024 どっかん sed -e '1s/o=test$/o=honban/' |
|
>>4025 ken 要は、ピアが送信したデータが全部届いたことを確認したいのですか? それならば、TCP/IP のレベルではなくアプリケーションのプロトコル レベルで実現するのが普通です。 例: - 送信側は「データ長 + データ」を送信。受信側は最初に受け取った データ長の分だけデータを受信したら、全データ到着とみなす。 - 改行コードをプロトコルのひとまとまりとみなす。送信側は データの末尾に改行コードをつけて送信。受信側は改行コードを 受け取ったら全データ受信とみなす。 端的に言うと、 recv の戻り値が 0 ＝ FIN が届いたとき です (ノンブロッキングモードなどの例外はあるかと思いますが)。 で、FIN を投げるには close か shutdown する必要があるということです。 |
|
レスありがとうございました。ｍ（＿＿）ｍ ＞要は、ピアが送信したデータが全部届いたことを確認したいのですか? はい。 ＞それならば、TCP/IP のレベルではなくアプリケーションのプロトコル ＞レベルで実現するのが普通です。 httpサーバーにつなげてｈｔｍｌを受信した場合に受信終了時にrecv()戻り値が 0を送っていたのは、shutdown()がかかっていたと判断していいのでしょうか？ だとすれば、再度htmlを受信する場合は、再度acceptでsocketを作成して受信 開始する必要があるのかテストする必要を感じました。 何度もレスいただきましてありがとうございました。 |
|
>>4028 ken > shutdown()がかかっていたと判断していいのでしょうか？ http サーバが shutdown か close したと判断してよいです。 > 再度htmlを受信する場合は、再度acceptでsocketを作成して受信 > 開始する必要があるのかテストする必要を感じました。 再度接続する場合は、クライアント側は socket を生成して connect しなおす必要があります。サーバ側はリスニングソケットは listen しっぱなしなので、クライアントが接続しなおしてきたら accept すれば よいです。 ただし毎回接続・切断を繰り返していては性能が出ないため、HTTP/1.1 に おいて keep-alive やパイプラインなどの、コネクションを切断せずに 複数のデータを取得するための仕組みが考案されているわけです (これも アプリケーション層での工夫です)。 |