Subj : Unix point?
To   : Tim Schattkowsky
From : mark lewis
Date : Fri Jan 14 2022 06:23 pm


On 2022 Jan 14 18:31:56, you wrote to me:

ml>> FWIW: message bodies are unbounded in FTN specs... any limitations
ml>> seen are placed there by the devs of those particular tools that
ml>> exhibit message length problems...

TS> I know,

i thought you probably did :)

TS> but this clash with the reality of many implementations (not including
TS> WP, at least up to ~2GB message length) makes the situation worse.
TS> What I have seen is that commonly messages are in practice split at
TS> slightly below 64k

this is what happens when hobbiests in highschool or early university write things for use in a network like fidonet... i remember someone, years ago, being quite happy and posting about them figuring out how to buffer the excess to a disk file instead of trying to handle everything in memory with the 64k limitation that was in effect back in those days... i think this was some time after i had released a tool that was capable of posting the entire nodelist of that time in one message... yeah... IIRC it was over 2G in size :)

TS> and I am not sure if any real world software bothers recombining them
TS> (WP does not).

perhaps you might look at the ^ASPLIT specification? there are tools that can unsplit those messages, too... i've used one or two of them in the past... generally they were used on the local side in the middle of the PKT processing flow... they would process the incoming PKT and create a new PKT with the messages put back together... then the tosser would run and place the full message into the message base while also tossing to downstream system and again splitting the message according to that system's tosser configs...

TBH, ^ASPLIT should have only been used on the local system if the message could not fit in the local message base storage format... that would have been a lot better than foisting it on all the systems in the path and making them have more messages to process but that made too much sense, really...

TS> However, since this was mostly relevanted for gated emails, it is
TS> today probably of little practical interest anyway.

sadly, it wasn't limited to only gated messages... it was more of "lazy coders unwilling or not knowing how to buffer to disk files"... this in the name of processing speed and trying to get or have the fastest message processing throughput they could attain... in today's world, they would still do everything in memory without disk buffering but this is because the whole methodology has changed and those former restrictions simply don't exist any more...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... On T-Day that rash on your stomach turns out to be steering wheel burn.
---
* Origin:  (1:3634/12.73)