As p a rt of the design process. we obs<:rved the per for m a nce of the hie server d uring in teractions with the c l ient. We n eedeu to com par<.: various contlict i ng a l ternatives ancl their effects on the overaU per formance of the server. Som<.: of the a lternat ives we stud ied were the adva ntages of using the l J LT R I X sys tem cache versus i m p leme n t i ng ou r own cache. We also stud ied the issue of persisten t lock requests on the network anu the server. These alternat ives arc
u iscusseu in this sect ion.
File
1/0Since the III T R I X opera t i ng syste m p rovides a kernel-based, u isk cache mechanism , we designeu the opera t i ng system's cache ma nager to p er form a l l cachi ng globally. The cache m an ager updates the cache b u ffers, performs read a head on data strea ms. and f·l ushes the cache bu ffers from uata
wri tten to uisk.
The tile server performs d isk wri tes as wri te behinds. \XIhen a request to write data is received
PATHWORKS: PC Integration Software
from a cl ient, the server responds by acknowledg ing success before the write is a ttempted (assuming the cl ient has proper write access to the file). This optimization a llows parallelism to occur between the client and the server because the c l ient is gener ating more data at the same time the server is writ ing the data to disk. I f the write fails, however, the server notes that the last write failed and returns the error on any subsequent access to the file. Heuristics
We found that certain applications would continu a l ly flood the server with lock requests even though the lock requests kept failing. These persis tent lock requests from applications used valuable
CPU time on the server system as wel l as network
bandwidth. For this reason, the ULTruX server needs
to determine if a client is being persistent a nd continually requesting locks which are failing. When the server detects continuous lock requests, it delays the lock request for a random period of time and then checks if the lock has become avail able. The server then either grants access if the lock is available, or returns the error at that time. This procedure reduces lock request traffic, since most locks are of short duration.
Security
Connection requests between client and server require a security check. Since PATHWORKS for ULTRIX was designed to be layered on the ULTRIX
operating system, we were able to take advantage of i ts security features. \X'hen a c l ient attempts to connect to the server, a username and p assword can be passed as part of the connect message. If these are supplied, the user is validated through system calls to obtain the password file entry for that user. If the user is not fou nd in the /etc/passwd file or if the password is invalid, the user is denied connection. If the ULTruX system is running in
enhanced security mode, further checks are made to ensure the account has not been disabled or the password expired. In either of these cases, the con nection would be denied. If a username is not sup plied, a default guest account may be used to establish privileges.
VAX
versus RISC Considerations
During the development of the PATHWORKS for ULTR!X file server, we did not anticipate that our code would have to differentiate between VAX and
38
ruse architectures. We expected that code written for an ULTruX system in a ruse environment would be recompiled on a VAX system. For the most p art, our assumptions were correct, except in the areas of memory allocation.
On the VA.,'( system, shared memory maps directly after the data segment in memory. This implementation prohibits the allocation of mem ory above a shared memory segment. In the ruse
implementation, shared memory is allocated at the very top of the memory image; therefore a great <leal more memory can be a l l ocated before the bot tom of the shared memory segment is reached. The d ifference in shared memory al location between the RISC and VAX systems is shown in Figure 3.
To increase the data segment size in the VAX sys tem, we replaced all malloc( )calls in the server modules with the fol lowing pseudocode:
D i s c o n n e c t f r o m s h a r e d m e m o r y m a l l o c ( ) R e c o n n e c t t o s h a r e d m e m o r y
Since this code is required only i n a VAX environ ment, i t is compiled when the server is built.
PATHWORKS Server Configuration
The PATHWORKS for LTruX file server al lows thesystem manager to configure the server environ ment to make the most efficient use of shared mem ory. The fol lowing parameters included in the lanman. ini file are the determining factors that enable shared memory to be scaled.
• maxsessions: The maximum number of PC work stations that can be simultaneously connected to the PATHWORKS for U LTruX server.
• maxconnections: The maximum number of con nections PC workstations can m ake to the ser vices offered. S HA R E D MEMORY TOP OF MEMORY S H A R E D MEMORY TOP OF CODE DATA, COD E,
STACK AND DATA
DATA, CODE, STACK
(a) VAX System (b) RISC System
FiguTe 3 Image Memory Layout
• m axopu1s: The maximum nu mber of tiles the
servc:r c1 n have open simult ane ou s!\·.
• u n iqucopenti lcs: The m a x i m u m n u m ber of unique open tiks the Sl:rver can have open si nn1 lta neousiY.
• m axservcr locks: The m a x i m u m n u m ber of byte ra nge locks the server can lo ck s i m u ltaneou sly. To help the user apply thesl: parameters to a par
ticu l a r system, till: "pesa memory" co m m a n d acts as a shared memory s izing calcu l a to r. It a l lows the user to i n p u t the parame ters and then e i th er i nll ica t<:s that the new p a ra meters w i l l tit i n the current system. or that the system shared me mory parameters need to be changed to support thl: new
configu ra t ion
Information logging
PA l l i\VORKS for l i i .TRIX i n format i o n loggi ng was llesignell fo r th e UITlUX syst<:m m a nager as we l l as wri tn/u sers of the ! .AN Ma nager appl ication. It pro
vides eve n t :1nd error logging i nfor mation i n two d istinct formats. The tirst format u ses the U lTRIX system log fi le: syslog. This l og tile is t yp ically mon i tored by \ ilTRIX system ma nage rs. Al l p rocesses which comprise PATHWOl{KS for \ I ITRIX submit con figura tion i n formation and error cond itions to this
tile. The till' server process a lso l ogs i n formation regard ing service usage. sessions, and co n nect i ons. The second form of event l oggi ng is performed e n t i rely by the server p rocess. The server pro cess l ogs error ami au d i t events to LAN M a nager co m pati ble l og ti les: er ror log and audit log. These l og tiles arc access ible through the m a n agem ent in terface as wd l as through the LAN M anager API
interface provid<.:d with DOS and OS/2 J.AN M anager im plementa t i ons. These Jil es contain i n for m a t ion o n session logo n/l ogoff, password errors, connec tions starrnl/rejcctnl . resource access granted/ denied, and server status cha ng<:s.
Swnmary
Th<.: J',\T I J \VOH KS for l l f :f'I{IX ti le server, together w i t h th<.: I'ATi l\VO R K S for DOS and PXIHWOHKS for OS/2 prollucts, pro,·itil:S a distr i bu ted com p u ting environmen t . The tile server is based on a cl ien t se rver model that offers transparent access to l l LI'lUX system resourc<:s from PC clil:n ts. It pro vides rile necessary tool s to i n tegrate these two d iverse com puting environments in a manner t h a t is both l'fticicnt ami easy to ma nage.
Di�ila/ TeciJuical jon rna/ 1 (,/ . . ; Xu. I \\" inter I'J'Jl
Design of" the PA T!-I WORKSjor l!UN.IX Nle Serl 'er
Ackrwwledgments
Many people were i nvolved i n the design ami bu ild ing of the PATHWOHKS for L: I TR IX tile server from i ts inception to its shipment. We wish to thank a l l t hose people: Pa u l Messier a n d J i m f<lahe rry. who gu i ded our efforts; Dan S m i t h , who designed ancl i m p lemented the NetBIOS l ayer: Ken Card i na le, who wrote the product documen tation: Marlene S teger, who ensu red that the p roduct shipped on time: and the manv i n d i v id uals who successfu l ly brought this prod uct to market.
References
I . Protocol Slandord f(n· Net!JJOS Sen •ice on o 10'1 UDP Transpo rt: Concepts and Jletbods, I n ternet Engineering l�ts k Force ( I LTr) n rc 1001 (March
1 987)
2. Protocol Standard j(n· Netl)f()S Serl 'ice 011 a JCP/ UDP 7iw tsport: Detailed SjJecijication, Internet Engineering Tas k Force (IETF) RFC 1002 (M arch
1987).
�. l!I.TNIX-32 Gu ide to Curses Screeii-Hcmdlin�, l i t:l'IUX Document Set, Software Deve l opment, vol. 2 (Maynard: Digital Equi p ment Corpora t i o n , Order No. i\,\-i'v! J-07 A-TE. 1<)88).
Mitchell P. Lichtenberg Jeffrey R. Curless