d88-eli@dront.nada.kth.se (Erik Liljencrantz) (07/09/90)
Why does these protocols (and probably several others) wait several seconds before the first packer is transfered? I'm transfering files from a PC to a UN*X host running rb (receive ymodem). Can I tell rb something special to not wait? Or is it the sending side that is waiting (unnessecarily)? Please remind me (by email) to read this newsgroup if You post a reply. Erik Liljencrantz | "No silly quotes!!" d88-eli@nada.kth.se | Embraquel D. Tuta
caf@omen.UUCP (WA7KGX) (07/09/90)
In article <1990Jul8.193633.9450@kth.se> d88-eli@dront.nada.kth.se (Erik Liljencrantz) writes:
:Why does these protocols (and probably several others) wait several seconds
:before the first packer is transfered? I'm transfering files from a PC to a
:UN*X host running rb (receive ymodem). Can I tell rb something special to
:not wait? Or is it the sending side that is waiting (unnessecarily)?
If you use rz on Unix and DSZ, ZCOMM or Pro-YAM on the calling machine
you should have no delay beyond that required to load and run rz.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAFtnixon@hsfmsh.UUCP (Toby Nixon) (07/09/90)
- Why does these protocols (and probably several others) wait several
- seconds before the first packer is transfered? I'm transfering files
- from a PC to a UN*X host running rb (receive ymodem). Can I tell rb
- something special to not wait? Or is it the sending side that is
- waiting (unnessecarily)?
In both XMODEM and YMODEM, the sender waits for the receiver to send
a NAK (or some other specific character, like "C" for XMODEM-CRC, or
even "CK" for XMODEM-1K), before the first data or header frame is
sent. The problem is that you normally start the receiver first, so
it sends out this initial character immediately, before the
transmitter has been started. You therefore have to wait for it to
be REtransmitted, usually after a 10-second delay.
There's really no way to avoid this with the way XMODEM and YMODEM
are designed, although you can reduce the pause by cutting the retry
delay down from 10 seconds to something less, and increasing the
number of retries. This can cause other problems, however,
particularly on packet networks where several characters may be
queued. One could also design the sender to "assume" that the first
character has been already sent, but this would defeat the automatic
protocol recognition (the NAK, C, or CK helps the sender know what
protocols the receiver supports).
The worst possible scenario is when the sender only supports plain
old XMODEM, but the receiver supports different flavors. In this
case, the receiver normally sends "C" or "CK" at least three times,
before giving up and sending a NAK. The sender may have to wait up
to 30 seconds or more before it sees the NAK and sends the first
frame. It's not good, but unfortunately that's the way it is.
With ZMODEM, the receiver also transmits first, but the sender also
has the ability to send a frame to the receiver to "wake it up".
Therefore, you normally don't see a pause before the start of a
ZMODEM transfer.
-- Toby
-----------------------------------------------------------------------------
Toby Nixon, Principal Engineer Fax: +1-404-441-1213 Telex: 6502670805
Hayes Microcomputer Products Inc. Voice: +1-404-449-8791 CIS: 70271,404
Norcross, Georgia, USA BBS: +1-404-446-6336 MCI: TNIXON
Telemail: T.NIXON/HAYES AT&T: !tnixon
UUCP: ...!uunet!hayes!tnixon Internet: hayes!tnixon@uunet.uu.net
MHS: C=US / AD=ATTMAIL / PN=TOBY_L_NIXON / DD=TNIXON
-----------------------------------------------------------------------------