Comments on "Pest" v. 0xFD. "You can't get to the moon by piling up chairs." 2022-01-14T22:49:08Z http://www.loper-os.org/?feed=atom&p=3969 By: Stanislav Stanislav http://www.loper-os.org http://www.loper-os.org/?p=3969#comment-20008 2021-11-20T22:28:48Z 2021-11-20T22:28:48Z In reply to bonechewer.

Dear bonechewer,

Merits a mention in the spec. Will go in v. 0xFC.

Yours,
-S

]]>
By: bonechewer bonechewer http://www.loper-os.org/?p=3969#comment-20007 2021-11-20T17:45:46Z 2021-11-20T17:45:46Z In reply to Stanislav.

Ah, okay, if old messages can still be retrieved after aging out of the ring buffer, then that changes things entirely. Might be worth alluding to that possibility explicitly in the spec since somehow unimaginative me failed to consider that possibility.

]]>
By: Stanislav Stanislav http://www.loper-os.org http://www.loper-os.org/?p=3969#comment-20006 2021-11-20T16:52:04Z 2021-11-20T16:52:04Z In reply to bonechewer.

Dear bonechewer,

Notionally a station will retain older messages (i.e. ones which have exited the in-memory ring buffer) on disk, indexed by hash; but I have not explicitly mandated this in the spec; hence the "best effort" verbiage.

Re: ChainFirst and ChainLast -- I'd rather not have Bitcoin-style "one request, potentially over9000 replies" mechanisms. One packet -- one response, is IMHO the Right Thing. And that way the station issuing the request always knows what the expected hash of the incoming message is, and knows to check the hash of incoming messages prior to the timestamp if and only if it is expecting a GetData response.

The other thing is, if the requested missing messages are broadcasts, it makes sense to request them stepwise from the entire WOT, rather than from only one peer.

Yours,
-S

]]>
By: bonechewer bonechewer http://www.loper-os.org/?p=3969#comment-20005 2021-11-20T06:17:59Z 2021-11-20T06:17:59Z I am enjoying reading the pest draft spec.

You have probably already considered this, but it occurs to me that a possible risk of having GetData successively request older and older messages until it reaches the last seen SelfChain or NetChain, is that if there is high latency, the oldest messages get more and more likely to have expired from a peer's ring buffer before they are requested.

I suppose one alternative would be a command like GetData that contained two hashes, ChainFirst and ChainLast. Receipt of such a command would cause the receiving station to search the chain of messages from a given peer backwards from ChainLast until it either found ChainFirst or encountered the beginning of its ring buffer, then send the messages found to the requesting station. If the requesting station knows it is getting the oldest stuff first, it should need to do less buffering.

If you have already considered and rejected this, and there is something I am missing, I shall be glad of the education.

]]>