boost.asio's socket's recieve/send functions are bad?

Question

Data may be read from or written to a connected TCP socket using the receive(), async_receive(), send() or async_send() member functions. However, as these could result in short writes or reads, an application will typically use the following operations instead: read(), async_read(), write() and async_write().

I don't really understand that remark as read(), async_read(), write() and async_write() can also end up in short writes or reads, right?
Why are those functions not the same?
Should I use them at all?
Can someone clarify that remark for me?

Answer 1

The read, async_read, write, and async_write are composed functions that call the class functions multiple times until the requested number of bytes is transmitted. They are included by the library as a convenience. Otherwise, every developer would need to implement the same logic.

The class functions wrap the underlying OS functions directly, which basically state in the documentation: these functions may return before all of the bytes are transmitted.

In most cases, you should use the free (composed) functions to transmit data.

Answer 2

First of all, you have to understand the word "asynchronous", it simply means "need not to wait". After asynchronous actions are invoked, the following action will execute without waiting for the asynchronous action return. While synchronous have to wait until previous synchronous actions return. The two following samples from Boost.Asio would make sense: A synchronous TCP daytime server

(Oops! not enough reputation, the second sample is easy to find though, called "An asynchronous TCP daytime server")