"Pest" v. 0xFD.
This is a continuation of "Pest" v. 0xFE.
There is a pretty-printed mirror of this page.
There is now a prototype! (Thank you, thimbronion!)
14 Dec 2021: And there is now a second prototype! (Thank you, jonsykkel!)
There is a working draft of v. 0xFC. (Note: it may change without warning!)
The document (very much a work in progress!) is available as a vtree. You will need:
- A V-tron. If you have no idea what V is, start here.
- pest_spec.kv.vpatch
- pest_spec.kv.vpatch.asciilifeform.sig
- pest_spec_FE.kv.vpatch
- pest_spec_FE.kv.vpatch.asciilifeform.sig
- pest_spec_FD.kv.vpatch
- pest_spec_FD.kv.vpatch.asciilifeform.sig
Add the above vpatches and seals to your V-set, and press to pest_spec_FD.kv.vpatch.
To "compile" the document to HTML, run make (this requires the "markdown2" utility.)
Please submit any proposed changes to this spec in vpatch form.
The full text is reproduced below, and any reader able to spare the time for a careful reading is invited to comment!
This version is obsolete! Please read v. 0xFC !
Click here for a printer-friendly version of this text.
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.
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
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.
Dear bonechewer,
Merits a mention in the spec. Will go in v. 0xFC.
Yours,
-S