Bitcoin Forum

all i have to do is to send the "version" message and the other node (v. 0.19.0.1) sends 3 messages: version+verack (as expected) alongside an alert message which seems strange because i have not yet sent any verack messages back to complete the handshake.
is alert a special case or does it happen with other messages too?

i am also wondering why bitcoin core nodes can't recognize a message if it has preceding garbage bytes (random bytes before the magic) but they are fine if it is after it. what's the point of magic then if it isn't used as the message start marker?

It's because of TCP guaranteeing order.

The verack is sent first, so the other node will receive that first. If they like the version and verack, then they can send their own verack indicating readiness to receive further messages. If not, they will just kill the connection. The protocol is not violated by sending the alert immediately after the verack and nothing bad happens.

The alert message in this instance is a special message. It is part of the old P2P alert system that has since been deprecated and removed. The alert message is only sent to old nodes that indicate that they still have the alert system. It is being sent immediately after connecting because that alert message will cause the "Alert Key Compromised" message to be displayed on nodes that still have the alert system.

However sending messages immediately after verack before receiving the other node's verack is a common thing to do. There are a couple of other messages that are not responses to anything and can just be sent immediately after verack. You should see this same behavior with the sendheaders message.

Because it is expecting only messages in discrete chunks. TCP generally gives it the messages in a single recv(). It is expecting the magic bytes at the beginning. If someone is sending garbage, then it wants to just disconnect as fast as possible because that could be a DoS attack. However garbage at the end of the message is fine because the message itself is self descriptive in size and garbage after the message can be discarded.

The magic bytes are not a start marker. They are an unique identifier.

As Andrew stated, a message is a discrete chunk of data, but this is not determined by TCP or recv(). Bitcoin divides the TCP stream into distinct messages, each containing a header and a payload. Garbage cannot precede or follow a message, but the payload can contain extra data at the end that will be ignored.

it is a little odd because i was expecting the "handshake" to be more strict like how TCP handshake (SYN, ACK packets exchange before any data is exchanged) is strict.

interesting. i have not encountered this yet, they all seem to be waiting for my verack after sending the 3 messages.