Hi Willy,

On 3/20/20 2:53 PM, Willy Tarreau wrote:
> Hi Emeric,
> 
> On Fri, Mar 20, 2020 at 02:29:48PM +0100, Emeric Brun wrote:
>> So I understand that since 1.6 the SMP_T are directly announced on the wire
>> for key types, and it brokes the documented values and this is hazardous to
>> rely on internal enum values.
> 
> Yes that's the issue Tim spotted.
> 
>> So we must re-introduce a mapping between internal and on-wire types.
> 
> Indeed.
> 
>> Some questions about choices:
>>
>> - Re-map types to documented values or Update the doc to match currently 
>> used values? 
> 
> I'd say that what's currently on the wire seems to more or less match the
> doc. Given that there are very few peers implementations, what's working
> right now seems the most important to me. So I'd suggest that we change
> the code to perform the mapping again and that we possibly update the doc
> in case it's wrong on some of them.

I understood that documented values are:
 0: signed integer
 1: IPv4 address
 2: IPv6 address
 3: string
 4: binary

and currenty (since 1.6):
   2 = signed int
   4 = IPv4
   5 = IPv6
   6 = string
   7 = binary

I know an other soft talking peers protocol which is compatible with peers 
proto for all haproxy's versions and which uses the new set of values.
It will break this compatibility re-mapping to documented IDs. That's why I 
asked.

The documented values are not used on any still supported haproxy's version. So 
I think it would be better to update the doc with the new ones
and add a mapping to avoid further changes.

> 
>> - About re-introduce the mapping, I'm not sure we should re-introduce the
>> mapping between fetches and tables types. Table types could stay internal,
>> using SMP_T... and we could map to protocol's values only when emitting the
>> message.
> 
> I didn't think about this possibility but I actually think it might be
> the best one. The reason the types were changed was to simplify the
> resolution of casts in "stick" rules, because if you remember we used
> to have two types of casts in the past, sample-to-sample and
> sample-to-table. But with your suggestion we'd keep the internals clean
> and simple to maintain and only the protocol would be adjusted on the
> wire, which is in fact what any agent should do. I really like this
> approach! You'll the probably just need to define some PEERS_TABLE_TYPE_XXX
> for example and map the table->type from SMP_T_* to those types and
> conversely, that sounds really clean.
Great!

 
> Thanks,
> Willy
> 

Emeric

Reply via email to