jhc@mtune.UUCP (07/30/86)
In article <538@pyramid.UUCP> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >>I think HoneyDanber is now the standard version of UUCP in S5R3. > >Correct. The current 3B release of SVR2 also includes HDB as standard. (Both >are woefully lacking in transition tools. *SIGH*) The S5R3 HDB also has a new >'e' protocol that uses TLI on streams, a small hack that is trumpted all over >the SVR3 promotional literature. I'd be curious to know who wrote it since it >doesn't look like Peter & company's work. (It's obvious from the labels that >the 'e' originally meant Ethernet.... :-)) Correct. HDB is in SVR3. Actually a development of HDB uucp, with some extra features, like the ability to split up Systems/Devices/Dialers, and being able to specify protocols in Devices, which is the correct place to do such things. I think that Carl has it the wrong way round - TLI can use proto 'e', and TLI is (in SVR3) streams-based. Fortunately I haven't seen the SVR3 promo blurb. I tend to agree that 'e' originally meant Ethernet, since 'e' protocol was originally only included if the system was running UNET. Of course, it could mean 'express' or 'extra' or enything :-). But surely the 'e' protocol pre-dates HDB, and at least some sites are offering it - bellcore for example. I'm sure they only mean to use it over their X.25 links, but they do offer it if you call them. BTW proto 'e' is *fast*, running over ISN and STARLAN on UNIX PC's I get the following results: 9600 baud/proto g: ~750 chars per second STARLAN/proto g: ~1700 chars per second STARLAN/proto e: ~26000 chars per second (yes, thousand) That's from memory - if I remembered wrong then I'll post a retraction. -- Jonathan Clark [NAC,attmail]!mtune!jhc My walk has become rather more silly lately.
halloran@unirot.UUCP (Bob Halloran) (07/31/86)
In article <679@mtune.UUCP> jhc@mtune.UUCP (Jonathan Clark) writes: >In article <538@pyramid.UUCP> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >>>I think HoneyDanber is now the standard version of UUCP in S5R3. >> >>Correct. The current 3B release of SVR2 also includes HDB as standard. (Both >>are woefully lacking in transition tools. *SIGH*) The S5R3 HDB also has a new >>'e' protocol that uses TLI on streams, a small hack that is trumpted all over >>the SVR3 promotional literature. I'd be curious to know who wrote it since it >>doesn't look like Peter & company's work. (It's obvious from the labels that >>the 'e' originally meant Ethernet.... :-)) > >I tend to agree that 'e' originally meant Ethernet, since 'e' protocol >was originally only included if the system was running UNET. Of >course, it could mean 'express' or 'extra' or enything :-). But surely >the 'e' protocol pre-dates HDB, and at least some sites are offering >it - bellcore for example. I'm sure they only mean to use it over >their X.25 links, but they do offer it if you call them. Actually, I believe it means 'error-free'; it's made for use over a channel that does its own error handling, hence the radically improved throughput you achieved, since no error checking/correction was being done in the software (your results edited out on this followup). There is also an 'x' protocol module specifically for X.25 links. Bob Halloran, Consultant ========================================================================= UUCP: topaz!caip!unirot!halloran DDD: (201)251-7514 CSNet/ARPA: unirot!halloran@caip.rutgers.edu ATTmail: RHALLORAN USPS: 19 Culver Ct, Old Bridge NJ 08857 Disclaimer: I speak for myself. Quote: "History is made at night. Character is what you are in the Dark." - Dr. Lizardo/John Whorfin, "Buckaroo Banzai"
jhc@mtune.UUCP (Jonathan Clark) (08/01/86)
Continuing the protocol-name discussions... proto "e"'s name is indeed given as "error-free" in the source. From a very brief look I was unable to determine the exact differences between "e" and "x" protocols, except that there are more DEBUG statements in "e" and more fiddling with timeouts in "x". "x" is given as X.25. Certainly the sources are *very* similar. I think that "x" is meant for use over bursty, packetizing X.25 links and "e" over non-bursty non-packetizing links but I don't really know. -- Jonathan Clark [NAC,attmail]!mtune!jhc My walk has become rather more silly lately.