What does it mean to flush a socket?
Asked Answered
R

4

29

I don't really know much about sockets except how to read and write to them as if they were files. I know a little about using socket selectors. I don't get why you have to flush a socket, what's actually happening there? The bits just hang out somewhere in memory until they get pushed off? I read some things online about sockets, but it's all very abstract and high level.

What's actually happening here?

Reformed answered 27/5, 2009 at 6:41 Comment(1)
From the user point of view there is no such thing as flushing a socket. There is internally, however.Scrupulous
A
56

There's a certain amount of overhead involved in writing to a network socket and sending data. If data were sent every time byte entered the socket, you'd end up with 40+ bytes of TCP header for every byte of actual data. (Assuming you're using a TCP socket, of course. Other sockets will have different values). In order to avoid such inefficiency, the socket maintains a local buffer, which is usually somewhat over 1000 bytes. When that buffer is filled, a header is wrapped around the data and the packet is sent off to its destination.

In many cases, you don't need each packet to be sent immediately; if you're transferring a file, early data may not be of any use without the final data of the file, so this works well. If you need to force data to be sent immediately, however, flushing the buffer will send any data which has not yet been sent.

Note that when you close a socket, it automatically flushes any remaning data, so there's no need to flush before you close.

Artemas answered 27/5, 2009 at 6:51 Comment(2)
how does NAGL tie into this, do you know?Janellejanene
@Janellejanene It decides when to send data. Contrary to this answer, it doesn’t just happen when the buffer is full.Scrupulous
A
14

You can't really flush a socket.

(From How can I force a socket to send the data in its buffer?)

You can't force it. Period. TCP makes up its own mind as to when it can send data. Now, normally when you call write() on a TCP socket,
TCP will indeed send a segment, but there's no guarantee and no way to force this. There are lots of reasons why TCP will not send a
segment: a closed window and the Nagle algorithm are two things to
come immediately to mind.

Read the full post, it is quite in-depth and clarified a lot of things for me.

Artiste answered 11/8, 2011 at 11:7 Comment(0)
H
4

Nagle's algorithm is often in use on sockets. In a nutshell, it waits until there's a non-trivial amount of data to send. The problem is to achieve a balance between transmission latency and the overhead cost of sending a packet of data.

The larger the data payload, the smaller the wasted bandwidth because the header is of (mostly) fixed size. Furthermore intermediate systems generally have performance limits based more significantly on the packet-rate, not the overall data-rate.

Horsemanship answered 6/6, 2009 at 14:36 Comment(4)
This answer doesn't really address how flushing a socket ties in, though.Scatology
How is this answer relevant to this question. does flush override Nagle's algorithm and send immediately?Camise
@QuinnTaylor It does actually, as soon as you recognize that from the user point of view there is no which thing as flushing a socket.Scrupulous
@Camise There is no such thing as flushing a socket other than what is described here.Scrupulous
B
2

At the lowest level you interact with TCP sockets using the recv()/WSARecv() and send()/WSASend() system calls, there is no flush system call for sockets.

Flushing is an user space concept. When a library wraps the OS socket functions into its own API, it may implement its own buffering, and flushing causes this application level buffer to be passed to the send() system call.

Keep in mind that the send() system call does not guarantee immediate sending, because the kernel may buffer the outgoing data for about 0.2 seconds before sending it unless so set the TCP_NODELAY flag on the socket.

Bireme answered 9/11, 2023 at 21:29 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.