Mail in the Third Imperium
Caleuche
(22 Jan 2018 22:25 UTC)
|
Re: [TML] Mail in the Third Imperium
Catherine Berry
(22 Jan 2018 22:33 UTC)
|
Re: [TML] Mail in the Third Imperium
Greg Nokes
(22 Jan 2018 23:02 UTC)
|
Re: [TML] Mail in the Third Imperium shadow@xxxxxx (20 Feb 2018 15:11 UTC)
|
Re: [TML] Mail in the Third Imperium
Greg Nokes
(20 Feb 2018 17:01 UTC)
|
On 22 Jan 2018 at 15:01, Greg Nokes wrote: > Digital is a bit faster and much more reliable. > > Each message is an encrypted blob, containing all of the information > you need to send. If you have a planetary net, you send it to your > recipient with a fully qualified address (ie, > emailaddress&planetarybody&system&subsector§or) > > The store and forward system determines fastest path, and dispatches > the message. > > It stores the message until it gets a ack back then it purges it. > > Rinse and repeat until the message arrives. > > If there are several paths that are close, it will send it along > several of them with a duplicate header. If you get several copies of > the message the extras are discarded by your local mail program. > > This system is physical layer agnostic - actual delivery is left up to > the segment. Actually, several store & forward type networks have something similar, but with a few extra details that help a lot. Fidonet mail and groups, and usenet's newsgroups do things slightly differently, but get pretty much the same results. And given that "news" and other punlic data will be going along the xboat routes too, it's instructive to consider them as well. every message (public or private) is going to have a unique msgid. and the headers (or at least a chunk of them) are going to be readable by the mail systems. there will be something in the headers that indicates not just point of origin and destination, but also which "nodes" tne message passed thru. This helps prevent things getting into a loop. That is, if it's gone thru A, B, C & D to get to E while on the way to (say) Q, then putting it in a bundle bound for any of the previous nodes, is a bad idea unless you know there's a problem that requires returning the message (or rather the msgid) with a "cannot be forwarded from here" tag. For public stuff, a record of the msgids would be kept for a *long* time, just to make sure you aren't forwarding stuff a node already has. This usually uses a sort of "I have"/"send me" exchange protocol. private messages will still have the msgids kept until the node gets a "message XXX" recieved from the node they forwarded it to. Each message, public opr private will have some sort of checksum or the like attached to make it possible to ensure some degree of certainty that the message received didn't get some bits garbled. So when new messages come in, the node checks them against the "checksum" and if it matches, either the message is intact or it got garbled in a *very* unlikely way. If it doesn't match, the message gets flagged as damaged, and the msgid, checksum sent, and checksum received are added to a "please resend" list that'll be sent back to the previous node on the next xboat. So the node creates a list of messages received ok with checksums to be sent back to the previous node on the next xboat. It sorts the received ok messages into bundles based on where they'll get sent next. And stores copies as well. when a node receives a list of "messages received ok" from a node it sent to, it checks the list. If the msgid and checksum match what it sent, it ads the info to the "sent successfully" file. And marks the messages as ok to delete. They may get deleted immediately, or they may be held onto for som period of time "just in case" If a message is on the resend list, it gets flagged and resent (if it gets resent more than once *someone* is going to be looking into *why* it's not going thru. Other possibilities. If a bundle doesn't acknowledged, either the ship got lost or something happened to the data. This requires investigation. If the bundle is acknowledge but one or more messages in to aren't acknowledged and also aren't listed as needing a resend, something fishy is going on! Ditto if you get an ack for bundle or a message that you didn't send. Somebody is playing games. When that -- Leonard Erickson (aka shadow) shadow at shadowgard dot com