TIP: Click on subject to list as thread! ANSI
echo: binkley
to: Ian Smith
from: David Nyquist
date: 1998-12-14 20:19:30
subject: Binkleyterm 2.60 XR6 DOS

On Fri Dec 11, 1998, Ian Smith wrote in a message to David Nyquist:

 IS> Does it EVER happen on inbound connects?

Nope.  Just outbound connects.

 IS> That's about 17 seconds after the end of business.  A fair delay,
 IS> but one that's not uncommon with Frontdoor and Intermail systems,
 IS> in my experience; I've often sat here wondering 'what's his mailer
 IS> waiting for, then?'

Probably who's the first one to chicken out and hangup first. :-)

 IS> It looks to me that in saying 'cosmetic', XR6 DOS is just reporting
 IS> a message that is usually suppressed, that is, the sessions
 IS> referred to having appeared to terminate normally, with all files
 IS> properly sent and received, then Bink is reporting the loss of DCD
 IS> often associated with the end of a session, where either end can
 IS> wind up winning the 'race' to hangup first.  The ZedZap specs don't
 IS> enforce either end quitting first, which some people have found
 IS> odd. 

It should be suppressed.  But I guess this one got away. :-(

 IS> I'm used to looking at FOSSIL buffer dumps after various calls, and
 IS> most of my recent modems have also shown Termination Reason in the
 IS> AfterCall modem stats as either Link Disconnect (the other end
 IS> hungup first) or Local Request (my end did) with more or less even
 IS> odds to other Bink systems, XR and 'classic'. 

 IS> Some other systems (such as Frontdoor and Intermail) seem to use a
 IS> different timeout, hanging onto the line rather longer after the
 IS> business is all done. 

Hmm.  Interesting how they Frontdoor and Intermail can do that.  I mean
there is no reason why they should wait as all the mail has been sent.

 IS> So unless there's any suggestion of sessions ending prematurely,
 IS> before all the work's been done, it seems to be really just a bit
 IS> of extra reporting. 

Extra reporting which is not needed.  I think the XE team might have
accidently taken something out and that's why we get those Lost Carrier
messages.

 IS> There's a chance it might occur more frequently if you have your
 IS> modem setup to do longer 'cleardown' on loss of DTR at your end;
 IS> I've seen some that seem to take ages, maybe an extra 20 seconds or
 IS> so, compared to those configured to do fast cleardown, so those
 IS> would regularly lose the 'race' to quit first, but apart from that,
 IS> be happy if your sessions are getting the mail ok .. :) 

I'm happy they're getting the mail.  If they weren't I would be using the
old version of Binkley. :-)

Cheers,
David Nyquist
 
--- 
* Origin: Value Link BBS 604-930-0715 (1:153/959)
SEEN-BY: 396/1 632/0 371 633/260 262 267 270 284 371 634/397 635/444 506 728
SEEN-BY: 639/252 670/218
@PATH: 153/959 831 800 140/1 396/1 633/260 635/506 728 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.