Comment by eternalban | Hacker News Reader

Comment by eternalban | Hacker News Reader

Parent Full thread

[I haven't watched the video - I come to HN to read .. but that said]

> I don't think the communication protocol between two processes, services, whatever has have the property of being synchronous or asynchronous.

This is news to those of us who have implemented or designed communication protocols between processes.

> It is more about how each side of the communication handles it internally.

You are confusing processing of information obtained via communication with the pattern of communication. A synchronous protocol is a lock-step exchange of data/meta-data between two communicating processes. You can have processes communicating via a synchronous protocol that handle the processing in an asynchronous manner. An asynchronous protocol does not require exchange of messages to be lock-step

   A: HELO w/ MY CREDS <blocks>
   B: HELO - ACCEPT CREDS
   A: GET 'foo' <blocks>
   B: HERE is 'foo' <data> 
   [A: queue foo data for async processing by an internal comp A']
   A: GET 'bar' <blocks>
   [A': processed 'foo'] 
   B: HERE is 'bar' <data> 
   [A: queue bar data for async processing by an internal comp A']
   ...
   [A': processed 'bar']

and then there could be this:

   A: HELO w/ MY CREDS <blocks>
   B: HELO - ACCEPT CREDS  
   A: GET 'foo' <doesn't block>
   A: GET 'bar' <doesn't block>
   B: HERE is 'foo' <data>       # B may even return 'bar' first in some cases 
   [A: queue foo data for processing ...]
   A: GET 'foobar' <doesn't block>
   B: HERE is 'bar' <data> 
   [A: queue bar data for processing]
   ...
   B: HERE is 'foobar' <data> 
   ...

Quaint diagrams we used to draw for protocols - this is just some random example from a quick search [note how it transitions from a sync handshake to async comm]:

https://www.researchgate.net/publication/344006359/figure/fi...

I think it's all a bit "in the eye of the beholder" as far as protocols. Here I mean the message patterns and implicit state models, ignoring software design choices.

I'd say the IP protocol is asynchronous in terms of flinging individual packets around. They can be buffered, delayed, etc. They can arrive at the recipient without notice.

TCP starts to make it "more synchronous" since the two parties have to signal back and forth negotiate coordinated buffers and perform a sequence of steps within timeout deadlines.

SMTP seems more asynchronous in terms of whole messages being delivered and stored without protocol-level coordination between messages.

Non-pipelined HTTP 1.1 is both "more synchronous" and "less synchronous". It adds more timing behavior to the use of TCP to have simplex phases of client-sending and server-sending. At the same time, you can think of the request and response messages a bit like email messages to be stored and forwarded. But there are narrower response time limits for an HTTP message pair to succeed or fail at the transport level compared to a message and reply via email.

Of course, these different scenarios are happening all at once in a normal SMTP or HTTP exchange. So the abstractions layered over introduce new protocol units which may have synchronous or asynchronous characteristics, while the underlying primitives continue to also occur with their own apparent characteristics.

A similar issue exists with voice over IP. The protocol is duplex streams which seems quite asynchronous to me. But a typical conversation involves synchronization at human language boundaries and is quite sensitive to latency. Conference calls can fall apart when participants lose synchronization and start talking over each other. This is a social communication protocol layered over the underlying audio streaming protocol.

What I think GP meant is that [a]synchrony is a property of how one locally handles the need to "wait" for something, and if the protocols being spoken are do not impose order then this is really evident. E.g.,

  A: do thing #0 (no wait)
  A: do thing #1 (no wait)
  A: do thing #2 (no wait)
  B: thing #1 result
  A: do thing #3 (no wait)
  B: thing #0 result
  B: thing #3 result
  A: do thing #4 (no wait)
  B: thing #2 result
  B: thing #4 result

In this example A reads responses from B but never sits idle while "waiting" for those responses.

At some point A might need to "block" waiting for all the results for extant requests. What does "block" mean? It could mean: not sending any more requests, not allowing the user to initiate more requests, not being responsive in the UI, and probably more.

A could also speak the same protocol synchronously:

  A: do thing #0
  A: <wait>
  B: thing #0 result
  A: do thing #1
  A: <wait>
  ...

Assuming this protocol does not impose ordering, then, the [a]synchrony property is purely local to A.

Even if order is required, A might do other things "while waiting" for responses from B, and that... might be asynchrony. In the traditional Unix single-threaded process model A might block but the system continues to be responsive because the kernel is not synchronous even if A is, and so the kernel can schedule other processes while A "waits" -- but no one would say that A is async in that case, nor would anyone say that the whole system is async either unless A's functionality were spread over multiple processes in such a way that the UI (or whatever) has an "async feel".

In reality we might have blocking behaviors even in fully async cases like the first one above owing to flow control, but even there the meaning of "blocking" will depend on what A does when B can't receive more messages due to flow control: A could transmit backpressure to whatever is causing A to generate messages to B, or A could stop generating messages to B, or A could stop being responsive in its UI, or...

I believe this is what TFA was getting at: that the meanings of these words (blocking, waiting, asynchronous, etc.) are somewhat fuzzy. Still, when someone says "let's do this asynchronously" I know what they mean, at least for the purposes of the discussion in which it comes up -- in actual design and implementation, once again, the meaning may vary, but the intent is still the same! The intent of doing things asynchronously is to amortize latency and better utilize local resources.

I believe what you describe is called pipelining.

Reply on news.ycombinator.com