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...
Need some logic I think in the crash limiter... so tics and files leave hand in hand, happily ever after...
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 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.
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.
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've got it disabled again on hub 4.
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...
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...
Bummer, I hope you get the tics soon. I did get the files on my next
poll after I posted that.
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 :)
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 =)
I've got the opposite, 2 files sitting in my inbound with no tic's.. DB3SR41S and G...
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...
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 :)
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.
Sysop: | echicken |
---|---|
Location: | Toronto, Ontario |
Users: | 2,224 |
Nodes: | 6 (0 / 6) |
Uptime: | 05:26:51 |
Calls: | 14,143 |
Files: | 295 |
Messages: | 551,233 |