[comp.protocols.appletalk] Max. number of volumes per server?

kenw@skyler.arc.ab.ca (Ken Wallewein) (06/06/91)

  Some one told me that, in AFP, there is a theoretical maximum number of
volumes which can be "published" by a given AppleShare server, and that
that number is actually quite low.

  Is this true?  If so, it would appear to have significant implications
for multi-user systems, such as Unix systems running CAP, which want to
make available one or more volumes for each of a large number of users.

  For that matter (this is a little off topic), has anyone thought of a
good way to separate -- in the Chooser -- their main AppleShare servers
from all those little servers that will pop up when everybody starts
running System 7?
--
/kenw

Ken Wallewein                                                     A L B E R T A
kenw@noah.arc.ab.ca                                             R E S E A R C H
(403)297-2660                                                     C O U N C I L

dave@cmi.com (David Halonen) (06/06/91)

>Some one told me that, in AFP, there is a theoretical maximum number of
>volumes which can be "published" by a given AppleShare server, and that
>that number is actually quite low.

If memory serves me, AppleShare 2.x supports up to 16 volumes.

David Halonen, Center for Machine Intelligence, EDS
Ann Arbor, MI (313) 995-0900
AppleLink: N0548  Internet: dave@cmi.com

jcav@quads.uchicago.edu (john cavallino) (06/07/91)

In article <KENW.91Jun5204106@skyler.arc.ab.ca> kenw@skyler.arc.ab.ca (Ken Wallewein) writes:
>
>  Some one told me that, in AFP, there is a theoretical maximum number of
>volumes which can be "published" by a given AppleShare server, and that
>that number is actually quite low.

I'm 99% sure that any limitation is implementation-dependent, as opposed to
defined in the AFP protocol specs.  I don't have _Inside Appletalk_ in front
of me, but I suspect AFP uses at least a 2-byte volume refnum, which would
mean a worst-case absolute max. of 32767 volumes per server.  Anyway, all
of this is copiously documented, and you should probably look it up before
jumping to conclusions.

-- 
John Cavallino                      |     EMail: jcav@midway.uchicago.edu
University of Chicago Hospitals     |    USMail: 5841 S. Maryland Ave, Box 145
Office of Facilities Management     |            Chicago, IL  60637
B0 f++ c+ g+ k s+(+) e+ h- pv (qv)  | Telephone: 312-702-6900