| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.