TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Paul Edwards
from: Rod Speed
date: 1996-04-03 09:04:24
subject: timeout

PE> Remember how we were discussing what happens if you call
PE> straight after someone else, what happens is that my system
PE> exits after receiving mail, takes the phone off hook (but
PE> doesn't answer it), which means you can get a dud call.

RS> Its theoretically possible to organise things so your
RS> modem does get a proper connect with the calling modem
RS> in that case, and does just treat that as a normal caller.

PE> Yeah, I thought of that too, but am not willing to put the work into that,
PE> and I would have to make major changes to the way I do my mailprocessing to

Dunno, my superficial reaction is that if you can adequately deal with
the situation where an attempt to dial out to Dave can be fielded as just
an incoming call, it might be feasible to do your mail processing as a two
step process where your FIRST attempt to busy the modem, and allow that to
fall thru to handling a caller if one happens, and THEN have a separate
event after that which does the full mail maint AFTER the previous event
has busied the modem successfully. You may not need to make major changes
to the mail processing event at all.

Essentially you just ensure that the mail processing
event cant fail coz the modem is already busy.

RS> The same possibility applys when you are repeat dialing on Dave
RS> and you happen to attempt to dial out just as someone calls in.
RS> It is doable in that last case, tho its harder in the case you
RS> are talking about, because its harder to postpone the mail
RS> processing that you planned to do with the modem busy.

PE> The last case is already taken care of, that's why
PE> Binkley has a "incoming call, dial aborted" message!

Sure, thats what I meant, that thats doable now. And so it may well
be feasible to use that approach with the mail processing event too.

PE> One solution to this problem would be for me to go back to my old method,
PE> and you guys all setting your modems to expire after about 3 minutes or
PE> something, whatever it is before Telecom gives up on your behalf.

RS> Thats a bit tricky coz there can be significant variation in the
RS> handshaking time, particularly with some particular circumstances.

PE> Pardon?  It should work fine.

Not when the handshaking time in successful sessions varys extensively
as you change modems at your end. Particularly when the time that matters
is the longest time thats ever seen for a successful handshake, plus a
margin for safety. The longer that gets, and it has to be reasonably long,
the more likely it is for you to come back on line late in the dial
attempt, loop the line coz its ringing, and then the caller times out
coz there is nothing like enough time left to successfully handshake.
In other words the callers system aborts the handshake coz you looped
the line very late in its timed event.

Maybe its possible to do it your way, with the modem not being busied,
and then have a special event which is invoked at the end of the mail
processing event which just checks to see if the modem is seeing a ring,
and spins its wheels till it stops ringing, and doesnt answer the call.
Then once the line has stopped ringing, that event terminates and you
drop into the normal mode waiting for the next RING.
@EOT:

---
* Origin: afswlw rjfilepwq (3:711/934.2)
SEEN-BY: 711/934
@PATH: 711/934

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™.