tr@thumper.UUCP (04/13/87)
[] I often call my host by dialing Telenet and connecting through it. Apparently, there is a "transparent" protocol going on while I am typing and receiving text data. But when I try to use Xmodem, Kermit, or Vtrans (a proprietary protocol that comes with Vterm, a commercial terminal emulator for the IBM PC), the transfer fails in the first packet. It sounds like I am out of luck unless there are some Telenet tricks I should know about. Are there? (Reply by posting or email; I don't care which. Posting might be interesting to others.) -- Tom Reingold INTERNET: tr@bellcore.com UUCP: ..!decvax!ucbvax!ulysses!bellcore!tr ihnp4!mhuxt/
W8SDZ@SIMTEL20.ARPA.UUCP (04/15/87)
The old file below may of some help.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
--cut-here--
Date: Sunday, 17 June 1984 21:53-MDT
From: Doug Brutlag <brutlag at USC-ECL.ARPA>
To: Info-Kermit at MIT-MC
Re: KERMIT ON TELENET
Another way to get KERMIT to transfer files on TELENET is to
configure TELENET to transmit the eighth bit. Most TELENET nodes are
set up for 7 bit communications only. You can set up eight bit mode, by
connecting to your host, then escape back to TELENET (with cr @ cr) and
giving the command:
SET? 0:33,63:0
The 0:33 parameter allows you to set certain ITI parameters
normally not used by TELENET users. The ITI parameter 63 enables the
eighth bit when set to 0 (contrary to what is written in the TELENET
documentation by the way). I have found this setting useful for both
KERMIT file transfers and for using a terminal with a META key for
setting the eighth bit for EMACS editing commands. If this fails you
should call the TELENET 800 number to find out how to allow eight bit
communications for your node. SOme nodes use old TELENET protocols
which require setting parameter 57:1 as well. If you have many people
using KERMIT via TELENET you can have your TELENET representative change
your local node to make the default setting of parameter 63 be 0.
By the way I do not encourage people to use KERMIT via TELENET
because of the delay in receiving the ACK/NAK. Even with an unloaded
network and 1200 baud nodes at either end, the delay in receiving the
ACK/NAK effectively lowers the transmission speed from 1200 baud to less
than 300 baud.
Doug Brutlag
[Ed. Note - We will try to work out a "sliding window" option for the
Kermit protocol over the summer. This should speed things up a bit,
assuming it can be widely implemented.]caf@omen.UUCP (04/16/87)
In article <634@thumper.UUCP> tr@thumper.UUCP writes:
:[]
:
:I often call my host by dialing Telenet and connecting
:through it. Apparently, there is a "transparent"
:protocol going on while I am typing and receiving text
:data. But when I try to use Xmodem, Kermit, or Vtrans
:(a proprietary protocol that comes with Vterm, a
:commercial terminal emulator for the IBM PC), the transfer
:fails in the first packet.
Your Kermit problem may be caused by the two programs having different
parity settings. Check the parity settings on both programs to make sure
they agree. It is also possible, but unlikely, that one of the other
myriad Kermit parameters may need tuning. Normally, Kermit works over
Telenet, alebit quite slowly because of the short block length and high
overhead.
XMODEM will not work unless all 256 code combinations pass through the
network, and the parameters used for your session may be "eating" some of
them. The same problems may apply to the other protocol you tried, which
may be an XMODEM mutant.
Assuming that the interface between your host system (presumably Unix) and
Telenet is not stripping the 8th bit, you should be able to use the rz/sz
programs posted to net.sources a while ago for ZMODEM file transfers with
your PC. ZMODEM escapes the characters and sequences that Telenet uses
for flow control and supervision, and the streaming technique gives high
throughput with Telenet and other packet switched networks. The shareware
ZCOMM program available from many bulletin boards including TeleGodzilla
supports ZMODEM as well as an accurate VT100 emulation.
Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix
...!tektronix!reed!omen!caf Omen Technology Inc "The High Reliability Software"
17505-V Northwest Sauvie Island Road Portland OR 97231 Voice: 503-621-3406
TeleGodzilla BBS: 621-3746 2400/1200 CIS:70007,2304 Genie:CAF Source:TCE022
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourlynortond@well.UUCP (04/18/87)
In article <520@omen.UUCP>, caf@omen.UUCP writes: > In article <634@thumper.UUCP> tr@thumper.UUCP writes: > :[] > : > :I often call my host by dialing Telenet and connecting > :through it. Apparently, there is a "transparent" > :protocol going on while I am typing and receiving text > :data. But when I try to use Xmodem, Kermit, or Vtrans > :(a proprietary protocol that comes with Vterm, a > :commercial terminal emulator for the IBM PC), the transfer > :fails in the first packet. > I had a similar problem using ProComm not to long ago and solved it by selecting a RELAXED option, which accounts for the end-to-end delays imposed by telenet. Also, make sure that you are at 8-bits, no parity when calling your local telenet node, and send <CR>D<CR> before sending anything else (rather than <CR><CR>). The "D" must be in upper case. After receiving the terminal prompt and entering "d1", you migh wish to revert to 7 bits even parity, since the Telenet messages are (apparently) hardcoded to 7-bits even parity. -- Daniel A. Norton ...{lll-lcc,ptsfa,hplabs}!well!nortond
clive@druhi.UUCP (Clive Steward) (04/21/87)
in article <634@thumper.UUCP>, tr@thumper.UUCP says: > > [] > > I often call my host by dialing Telenet and connecting > through it. Apparently, there is a "transparent" > protocol going on while I am typing and receiving text > data. But when I try to use Xmodem, Kermit, or Vtrans > (a proprietary protocol that comes with Vterm, a > commercial terminal emulator for the IBM PC), the transfer > fails in the first packet. Well, you are out of luck, as you suspect. Packet networks introduce delays which are in excess of the timeouts on simple protocols. Increasing the timeouts would work, but at tremendous (5:1 or greater) cut in throughput. The only protocols which will work are of the windowing variety -- like the X.25 used internally by the nets themselves. (Windowing means keeping track of a list of packets which have been sent but not acknowledged yet, and marking them off/resending as necessary. There are many flavors with various sophistication about this). You might like to try Chuck Forsberg's YAM protocols -- he recently posted a set of sources for them in C. Either Ymodem or Zmodem (don't have doc handy...) is an upgrade to Xmodem which has windowing. You'll need to compile and run them on both your host and home machine; must have matching set. Clive Steward Resident Visitor (That's what AT&T calls contract workers and consultants, whatever field you happen to be working in.)
wheels@mks.UUCP (04/22/87)
In article <1864@druhi.UUCP>, clive@druhi.UUCP (Clive Steward) writes: > Well, you are out of luck, as you suspect. > > The only protocols which will work are of the windowing variety -- I don't think this is right. I have often used Compuserve's B protocol (non-windowing) while connected from home to Datapac through a gateway to Compuserve's network. The turn-around time didn't seem excessive. I have also used a non-windowing protocol over Datapac to other Canadian host systems with no problems. The only tricky part I found was to ensure that the local PAD had all its parameters set correctly. It must not swallow any control characters (for most protocols, although Kermit is not so bad), and it must forward the packet with minimal timeout. On Datapac PADs, they can be placed into a "transparent" configuration, which works fine. I have worked with Telenet PADs, and I think they can also be made transparent. -- Gerry Wheeler {seismo,decvax,ihnp4}!watmath!mks!wheels Mortice Kern Systems Inc.
hwfe@ur-tut.UUCP (Harlan Feinstein) (04/26/87)
In article <1864@druhi.UUCP> clive@druhi.UUCP (Clive Steward) writes: >in article <634@thumper.UUCP>, tr@thumper.UUCP says: >> >> [] >> >> I often call my host by dialing Telenet and connecting >> through it. Apparently, there is a "transparent" >> protocol going on while I am typing and receiving text >> data. But when I try to use Xmodem, Kermit, or Vtrans >> (a proprietary protocol that comes with Vterm, a >> commercial terminal emulator for the IBM PC), the transfer >> fails in the first packet. > >Well, you are out of luck, as you suspect. No, what he needs is simply windowed protocols, as you suggest. The best two packages/protocols you can use, in my experience, are PROCOMM's windowed Kermit, and Telix's SEAview. I tried SEAview for the first time about a week ago over Telenet's PC Pursuit package, and I was amazed. It took only an extra 5% of time over a normal, local transfer, as opposed to the XMODEM family (non-windowing) that takes 3 to 4 times normal time over Telenet's packet network. Both PROCOMM and Telix have the shareware-type money that you're supposed to pay them if you decide to use their package, but it's quite inexpensive compared to the commercial packages out there. If you cannot find either of these windowing protocols, YMODEM is the next best thing, because the data stream is interrupted for CRC or checksum stuff only once every 1K of data, as opposed to XMODEM's 128 bytes. Harlan Feinstein student, University of Rochester
dfr@onecom.UUCP (04/28/87)
I have a similar need for a "windowing" protocol.
We have a product which currently supports vanilla
XMODEM, but have been told that to get reasonable usage
of satellite links (due to transmission delays),
the protocol needs the ability to
transmit "n" packets without having received ACK/NAK's
between.
Can anyone send me information on such beasts?
I have heard that a "windowing" version of KERMIT exists.
Any info on protocol documentation, source code, or even
an email address where I might find some would be greatly
appreciated.
Thanks for any help.
--
----------
Dennis F. Reed TelWatch, Inc. (formerly OneCom, Inc.)
{ihnp4 ucbvax!nbires}!onecom!dfr 2905 Wilderness Place
303-440-4756 Boulder, CO 80301