The Epic of MRUlist.

Ian Bruene ianbruene at gmail.com
Tue Apr 28 09:20:37 UTC 2020


After a great deal of refactoring, digging, confusion, and generalized 
wrestling with the surprising number of tentacles that comprise the 
mrulist system I can now make a report of sorts:

*Error handling expected by the protocol:*

* If there is no overlap between the requested entries and what the 
server has available the client is supposed to back up until it can find 
an overlap. In the worst case this can mean completely restarting the 
request sequence.

The current code (this was true in the original C version as well) 
pretends to do this and will bail if it happens 8 times, but does not 
make any changes whatsoever to the request. For all meaningful purposes 
this is not implemented in the client.

* Duplicate entries may be created as data is updated during the request 
sequence.

This is implemented.

* Packet errors should result in packet size adjustment.

This is implemented.

*Ways the mrulist handler as currently written can exit its packet loop:**
*
* Unspecified errors.

* Too many (fake) restarts.

* Bad data in mrulist response.

* Finding an ending packet, represented by the "now" tag.

*Implications:*

* What happens when a packet in the middle of the sequence is dropped? 
Who knows! If it is seen as a timeout then the client will adjust packet 
size and try again... forever. Or maybe it silently doesn't notice?

* What happens when the final packet is dropped? Same as before, except 
that never seeing the "now" field means that silent failure will result 
in an infinite loop. I think.

* If the server data changes enough while the request sequence is 
running the system can just fail for no good reason because the error 
handling for that doesn't exist. Arguably that is when things are going 
well; I can imagine some subtle and wacky hijinks when dumb luck causes 
it to not fail properly.

-- 
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan

/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200428/93b028a0/attachment.htm>


More information about the devel mailing list