Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Communications Toolbox questions
Message-ID: <9346@hoptoad.uucp>
Date: 19 Dec 89 08:43:57 GMT
References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp> <37028@apple.Apple.COM> <9223@hoptoad.uucp> <37200@apple.Apple.COM> <9325@hoptoad.uucp> <898@excelan.COM> <9344@hoptoad.uucp>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 24

In article <9344@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>As for when to start the transfer tool, that's not insoluble under the
>current architecture, as long as you force the user to give a "Receive
>File" command *before* the actual transfer starts; the command sequence
>is then the same as on a normal terminal connection -- first give the
>typed commands to start a transfer on the other end, then select
>"Receive File" on your side to specify where the file should be
>received, then the application responds to the "Receive File" menu
>command by starting up the transfer.

Sorry, I realized right after sending this message that this is
slightly off.  If you start up the RETR on the server before you start
listening on the user port, then the server will get an ICMP no
destination packet and abort the transfer.  What you have to do is take
the "Receive File" menu command first, open the user port for listening
in response to this menu command, *then* send the RETR to the server.
The latter part can be done by leaving the keyboard live on a
type-through interface, or by sending the RETR command from software in
a structured interface.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Philosophy is the talk on a cereal box
 Religion is the smile on a dog" -- Edie Brickell, "What I Am"