Why are TcpStream writes async at all?

[JonathanWilbur]

Forgive me if this is a newbie question. I haven't done much with sockets in compiled languages (I've programmed in NodeJS for years, in which you generally don't have to worry about this detail).

Why does Tokio's TcpStream return a future at all? Isn't the system's response to a write pretty much instantaneous? As far as I understand it, I think the way TCP writes work at a system level is that the programming language runtime just says "here is a range of bytes to write to this port" and the OS responds then and there whether or not it will or will not do this. In other words, what is the write future even waiting for / polling for?

[JonathanWilbur]

For a little more context, I am writing some code that I want to generalize over Write and AsyncWrite, and I'm not even sure that's possible, and it has me wondering why Tokio's TcpStream doesn't just implement std::io::Write.

[sfackler]

There is a finite buffer in the kernel of data that is queued up to be written out over the network. The kernel cannot write that data until it confirms that the recipient has already received the previously sent data. If the buffer fills, new writes need to wait.

[JonathanWilbur]

I see. Thank you!

[Darksonn]

Notice that TcpStream has a try_write method that is not async. This method will either immediately perform the write, or fail with an error saying "the OS buffer is full right now, come back later". The async part is the logic that knows when "later" is.