It is common for ping-pong protocols to allow to specify some data in the ping packet that is returned in the pong packet.

It allows to build more abstractions in the client side without the server realizing it at all. For example:

* Setting as payload the time at which the packet was sent allows to calculate client-side the round-trip-time without adding complexity (you don't need to remember the sent time client side).

* Setting as payload an unique incremental ID allows an event-driven client that may have application side reordering of packets to understand the order of the arriving replies.

* Setting the payload to a client-known pattern is useful to detect server-side or network data corruption.

And so forth... ICMP ping-pong packets use the same mechanism.

The heartbeat extension was originally designed for DTLS, which is TLS over UDP. UDP datagrams don't arrive in a guaranteed order, or within any bounded time. If heartbeat used a fixed message, then if you sent a request and receive a response using DTLS, you would have no way of knowing if that response was a response to that request, or to some other request you sent ten minutes ago, or what.

Allowing the request and response to carry a payload lets you mark each request with a unique identifier, so that you can recognise the resulting responses.

It's basically like an HTTP cookie. In reverse.

I have no idea why the payload is variable-sized, rather than being (say) a fixed 32 bits. I would guess the specifier didn't want to bake in assumptions about how much space a unique identifier would need.

> I have no idea why the payload is variable-sized

For DTLS path MTU discovery (according to the heartbeat extension RFC).

That could have been accomplished with a fixed-length payload and variable-length padding, though.

I'm probably missing something, but if it's going to be of variable size, why not just a null-terminated string? Why does the size itself need to be specified along with the string?

EDIT: Nevermind, this thread [0] has more discussion about it.

[0] https://news.ycombinator.com/item?id=7572081

> I would guess the specifier didn't want to bake in assumptions about how much space a unique identifier would need.

Yep, although an up-to-64KB buffer seems like overkill you'd get a guy getting by on a byte, while the other one has a distributed system and wants UUID or something

Makes sense. But 64k of data seems oddly large just to ID a message.

64k is the max value of a 2-byte unsigned int, as 2^16 - 1 = 65535; is that the size of the length prefix?

I looked at the code and I'm pretty sure I saw that the payload size variable was a long int, so I was confused by this too.

This has puzzled me too. The RFC that describes the extension [1] seems to be silent on the actual rationale for allowing an arbitrary message.

All I can think of is that the designer of the extension wanted to specify a mechanism with enough extensibility to allow requester-generated sequence numbers with arbitrary formats to be sent. Alternatively, if the sender makes the message unpredictable and compares the request and response messages and finds them the same, then this provides some weak "proof" that the responding server is the one that the request was sent to.

I don't find either of these particularly convincing though.

[1] https://tools.ietf.org/html/rfc6520

It verifies that you're actually connected to the server and it is listening to you rather than just some dumb box that keeps nodding and replying with "OK" with glazed over eyes regardless of what you say.

So instead you could be communicating with a marginally less dumb box, which nods and replies with whatever you said instead?

If it can reply whatever you requested accurately, then the established 2-way communication can be said to have the same quality.

That's precisely the point that riles our tinfoil-hated friends: Heartbeat should be a simple matter of hi-ho's ad infinitum (ie: no or constant-space parameters).

This is, of course, glossing over the fact that TLS over a TCP link doesn't actually need a heartbeat. TLS/UDP does, granted. Ever heard of DTLS?

Here's a use case it allows: computing latency without storing the time locally. Drop the current time into the heartbeat, plus a cryptographic signature so the server can't change it. The signature requires a variable sized payload, or it won't be able to fit in ten years.