johnan@ism.isc.com (John Antypas) (11/07/90)
Interactive Systems is now the fortunate owner of many different modems. Some are Telebits, some are V.32, some are 2400 baud no-namers, etc. Unfortunately, we do UUCP with all of them. We've been looking at the transfer stats and have noticed the different flavors of modems each treat UUCP a bit different. We are looking into placing a new protocol into UUCP which copes with the higher-speed modems, but doesn't require protocol spoofing, nor does it assume your running X.25 (no f protocol). What characteristics should we shoot for when dealing with what we call, the new low-end high speed modem. This "modem" appears to have the followig basics: NOT V.32, V.42/42.bis, PEP! Totally unique protocols Can do 9600 baud without compression, but with compression can do 38.4K Either does not have a back channel, or must "turn the channel around" and can take a second or so to do it. I've been looking at a modified 'g' protocol using 2K blocks window size 7. Am I completely off track? Obviously, this works best with ASCII files in bulk like Batch SMTP. Tell us what you want, maybe we can put it in. John Antypas / Interactive Systems Corp. uucp: ...!uunet!ism!johnan Internet: johnan@ism.isc.com All statements above responsability of the author.
cec@cup.portal.com (Cerafin E Castillo) (11/08/90)
Make sure that it is compatible with ALL existing UUCP 'g' protocol
implementations.
Don't rely on compression. V.32bis is a 14.4 kbps protocol now
being used. You should be able to do at least 14.4 kbps. Serial
interface should be 38.4 kbps capable.
A low ACK/NACK with large packet capability would be great (i.e.
Z-modem), with the role reversals and statistics.
It would also be great to be able to use uucp interactively, in
the way of a Kermit server...
BETTER ERROR MESSAGES!!!! Please tell the user what really went
wrong. No more NFW errors!
A better UUX command.
Built-in Pathalias or mail path resolution.
Start with the basics interface, as well as the protocol. Efficiency
and user friendliness would help just as much as speed.
Good Luck!
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \|| \\|
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
NTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================johna@grumpy.boston.ma.us (John Adams) (11/08/90)
In article <1990Nov07.155516.17815@ism.isc.com> johnan@ism.isc.com (John Antypas) writes: >Interactive Systems is now the fortunate owner of many different modems. >We are looking into placing a new protocol into UUCP which copes with >the higher-speed modems, >Tell us what you want, maybe we can put it in. We want a protocol which is supported by all callable uucp sites. Do you intend to distribute patches for all existing UUCP binaries? A new protocol may have merit but only if it's widely distributed. -- John Adams johna@grumpy.boston.ma.us (617) 646-6491
grr@cbmvax.commodore.com (George Robbins) (11/08/90)
In article <1990Nov07.155516.17815@ism.isc.com> johnan@ism.isc.com (John Antypas) writes: > Interactive Systems is now the fortunate owner of many different modems... > > We are looking into placing a new protocol into UUCP which copes with > the higher-speed modems, but doesn't require protocol spoofing, nor > does it assume your running X.25 (no f protocol). What characteristics > should we shoot for when dealing with what we call, the new low-end > high speed modem. Please review carefully all existing BSD and AT&T protocols and see which are salvagable. The silly little "g" protocol should give good results if you fix the buffer allocation stuff so you can actually negotiate packet sizes. It's easy... **BUT** you also need to make sure the tty drivers will support large "raw" queues - 255 characters isn't enough, and watch out for other raw mode silliness. It may all be fixed with streams??? I'd also suggest you get in touch with rick@uunet or csg@pyramid - these and others have invested serious time into uucp problems and foibles.. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
root@zswamp.fidonet.org (Geoffrey Welsh) (11/08/90)
John Antypas (johnan@ism.isc.com ) wrote: >Interactive Systems is now the fortunate owner of many >different modems. >Some are Telebits, some are V.32, some are 2400 baud >no-namers, etc. >Unfortunately, we do UUCP with all of them. You are just the sort of person I (and, I am sure, many others) need to chat with! (I sense you running away already.) Could you list the modems you use and your impressions of them? Any glaring problems? Perhaps you'd categorize them as 'perfect' <grin>, 'good', 'workable' and 'NFG'? The modem market is so confusing today. Many people come to me asking for recommendations... at 9600 bps, the answer was usually easy, dictated by the application: UUCP implied Telebit, BBSing implied USRobotics. At 2400, I always named Hayes because I can be sure that the product is good and the service excellent. However, most 2400 bps buyers turn away when they hear that. They don't want to pay Hayes prices, and I'm at a loss to suggest reliable, let alone comparable, 2400 bps modems that are not as expensive as Hayes'. V.32 opens a whole new can of worms. I am about to embark on a V.32 modem evaluation spree which may include GVC, USRobotics, Practical Peripherals, ATI, and Lord knows who else. >We are looking into placing a new protocol into UUCP which >copes with >the higher-speed modems, but doesn't require protocol >spoofing, nor >does it assume your running X.25 (no f protocol). What >characteristics >should we shoot for when dealing with what we call, the new >low-end >high speed modem. Basically, this 'problem' has already been solved outside of the UUCP world, and the answer looks a lot like Omen Technologies' ZMODEM. FidoNet, which deals with the lack of Usenet's financial resources by squeezing every bit of efficiency it can, uses a protocol called ZedZap (among others), a ZMODEM type protocol whioch allows for much larger block sizes than the original ZMODEM spec (8K at 9600 bps). ZMODEM provides much larger data blocks than UUCP-g, meaning lower overhead. It doesn't require ACKs during an error-free transfer, meaning that it will work well with PEP, V.29, and other unidirectional carriers. It does correct errors when necessary, so a guaranteed error-free link isn't necessary (unlike UUCP-e), but having one does help throughput. The downside is that streaming protocols like ZMODEM require perfect co-ordination of handshaking between the modems and their hosts. UUCP-g doesn't, if you assume (or provide) a buffer at every point that exceeds the maximum window size. >Can do 9600 baud without compression, but with compression >can do 38.4K Leave that up to hardware compression on the modems (PEP2, MNP5, V.42bis) or precompress the data (like compressed batched news). >Either does not have a back channel, or must "turn the >channel around" and can take a second or so to do it. The only solution to this is a streaming protocol. >I've been looking at a modified 'g' protocol using 2K blocks >window size 7. This would still require an ACK (implying a carrier reversal) every block (2K at PEP speeds is 1.5 - 2 seconds; do you want to induce up to 30 pairs of carrier reversals every minute? >Tell us what you want, maybe we can put it in. I think that a ZMODEM-based UUCP protocol is long overdue. No protocol is perfect under all circumstances, but ZMODEM is a fairly versatile protocol with relatively high efficiency (especially compared to other 'universal' protocols like Kermit!) Disclaimer: I don't own or operate an Interactive Systems OS. I can't recall ever *seeing* one. My suggestion is made in good faith as my worthy deed of the day. You're not going to increase your revenue from me by taking up the idea, nor do I proimise to abandon all my worldly posessions and sell ISC products. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
king@motcid.UUCP (Steven King) (11/08/90)
In article <1990Nov8.033541.1039@grumpy.boston.ma.us> johna@grumpy.boston.ma.us (John Adams) writes: >We want a protocol which is supported by all callable uucp sites. >Do you intend to distribute patches for all existing UUCP binaries? >A new protocol may have merit but only if it's widely distributed. And not to forget non-Unix machines. There are a fair number of sites based on other platforms that are using UUCP clones to handle transfers. Any new protocol will have to be backward compatible with the older one. -- ---------------------------------------------------+--------------------------- The trouble with living in sin is the shortage | Steven King 708-540-6771 of closet space. | Motorola Cellular (Missy Dizick) | ...uunet!motcid!king
friedl@mtndew.Tustin.CA.US (Stephen Friedl) (11/08/90)
John Antypas from Interactive askes what we are looking for in a new+better UUCP protocol, then John Adams responds: > > We want a protocol which is supported by all callable uucp sites. > Do you intend to distribute patches for all existing UUCP binaries? > A new protocol may have merit but only if it's widely distributed. Get uunet to run it and it will become popular Real Fast. Stephen -- Stephen J. Friedl, KA8CMY / I speak for me only / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl Only 6% of North Carolina blacks didn't vote racist
guy@auspex.auspex.com (Guy Harris) (11/09/90)
>It would also be great to be able to use uucp interactively, in >the way of a Kermit server... > >BETTER ERROR MESSAGES!!!! Please tell the user what really went >wrong. No more NFW errors! > >A better UUX command. > >Built-in Pathalias or mail path resolution. > >Start with the basics interface, as well as the protocol. Efficiency >and user friendliness would help just as much as speed. All the above are nice, *but* far beyond the scope of what I infer ISC is thinking of doing - I think they're just looking at doing a new low-level protocol, at the same level as the "g", "e", "t", "f", etc. protocols. You're asking for a new UUCP, not a new UUCP protocol; I don't have any problem with that, just bear in mind that it sounds like it's outside the cope of what ISC wants to do....
jdeitch@jadpc.cts.com (Jim Deitch) (11/09/90)
In article <1990Nov07.155516.17815@ism.isc.com> johnan@ism.isc.com (John Antypas) writes: >Interactive Systems is now the fortunate owner of many different modems. >Some are Telebits, some are V.32, some are 2400 baud no-namers, etc. >Unfortunately, we do UUCP with all of them. We've been looking at the >transfer stats and have noticed the different flavors of modems each >treat UUCP a bit different. > >We are looking into placing a new protocol into UUCP which copes with >the higher-speed modems, but doesn't require protocol spoofing, nor >does it assume your running X.25 (no f protocol). What characteristics >should we shoot for when dealing with what we call, the new low-end >high speed modem. > >This "modem" appears to have the followig basics: > >NOT V.32, V.42/42.bis, PEP! Totally unique protocols >Can do 9600 baud without compression, but with compression can do 38.4K >Either does not have a back channel, or must "turn the channel around" and > can take a second or so to do it. > >I've been looking at a modified 'g' protocol using 2K blocks window size 7. >Am I completely off track? Obviously, this works best with ASCII files >in bulk like Batch SMTP. > >Tell us what you want, maybe we can put it in. > >John Antypas / Interactive Systems Corp. >uucp: ...!uunet!ism!johnan Internet: johnan@ism.isc.com >All statements above responsability of the author. How about something that has been in use on the FIDO net system for quite some time. When you use the frontend, Binkleyterm, one of the transfer protocols is called Zed Zap. What happens is this: If the connection is 9600 or greater the block size is put at 8k and they use a zmodem type of streaming protocol. If the speed is 2400 baud but less than 9600 baud the block size is 2k and the streaming protocol is used. If the modem speed is less than 2400 baud then they use a block size of 1k and the streaming protocol is used. This results in the best of both worlds, high block rates with no reverse channel unless there is a problem. It also causes an expect error message that is realitivley the same time wise regardles of the speed of the connection. You asked and I answered. Jim -- UUCP: nosc!jadpc!jdeitch ARPA: jadpc!jdeitch@nosc.mil INET: jdeitch@jadpc.cts.com
larry@syscon.UUCP (Larry Snyder) (11/10/90)
cec@cup.portal.com (Cerafin E Castillo) writes: >Make sure that it is compatible with ALL existing UUCP 'g' protocol >implementations. >Don't rely on compression. V.32bis is a 14.4 kbps protocol now >being used. You should be able to do at least 14.4 kbps. Serial >interface should be 38.4 kbps capable. will these new modems with v.32bis be backwards compatible with v.32 with v.42bis? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
urlichs@smurf.sub.org (Matthias Urlichs) (11/10/90)
In comp.dcom.modems, article <1889.2739aa0d@dcs.simpact.com>, jeh@dcs.simpact.com writes: < In article <1990Nov07.155516.17815@ism.isc.com>, johnan@ism.isc.com < (John Antypas) writes: < > [...] < > I've been looking at a modified 'g' protocol using 2K blocks window size 7. < > Am I completely off track? < < This is a fine idea, but it isn't really a modified 'g' at all. 'g' supports < up to 4K packets and a transmit window size of 7. Some *implementations* are < restricted to 64 byte packets and a tx window of 3, but there is provision in < the startup sequence for learning what the other end wants and restricting < yourself to that. So a 'g' that handles 4Kx7 can still talk to one that < only does 64x3. < Sorry, but no. Lots of g's _think_ they can do 4K packets, but internally they use some stupid small buffers anyway because the support for big blocks hasn't been tested in the last ten years or so. You'll also run into trouble if you try to talk to a Telebit with UUCP spoofing enabled, and want to use bigger blocks. < If the modems do NOT give you a reliable data link, you are back to acking < each packet. Actually, it might be sufficient to NAK packets if there's an error but to keep quiet otherwise. Using UUCP, this is OK because you're transmitting a file and the sender can always back up as far as the receiver wants it to. < [...] Also note that, for a < scheme where packets are numbered modulo 'n', the maximum transmit window < size for a retransmit-entire-window protocol like 'g' is n-1, but for a < selective reject protocol it is (n/2)-1. < It might be a better idea to just use the offset into the file you're transmitting. That way you wouldn't need to worry about windowing and the machines involved could agree on these things on a dynamic basis. (On the other hand, you'd also need a start character, and some size information, and a CRC checksum, and that might incur too much overhead. :-( ) One problem that you're not going to cure with this is that if you have a full duplex link, about half the bandwidth is wasted. Fixing this would probably require major mods to the uucico's involved. Hmmmm ... Thinking some about this ... you could possibly fake it by talking to a sending and a receiving uucico across two pty ports, and multiplexing the resulting full duplex data stream yourself. Hmmm --- that way you wouldn't even have to modify your uucico. If I had enough time I would do this -- the idea certainly looks like it would work. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/
atman@ecst.csuchico.edu (Homeless hacker) (11/10/90)
In article <5134@orchid3.UUCP> king@motcid.UUCP (Steven King) writes: >And not to forget non-Unix machines. There are a fair number of sites >based on other platforms that are using UUCP clones to handle transfers. >Any new protocol will have to be backward compatible with the older one. No no no, just release portable source. Make sure all your variable names are 8 characters or less! :-)
marc@aria.UUCP (Marco S Hyman) (11/10/90)
In article <5134@orchid3.UUCP> king@motcid.UUCP (Steven King) writes:
Any new protocol will have to be backward compatible with the older one.
Not so. A new UUCP would have to be backward compatible, but not a new UUCP
protocol. It is reasonable to require both ends of a connection to speak
the same protocol. Old UUCPs or UUCP clones would just negotiate the use of
a different protocol.
BTW: USENIX was looking at UUCP a few (6?) months ago. Did anything ever
come out of that?
// marc
--
// work: aria!marc@uunet.uu.net uunet!aria!marc
// home: marc@dumbcat.sf.ca.us {ames,sun}!pacbell!dumbcat!marc les@chinet.chi.il.us (Leslie Mikesell) (11/10/90)
In article <1990Nov07.155516.17815@ism.isc.com> johnan@ism.isc.com (John Antypas) writes: >I've been looking at a modified 'g' protocol using 2K blocks window size 7. >Am I completely off track? Obviously, this works best with ASCII files >in bulk like Batch SMTP. How much work do you want to do? I'd start by making the packet and window sizes negotiable, as well as the frequency of ACKs desired (it's not really necessary to ACK every packet, but it may be desirable to use small packets so you can request a resend of a small piece when necessary). Then I would allow a configuration file setting for the initial values and minimum and maximum limits for each of these variables for each entry in Systems, Devices, and Dialers (actually the equivalents as per Sysfiles), plus an entry for inbound devices. When this new protocol is agreed upon, each machine would take the smallest of the values from the relevant entries and pass to the other machine, and the smaller of the two values for each variable would be used for the session. This would allow the best values for the most limiting factor, whether it is the destination machine (Systems), the modem setup (Dialers), or the communications link - modem/PAD/satellite (Devices). The session would start out with the pre-set initial values and increase the values to the maximums after a few error-free packets - any errors would drop the values to the mimimum and several error-free packets would be required before working upwards again. A log of the errors would make it possible to optimize for any type of link. Compression would be another possibility at this level but it should also be controlled by the config files so it could be disabled where something in the link compresses for you or one of the machines doesn't want the CPU overhead. It should also be done on a per-packet basis (though not necessarily alligned with the communications protocol packets) so that already-compressed data will never expand by more than the packet headers. The next thing to tackle would be windowing the per-file ACKs. That is, do not wait for permission to start sending a file on start-up (but let the receiver discard and cancel) and do not wait for the final ACK after each file before sending the next. Doing this correctly will require some state information to be saved between sessions to detect cases where a file is transferred correctly but the ACK does not get back to the sender (this happens now, but with a maximum of one file per session and uux jobs typically take at least two files for the receiver to be able to execute anything). This part is likely to be the hardest to work into the existing scheme, but it is the most significant if you transfer a lot of small mail messages and don't want to impose the arbitrary delays to apply some other form of batching. The one other thing that might be considered is a way to escape certain control characters within the protocol. I'm thinking specifically of links that need (or work best with) xon/xoff flow control and/or have a data-link escape character that normally doesn't pass through, but it would be nice to generalize this into something that could be specified in the config files. Les Mikesell les@chinet.chi.il.us
grr@cbmvax.commodore.com (George Robbins) (11/10/90)
In article <1889.2739aa0d@dcs.simpact.com> jeh@dcs.simpact.com writes: > In article <1990Nov07.155516.17815@ism.isc.com>, johnan@ism.isc.com > (John Antypas) writes: > > [...] > > [...] > > I've been looking at a modified 'g' protocol using 2K blocks window size 7. > > Am I completely off track? > > This is a fine idea, but it isn't really a modified 'g' at all. 'g' supports > up to 4K packets and a transmit window size of 7. Some *implementations* are > restricted to 64 byte packets and a tx window of 3, but there is provision in > the startup sequence for learning what the other end wants and restricting > yourself to that. So a 'g' that handles 4Kx7 can still talk to one that > only does 64x3. Note that this isn't precisely true. Due to an incomplete implemenation of the negotiation/startup code, most versions of uucp will "negotiate" the larger packet sizes, but blow off when they scribble past the end of the "big" buffers. This requires that either the user be able to specify window/packet sizes (not a bad idea) or the use of a new protocol designator to indicate a working "g" protocol. I believe "G" has been suggested. The problem exists in the versions of uucp that serve as the base for the pre-HDB AT&T uucp and the 4.2/3 BSD uucp. This represents a very large percentage of the traditional uucp installed base. I don't recall right off if HDB does it right, if so then a growing segment of the uucp base could play. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
jeh@dcs.simpact.com (11/11/90)
In article <+2m8g2.lb1@smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes: > In comp.dcom.modems, article <1889.2739aa0d@dcs.simpact.com>, > jeh@dcs.simpact.com writes: > < [uucp g negotiates packet and window size] > < yourself to that. So a 'g' that handles 4Kx7 can still talk to one that > < only does 64x3. > > Sorry, but no. > > Lots of g's _think_ they can do 4K packets, but internally they use some > stupid small buffers anyway because the support for big blocks hasn't been > tested in the last ten years or so. Hmmmmm. Well, if one still wanted to stay with "g", this would be fixable with an option in the systems file entry(ies) for those hosts. "When talking to this host, restrict packet size to n, and window size to m." > You'll also run into trouble if you try to talk to a Telebit with UUCP > spoofing enabled, and want to use bigger blocks. THis I have not seen -- I have tested a 7x4k g through a TB+ and it works fine, though it only runs 3x64. Ad I don't know why there should be trouble. The packet and window size negotiation is not really "negotiation", it is each receiver telling the sender "this is the biggest number I can handle", and the sender is expected to comply. If the telebit tells me that it won't take more than 3x64, that's all I'll send. And if I tell the telebit that I can take 7x4K, but it only chooses to send me 3x64, that works fine too. And that is exactly what happened in my tests, confirmed both by debug output and by line analyzer. > Actually, it might be sufficient to NAK packets if there's an error but to > keep quiet otherwise. Using UUCP, this is OK because you're transmitting a > file and the sender can always back up as far as the receiver wants it to. Sounds like zmodem. Which is not intended as a pejorative statement -- just an observation. > One problem that you're not going to cure with this is that if you have a > full duplex link, about half the bandwidth is wasted. Fixing this would > probably require major mods to the uucico's involved. > > Hmmmm ... Thinking some about this ... you could possibly fake it by ... Someone actually hacked this together a year or so ago. As I recall he never did get it working perfectly but I am sure this was just an implementation bug and not a real flaw in the design; the design looked fine. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
urlichs@smurf.sub.org (Matthias Urlichs) (11/11/90)
In comp.dcom.modems, article <1898.273bd977@dcs.simpact.com>, jeh@dcs.simpact.com writes: < In article <+2m8g2.lb1@smurf.sub.org>, urlichs@smurf.sub.org < (Matthias Urlichs) writes: < > < > Lots of g's _think_ they can do 4K packets, but internally they use some < > stupid small buffers anyway because the support for big blocks hasn't been < > tested in the last ten years or so. < <Hmmmmm. Well, if one still wanted to stay with "g", this would be fixable with <an option in the systems file entry(ies) for those hosts. "When talking to <this host, restrict packet size to n, and window size to m." < OK, but that implies that the protocol can get at the systems file entry, which requires modification of your UUCP beyond linking in another protocol and augmenting the protocol table. It might be better to create a new protocol for working big-packet g protocol implementations. Call it "G". ;-) < > You'll also run into trouble if you try to talk to a Telebit with UUCP < > spoofing enabled, and want to use bigger blocks. < <This I have not seen -- I have tested a 7x4k g through a TB+ and it works fine, <though it only runs 3x64. [...] Hmmm ... I'll have to look into this some more, then... < > One problem that you're not going to cure with this is that if you have a < > full duplex link, about half the bandwidth is wasted. < > Hmmmm ... Thinking some about this ... you could possibly fake it by ... < > [ multiplexing two uucico conversations onto one line ] < <Someone actually hacked this together a year or so ago. As I recall he never <did get it working perfectly but I am sure this was just an implementation bug <and not a real flaw in the design; the design looked fine. < Are the sources for this available anywhere? -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/
mje@olsa99.UUCP (Mark J Elkins) (11/12/90)
In article <1898.273bd977@dcs.simpact.com> jeh@dcs.simpact.com writes: >In article <+2m8g2.lb1@smurf.sub.org>, urlichs@smurf.sub.org >(Matthias Urlichs) writes: >> In comp.dcom.modems, article <1889.2739aa0d@dcs.simpact.com>, >> jeh@dcs.simpact.com writes: >> < [uucp g negotiates packet and window size] >> < yourself to that. So a 'g' that handles 4Kx7 can still talk to one that >> < only does 64x3. >THis I have not seen -- I have tested a 7x4k g through a TB+ and it works fine, .... >exactly what happened in my tests, confirmed both by debug output and by line >analyzer. Apart from using a line analyser (I assume you mean Data-Scope) (what do you look for??), how can you tell what a particular machines version of uucp is using?? I've been hacking some uucico source (adding other protocols - etc) but the negotiation that 'G' does leaves me cold - so again - how can you tell both the buffer and window sizes? (Where is it in the Source code [at+t V Rel 3.2])??? >> Actually, it might be sufficient to NAK packets if there's an error ... >Sounds like zmodem. Which is not intended as a pejorative statement -- just an >observation. I had heard that Sys V Rel 4.0 was ment to use something like this - or at least, uucp would have the ability to start up a file transfere from were it had been cut off - just like Z-modem! >> Hmmmm ... Thinking some about this ... you could possibly fake it by ... >Someone actually hacked this together a year or so ago. As I recall he never >did get it working perfectly but I am sure this was just an implementation bug >and not a real flaw in the design; the design looked fine. Given the oppertunity to add to the wish list, 1 - Plug-in protocols (eg 'e', 'f', 'h', 'x'....) (so you don't need source code) 2 - Plug in Dialers... somewhat in the way that SCO does, ie - you could add 'connectors' for ethernet, built-in X25, funny modems.... etc -- . . ___. .__ Olivetti Systems & Networks, Unix Support - Africa /| /| / /__ UUCP: {uunet,olgb1,olnl1}!olsa99!mje (Mark Elkins) / |/ |ARK \_/ /__ LKINS mje@olsa99.UUCP (Postmaster) Tel: +27 11 339 9093
david@twg.com (David S. Herron) (11/16/90)
In article <1990Nov09.230452.6549@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Nov07.155516.17815@ism.isc.com> johnan@ism.isc.com (John Antypas) writes: >>I've been looking at a modified 'g' protocol using 2K blocks window size 7. >>Am I completely off track? Obviously, this works best with ASCII files >>in bulk like Batch SMTP. > >How much work do you want to do? I'd start by making the packet and >window sizes negotiable, as well as the frequency of ACKs desired >(it's not really necessary to ACK every packet, but it may be desirable ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yeeaaaahh.. that makes me shudder.. how do you tell the difference between a lost NAK & an ACK which you ACK'd without ACKing? Now.. if your protocol did a "mass ACK" by, for instance, saying "this ACK is for packets 1,3-5,7,8-12" then the cost of ACKing is greatly reduced. Is this what you mean? >Compression would be another possibility at this level but it should also >be controlled by the config files so it could be disabled where something >in the link compresses for you or one of the machines doesn't want the >CPU overhead. It should also be done on a per-packet basis (though not >necessarily alligned with the communications protocol packets) so that >already-compressed data will never expand by more than the packet headers. erm.. why would it be good for the communications protocol to pick out the compression scheme? The protocol doesn't know a bit about what kind of data it's transmitting &so can only use some generic scheme. Instead I feel that it'd be best for the compression to be done outside the protocol -- like it's done now with Usenet news. This way if the end-{user,process} knows it's transmitting video sequences it can use some compression well-suited for *that* while Usenet news can continue using compress v4 ... Note that for CPU load it (probably) doesn't matter whether the compression is done in uucico or in a seperate program, it's still CPU time on the local system. Finally -- adding compression into a protocol module will make it larger, make it take longer to write, and longer to debug. Note that mail isn't currently compressed. It would be pretty simple to write an rmail which recognized that the input was compressed, after all that's why compress-v4 has it's own magic number, and decompress it before doing anything else. But I *gaurantee* that it'd be a looooong time before that was supported very widely.. >The one other thing that might be considered is a way to escape certain >control characters within the protocol. I'm thinking specifically of >links that need (or work best with) xon/xoff flow control and/or have >a data-link escape character that normally doesn't pass through, but >it would be nice to generalize this into something that could be specified >in the config files. The PhoneNet protocol (available in the MMDF sources but it's history starts in a different place than MMDF) does exactly that. In the config file you give what amounts to being a 256-bit bitmap of characters that can be sent through a particular link. It has some way of negotiating how the illegal characters are escape'd at the initial handshake &such. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Use the force Wes!
rsalz@bbn.com (Rich Salz) (11/17/90)
In <1898.273bd977@dcs.simpact.com> jeh@dcs.simpact.com writes: >THis I have not seen -- I have tested a 7x4k g through a TB+ and it works fine, >though it only runs 3x64. I believe that's because peter wrote the (first version) of the TB spoofing code. (He's the H in HDB.) Most other UUCP's are buggy in that they either get the negotiation wrong, or believe and then happily overrun their fixed- sized buffers. Rick Adams and Carl at Pyramid worked on this stuff over three years ago (ahh, for the days when pyramid!csg would email me the latest Pyramid UUCP for the asking... :-) /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
ed@alt.dah.sub.org (Ed Braaten) (11/17/90)
mje@olsa99.UUCP (Mark J Elkins) writes: >Given the opportunity to add to the wish list, >1 - Plug-in protocols (eg 'e', 'f', 'h', 'x'....) (so you don't need > source code) Great idea! This would be major improvement. Has anybody at Interactive, SCO, AT&T, etc. considered this? --------------------------------------------------------------------------- Ed Braaten | "... Man looks at the outward appearance, Work: ed@imuse.de.intel.com | but the Lord looks at the heart." Home: ed@alt.dah.sub.org | 1 Samuel 16:7b ---------------------------------------------------------------------------