READ EARLEST

[crotwell]

The protocol supports POSITION SET EARLIEST but might also be useful for debugging to support READ EARLIEST to get the earliest packet. And similar for READ LATEST.

Ringserver currently responds to READ EARLEST with error of Packet 0 not found in ring which doesn't make it clear if this is not part of the protocol, or if is just not implemented in ringserver/libdali.

[crotwell]

Actually, ringserver responds with Error parsing READ command parameters which makes more sense. Bug in my script.

Still woudl be nice to have READ EARLEST.

[crotwell]

Last comment, the reason for this idea...

You can fake it with POSITION EARLEST and then READ the returned packet id. However, in a busy ringserver with large data volume, the packet id returned might get flushed out of the ring before the read command can be sent. Hence a single op atomic READ EARLIEST and READ LATEST won't cause a race condition.

[chad-earthscope]

Hence a single op atomic READ EARLIEST and READ LATEST won't cause a race condition.

Being pedantic: It's only atomic from the client perspective, it remains a race condition in the server, which has code to check that the positioning of a read and then a subsequent actual read of the packet got the same thing. Granted this would reduce the "misses" significantly compared to the time incurred in the network command transit. It's just not perfect, because it's always possible to skip off the end of a very busy ring.

[crotwell]

Fair enough. And on reflection I am not sure how useful this actually is, so feel free to "won't fix" this unless you think it has use.