Subject: PT3/telnet/rlogin/zmodem/the.kitchen.dot.sink
From: [email-masked] (Brendan Hoar)
Date: 15 Jul 92 09:45:10 GMT
Newsgroups: comp.sys.apple2

A set of comments on Scott Alfer's post that hasn't yet appeared at this site
so I cannot quote it directly:

A)  Telnet is no good for Zmodem.  Under MOST implementations, you should be
able to DOWNLOAD from the host to the terminal if all other things are set
correctly.  However, sending certain characters from the terminal (such as ^],
^S, ^Q and a few others) will cause the telnet session to royally screw
Zmodem.  Therefore, unless you have the really special and very prized
extremely configurable version of telnet on your terminal server, don't
upload.

B)  Rlogin can be ok with Zmodem.  Downloads work fine 99+% of the time. 
Uploads will work if you have an 8-bit transparent version of rlogin (that is,
no escape carriers, no flow control, etc).  On the unix box I use a great deal
of the time, rlogin is 'rlogin -8 sitename -l username' with one or more other
options to make it transparent.  Try 'man rlogin' and spend some time with
that.  The Annex (or Annex-II) termservers I've used had a good rlogin program
..  However many hosts do not support rlogin because it is less safe.

C)  Zmodem, or sz rather has some very interesting defaults.    Among them:
        1024-byte packets (at least the data part)
        A 4+ packet window.
What this means?
If the term server you use can not buffer 4K of data, or if the string of
telnets/rlogins can not buffer 4K of data, you will have to change the
defaults.

For example.  I call @ 2400bps to a Decserver that has a LAT to Telnet
gateway.  I telnet to the unix machine.  So, not only do I have a very
lousy/noise telnet connection, by the round trip delay of my full duplex
typing is about 2-8 seconds on average.  I make a lot of typos cause of that. 
Backspacing is a nightmare (remember, line noise?).

Anyway, I download with success...why?

sz -bw 512 file.names

the -w 512 option sets 128 bytes data packets with 4 packet windows. 
Therefore, on every error, there is always less than 512 bytes of lost data
before a re-sync.  Now, I'm not saying that this method will give me good CPS
results, but hey, I've got 2 GSs and an extra phone line... :)

Other people have experimented with other options (-l comes to mind) to set
the defaults to more be more error tolerant but less speedy.

The 128 byte packets sound like xmodem, but if I xmodem does not have the
windowing necessary on my full duplex delayed phone connection...the 512 byte
window pretty much maches the delay enuff that I'm hardly seeing the RxD light
go off, except when I get line hits.  With xmodem (128 byte packets, no
windows), the transfer would be a slug...take 2-4 times as long.

D)  I said telnet was no good for Zmodem, then in C) I changed my mind? 
Basically the idea is this - if you are having problems with transfering files
from a UNIX host to a terminal (IIGS/PT3) and you use telnet, there is a 99%
chance that the problem is with telnet.  You have to play with it and you have
to learn to configure it.  IF that fails, you have to learn ways around it. 
I've never sucessfully uploaded binary files via a telnet connection.  Sending
an ASCII file via Zmodem over telnet from terminal to host has been known to
work, but is far from guaranteed.

E)  Some terminal servers (Annex, etc) are not 8-bit clean to begin with. 
They may have an option to have an inband escape character as well as using
the BRK signal from the modem.  I usually type 'stty attn undef' before
telneting or rlogining anywhere just to be sure since sometimes other people's
settings stick around for the next caller.  Er...that may actually be 'set
attn undef'.  Use the Annex help facilities and have it tell you its settings.
DECServers are a pain too, especially since the heirarchical command system
has things that affect ports at different levels.  Try 'help set port' for
starters...I cannot remember off hand some of the commands I use there.  See
also 'help set connection' (maybe?).  Some of these commands only work when
you are already connected to a site so you may have to use the break signal to
get to the command prompt, change some settings and then enter 'resume' at the
'Local>' or whatever prompt.

F)  As mentioned before, overflowing of the buffers in devices between the
host and terminal will wreak havok on zmodem.  Try smaller window sizes
(-w 2048 or -w 1024) or play with the '-l' option.  For the most part, it is
impossible to change the buffer sizes on intermediate computers and terminal
servers.

This is all off of the top of my head, so forgive me.

BTW, anyone want to write a patch for PT3 that turns off AppleTalk Interrupt
servicing for the session so that I can use a high speed modem and AppleTalk
at the same time?  38400/V.32bis/V.42bis Zmodem does not mix with AppleTalk. 
I've got 2 GSs and an AppleTalk Imagewriter II on the net, no fileservers. 
What would be really cool is a patch that turned off AppleTalk, but reinstated
it while you were printing...then turned it off again.  Of course, this may be
more trouble that it is worth.  For now, I just boot up with Slot7 set to
'Your Card' to use PT3.

Oh yeah...a local place is selling Macinslosh Powerbook 100 4/40s (4 Megs of
memory, 40 meg HD) with an external HD floppy drive for $829 + tax.  Images
of having a portable computer for letter writing while traveling AND having a
SCSI equipped file server for my 2 IIGSs at home came to mind.

And it runs twice as fast as a Mac SE.

Zip wants almost 400 dollars to upgrade my 10/64zip to a 14/64zip.

I may be quite quite angry at apple corporate for their policy decisions when
it comes to the II line...but 829 for a portable...sale ends 7/21 or when they
run out of them...

And yes I asked and it was not a typo.
____________
Loc.|Address|___What are we?___ 5 billion pieces   If this was all mine...
[email-masked]|____so defined____  any test would be fine
[email-masked] (703) 998-5687| but flames just blur lines
[email-masked]| So all I want is to resign