You may not have noticed, but stream-based network IO is famously not like regular file IO. Well, mostly network read IO. Believing that it is is a common socket programming error.

A great deal of the time, programs and programmers do not want to care about this. When they say 'read ten bytes', they want to get back exactly ten bytes (assuming that the stream is not closed on them) and they do not care how long they have to wait for those ten bytes to all show up. In most cases, if you return less than ten bytes all they will do is turn around and immediately try to read more bytes.

(Programmers who actively want short reads tend to set their network sockets to nonblocking mode and do other special things.)

By now it is far too late to change the base behavior of systems. But if your language has a network IO package, it is high time that you provided not just a read() operation but also a readall() operation to go with it. In fact, I would go so far as to say that what you should really provide is read() and readshort(); readshort() would be the current 'read whatever the OS says is there', and read() would do 'read all' unless the socket was in non-blocking mode.

(If you have a moral objection to doing this in your basic network support layer, please provide it as a common mixin or simple additional layer that is easy to stack on top of a bare network socket.)

Such an interface would be an error-shielding interface. It would avoid a class of errors, or at least avoid requiring programmers to repeatedly write the same code to do network re-reading correctly. In almost all cases the overall code would get simpler; either the higher layer wouldn't have to worry about this any more or programmers using the higher layer on network streams wouldn't have to shim something to do re-reads in between the higher layer and the actual network socket.

It's quite possible that making this change would expose the fact that you need additional interfaces, for example a 'read until you see character X' interface for simple (text) line-based network protocols like SMTP.

(Simple servers for such protocols mostly work today because read() almost always returns a full line and only a single line.)

A similar thing can and should be done for write() on any platform where a write to a blocking network socket doesn't necessarily write out all of the data. (This is not all of them.)

(This grump is brought to you by me having to deal with this issue yet again.)

By the way and as a side note, this means that a great many simple examples of network programming in high level languages are wrong. By ignoring this issue (either through ignorance or a desire for simplicity) they lure programmers into writing subtly erroneous network code, code that works most of the time but not always.

(That not ignoring this issue would make your simple network IO examples 'too complex' is in fact a sign that your language needs a simpler interface to this issue.)