What is the Difference Between read() and recv() , and Between send() and write()?

Question

What is the difference between read() and recv(), and between send() and write() in socket programming in terms of performances, speed and other behaviors?

Solution 1

The difference is that recv()/send() work only on socket descriptors and let you specify certain options for the actual operation. Those functions are slightly more specialized (for instance, you can set a flag to ignore SIGPIPE, or to send out-of-band messages...).

Functions read()/write() are the universal file descriptor functions working on all descriptors.

Solution 2

Per the first hit on Google

read() is equivalent to recv() with a flags parameter of 0. Other values for the flags parameter change the behaviour of recv(). Similarly, write() is equivalent to send() with flags == 0.

Solution 3

read() and write() are more generic, they work with any file descriptor. However, they won't work on Windows.

You can pass additional options to send() and recv(), so you may have to used them in some cases.

Solution 4

I just noticed recently that when I used write() on a socket in Windows, it almost works (the FD passed to write() isn't the same as the one passed to send(); I used _open_osfhandle() to get the FD to pass to write()). However, it didn't work when I tried to send binary data that included character 10. write() somewhere inserted character 13 before this. Changing it to send() with a flags parameter of 0 fixed that problem. read() could have the reverse problem if 13-10 are consecutive in the binary data, but I haven't tested it. But that appears to be another possible difference between send() and write().

Solution 5

Another thing on linux is:

send does not allow to operate on non-socket fd. Thus, for example to write on usb port, write is necessary.

View more solutions

Comments

[carefulnow1]

Think of write as implemented like this: #define write(...) send(##__VA_ARGS__, 0).

[semaj]

Perhaps not having to deal with flags may be perceived as more convenient.

[Joey Adams]

This isn't the whole story. recv can only be used on a socket, and will produce an error if you try to use it on, say, STDIN_FILENO.

[Eloff]

This thread is now the first hit on Google, Google loves stackoverflow

[Joseph Quinsey]

+1. See also winsock not supporting read/write

[Abhinav Gauniyal]

This is incorrect, there's one other difference in case of datagrams of 0 length - If a zero-length datagram is pending, read(2) and recv() with a flags argument of zero provide different behavior. In this circumstance, read(2) has no effect (the datagram remains pending), while recv() consumes the pending datagram.

[Mecki]

@AbhinavGauniyal How would that provide different behavior? If there's a 0 byte datagram, both, recv and read will deliver no data to the caller but also no error. For the caller, the behavior is the same. The caller may not even know anything about datagrams (it may not know that this is a socket and not a file, it may not know that this is a datagram socket and not a stream socket). That the datagram stays pending is implicit knowledge about how IP stacks work in kernels and not visible to the caller. From caller perspective, they will still provide equal behavior.

[Abhinav Gauniyal]

@Mecki that's not implicit knowledge for everyone, take me for example :)

[sehe]

@Mecki if the datagram stays pending in only the read scenario, wouldn't that cause repeated reads to repeatedly "succeed" with zero-length reads (so, infinitely)?

[Mecki]

@sehe A read of 0 bytes without error is documented as "end-of-stream". So yes, you can keep reading as long as you won't but the system already told you that you are at the end thus you cannot expect any more data to be read. For recv the same is documented for stream sockets (e.g. TCP). Datagram sockets (e.g. UDP) have no beginning and no end, so returning zero bytes has no specified meaning for them.

[sehe]

@Mecki what does a non-blocking successful read of 0 bytes indicate? Does the datagram still stay pending? Exactly that, and only that, is worrying me: the behaviour that a datagram can stay pending even if successfully read. I'm not sure whether the situation can arise, which is wy I'd like to keep it in mind.

[Mecki]

@sehe If you are worried, why don't you use recv? The reason why recv and send where introduced in the first place was the fact that not all datagram concepts could be mapped to the world of streams. read and write treat everything as a stream of data, whether it is a pipe, a file, a device (e.g. a serial port) or a socket. Yet a socket is only a real stream if it uses TCP. If it uses UDP it's more like a block device. But if both sides use it like a stream, it will work like a stream and you cannot even send an empty UDP packet using write calls, so this situation won't arise.

[sehe]

@Mecki that's the approach I was gravitating to. It's just that lots of legacy code use the read style interface and I'd rather to be more sure that this is actually ok (with non-blocking reads). Thank you for your clarifying remarks. That's really helpful. I love when people take the time to share these bits of hard-earned experience. Cheers!

[Ericson2314]

OP is wrong about the read(0) differences not matting, see which just taught me this spectrum-os.org/lists/hyperkitty/list/[email protected]/‌​… For a UnixDomain datagram socket which is reliable, the buffer can fill up with empty packets, and send/write will block. read(0) means no progress, recv(0) means progress.

[JonS]

Windows also doesn't receive a UDP packet with less than 3 bytes of data, so, there's issues with Windows. :)