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