Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!labtam!eyrie!phoenix!proff
From: proff@phoenix.pub.uu.oz.au (Frederick Solidus)
Newsgroups: comp.sys.amiga.tech
Subject: Re: PIPEing from ser:
Message-ID: <1990Nov28.082341.1068@phoenix.pub.uu.oz.au>
Date: 28 Nov 90 08:23:41 GMT
References: <1990Nov16.104712.20944@phoenix.pub.uu.oz.au> <11640032@hpfcdc.HP.COM>
Organization: Phoenix ComSystem. Public UNIX Melbourne Australia.
Lines: 37

In <11640032@hpfcdc.HP.COM> koren@hpfcdc.HP.COM (Steve Koren) writes:



>> The whole point of the discussion is quite simple: a call to Write()
>> will take as long as it pleases to take.  If you happen to be a terminal
>> program, and it takes 10 hours for the user to wake up the next morning
>> and stick the right disk in, chances are the other end of session has
>> timed out on you.

>Well, yeah, it goes without saying that you've gotta stick the disk
>in the drive :-) - but even if the floppy takes several minutes to
>write the data, that'll work just fine.  I use cts/rts all the time
>and it works like a charm.  It will, as I mentioned before, allow
>receiving data to a floppy from a high speed serial line.  I've done
>this at 14400+ bps with no problems.  Granted, the other system will
>have to pause sometimes to wait for the floppy, but no data is lost.
>If your remote system give up *that* fast, I'd think something would
>be wrong with it.  Similarly, as long as the consumer end of the pipe
>got around to consuming a block every few minutes, things should
>work just fine.

>   - steve

Thats not the case with me. Downloading to pipe: from jrcomm, and then taking
that pipe out put and feeding it to lharc does not work, after 10k, the files
become currupted. I assume this is because Jrcomm keeps a buffer of its own
and that buffer is larger than the transfer buffer of pipe:

Is that correct? Or, perhaps jrcomm does not handshake correctly with the
transfer buffer, and jrcomm is held before it has time to inform the sender
of its condition. However, zmodem should find this fault, and resend the lost
packets - which it does not, so I must assume that the fault lays somewhere
in the jrcomm to pipe: communication.


Proff/The Force