[Simh] Way out idea for simh

[Veit, Holger]

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:
>>>> On 20 Apr 2016, at 23:25, Phil Budne <phil at ultimate.com> 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 
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.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6181 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160421/8aedccbf/attachment-0001.bin>