Willy, 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