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
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
