• Another Feature/Issue...

    From Ozz Nixon@1:275/362 to All on Fri Feb 8 23:06:00 2019
    Hello everybody.

    If I set the IN path to my network drive - it unpacks from network drive back to network drive, then processes TOSS from network drive - basically triple+ my
    billable. (Running VPS servers with BandWidth Quotas)...

    Can we add UNPACK TO PATH?

    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From mark lewis@1:3634/12.73 to Ozz Nixon on Tue Feb 12 11:09:48 2019
    On 2019 Feb 08 23:06:00, you wrote to All:

    If I set the IN path to my network drive - it unpacks from network
    drive back to network drive, then processes TOSS from network drive - basically triple+ my billable. (Running VPS servers with BandWidth Quotas)...

    some tossers have a TEMP directory location you define in the config so the mail is unpacked to and tossed from there... we used it to unpack to ramdrives for faster tossing... does FMail have this feature?

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... My compact discs are not miniature Frisbees.
    ---
    * Origin: (1:3634/12.73)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Tue Feb 12 22:04:02 2019
    Hi Ozz,

    On 2019-02-08 23:06:00, you wrote to All:

    If I set the IN path to my network drive - it unpacks from network
    drive back to network drive, then processes TOSS from network drive - basically triple+ my billable. (Running VPS servers with BandWidth Quotas)...

    Can we add UNPACK TO PATH?

    You mean something like a TEMP path where it puts "inbetween" files?

    BTW: I think most nodes nowadays prefer to exchange uncompressed plain .pkt files directly (I do). (And binkd can take care of compressing files on the fly, if you prefer that.) In which case you don't have the above "problem"...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ozz Nixon@1:275/362 to Wilfred van Velzen on Thu Feb 14 10:23:58 2019
    Hello Wilfred.

    12 Feb 19 22:04, you wrote to me:

    Hi Ozz,

    On 2019-02-08 23:06:00, you wrote to All:

    Can we add UNPACK TO PATH?

    You mean something like a TEMP path where it puts "inbetween" files?

    Exactly. I do not plan on runngin BinkD, iREX, Argus and siblings, etc. I wrote
    my own BinkP in 2017 and spent months last year runing every OPT against it to make sure *I* run them correctly. My uplink sends compressed, which to make makes much more sense then compress on the fly (personal preference).

    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Thu Feb 14 23:07:43 2019
    Hi Ozz,

    On 2019-02-14 10:23:58, you wrote to me:

    My uplink sends compressed, which to make makes much more sense then compress on the fly (personal preference).

    Current fidonet over the internet, is so fast, that most sessions only exchange
    a single pkt file, with only a single or a few messages, typically a few hundreds or thousands bytes. It makes no sense starting up a compression program, that writes them to an compressed "intermediate" file on disk before transmission, when most of those pkt files fit into a single tcp/ip frame. Or when binkp can compress them on the fly which doesn't require extra disk writes
    and reads for the compressed data.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ozz Nixon@1:275/362 to Wilfred van Velzen on Fri Feb 15 10:48:06 2019
    Hello Wilfred.

    14 Feb 19 23:07, you wrote to me:

    Hi Ozz,

    On 2019-02-14 10:23:58, you wrote to me:

    Current fidonet over the internet, is so fast, that most sessions only exchange a single pkt file, with only a single or a few messages, typically a few hundreds or thousands bytes. It makes no sense
    starting up a compression program, that writes them to an compressed "intermediate" file on disk before transmission, when most of those
    pkt files fit into a single tcp/ip frame. Or when binkp can compress
    them on the fly which doesn't require extra disk writes and reads for
    the compressed data.

    True for Fidonet - however, other networks I am on push hundreds of messages per poll. But, I only poll them 2 or 3 times a day - and they are extremely active. No problem.

    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Sat Feb 16 12:08:34 2019
    Hi Ozz,

    On 2019-02-15 10:48:06, you wrote to me:

    Current fidonet over the internet, is so fast, that most sessions
    only exchange a single pkt file, with only a single or a few
    messages, typically a few hundreds or thousands bytes. It makes no
    sense starting up a compression program, that writes them to an
    compressed "intermediate" file on disk before transmission, when most
    of those pkt files fit into a single tcp/ip frame. Or when binkp can
    compress them on the fly which doesn't require extra disk writes and
    reads for the compressed data.

    True for Fidonet - however, other networks I am on push hundreds of messages per poll. But, I only poll them 2 or 3 times a day - and they are extremely active. No problem.

    That's a use-case where compression makes sense. So it's a good thing you can choose for each connection if you want compression or not! ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From mark lewis@1:3634/12.73 to Ozz Nixon on Sat Feb 16 16:11:20 2019
    On 2019 Feb 15 10:48:06, you wrote to Wilfred van Velzen:

    True for Fidonet - however, other networks I am on push hundreds of messages per poll. But, I only poll them 2 or 3 times a day - and they are extremely active. No problem.

    imagine what it'll be like when you get a """real setup""" going (J/K!) where you are in a "crash me, crash you" configuration such that pkts and tics/files are processed immediately on arrival... my old system used to process mail once
    an hour before it became a tier 1 mail hub... it spent a lot of time processing
    mail... especially since it was also only 800Mhz... my new setup processes the mail and files as soon as they come in... "WOW!" doesn't even begin to cover the experiance of seeing messages come in, being fully processed, and sent out to all my linked systems in less than 30 seconds... i have some stats around here somewhere that i need to figure out how to process and look at in a more human readable format...

    i haven't seen changes in speed like that since going from a 486-40 to a 200mhz
    pentium ii and then again from the pii to 800mhz whatever cpu i was running... that system didn't want to come back up after Hurricane Florence came through here so i had a choice... stay offline or set up a new system... i finally decided to make another VM and install a new setup there... it is ubuntu server
    18.04 LTS with no GUI crap on it... i ended up choosing synchronet BBS (aka sbbs) for the job over a few others that i had looked at... it has performed admirably here and as i get more used to it, i can contribute fixes back upstream or make mods available for others if they want them... i couldn't really do that before... plus it gives me something to do during this downtime until the weather clears and construction jobs come back to life...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... We don't make sense, but we do like pizza.
    ---
    * Origin: (1:3634/12.73)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Sat Feb 16 23:19:32 2019
    Hi mark,

    On 2019-02-16 16:11:20, you wrote to Ozz Nixon:

    my new setup processes the mail and files as soon as they come in... "WOW!" doesn't even begin to cover the experiance of seeing messages
    come in, being fully processed, and sent out to all my linked systems
    in less than 30 seconds...

    That's slow! ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ozz Nixon@1:275/362 to Wilfred van Velzen on Sat Feb 16 12:41:55 2019
    Hello Wilfred.

    16 Feb 19 12:08, you wrote to me:

    That's a use-case where compression makes sense. So it's a good thing
    you can choose for each connection if you want compression or not! ;)

    No complaints here! I am honestly impressed in how well FMail is operating in my mailer in Virginia, Tosser in Texas, NNTP Server in Texas, and NNTP Client on my Mac Laptop in Virginia ;-)

    Now, I am on the hunt to migrate everything in-house on Mac. Then I will push out to my Linux server in Arizona, and my Windos Server in Texas. And move on to the next milestone...

    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Sun Feb 17 12:49:42 2019
    Hi Ozz,

    On 2019-02-16 12:41:55, you wrote to me:

    No complaints here! I am honestly impressed in how well FMail is
    operating in my mailer in Virginia, Tosser in Texas, NNTP Server in
    Texas, and NNTP Client on my Mac Laptop in Virginia ;-)

    Are these locations known to have a bad influence on the opperation of computer
    software? ;-)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Sun Feb 17 15:43:24 2019
    On 2019 Feb 16 23:19:32, you wrote to me:

    my new setup processes the mail and files as soon as they come in...
    "WOW!" doesn't even begin to cover the experiance of seeing messages
    come in, being fully processed, and sent out to all my linked systems
    in less than 30 seconds...

    That's slow! ;)

    hahaha... not really... that's with some 40+ links and compared to the old system which may have taken 20 minutes to process the mail and files before letting the mailer send the outbound stuff... that was also directly related to
    delaying processing as well as doing a lot of stuff during the processing... especially when it came to processing the files areas and generating the new static web pages, files lists and files stats...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... My sister could make some black bread for you (Translation: Burned)
    ---
    * Origin: (1:3634/12.73)
  • From Ozz Nixon@1:275/362 to mark lewis on Sat Feb 16 19:40:53 2019
    On 2019-02-16 21:11:20 +0000, mark lewis -> Ozz Nixon said:

    imagine what it'll be like when you get a """real setup""" going (J/K!)
    where you are in a "crash me, crash you" configuration such that pkts
    and tics/files are processed immediately on arrival... my old system
    used to process mail once an hour before it became a tier 1 mail hub...
    it spent a lot of time processing mail... especially since it was also
    only 800Mhz... my new setup processes the mail and files as soon as
    they come in... "WOW!" doesn't even begin to cover the experiance of
    seeing messages come in, being fully processed, and sent out to all my
    linked systems in less than 30 seconds... i have some stats around here somewhere that i need to figure out how to process and look at in a
    more human readable format...

    I can appreciate what you are saying. If I can get FMTP operational and accepted, then it goes down to 0 zero seconds, 0 bytes, all echos.
    --
    +++ Are we having fun yet? I am!
    ATZ|ATDT911|1,2~555

    --- FMail-W32 2.0.1.4
    * Origin: ExchangeBBS WHQ (1:275/362.0)