Hacker News Reader

Comment by veblen | Hacker News Reader

Imagine two blind people who want to have a conversation. Before they start, each person needs to ensure that the other can both speak and hear. Typically, one person begins by asking, 'Can you hear me?' to check if the other can hear them. The second person responds with 'Yes,' confirming that they can hear. Then, the second person asks, 'Can you hear me?' and the first person replies, 'Yes,' completing the process.

In total, there are four exchanges (two questions and two answers). However, if you look closely, the second person's reply of 'Yes' already confirms that they can both hear and speak. Therefore, the second 'Can you hear me?' is unnecessary. With just three exchanges (one question and two answers), both people know that they can send and receive messages.

View on HN

What if the first blind person was also deaf and just trolling the other blind person so wouldn't the second "Can you hear me?" be needed?

Troll Control Protocol

Then you set the “evil” bit

Actually, the second answer is also unnecessary. The conversation can go like this:

A: Can you hear me?

B: Yes

A: What time is it?

B: 5 o'clock

A: Thank you, goodbye!

B: Goobye!

Nothing is lost compared to:

A: Can you hear me?

B: Yes

A: Yes

A: What time is it?

[...]

Well there the “what time is it?” serves as the “great, I can hear you too!” but I take it that the point is that B needs some reply from A to know that they can hear them.

You could also just start with "What time is it?" and see what you get back, right?

I believe that's UDP. :)

it ? is time What What ?

Who is this? What? No! You called me!

But person A might not be ready to ask a question, and person B doesn't want to wait around forever to have a conversation with someone who might not even be able to hear them.

Both sides need to know to "commit" to the connection.

Isn't the whole point here that handshakes are cheaper compared to the actual content? If you use the content as the handshake itself, you can end up with huge content only to find out that the conversation didn't work.

That conversation can also go like;

A: Can you hear me?

B: Yes

A: What is the full unabridged story of War and Peace?

B: <...>

A: I am going to a take a nap for now, goodbye!

B: ... Goodbye!

TCP is two way and in your example B has no idea that A can receive the messages it is sending. Example: What if B needs to ask A about the date in the same conversation, it doesn't know for sure it would get a reply (it can try but that's not TCP then).

The problem is the other way around.

A: Can you hear me? B: Yes B: What time is it? A: ...

At the point that B has replied Yes, B knows that it can hear A and that it can send to A but it doesn't know that A can hear B. As long as A makes the first move in the rest of the conversation that's fine - the next message from A confirms that B's "Yes" was received, but if A has nothing to say then B has to send it's next query and hope that A received the Yes successfully. If it didn't then B thinks the connection is established but it actually hasn't been.

TCP Fast Open does you one better:

A: If you can hear me, what time is it?

B: Yeah I can hear you; it’s 5.

Reply on news.ycombinator.com