Of course I can do something like

int wantToSend = someValue;
int sent = client.write(data, size);
if (sent < 0 || wantToSend < sent) {
 // no space left
}

But I find it more elegant to know up front.

Print.h states:

 // add availableForWrite to make compatible with Arduino Print.h
 // default to zero, meaning "a single write may block"
 // should be overriden by subclasses with buffering
 virtual int availableForWrite() { return 0; }

Looking at the implementations of WiFiClient::write(), none of them use buffering. Instead they try up to WIFI_CLIENT_MAX_WRITE_RETRY times to send the data, and return how much was actually sent. Thus these functions basically block until all data sends. For that reason it doesn't make sense to have an availableForWrite(). size_t WiFiClient::write(Stream &stream) looks async, but it also blocks until the stream empties.

I see. I missed that comment somehow 🤔

I'm looking at the regular "write(data, size)" method though. That doesn't seem to be blocking (MSG_DONTWAIT) but keeps writing and ultimately tries (#defined) 10 times before returning the amount written.

But then again, how to write large data? EAGAIN and EWOULDBLOCK result in zero bytes written. Should I divide the data into small chunks myself?

Wait, does socket send return EWOULDBLOCK only when the buffer is completely full? Or also when size is bigger then the buffer's free space?

(I really should read a book about socket programming, this is completely new for me)