nick@nswitgould.OZ (Nick Andrew) (01/09/89)
in article <1853@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) says: | | I haven't seen any. The reason I didn't mention X/YMODEM in the book probably | has to do with the fact that I don't have the foggiest idea of what | (it is)/(they are). I know about uucp, kermit, X.25, 802, and OSI. Does this | supersede any of these? I hope it supersedes OSI, because that is the one | most in need of being superseded. For MINIX, I suspect kermit is going to be | the standard file transfer mechanism (other than the Amoeba networking for | people with Ethernets). Kermit is available on all known machines, and the | MINIX version seems pretty stable and reasonably efficient. I suspect Kermit is NOT going to be the standard file transfer protocol for Minix, unless it is talking to some of the less capable (comms-wise) mainframes. The standard for the personal computer world has been based around Xmodem, Ymodem, Sealink, Zmodem, etc... for some years now. As much as I respect the Kermit protocol (and I _do_ respect it), it is an inefficient protocol, and does not make full use of Minix's serial capabilities. As a non-streaming protocol, it is slow compared to those protocols mentioned above. I have ported Zmodem to Minix. This required trivial changes to the ioctls setting up the tty1 device. In terms of line utilisation, it seems to achieve nearly 100% utilisation on receive, and about 97% on transmit. (Note these figures are estimates). I am in the process of porting Sealink to Minix. This is a less trivial task, as Sealink was designed for the PC world, whereas Zmodem was designed to be portable over several flavours of Unix. Sealink being a streaming protocol like Zmodem, should achieve close to 100% line utilisation with little overhead, and no propagation time delays. By all means, let's keep Kermit, but I don't feel there is a need to make it the "standard". Regards to all, Nick. -- "Zeta Microcomputer Software" ACSnet: nick@nswitgould.oz UUCP: ...uunet!munnari!nswitgould.oz!nick Fidonet: Nick Andrew on 713/602 (Zeta), nick@nswitgould on 713/603 (ACSgate)
ncoverby@ndsuvax.UUCP (Glen Overby) (01/18/89)
In article <10239@nswitgould.OZ> nick@nswitgould.OZ (Nick Andrew) writes: > As much as I respect the Kermit protocol (and I _do_ respect it), >it is an inefficient protocol, and does not make full use of Minix's serial >capabilities. As a non-streaming protocol, it is slow compared to those >protocols mentioned above. This holds quite true for the original Kermit specification, but it has since been expanded to allow long packets and sliding windows. If I recall correctly, packets can be up to 64K in length, and there can be 128 outstanding packets. I have yet to see an implimentation that allows all of the options; currently most impliment packets up to 1K long and there are only a few sliding windows implimentations. Other nice things about Kermit are that it's protocol is written down in one place (one which is not related to an *implimentation*) and that the authors of the protocol maintain a collection of implimentations. To say that kermit is less efficent is quite subjective since there are so many parameters. It is unfair to compare an XMODEM derivitive in "maximum" mode to a kermit in "minimum" mode. But we're all used to this kind of comparison, right?? :-) BTW, I haven't gotten C-Kermit with the diffs posted recently to assemble/link because asld keeps giving an "out of memory" error (I assume this is on the output). Anybody other than the author gotten this one going? The earlier "uxkermit" works fine on my (8mhz 8088) system. > I have ported Zmodem to Minix. I haven't seen your diffs yet...They may be "trivial", but they still take time. > By all means, let's keep Kermit, but I don't feel there is a need >to make it the "standard". I recall Andy's "Computer Networks" book had an appropriate quote relating to standards... it was something like "the nice thing about computers is that there are so many standards to pick from". Glen Overby ncoverby@plains.nodak.edu uunet!ndsuvax!ncoverby ncoverby@ndsuvax (Bitnet)