Does Socket IO involve Disk IO?

Question

If one process sends data through a socket to another process on the same machine how likely is it that a disk read/write will occur during transmission? There seems to be a soc

Answer 1

Not directly. TCP / UDP network sockets, over localhost, or a UNIX Domain Socket will operate in memory. UNIX Domain Sockets are typically the fastest option outside of dropping into kernel space with a module.

sockets over localhost pipes are nearly as simple as a couple of memcpy's between userspace and kernel space and back. In TCP case, you have the stack overhead.

Both files and sockets share the kernel abstraction of descriptor table, but that doesn't imply an actual file.

Of course, the database may trigger some write to a log, as a result of your transaction.

Answer 2

In the POSIX model, as well as many other kernels, files are not only in disks. Instead, every device is represented by a "special file". They live in directories or some sort of namespace, but accessing them is not disk access, even if they are placed in a directory on disk.

If you have memory pressure, then it's possible for some of your data buffers to get swapped out. But this has nothing to do with the "file" nature of devices. It's just using the disk as additional RAM.

So "Yes, socket I/O is file I/O, but not disk read/write."

Answer 3

Grabbing the "Design of the 4.4BSD Operating System", which describes what can be considered the reference implementation, sections 11.2 "implementation structure" and 11.3 "memory management", and in the absense of extreme memory pressure, it appears to be guaranteed that there will be no disk I/O involved in transmission.

Data transmitted is stored in special structures, mbufs and mbuf clusters, data is added or removed at either end of each buffer, directly. Probably the same buffers will be used over and over, being freed to a specific pool and then reallocated from there. Fresh buffers are allocated from the kernel malloc pool, which is not swappable. Growth of the number of buffers will obviously only occur when the consumer is slow and up to a limit.

Put simply, as to the data, in the reference implementation these buffers are not backed by files, much less by a file in the file system where the inode is placed, at best they would be backed by swap space, even if extremely unlikely to be paged out.

This only leaves out meta data and status information which may be on the inode. Naturally, inode creation and lookup will cause disk access. As to status, all I can think of is atime.

I can't find authoritative information regarding atime on UNIX domain sockets. But I tried on FreeBSD and on Linux and all four file times were always kept as the inode creation time. Even establishing a second connection to a UNIX domain socket does not seem to update atime.