[Simh] Way out idea for simh

[Johnny Billquist]

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