Comment by hiAndrewQuinn 2 days ago
Actually, when you put it like that, sending 'hello' back might be the best thing you could do. They sent you a SYN, you send back and ACK, then the real conversation can begin.
I suddenly no longer agree with TFA. This makes way more sense to me in this light.
In what way is that better than "Hello. How do I do x?" If they never reply, that's of no practical difference from just sending "Hello" and not getting a reply.
In TCP, it's useful because it happens in a different layer of abstraction. Even then, QUIC was developed (partly) because it was realised there's no point waiting for the full SYN / SYN ACK / ACK before starting some of the higher-level exchange (although the early data transfer in QUIC is used for TLS initiation rather than application-level data).
It's better because X might take a while to write correctly, and you might want some assurance that you have the other person's full attention first before you even send that message. It's a commitment mechanism of sorts.
This doesn’t make sense to me. What does it matter if you have their attention first? It’s asynchronous communication. I find it so damn rude to demand my attention first before you begin typing out a long message. Like do you want me to watch the chat bubble animation while you type or something?
Yes, I do. Sometimes people want (more) synchronous communication despite the asynchronous medium. Among other things that helps guarantee a speedy response. A lot of people use asynchronicity as a way to simply avoid answering in a timely fashion, so framing it like this can make sense if you can't afford that.
In addition, seeing the chat bubbles appear moments after you finish your round is a good sign the other person isn't multitasking and letting their own attention get fractured.
I never found it rude to begin with, just not using the medium to its strengths. But this has me realizing maybe it's a deliberate way to eschew those strengths, for some purpose or another.
The relevance of TFA is that this only works if the initiating party is still connected, and to make matters worse there is no ERR_SOCKET_CLOSED returned by most chat clients if that party got distracted before seeing the ACK. Then minutes or hours later they get back "hey sorry, missed your reply, ${QUERY}"
when they could have just included `${QUERY}` in the initial send, or at least `framing(${QUERY})`.
Right, but the problem is that with async communication, you don't need a synchronous ack handshake.
Instead you can pipeline both messages: `[hello][are you coming to lunch with us?]`, and that's more convenient and efficient for the receiver and sender.
The problem that TFA is referring to is that context switching is very expensive for the receiver, so without pipelining, the receiver pays a huge cost just to send back the ack and then again to finally reply to the payload once it is sent. The receiver is asking that you send all messages; it prefers to buffer them.