NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/amiga/datacomm/7692

Text File | 1992-11-16 | 1.9 KB | 39 lines

Newsgroups: comp.sys.amiga.datacomm
Path: sparky!uunet!think.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!pooler
From: [e-mail] (Robert Peter Poole)
Subject: Re: XPR-Bidirectional
Message-ID: <27v1fw=@rpi.edu>
Nntp-Posting-Host: vccsouth18.its.rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 16 Nov 1992 16:01:55 GMT
Lines: 27

In article <[e-mail]> [e-mail] (ANTHONY FRANCIS PRESTON) writes:
>Why is BiModem so complex?  You send a packet while recieving a packet,
>If you have to Ack/Nack, you just have an Ack/Nack packet.  Communications
>just becomes send the next packet.  It would seem that the Zmodem form
>could be used in both directions.  It should be fairly easy to do on the
>Amiga, just use asyncronous I/O and wait on both requests.

Well, Bimodem has to address the issues of (a) a user requesting more files
for download during a download, (b) a user adding more files to the upload
queue, (c) securities (i.e., if a user requests files on the other end which
are not supposed to be available to that user; or if the BBS requests files
from the user that the user doesn't want made available), (d) resuming aborted
downloads or updating files (useful for business applications where you only
need to transmit the additions to a database or text file, for example), and
several others.

Also, an engineering friend of mine mentioned that there is a critical
bandwidth limit on a phone line that prohibits actually doubling your
throughput with a bidirectional protocol when you are using high baud rates.
(And yes, I mean baud, not bps, in this case.  :-)  So if you get 19200 bps
unidirectional, don't expect to be able to transfer twice that amount
(19200 bps send and 19200 receive) with a bidirectional protocol.

So maybe things are a little tougher than we imagine...

Rob Poole
[e-mail]