home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / dcom / modems / 13056 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.6 KB
  1. Xref: sparky comp.dcom.modems:13056 comp.unix.sysv386:14131 comp.protocols.misc:668 biz.comp.telebit:899
  2. Newsgroups: comp.dcom.modems,comp.unix.sysv386,comp.protocols.misc,biz.comp.telebit
  3. Path: sparky!uunet!utcsri!geac!torsqnt!uunorth!anton
  4. From: anton@analsyn.gts.org (Anton J Aylward)
  5. Subject: Re: uucico w/v32bis vs zmodem w/v32bis
  6. Message-ID: <1992Sep6.203025.7861@analsyn.gts.org>
  7. Organization: ASCI: UNIX Database and Communications
  8. X-Newsreader: Tin 1.1 PL4
  9. References: <Bu40L8.47w@gator.rn.com>
  10. Date: Sun, 6 Sep 1992 20:30:25 GMT
  11. Lines: 48
  12.  
  13. larry@gator.rn.com (Larry Snyder) writes:
  14. : gert@greenie.ucrc.sub.org (Gert Doering) writes:
  15. : 
  16. : >anton@analsyn.gts.org (Anton J Aylward) writes:
  17. : 
  18. : >>"If Z-modem is so good, why not tell us how to put a plug-in replacement
  19. : >> for UUCP based on Z-Modem, which interfaces to news and mail in just
  20. : >> the same way....."
  21. : 
  22. : >Various people are working on a Z-Modem-like protocol for Taylor-UUCP.
  23. : 
  24. : regular zmodem doesn't do so how with todays high speed modems with
  25. : DTE speeds > 38400.  For example, with my TurboPEP modems, zmodem maxes
  26. : out at around 2100 cps while ymodem-g can exceed that.  What we need is
  27. : a large packet zmodem (like Wazoo -- from Fidonet) with 8K packets to
  28. : take advantage of todays modems and 115200 baud DTE speeds
  29.  
  30. I'll ask again.... any ideas about plugging zmodem in as a dial-in
  31. replacement for UUCP?  Not as "another"  UUCP protocol, but a bit of
  32. encapsulation with C or shell.
  33.  
  34. Main problem is that while I can set up a "BBS" interface, or even a 
  35. login that drops you straight in to zmodem, the beauty of UUCP is that
  36. it is fully autonomous - the C. D. and X. remove the need for human
  37. intervention.  Its not just upload-download.  The X. can say to ram the
  38. D. through rmail/rnews etc.  
  39.  
  40. The other alternative, which I discussed briefly with perher h. once but
  41. never did anything with, is to have dynamicaly extendable protocol
  42. suites.  Imagine the upper layes of uucuci being a collection of
  43. {shell,perl} scripts and there being a set of programs "g", "f", "x" "t"
  44. (etc) which get called at a lower level to do the work:
  45.  
  46.     /usr/lib/uucp/protocols/g/cico [-t n] [-x n] [-r 0|1] C.files.....
  47.  
  48. and so on.
  49.  
  50. This would make applying upgrades to protocols easier... and alalow
  51. people to experiment with new protocols without having to have all of
  52. the rest of the program to worry about.
  53.  
  54. In fact the upper layers can be divided up like this too.  
  55. All the classical justifications about visibility and maintainability
  56. apply.  LRUs for upgrades, changes, enhancements, logging...
  57.  
  58. Ian, are you listening ?
  59. --
  60. Anton J Aylward
  61.