On 2016-04-21 12:21, Veit, Holger wrote:
Am 21.04.2016 um 11:31 schrieb Johnny Billquist:
On 2016-04-21 10:01, Veit, Holger wrote:
Am 20.04.2016 um 22:35 schrieb Sampsa Laine:
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
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.
Understood. But my point was that FTP do not have the acknowledgement of
data. You have acknowledgement of commands, but the data traffic is
actually a simplex connection with just data going one way, and nothing
going the other. TCP do the handshaking and signalling, but as far as
FTP is concerned, it just sends the file as fast as it can over the data
channel, and then close it. And that's it.
So it does less than the above schematic outline of a transfer.
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.
Agreed. The FILE META DATA is a complex thing, and FTP actually do not
solve this in a satisfactory manner. There were attempts at solving it,
if people read the RFCs, but the design do not accommodate for some
needs. So when I wrote the FTP implementation for RSX, I had to go for
some non-standard extensions, which only works between two RSX hosts.
(VMS FTP implementations also hit that problem, and there are a couple
of different odd solutions for dealing with it.)
TELNET is yet another story, but yes, it is more complex than people
might first think.
Johnny
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
