• Crash Limiter

    From Avon@21:1/101 to g00r00 on Tue Feb 19 02:06:57 2019
    Found an issue..

    If you set say 1000 as the limit, then Mystic holds back the file but still sends it's TIC ... that's going to cause problems with tossing in files at
    the nodes end.

    In this case I hatched an updated version of Nicks D'Bridge to replace an
    older version on file in the utils base... the actual file > 1000kb but the TICs have left the building...

    [snip]

    Feb 18 20:54:20 S: PWD
    Feb 18 20:54:20 R: OK secure
    Feb 18 20:54:20 S: NUL QSIZE 9 files 708,696 bytes
    Feb 18 20:54:20 Sending: 0000fffb.mo3 (1,103 bytes)
    Feb 18 20:54:20 S: FILE 0000fffb.mo3 1103 1550523234 0
    Feb 18 20:54:20 R: NUL QSIZE 0 files 0 bytes
    Feb 18 20:54:20 Remote Queue: 0 files 0 bytes
    Feb 18 20:54:20 R: EOB
    Feb 18 20:54:21 R: GOT 0000fffb.mo3 1103 1550523234
    Feb 18 20:54:21 Sending: DB3SR41G.tic (1,481 bytes)
    Feb 18 20:54:21 S: FILE DB3SR41G.tic 1481 1550475560 0
    Feb 18 20:54:21 R: GOT DB3SR41G.tic 1481 1550475560
    Feb 18 20:54:21 Sending: DB3SR41S.tic (1,481 bytes)
    Feb 18 20:54:21 S: FILE DB3SR41S.tic 1481 1550475536 0
    Feb 18 20:54:21 R: GOT DB3SR41S.tic 1481 1550475536
    Feb 18 20:54:22 Sending: nr20b186.rar (124,200 bytes)
    Feb 18 20:54:22 S: FILE nr20b186.rar 124200 1550390076 0
    Feb 18 20:54:24 R: GOT nr20b186.rar 124200 1550390076
    Feb 18 20:54:24 Sending: nr20b186.tic (1,427 bytes)

    [snip]

    Need some logic I think in the crash limiter... so tics and files leave hand
    in hand, happily ever after...

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/02/15 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Al@21:4/106 to Avon on Mon Feb 18 05:58:32 2019
    In this case I hatched an updated version of Nicks D'Bridge to replace an older version on file in the utils base... the actual file > 1000kb but the TICs have left the building...

    Need some logic I think in the crash limiter... so tics and files leave hand in hand, happily ever after...

    Yep! I've got 2 bad tic's in the inbound but not the files that go with them. When they do arrive I'll rename those .bad files back to .tic and retoss.

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Al@21:4/106 to Avon on Mon Feb 18 06:04:04 2019
    Need some logic I think in the crash limiter... so tics and files leave hand in hand, happily ever after...

    And they have arrived and are now in the fsx_utls directory.. :)

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From g00r00@21:1/108 to Avon on Mon Feb 18 12:16:16 2019
    If you set say 1000 as the limit, then Mystic holds back the file but still sends it's TIC ... that's going to cause problems with tossing in files at the nodes end.

    If we want it to prevent tics associated to a large file in a filebox that
    will take a bunch of work. I've added it to my list.

    --- Mystic BBS v1.12 A43 2019/02/17 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to g00r00 on Tue Feb 19 17:24:55 2019
    On 18 Feb 2019 at 07:16a, g00r00 pondered and said...

    If you set say 1000 as the limit, then Mystic holds back the file but still sends it's TIC ... that's going to cause problems with tossing files at the nodes end.

    If we want it to prevent tics associated to a large file in a filebox
    that will take a bunch of work. I've added it to my list.

    sorry about that... yeah as you'd appreciate it's not good sending a TIC without a file at the same time. Given it's large hatched files that the
    system is trying to avoid during a CRASH session with a node there's going to need to be some logic added I guess.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/02/17 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Mon Feb 18 23:30:08 2019
    sorry about that... yeah as you'd appreciate it's not good sending a TIC without a file at the same time. Given it's large hatched files that the system is trying to avoid during a CRASH session with a node there's
    going to need to be some logic added I guess.

    Yes, if you plan to hatch files larger than your crash limit. I didn't
    really expect that to be a situation since hatched files are generally small.

    I'll look into getting that into the queue system when queuing filebox

    --- Mystic BBS v1.12 A43 2019/02/17 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Black Panther@21:1/186 to Avon on Mon Feb 18 22:43:04 2019
    On 18 Feb 2019, Avon said the following...

    If you set say 1000 as the limit, then Mystic holds back the file but still sends it's TIC ... that's going to cause problems with tossing in files at the nodes end.

    I've got it disabled again on hub 4.


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A43 2019/02/08 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Black Panther@21:1/186 to Avon on Mon Feb 18 22:50:38 2019
    On 19 Feb 2019, Avon said the following...

    If we want it to prevent tics associated to a large file in a filebox that will take a bunch of work. I've added it to my list.

    sorry about that... yeah as you'd appreciate it's not good sending a TIC without a file at the same time. Given it's large hatched files that the system is trying to avoid during a CRASH session with a node there's
    going to need to be some logic added I guess.

    I'm wondering if having a setting that would just hold all the hatched files and tics from being crashed. Any mail would be sent, but the node would have
    to poll in order to get the files...


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A43 2019/02/08 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Avon@21:1/101 to Black Panther on Tue Feb 19 18:58:16 2019
    I've got it disabled again on hub 4.

    I'll do the same in NET 1 tonight when I get in.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/02/17 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to Black Panther on Tue Feb 19 19:12:29 2019
    On 18 Feb 2019 at 05:50p, Black Panther pondered and said...

    I'm wondering if having a setting that would just hold all the hatched files and tics from being crashed. Any mail would be sent, but the node would have to poll in order to get the files...

    Not so sure... the idea was that small files would get sent but large files would remain on the HUB to collect. It would enable CRASH traffic to flow (messages and files) to nodes but avoid tying up Fidopoll for a long period
    of time when it was sending to 50 nodes 4-8 large files in sequential fashion.

    I'd still like to see nodelists and other non message packet small files
    pushed to nodes that have CRASH set. It's just the larger stuff like artpacks or some software that causes a bottleneck when you're pushing to 50+ nodes
    one after another and with differing connection speeds.

    Ideally if Fidopoll could poll (let's say) 10 nodes at a time concurrently
    then that would help speed up delivery of messages/files. But ensuring nodes are not polling the HUB at the same time fidpoll is polling them leading to a conflict in file ownership I think is the reason we have the sequential
    polling we have.

    Perhaps nodes could be pooled into groups so it was still a case of
    sequential polling of those groups but at least you might have more copies of fidopoll running to cover the 50+ nodes... just an idea :)

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/02/17 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Bucko@21:4/131 to Al on Tue Feb 19 01:44:20 2019
    On 18 Feb 2019, Al said the following...


    Yep! I've got 2 bad tic's in the inbound but not the files that go with them. When they do arrive I'll rename those .bad files back to .tic and retoss.

    I've got the opposite, 2 files sitting in my inbound with no tic's.. DB3SR41S and G...

    --- Mystic BBS v1.12 A43 2019/02/15 (Windows/32)
    * Origin: The Wrong Number Family Of BBS' - Wrong Number ][ (21:4/131)
  • From Al@21:4/106 to Bucko on Mon Feb 18 23:16:40 2019
    I've got the opposite, 2 files sitting in my inbound with no tic's.. DB3SR41S and G...

    Bummer, I hope you get the tics soon. I did get the files on my next poll after
    I posted that.

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Bucko@21:4/131 to Al on Tue Feb 19 02:19:28 2019
    On 18 Feb 2019, Al said the following...


    Bummer, I hope you get the tics soon. I did get the files on my next
    poll after I posted that.


    I'm sure i will... :)

    --- Mystic BBS v1.12 A43 2019/02/15 (Windows/32)
    * Origin: The Wrong Number Family Of BBS' - Wrong Number ][ (21:4/131)
  • From MeaTLoTioN@21:1/158 to Avon on Tue Feb 19 11:13:53 2019
    Perhaps nodes could be pooled into groups so it was still a case of sequential polling of those groups but at least you might have more
    copies of fidopoll running to cover the 50+ nodes... just an idea :)

    Ooh multi-threaded fidopoll, I like it.

    Would having an incoming and an outgoing port for fidopoll make it better?
    like if fidopoll could spawn up an outgoing port at random for it's hatchings and pushings, leaving the incomming port alone for nodes to pole it? Would solve bandwidth issues assuming you have on the hub enough for everything
    going on =)

    ---
    |14Best regards,
    |11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

    |07── |08[|10eml|08] |15ml@erb.pw |07── |08[|10web|08] |15www.erb.pw |07───┐ |07── |08[|09fsx|08] |1521:1/158 |07── |08[|11tqw|08] |151337:1/101 |07┬──┘ |07── |08[|12rtn|08] |1580:774/81 |07── |08[|14fdn|08] |152:250/5 |07───┘

    --- Mystic BBS v1.12 A43 2019/02/10 (Linux/64)
    * Origin: The Quantum Wormhole, Ramsgate, UK. bbs.erb.pw (21:1/158)
  • From Avon@21:1/101 to MeaTLoTioN on Wed Feb 20 00:44:34 2019
    On 19 Feb 2019 at 06:13a, MeaTLoTioN pondered and said...

    Would having an incoming and an outgoing port for fidopoll make it
    better? like if fidopoll could spawn up an outgoing port at random for it's hatchings and pushings, leaving the incomming port alone for nodes
    to pole it? Would solve bandwidth issues assuming you have on the hub enough for everything going on =)

    The incoming port for most systems is 24554 which is the default BinkP server port. Fidopoll uses that for most connections it makes with systems it polls unless you define a different port in the BinkP Hostname section for an echo node.

    The issue I think relates more to avoiding a clash if fidopoll is polling a node that also happens to poll the HUB at the same time for the same traffic.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/02/17 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to Bucko on Wed Feb 20 01:27:42 2019
    On 18 Feb 2019 at 08:44p, Bucko pondered and said...

    I've got the opposite, 2 files sitting in my inbound with no tic's.. DB3SR41S and G...

    The tics would have arrived separately and earlier and been processed without the accompanying files that landed later and now languish. I'd delete them
    from your inbound dir and I'll rehatch again in the coming days. I just need time to manually update settings for 50+ nodes which takes time :)

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/02/17 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From CyntaxX@21:4/113 to Bucko on Tue Feb 19 09:01:52 2019
    On 18 Feb 2019, Bucko said the following...

    On 18 Feb 2019, Al said the following...


    Yep! I've got 2 bad tic's in the inbound but not the files that go wi them. When they do arrive I'll rename those .bad files back to .tic a retoss.

    I've got the opposite, 2 files sitting in my inbound with no tic's.. DB3SR41S and G...

    Check your badfile dir. Mine were there, so I just pasted them into the echomail in dir and it tossed them just fine.

    --- Mystic BBS v1.12 A42 2018/12/27 (Raspberry Pi/32)
    * Origin: Digital Wurmhole | digitalwurmhole.ddns.net:2323 (21:4/113)
  • From Bucko@21:4/131 to Avon on Tue Feb 19 23:35:58 2019
    On 19 Feb 2019, Avon said the following...


    The tics would have arrived separately and earlier and been processed without the accompanying files that landed later and now languish. I'd delete them from your inbound dir and I'll rehatch again in the coming days. I just need time to manually update settings for 50+ nodes which takes time :)

    No sweat Avon,, I will take care of that now.. :)

    --- Mystic BBS v1.12 A43 2019/02/15 (Windows/32)
    * Origin: The Wrong Number Family Of BBS' - Wrong Number ][ (21:4/131)
  • From Bucko@21:4/131 to CyntaxX on Tue Feb 19 23:38:04 2019
    On 19 Feb 2019, CyntaxX said the following...

    On 18 Feb 2019, Bucko said the following...

    Check your badfile dir. Mine were there, so I just pasted them into the echomail in dir and it tossed them just fine.


    Actually, I have them in my inbound. I did as Avon said and deleted them.

    --- Mystic BBS v1.12 A43 2019/02/15 (Windows/32)
    * Origin: The Wrong Number Family Of BBS' - Wrong Number ][ (21:4/131)