Path: utzoo!mnetor!uunet!van-bc!sl From: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Newsgroups: comp.dcom.modems Subject: Re: Trailblazer Speed Stats Message-ID: <1704@van-bc.UUCP> Date: 11 Apr 88 01:17:05 GMT References: <3570@cbmvax.UUCP> <297@zinn.MV.COM> Reply-To: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Organization: Public Access Network, Vancouver, BC. Lines: 44 In article <297@zinn.MV.COM> mem@zinn.MV.COM (Mark E. Mallett) writes: >In article <3570@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes: >> ... uucp thinks the >> transfer is "done" while the trailblazer still has (allegedly) up to >> 10K of data buffered internally. > >Is this true? Can the host see the transfer as complete when there is >still up to 10KB buffered in the modem? 10K could represent a lot of >mail or news or control files that would have been deleted: what happens >if the phone connection breaks at this point? What is done to ensure >that no outgoing files are deleted until the receiver actually records >them, given the above statement? > It's true, but with qualifications. Uucico on the sending host essentially has a conversation with the uucico in the receiving host. A series of messages are exchanged, something along the following lines: Sender Receiver S filename - sending file SY - OK CY or CN5 The sender sends a message with the name of the file it want's to send. The receiver responds SY if it's willing to receive it. (Or SN2 - not permitted, SN4 - can't make workfile.) If SY, the sender sends the file. When it is finished it stops timing the transfer. It now waits for the CY message. If CN5 is received the sender knows that the file was not transmitted properly. The timings seem to represent the time to transfer or receive the file, not including waiting for the response message. On direct machine to machine transfers this will be almost the same on both sides. With a 10k buffer in the middle it can be out quite a bit! -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532