Hi Tim,

On Wed, Mar 11, 2020 at 07:44:00PM +0100, Tim Düsterhus wrote:
> Dear List
> I'm currently working a Peer Protocol implementation to passively
> monitor what's happening within HAProxy.
> The protocol specification is horribly underdocumented (docs/peers.txt
> is incomplete) and I believe I found a mistake in the existing
> documentation:
> 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

> > Table Type present the numeric type of key used to store stick table 
> > entries:
> > integer
> >  0: signed integer
> >  1: IPv4 address
> >  2: IPv6 address
> >  3: string
> >  4: binary
> But I'm seeing the value 6 for string. After reading the source code the
> type actually appears a member of SMP_T_* which would match up.

I didn't remember that we remerged the types. Originally there were
types for stick tables and types for samples, with an implicit cast
between the two. The translation from a sample to a stick table key
is done by smp_to_stkey().

> Two questions:
> 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.

> 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

>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.

Thanks for spotting this!

Reply via email to