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)
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! :-)
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
jeh@dcs.simpact.com (11/10/90)
In article <1990Nov8.033541.1039@grumpy.boston.ma.us>, johna@grumpy.boston.ma.us (John Adams) writes: >>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. Please note that all uucps are supposed to negotiate the protocol to be used. The answerer sends a list of the protocols supported, and the caller sends back the selection. Thus Interactive is free to define a new protocol as long as they (a) get the protocol negotiation right, (b) pick a single-letter protocol identifier that isn't already in use, and (c) continue to support 'g 'protocol. --- 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
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
tron1@tronsbox.xei.com (HIM) (11/11/90)
Actually .. if you are looking for a way to make a protocol that would make
lots of folks happy try this :
IF you are going to define a NEW protocol (as opposed to tweeking one
that exists ... look into one of the two way protocol's.
Sure , this is a more extensive change but it is a provent technology.
While machine A is sending with a "Zmodem" type in one direction,
machine B can ALSO be sending a "Zmodem" type in the other direction.
Granted , some things must be done in case of error's that will stumble
the protocol for a packet or two every now and then , but with
high speed ECC modems like the telebits you still get an overall
win on throughput.
With some > 9600 baud modems the connection is not 9600 bi-directional
but a 9600/2400 combination the flip flops, but you could detect
that and switch to an older method or take the 2400 link anyway.
I am using Diga! (an Amiga terminal program) as a mental starting base
here (and some experiments Ive done with folks here playing with
this type of thing for a custom BBS ).
They have a 2 way file transfer option that overlays a CHAT channel on
top of THAT and the efficiency is almost a 160% speed savings.
(A one way ZMODEM is faster for one file, but the two way tome is faster
than two zmodems)
Look into it.
========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]=======
=Also the mantra and spells, the obeah and the wanga; the work of the wand=
=and the work of the sword: these shall he learn and teach. =
= He must teach; but he may make severe the ordeals. =
=========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 ===================
= NONE of the opinions represented here are endorsed by either =
= Xanadu Enterpises or its clients, AT&T Bell Labs or others. =
=== The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ==== 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)/
curt@cynic.wimsey.bc.ca (Curt Sampson) (11/11/90)
urlichs@smurf.sub.org (Matthias Urlichs) writes: > 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. > [...] > < 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. This is starting to look more and more like zmodem by the minute. Zmodem protocol returns NAKs only. One of the advantages of this scheme is that if you're using a half duplex link there will be no turnarounds until you actually have an error. Zmodem does use blocks of course, because you have to block it to be able to calculate the checksum and the like. It uses adaptive block sizing, though. The better implementations start with 256 byte blocks. They will move down as far as 32 byte blocks (on a very noisy line) or up as far as 8K blocks at 9600 or higher BPS. It can also send a short block of any length to finish off the file. Zmodem also has provisions for a restart on an interupted transfer (i.e., when you hang up or get hung up upon for whatever reason and then call back). It's just like a NAK in the transfer, actually. You just hand it a byte offset into the file and tell it to go. > 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. My copy of the uucp protocol description seemed to imply rather strongly that it would be possible to have a uucp session going in each direction. Obviously, the ones currently in use don't do this. It would be very nice to have, though. There is a protocol out there call Janus, I believe, that supports this. cjs curt@cynic.UUCP | "The unconscious self is the real genius. curt@cynic.wimsey.bc.ca | Your breathing goes wrong the minute your {uunet|ubc-cs}!van-bc!cynic!curt | conscious self meddles with it." --GBS
urlichs@smurf.sub.org (Matthias Urlichs) (11/12/90)
In comp.mail.uucp, article <wsXgs2w163w@cynic.wimsey.bc.ca>,
curt@cynic.wimsey.bc.ca (Curt Sampson) writes:
<
< Zmodem also has provisions for a restart on an interupted transfer
< (i.e., when you hang up or get hung up upon for whatever reason and
< then call back). It's just like a NAK in the transfer, actually. You
< just hand it a byte offset into the file and tell it to go.
<
< > 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.
<
< My copy of the uucp protocol description seemed to imply rather
< strongly that it would be possible to have a uucp session going in
< each direction. Obviously, the ones currently in use don't do this.
< It would be very nice to have, though.
<
The g protocol's packet handler (for those with source code: pk[01].c) would
support bidirectional traffic.
However, neither uucico itself nor the uucico-to-protocol driver interface
(cntrl.c, [fget]io.c) allow this. Implementing bidirectional transfer seems
to imply either a major rewrite, major hacks inside the protocol driver,
implementing a bidirectional data stream (actually two, since uucico wants
"high-level" acknowledgements) for the uucico to talk to, or collecting the
UUCP job files and blasting them across the line with something totally
different.
The second option (protocol driver hackery) would imply to simultaneously (a)
get data from the local uucico and store it somewhere, (b) receive data from
the remote side and store it somewhere else, (c) feed the data from (a) to
the remote side, and (d) feed the incoming data to the local uucico once (a)
is finished. The hard part is to decide what to do about line errors (you'll
have to keep a massive amount of state) and what to do when the remote side
says that it won't accept a file whose receipt you already acknowledged to
the local uucico.
As to sending files over with a different program -- I do have "sz" and "rz"
here to do zmodem with if I have to, but they don't look like it would be
particularly easy to convince them to run bidirectionally.
Does anybody have something which can do real bidirectional stuff?
< There is a protocol out there call Janus, I believe, that supports this.
<
Where? How? Documentation? Source code?
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/curt@cynic.wimsey.bc.ca (Curt Sampson) (11/12/90)
urlichs@smurf.sub.org (Matthias Urlichs) writes: > < There is a protocol out there call Janus, I believe, that supports this. > < > Where? How? Documentation? Source code? It is implemented in version 2.4 of BinkleyTerm, for which source is available. If anybody is interested in a specification document or an acutal hunk of source, I can probably dig it up. Email me for details. cjs curt@cynic.UUCP | "The unconscious self is the real genius. curt@cynic.wimsey.bc.ca | Your breathing goes wrong the minute your {uunet|ubc-cs}!van-bc!cynic!curt | conscious self meddles with it." --GBS
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!
les@chinet.chi.il.us (Leslie Mikesell) (11/16/90)
In article <8290@gollum.twg.com> david@twg.com (David S. Herron) writes: >>(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? Easy - you just send the packet number of the last received packet back in the ACK packet. >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? Almost, but all you have to do is assume that any ACK ack's all previous packets. First, this means that lost ACK's within the transmit window can simply be ignored, but more importantly the speed of error recovery is tied to packet size and skipping some of the ACK's intentionally will be more efficient where there is a high-turnaround time or packet charge on the reverse direction without increasing the time it takes to NAK a bad packet. Ideally, you would ACK slightly before the transmit window is filled (i.e. soon enough for the ACK to get back before transmision stops), but on links that are generally error-free the transmit window could be huge. > >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. I meant that it should try to apply one or more generic schemes and each packet would carry a compression-type code. If none of the schemes work to actually compress the data, it could be passed through uncompressed on a packet-by-packet basis and thus never cause an expansion of more than the type code in the packet header (unlike the normal compress program when used in a pipe). >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. Do you enjoy providing the disk space for both compressed and uncompressed copies? >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. Like the CPU time, it's all the same one way or the other. It's going to take the same amount of work on the compression module whether it is linked into the communication code or not. If it's not, it will always require intermediate disk space to use, and will be more difficult to arrange to happen on remote requests. There will be situations where the link is cheaper than the CPU at one or both ends, something in the link already does compression, or the data is always pre-compressed, so there is still the need to disable it, in which case the type code can be omitted from the packet header. >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.. Do you really want to write a high-level front end for everything that involves communications? Do you want it to know which links need compression and which ones don't? If you want things compressed specifically because they are going across a slow and/or expensive link, then the thing to do is to tie the compression specifically to the transport across that link. The other problem with mail is that it usually consists of lots of little files which don't compress well unless you batch them, and you can't batch them easily unless you impose an arbitrary delay on delivery. The cleanest solution is to do the compression on the fly and allow multiple files to be outstanding in the transmit window, even though this will introduce some new problems to deal with. >>The one other thing that might be considered is a way to escape certain >>control characters within the protocol. >The PhoneNet protocol (available in the MMDF sources but it's history >starts in a different place than MMDF) does exactly that. Unfortunately it would be impossible to negotiate the 2nd most likely situation and remain compatible with existing uucico's. This is the case where you are connected over something that looks like an X.25 PAD and the DLE character is used to get the PAD's attention instead of being passed through. Uucico uses DLE as a start-of-packet character even during the initial negotiations before the protocol is selected. You could, of course, give the program a different name and recognize a new start-up mode when that name is used, but then it becomes more difficult to install and maintain. Les Mikesell les@chinet.chi.il.us
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.
david@actsn.fay.ar.us (David Summers) (11/18/90)
In article <p6v9g2.[q5@smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes: [ ... deleted ... ] > < > 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)/ I tried playing around with multiplexing 2 uucico's last year, creating a total of 4 processes per machine. I tried to implement a sort of Zmodem-type streaming protocol but had strange problems (admittedly (sp?) my first attempt at designing my own protocol) where the receiver would lose packets and things would never get back in sync and finally it would give up. I finally had to back off to having every big packet ACKed by a small packet but I was still coming close to cutting transmission times by 2 when things were flying in both directions. I essentially spoofed UUCICO to think that each connection was the only one on the channel, by using pipes. The biggest problem I ran into was that Xenix (and maybe AT&T SysV???) can only handle about 256 bytes at a time before it starts dropping stuff, when there is any kind of load on the system. I liked what I saw mentioned previously....use existing UUCICO but pipe the input and output through pipes to another process. For some reason I didn't think of that (maybe because I have source?). Anyway, it seems to work but my error correcting protocol is somehow not working and I ran out of time to work on it while trying to finish my undergraduate work and beginning GRAD school. I would like to work on it some more but haven't found the time. I could send the sources to anyone interested, or put it up for FTP if there is enough interest. Be warned that it is only the mods to the standard UUCP and most of that is just in the protocol selection. UUCICO is designed to just drop in another protocol and I took advantage of that. I created my own 'b' protocol to test thins out. I also have it set up to test out on an error "connection" between two pipes on the same computer. It was interesting trying to debug 8 processes at once....... - David Summers (david@actsn.fay.ar.us) -- I'm sick and tired of this machine, I wish that I could sell it. It never does just what I want, but only what I tell it! - David Summers (david@actsn.fay.ar.us)
rsalz@bbn.com (Rich Salz) (11/21/90)
In <1990Nov16.060148.2194@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Almost, but all you have to do is assume that any ACK ack's all previous >packets. ... much discussion of ACK's and windows deleted... If you're going to redesign TCP, make sure you read ALL about it first. It is one of the best sliding-window protocols around, and has undergone more design and implementation engineering than UUCP ever will. Get the TCP-related RFC's (and there are a bunch of them) and perhaps read Comer's internetworking book. Protocol design is VERY HARD. /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.
anton@bkj386.uucp (Anton Aylward) (11/22/90)
I have often stated that the bulk of UUCP should be done with shell not with C. Why ? Well look at the XENIX version, the dialer is 'just a program'. UUCICO doesn't care it is is C or a shell script. Various modules gatehr the list of work files, check if machines are callable, and deal with lists, which can easily be donw with the shell. We could do the same with the protocol modules: gprotocol read file to stdout gprotocol write file read from stdin fprotocol ....... and make the whole thing table driven. We would then be able to easily tune the timeout, substitute better send-expect handling..... OK, it makes it easy to modify, configure, tune and extend. By the software metrics I have always worked to thet is a GOOD THING (tm). So why aren't we doing this ? /anton aylward
shwake@raysnec.UUCP (Ray Shwake) (11/23/90)
anton@bkj386.uucp (Anton Aylward) writes: >I have often stated that the bulk of UUCP should be done with shell not with C. [writer's arguments for this proposition] >So why aren't we doing this ? Since the original UUCP implementation *was* written using shells, it might be more accurate to ask "why aren't we doing this any longer?" The answer, of course, is that it's much less efficient, and much less secure, than a compiled implementation.