Text 10399, 75 rader
Skriven 2013-09-23 22:10:22 av Michiel van der Vlist (2:280/5555)
     Kommentar till en text av mark lewis (1:3634/12.0)
Ärende: R/C Elections R28.
==========================
Hello mark,

On Monday September 23 2013 10:09, you wrote to me:

 ml>> i wonder what it looks like to a binkd system when the one it is
 ml>> trying to connect with refuses the connection because of limited
 ml>> server connections...

 MvdV>> A time out?

 ml> i'm not sure... i've adjusted my binkd, as an experiment, to only one
 ml> server and one client... that means that i can have only one inbound
 ml> connection at a time and i can make only one outbound connection at a
 ml> time... i have several folks who poll here right on the top of the
 ml> hour... all at the same exact time, so several of them get 'unable to
 ml> connect' messages or something else... it is that 'something else'
 ml> that i'm curious about...

Interesting experiment. Let us know how it evolves.

 MvdV>> Athough technically I have a dynamic IP, it has not changed for
 MvdV>> years and probably will not change as long as the MAC address
 MvdV>> of the router stays the same. For all intents and purposes it
 MvdV>> may be treated as a static IP. So indeed, using the IP instead
 MvdV>> of the host name would work.

 ml> my thoughts exactly... then then, since the raw IP would be being
 ml> used, any failure to connect would be due to a problem in the route(s)
 ml> taken from the originator to the destination...

Or a problem with the originator or the destination.

 ml> even an overloaded router at one point in time could result in a
 ml> failure to connect...

Possible in theory, but unlikely in practice. The Western European backbones
have so much as yet unused bandwith and so much redundancy, that it is unlikely
that a single overloaded router could completely disable a low bandwith
application as binkp.

 ml> if one's binkd hold period is set for 4 minutes, then it would take
 ml> that long before the next attempt was made... one's binkd timeout and
 ml> connection-timeout settings tell binkd how long to wait during an
 ml> attempt before giving up on a connection... one could make a guess
 ml> that ward's setting are pretty close to

 ml> timeout 30
 ml> connect-timeout 30
 ml> call-delay 60
 ml> rescan-delay 60
 ml> hold 4m

An educated guess, but...

 ml> the above based on the next connection attempt that succeeded... i
 ml> believe you said it was less than 5 minutes later?

No, it was the other way around. First there was a successful connection. Mail
was transferred. Then 4 minutes and 16 seconds later, Ward claimed to have a
failed connection.

The more I think about it the less sense it makes. Why was there a second
attempt four minutes later in the first place? The only reason that makes sense
is that there was new mail to send. But if that was the case, why did his
system just try once? Why did it not continue to try to connect? And if there
was mail waiting to be sent, why did my system not pick it up when it made a
successful connect initiated from my side about an hour later?

It just does not add up...


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20110320
 * Origin: http://www.vlist.org (2:280/5555)