KvE>> - A perceived update, that did not influence the content of the KvE>> nodelist.
BF> And hatching the exact same file -- knowing that it will be detected as BF> a dupe by any decent file processor -- several times a day, what good will BF> that do?
In general the dailylist is not updated, when a region update arrives. But there are sections that are maintained manually by the ZC.
BF> The RC that supplied the update should get an instant reply showing BF> the BF> result. Since the content is not changed, what interest would the rest of BF> the regions have in the exact same daily list hatched once again?
KvE>> - Testing the modified production of the nodelist, knowing, that KvE>> subsequent delivery would do no harm. Doing a testrun in te afternoon KvE>> is a better option then, staying up till after midnight when the KvE>> actual run is scheduled.
BF> I still don't see why hatching the exact same nodelist once again will BF> be of any value to the regions. Surely there would be better ways to have BF> this done for sysops interesting in it?
I still fail to see the problem.
At the start it was explained that the file could be hatched more then once a day. If your file processor decides it is a duplicate, because the file is identical, the the file is dumped and still nothing is lost.
What I would like to tune in on is what happened at your system and probably happens at Bennys system as well, the deliveries within 40 secs.
I do not know if it is the same phenomenon, but occasionally I also notice, that there is a failed session, and a repeat shortly afterwards. I think that is by design in Binkd.
But why do the sessions apparently fail more then normally. When I look at nodelist transfers between my system and Ward, i see speeds of +/- 5500 CPS. When I send a comparable file to someone else, I get speeds of 23000 CPS. So it looks like the transfers with Ward take quite some time, and maybe timeouts are reached.
Now why would the transfers from Ward be so slow.
For one, uplinks usually have a lower bandwith, According to the tic files 11 files are sent at the same time. How may outgoing sessions are running simutanously is defined by maxclients in de binkd.cfg.
It would be worth a try, if Ward reduced the number of simultanous sessions by lowering the value of maxclients.
On the other hand. The receiving side should have no problem with two or more stage deliveries. So what can go wrong.
On my system I have had no problems with the above. I run a batch process on incoming files at regular intervals so the chance that this happens in between a failed session and the direct repeat is minimal.
But what happens if the file processing is initiated by binkd directly after the session is closed?
If that causes havoc, then who should solve the problem. The sender is within the specifications of fidonet. There is no minimal transfer speed specified, a failed transfer is follewed by a repeat. He has no knowledge of whatever softwere is processing the files at the receivers end.
Kees
--- GoldED+/LNX 1.1.5 * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
