Am 14.03.20 um 10:13 schrieb Willy Tarreau:
>> This is about the "Table Definition Message", more specifically the
>> "Encoded Table Type".
>> docs/peers-v2.0.txt says:
> There's also doc/peers.txt which is more recent and more complete. I don't
> know if there are still some parts of peers-v2.0 which were not covered by
> peers.txt.

Neither of them are sufficient to understand the protocol. Not even both
of them taken together. Some paragraphs are also pretty unclear. All in
all I had to read the code to understand what's happening.

The peers.txt is more correct on what it says, but it's missing
essential information (e.g. what incremental updates are).
peers-v2.0.txt contains more information, but also more mistakes
(especially regarding the "magic numbers" such as the table types).

In short: There is much work to be done regarding those documents. I'm
not sure whether I would recommend rewriting them from scratch, but
that's probably easier than trying to fix them up.

>> 1) Is my understanding correct that the type refers to SMP_T_*?
> I didn't think it was the case but it indeed looks like this is what
> is being sent over the wire! I'm seeing in peers.c:
>         /* encode table type */
>         intencode(st->table->type, &cursor);
> Where table->type definitely is one of these SMP_T_* values.

Okay, then I understood that line correctly.

>> 2) Can I rely the order of the SMP_T_* enum *NOT* changing (i.e. new
>> types are only added at the end)? Or rather: Is the peer protocol stable
>> enough for third party implementations or can it change at will during
>> HAProxy upgrades?
> No we shouldn't rely on this and we should instead change the peers code
> to remap SMP_T_* to the on-wire value. I think this got broken a long
> time ago when extending the sample types to support the ADDR type which
> carries both IPv4 and IPv6, and nobody noticed that these types were
> transported directly over the wire :-(  Bingo, that was this patch
> between 1.5 and 1.6 that merged the two:
>   commit 5d24ebc3d70e7a0316d0954777a5f75a64fe7ac5
>   Author: Thierry FOURNIER <tfourn...@arpalert.org>
>   Date:   Fri Jul 24 08:46:42 2015 +0200
>     MEDIUM: stick-tables: use the sample type names
>     This patch removes the special stick tables types names and
>     use the standard sample type names. This avoid the maintainance
>     of two types and remove the switch/case for matching a sample
>     type for each stick table type.
> So now from what I'm seeing, we should document that on the wire we
> have this:
>    2 = signed int
>    4 = IPv4
>    5 = IPv6
>    6 = string
>    7 = binary

Perfect, I'll use those values within my implementation.

> From now, the best solution likely is to check where the table type is
> used and instead go back to a table-specific type with hard-coded values
> matching what we have now.

Should I file an issue for tracking that?

Best regards
Tim Düsterhus

Reply via email to