recv,wsarecv如何发现对方传送结束问题,100分

Question

我知道TCP有PUSH代表最后一段,我想知道在接收端socket操作中,是如何告诉应用程序某段数据结束了,包括recv和wsarecv.
答对者加分,不够再加!

Answer 1

The PSH bit is not a record er and is independent of segment boundaries. The transmitter SHOULD collapse successive PSH bits when it packetizes data, to send the largest possible segment. A TCP MAY implement PUSH flags on SEND calls. If PUSH flags are not implemented, then the sending TCP: (1) must not buffer data indefinitely, and (2) MUST set the PSH bit in the last buffered segment (i.e., when there is no more queued data to be sent). The discussion in RFC-793 on pages 48, 50, and 74 erroneously implies that a received PSH flag must be passed to the application layer. Passing a received PSH flag to the application layer is now OPTIONAL. An application program is logically required to set the PUSH flag in a SEND call whenever it needs to force delivery of the data to avoid a communication deadlock. However, a TCP SHOULD send a maximum-sized segment whenever possible, to improve performance (see Section 4.2.3.4). DISCUSSION: When the PUSH flag is not implemented on SEND calls, i.e., when the application/TCP interface uses a pure streaming model, responsibility for aggregating any tiny data fragments to form reasonable sized segments is partially borne by the application layer. Generally, an interactive application protocol must set the PUSH flag at least in the last SEND call in each command or response sequence. A bulk transfer protocol like FTP should set the PUSH flag on the last segment of a file or when necessary to prevent buffer deadlock. At the receiver, the PSH bit forces buffered data to be delivered to the application (even if less than a full buffer has been received). Conversely, the lack of a PSH bit can be used to avoid unnecessary wakeup calls to the application process; this can be an important performance optimization for large timesharing hosts. Passing the PSH bit to the receiving application allows an analogous optimization within the application.Read more: http://www.faqs.org/rfcs/rfc1122.html#ixzz0Z5VlTHD7从上面的解释看,是可以知道的呀,是optional项

Answer 2

int readLen = Receive(m_recvBuf + m_bufOffset, 1500, 0);if(readLen <= 0)
{
  TRACE("消息接收完毕!");
}最保险的机智是你发送端和接受端有消息ACK或者链路层的接收响应,把消息格式定义好确保你接受到完整的消息 

Answer 3

俺E文不大行，但看意思这个PUSH标志应该是TCP协议栈软件用来处理缓冲区的，并不一定意味着最后一段。而且在接收方，这个标志似乎没有暴露到recv这些api接口上。

Answer 4

Generally, an interactive application protocol must set the PUSH flag at least in the last SEND call in each command or response sequence. A bulk transfer protocol like FTP should set the PUSH flag on the last segment of a file or when necessary to prevent buffer deadlock. At the receiver, the PSH bit forces buffered data to be delivered to the application (even if less than a full buffer has been received). Conversely, the lack of a PSH bit can be used to avoid unnecessary wakeup calls to the application process; this can be an important performance optimization for large timesharing hosts. Passing the PSH bit to the receiving application allows an analogous optimization within the application.
上面的话是指肯定有一个信号是给接收方了.肯定是有这一项的,难道微软打了埋伏? 如果靠应用层是可以,但能在socket解决的事,还是希望在socket解决.

Answer 5

首先声明，本人菜鸟，在些发表一下本人的愚见tcp协议是可靠的传输协议，所以每次发送的返回的实际发送的数据长度就是客户端已经收到的长度，你在发送数据前，先发送数据长度，在客户端接收的时候把每次实际接收到的长度加起来，当等于前面说的数据长度时，就表明发送完成了，