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/
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