5 ms·

Can someone explain why Heartbeat needed to return the text it was sent, rather than always returning an "OK" message? What advantage does returning the text g

Can someone explain why Heartbeat needed to return the text it was sent, rather than always returning an "OK" message? What advantage does returning the text give you?

jonnydark 13y ago
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.
- jon-wood 13y ago
  So instead you could be communicating with a marginally less dumb box, which nods and replies with whatever you said instead?
  - dferlemann 13y ago
    If it can reply whatever you requested accurately, then the established 2-way communication can be said to have the same quality.
hf 13y ago
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?
andyjohnson0 13y ago
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 https://tools.ietf.org/html/rfc6520
twic 13y ago
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.
- fulafel 13y ago
  > I have no idea why the payload is variable-sized For DTLS path MTU discovery (according to the heartbeat extension RFC).
  - EvanAnderson 13y ago
    That could have been accomplished with a fixed-length payload and variable-length padding, though.
- masklinn 13y ago
  > 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
- priomsrb 13y ago
  Makes sense. But 64k of data seems oddly large just to ID a message.
  - tedchs 13y ago
    64k is the max value of a 2-byte unsigned int, as 2^16 - 1 = 65535; is that the size of the length prefix?
antirez 13y ago
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.
Strilanc 13y ago
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.

Can someone explain why Heartbeat needed to return the text it was sent, rather than always returning an "OK" message? What advantage does returning the text give you?

jonnydark 13y ago

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.

jon-wood 13y ago
So instead you could be communicating with a marginally less dumb box, which nods and replies with whatever you said instead?
- dferlemann 13y ago
  If it can reply whatever you requested accurately, then the established 2-way communication can be said to have the same quality.

hf 13y ago

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?

andyjohnson0 13y ago

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 https://tools.ietf.org/html/rfc6520

twic 13y ago

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.

fulafel 13y ago
> I have no idea why the payload is variable-sized For DTLS path MTU discovery (according to the heartbeat extension RFC).
- EvanAnderson 13y ago
  That could have been accomplished with a fixed-length payload and variable-length padding, though.
masklinn 13y ago
> 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
priomsrb 13y ago
Makes sense. But 64k of data seems oddly large just to ID a message.
- tedchs 13y ago
  64k is the max value of a 2-byte unsigned int, as 2^16 - 1 = 65535; is that the size of the length prefix?

antirez 13y ago

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.

Strilanc 13y ago

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.