Yeah, I’ve worked on internet based mail systems for a few decades - including fidonet and wwiv back in the 80s.

I’d personally postulate that fidonet and Usenet are not the state of the art for high throughput, high latency message systems during the 3I.  I’m fairly certain that outside of NASA and their ilk the vast majority of thought is currently going into optimizing for low latency. Until we start to need to tackle this problem, there will be almost no work going into it.

I figure that low level services like that are abstracted so many levels away by the time of the 3I that most folks are not even aware of them. They just plug in an address and a few weeks or months later get a reply. Just like today things like Apache Kafka power large portions of the internet however almost nobody outside of the feild know what they are. A generalist might known at a high level how it works, and experts in each part might have detailed knowledge about their parts. But very few will have a holistic deep understanding.

Sent from my iPhone

>> On Feb 20, 2018, at 7:09 AM, shadow at shadowgard.com (via tml list) <xxxxxx@simplelists.com> wrote:
>>
>> 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
>
>
> -----
> The Traveller Mailing List
> Archives at http://archives.simplelists.com/tml
> Report problems to xxxxxx@simplelists.com
> To unsubscribe from this list please go to
> http://www.simplelists.com/confirm.php?u=g8EYmpjfNu22Uwq2slNgbtlSYHMIUXYZ