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)

Re: [TML] Mail in the Third Imperium shadow@xxxxxx 20 Feb 2018 15:09 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&sector)
>
> 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