home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / bbs / waffle / 6444 < prev    next >
Encoding:
Text File  |  1993-01-25  |  3.1 KB  |  66 lines
  1. Newsgroups: comp.bbs.waffle
  2. Path: sparky!uunet!gatech!bselab.bls.com!skylab!hypnos!dawson
  3. From: dawson@hobbes.bsan.bls.com (Willard Dawson)
  4. Subject: Re: scheduled events that take phone off-hook?
  5. Message-ID: <1993Jan25.174442.1048@hypnos.bssi.bls.com>
  6. Sender: usenet@hypnos.bssi.bls.com (Usenet Administrator)
  7. Organization: BellSouth Systems Integration
  8. References: <930122.145433.6p6.rusnews.w164w@alpha3.ersys.edmonton.ab.ca> <w44VXB3w165w@proteus.qc.ca>
  9. Date: Mon, 25 Jan 1993 17:44:42 GMT
  10. Lines: 54
  11.  
  12. randall@proteus.qc.ca (Randall Reid) writes:
  13.  
  14. >russell@alpha3.ersys.edmonton.ab.ca (Russell Schulz) writes:
  15. >
  16. >> for five minutes, I can't foresee a problem (realistically).  for longer
  17. >> periods of, say, a half-hour and up, I can easily imagine some fabled
  18. >> network trouble indicator light coming on, and no one being pleased that
  19. >> it was just you wanting to give the world a busy signal.
  20. >> 
  21. >> I don't know if these things really exist or not, myself.
  22. >> 
  23. >> again, just ignoring the rings hurts no one, unless your users are clueless
  24. >> to the point of no return.  even then, if they leave, you're just raising
  25. >> the average IQ of your callers...
  26. >> -- 
  27. >> Russell Schulz  russell@alpha3.ersys.edmonton.ab.ca  ersys!rschulz  Shad 86c
  28. >
  29. >Being busy for a user may be OK but for an incoming uucp call its a
  30. >different story IMHO.
  31. >
  32. >I prefer my uucp sites to appear "busy" if they aren't ready to connect to
  33. >me.   The reason is that my Waffle system will respond quickly to a busy
  34. >signal and I can get on with polling someone else.  If the site doesn't
  35. >answer, Waffle will sit there for 10+ rings waiting to time out.
  36.  
  37. The answer to that little problem is called "intelligent polling." :-)
  38. If Tom (or whomever actually owns the darned uucico code) would add support
  39. for "retry" time management, you could rest a bit easier and worry less
  40. about your UUCP neighbors going offline.  Something like most real UNIX
  41. uucico's do... "Retry time not reached..."
  42.  
  43. Of course, if you want to resort to a wrapper program and manage your own
  44. retry-times (calling uucico with specific sitenames), then you've done
  45. effectively the same.  I don't like that too much, but I'm beginning to
  46. think it would be worth the effort, especially now that my own UUCP neigh-
  47. bor count is up around 20, and some of them have had downtime recently.
  48. As long as only a single host is offline, it's not too much a worry.  But,
  49. when three, four, or more are down, you really lose a bunch of time...
  50.  
  51. I'd rather just call "uucico -s any" and have uucico do it's own dirty
  52. work...
  53.  
  54. >This amounts to a "lot" of wasted time for a system that makes around
  55. >200 calls/day and has 20 other uucp sites to service (like mine).
  56. >
  57. >-- 
  58. >Randall J. Reid           Internet: randall@proteus.qc.ca | randall@tpg.org
  59. >Le Groupe Proteus         Uucp: uunet!proteus!randall
  60. >Montreal, Quebec CANADA   Voice: +1 514 630 7103,  FAX: +1 514 331 7934
  61. --
  62.  Willard Dawson, BellSouth Advanced Networks, 1100 Johnson Ferry Road, Ste. 880
  63.  Atlanta, GA  30342, Voice: +1 404 303 2343, UUCP: gatech!vdbsan!hobbes!dawson
  64.  Internet -> X.400:  /G=W/S=DAWSON/O=BSAN/ADMD=BELLSOUTH/C=US/@sprint.com
  65.  Percent hack:  dawson%vdbsan@gatech.edu   ::    Standard disclaimer applies.
  66.