在C,TCP的服务器/客户端中,如果我在程序中连续读/写会怎么样?这是可能的,还是我总是遵循“客户端写 - >服务器读 - >服务器写 - >客户端读”结构吗?
有可能做这样的事吗?或者是否可能从客户端的第二次读取中收到服务器中第三次写入的数据,以及其他类似的坏处?
client.c
write (1)
read (2)
read (3)
read (4)
server.c
read (1)
write (2)
write (3)
write (4)
答案 0 :(得分:4)
TCP传输数据流。
因此,对write
的N次调用可能导致对read
的M次调用(其中N> 0且M> 0且N <= =传输的字节数且M <=传输的字节数)。
然而,在所涉及的各种写入和读取之间将保留发送字节的顺序。
作为直接结果,您不能只使用write
和read
的普通调用来同步进程。例如,您需要添加每个步骤要传输的字节数。
简化:您需要在TCP流之上使用应用程序级协议。
答案 1 :(得分:3)
是的,这是可能的。读取将阻止(默认情况下),直到可以在套接字上读取数据。没有必要尝试按特定顺序安排读取和写入,您的程序将等到有read()
调用返回之前有需要阅读的内容。
您的代码将导致:
Server blocks in read()
Client write()s
Client blocks in read()
Server receives data, read() returns
Server write()s three times
Client receives data, read(1) returns
Client's read(2) is called and returns as soon as data arrive
Client's read(3) is called and returns as soon as data arrive
在一个非常快速的链接上,服务器write()和客户端read()可能在大致相同的时间发生,甚至交错,但服务器write()s将始终在订单和客户的read()将始终按顺序排列。
如果套接字是SOCK_STREAM,则保留数据排序,例如。像你一样询问的TCP或UNIX套接字。
因此read(2)将始终返回用于TCP套接字的write(2)中写入的数据。
如果你使用了UDP套接字(SOCK_DGRAM的默认设置),你可能会发现这些消息是无序接收的,或者根本没有。