[comp.sys.mac.programmer] AFP calls

jverdega@cae.wisc.edu (Jeffrey Verdegan) (06/04/91)

Does anyone know what a good value is to use for the aspTimeout field of
AFPCommand's paramter block?  IM V-542 says it's the "Retry interval in 
seconds."  Is this the time between retries, or the duration over it will keep
trying before it gives up?  Also, for standard calls, like FPEnumerate, 
FPOpenDir, FPOpenVol, etc, do both the csCode field of the paramBlock and the
first byte of the command buffer contain the code for the command, e.g. 0x19
for OpenDir.  I'm getting -5018 and -5019 errors when I call FPEnumerate, and
I'm having a hard time figuring out why.  I don't know if the above questions
are related to it or not.  I'll see when I get a few responses, and if that
doesn't prove to be the problem, well I guess you'll be hearing from me again.

Please reply to jverdega@cae.wisc.edu.
Thanks in advance!  :-) 

kurash@kinsman (Mark Valence) (06/04/91)

In article <1991Jun3.164915.15760@doug.cae.wisc.edu> jverdega@cae.wisc.edu (Jeffrey Verdegan) writes:
>Does anyone know what a good value is to use for the aspTimeout field of
>AFPCommand's paramter block?  IM V-542 says it's the "Retry interval in 
>seconds."

A "good" value is 1 second.  A "great" value is determined dynamically,
based on the history of the ASP/AFP session.  For instance, before you
start a session between a client and server, you could either use info
gleaned from your NBP lookup, or from a few echo packets, to determine
the round-trip time from client to server (and back).  Then, you would
use this value in your Logon's retry interval (time out value for ATP).
You could then look at the amount of time it actually took for the
Logon to succeed (there are some details here, like how many packets
your Logon UAM requires), and use this for the next packet's interval.
Each time you send a packet, figure out the round-trip time, and then
use this (maybe weighted with the previous interval) to determine your
next request's interval.

A few caveats:  DON'T include the round trip time for reads and writes
in your calculations, unless you also factor in the number of packets that
will be sent.  For large buffers, this value can be illusive (although
deterministic).  You will need to read the ASP chapter in Inside AppleTalk
if you want to use these times.  Also, if you are not using the .XPP
driver, you will be implementing reads and writes yourself, so you will
have access to the exact packet count (and probably don't need to be
reading this message).

Also, you might want to include some slop for those disk-intensive calls
(i.e. calls that need to search directories, or load icons & other info).
Your dynamic-interval calculations can become quite complex (although it
is easy to overdo it).

>  Is this the time between retries, or the duration over it will keep
>trying before it gives up?

The former.

>  Also, for standard calls, like FPEnumerate, 
>FPOpenDir, FPOpenVol, etc, do both the csCode field of the paramBlock and the
>first byte of the command buffer contain the code for the command, e.g. 0x19
>for OpenDir.

Page 542 in IM V says that the csCode field is "Always AFPCall".  Well, if
you are using a high level language like Pascal or C, and you are using
the AFPCommand glue, this value is stuffed into csCode for you.  If you
are using assembly, or are using PBControl calls from a high level language,
you will have to place AFPCall ($FA = 250) into the csCode field yourself.

The first byte MUST contain the command code, as you are probably doing.

>  I'm getting -5018 and -5019 errors when I call FPEnumerate, and
>I'm having a hard time figuring out why.  I don't know if the above questions
>are related to it or not.  I'll see when I get a few responses, and if that
>doesn't prove to be the problem, well I guess you'll be hearing from me again.

That's afpObjectNotFound and afpParmErr.  If you are getting the former, it
may be because you have misformed the command buffer.  If you are getting the
latter, you are definitely misforming the CB.  You might take a look at what
you are sending with Peek, or, if you do not have a spare machine or do not
have Peek, you could use Macsbug.  Make sure you place the correct length
in you paramblock (CBSize field).

>
>Please reply to jverdega@cae.wisc.edu.
>Thanks in advance!  :-) 

Sorry, jverdega, but mail's jist not gittin through from here.

Mark.