来自我的客户:
send(socket, "this is a buffer", ...);
send(socket, "second buffer", ...);
从我的服务器,recv
保证使用r
中的"this is a buffer"
结束一个块并从s
开始另一个带"second buffer'
的块?< / p>
答案 0 :(得分:3)
不,一点也不。由于网络的所有处理,您无法控制接收数据时发生的情况。你无法做出任何关于你在任何recv调用中获得多少的假设(除了它将是&lt; =发送的金额)。你可以得到一个字节。
答案 1 :(得分:0)
不,Windows套接字(与其他基于TCP的抽象一样)是流式传输。您正在寻找使用Windows套接字的打包方式。
答案 2 :(得分:0)
我不会依赖它。阅读时,你可能会立刻得到它们。中间有很多东西 - 数据包重新排序,网络延迟等,它们会影响数据包实际到达另一端的时间,并且可能是第二个缓冲区可能比第一个更快地找到它并且将等待(如果你& #39;重新使用TCP,如果没有,则第一个到达。然后到达的任何东西都会给你。您应该在接收方解析数据而不依赖于它的发送方式(TCP为您提供某些订单保证,UDP也不会这样做。)
答案 3 :(得分:0)
如果希望在收到指定数量的字节之前阻止recv,则可以使用标志MSG_WAITALL。
http://pubs.opengroup.org/onlinepubs/007904975/functions/recv.html
答案 4 :(得分:0)
对于UDP和其他数据报协议,将根据需要保留数据包边界。对于TCP和其他流协议,没有这样的运气。