Xref: utzoo comp.mail.uucp:5466 comp.dcom.modems:7343 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!dimacs.rutgers.edu!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.mail.uucp,comp.dcom.modems Subject: Re: What should a new UUCP protocol do? Message-ID: <8290@gollum.twg.com> Date: 15 Nov 90 21:13:43 GMT References: <1990Nov07.155516.17815@ism.isc.com> <1990Nov09.230452.6549@chinet.chi.il.us> Reply-To: david@twg.com (David S. Herron) Followup-To: comp.mail.uucp Distribution: usa Organization: The Wollongong Group, Palo Alto, CA Lines: 62 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, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Use the force Wes!