That was not a description. I merely appended the primary motivation for pipelining. We trade latency for throughput in pipelining.*
It's also not opinion. When pipelining, the communicating peers are not sychronizing their interactions; it occurs in an a-synchronous manner. Where does opinion get into the picture?
* since we typically end up packing a multiplicity of requests in a given MTU and further we can saturate the link (on both ends) since we are not blocking for a response before sending the next request. In synchronous protocols, the full bandwidth can't be utilized as there are cycles where the link (on respective sides) is idle.
As for description of pipelining, this question came up years ago in Redis's newsgroup and I posted the following (It starts sync and the final segment is 'pipelining' :)
I was not referring to the statement that pipelining serves maximizing throughput. I agree with that. I was referring to the statement that pipelining would be a kind of asynchronous communication.
Look, you are welcome to your 'opinion' but the q remains (given that there are only 2 choices here) as how pipeling is a form of "synchronous" communication.
[p.s.]:
pipelining is a kind of async comm because unlike the general case of asynchrony, the response order mirrors the request order (which is not a requirement of the general case.)
I never said that pipelining is synchronous communication. If our go back to my original post. I merely said that (a)synchronicy is not a feature of a protocol, but how sender/receiver handle the communication internally.
