Am 21.04.2016 um 11:31 schrieb Johnny Billquist:
Yes, I know, that FTP uses two TCP channels on ports 20 and 21 for the traffic, and a large number of higher incoming ports - a major nightmare for firewalls. Beyond the necessary negotiations for that, and the use of certain textual acknowledge codes, it effectively does no more than the above for transferring a file than the above. It has quite a number of additional commands to browse a directory tree, and other things, and there is passive/active mode and quoted command extensions, but they are not strictly necessary for the purpose.On 2016-04-21 10:01, Veit, Holger wrote:Am 20.04.2016 um 22:35 schrieb Sampsa Laine:On 20 Apr 2016, at 23:25, Phil Budne <[email protected]> wrote: Ken.Cornetet wrote:I guess I need to shout this: ******* KERMIT DOES NOT WORK ON SIMH EMULATED RTE-6/VM ********Why not?Kermit does not exist (and probably couldn't feasibly exist) on any earlier versions of RTE.Again, why not? Having just written a new shell for PDP-7 UNIX (because the original could not be found), I can't imagine much other than a lack of something resembling a serial console that would prevent _some_ version/subset of KERMIT (or something similar like X or ZMODEM) from being cobbled together.And since the connection can be assumed to be lossless, the protocol could be really simple, e.g. something like this: G=Guest, H=Host Example of a write operation.. G: WRITE-FILE H: ACK // Now we send the file structure / word size etc G: FILE-META-DATA G: <file size and a bunch of OS specific stuff that is written to a second file> H: ACK G: FILE-DATA G: <the actual data> G: ACK Done.And this is just a non-formalized textual description of how FTP, or ZMODEM, or Kermit work. The fine print is in the "Now we send the file structure / word size etc".I wouldn't go that far. FTP does not really work that way, unless you have a very loose definition of TCP and FTP. And I don't know much about XMODEM, but yes, this is a pretty close description of how KERMIT works.Johnny
What I wanted to emphasize, actually was the innocent looking "FILE META DATA" because this turns out as a complex issue of translating one _language_ into another. Directory/Record size/Valid filename characters/Encoding/Word size/Endianness/number representation and much more. This is something that one or the other side has to handle, and it's likewise to become a great mess of the horrible TELNET protocol which needs to deal with numerous OPTION extensions in the various RFCs - and this, in principle, for both sides of the connections. No criticism of the implementors of the simh TELNET interface (because I myself tried to write a telnet server myself), but with respect to standards, this is unfortunately a sunny-weather-implementation. One should not underestimate the complexity of such an interface, particularly if there is no restriction on either side.
Holger
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
