Rochester Institute of Technology
RIT Scholar Works
Theses Thesis/Dissertation Collections
8-1-1986
A Study of the Xerox XNS Filing Protocol as
Implemented on Several Heterogenous Systems
Edward Flint
Follow this and additional works at: http://scholarworks.rit.edu/theses
This Thesis is brought to you for free and open access by the Thesis/Dissertation Collections at RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact ritscholarworks@rit.edu.
Recommended Citation
Flint, Edward, "A Study of the Xerox XNS Filing Protocol as Implemented on Several Heterogenous Systems" (1986). Thesis.
Rochester Institute of Technology. Accessed from
Rochester [nstitute of Technology School of Computer Science and Technology
A Study of the Xerox XNS Filing Protocol as Implemented on Several Heterogenous Systems
August. 1986 Ed Flint
A thesis. submitted to the Faculty of the School of Computer Science and Technology. in partial fullfillment of the requirements for the degree of Master of Science in Computer Science.
Approved by
Leslie Jill Miller 8/7/86
John L. Ellis 8/26/86
James E. Heliotis 8/23/86
Title of Thesis:
A Study of the Xerox XNS Filing Protocol as Implemented on Several Heterogeneous Systems
( Edward Flint hereby grant permission to the WaUace Memorial Library , of RlT, to reproduce my thesis in whole or in part. Any reproduction wiU not be for commercial use or profit.
Date: September 25, 1986
Table
ofContents
Table
ofContents
2Abstract ...
5
Key
Words andPhrases 5
Computing
ReviewSubject
Codes5
1. Introduction ...
6
2. XNS
Architecture
.82.1. ISO Model 8
2.2.
Servers, Services
andClients
102.3- XNS Protocolsand
Standards
122 3.1. Physical/Data Link
Protocols
122
3
2 Internet TransportProtocols
12233
Courier(Remote
Procedure CallProtocol) 13
234 Application Protocols 14
3.
Filing
ProtocolOverview . . . I"3.1.
Clients
andServers
.1~
32 Procedures . . 18
33- Sessions
34. Users andAuthentication
19
20 20 21 217 1
3
5. Files: content and attributes36. Handles
3.""
Controls 38. Scopes
39. Errors 22
Implementation Descriptions . . 24
4.1.
Attribute Acceptance- Services . 254.1.1.
Xerox 8037 File Service 254
1.2 VAX/VMS File Service 254.1.3.
UNLXFileService 2"4
2 Attribute Usage- Clients 2842
1 XDEFileTool . . .2842
2 VAX/VMS Client . . 294.2
3. UNLXClient . . .2943.
Procedure Support - Services ...30
4.3.1. Xerox
803"
File Service
30
4
32 VAX/VMS FileService
304.3.3- UNLX File Service 32
4.4. Procedure
Support-Clients 33
4.4.1.
XDEFileTool33
4.4.2
VAX /VMS Client . . 354.4.3.
UNLX Client. ...35
Implementation
Incompatibilities
. . 3"5.1. Areasof
Incompatibility
3~
51.1. Non-support of
Filing
constructsby
the nativeoperating
system 38 5.1.2. Alternatespecifications in theFiling
Protocol . 385.2
Resolving
incompatibilities39
52 1. Non-support of
Filing
constructsby
the nativeoperating
system39
5.2.2 Alternate specificationsintheFiling
Protocol 42FilingSubset 45
6.1.
Overview 456.1.1.
Motivation . 456.12
Requirementsand Goals 466.2
Definition 4"6.3.
Attributes ... 486.3.1. Mandatory
Attributes 486.3.1.1.
createdOn 4863
12 dataSize .48
6.3.1.3. isDirectory
486.3
1 4 modifiedOn . 496.3.I
5 pathname . 496.3-1.6.
type 506.32.
Implied Attributes 506.3-3.
Optional Attributes 506.4.
Remote Procedure Support . 506.4.1.
Session Support . 5164
2Opening
andClosing
Files . . 516.4.3 Enumerating
Files in Directories 526.4.3-1.
Scopes . 526.4.3-2
AttributeSupport 526.4.4. Storing
Files . 526.4 6. Deleting
Files .546.5.
RemoteProcedure
Restrictions . .546.6. Remote
Errors .566.7. Procedures
andAttributes 566.8.
Courier Definition60
References 6"
Appendices
A FilingSubset Implementor's Guide
69
B.
Filing
Protocol. . "0Abstract
The Xerox Network System is composed of
heterogeneous
processors connected across a variety oftransmissionmedia A series ofprotocolsis
defined
to describe the communication mechanismsbetweensystem elements.
One
of these protocols, theFiling Protocol,
defines a general purposefile
managementsystem. Current implementations of the protocol, although derived
from
the Xerox specification, fallshort of
providing
the interconnect! vity between elements desired in aheterogeneous
network systemThe
definitionof aneasily
implemented protocol subset that provides the commonfile
systemfunctions
of retrieval, storage, enumeration/location and deletion is derived from experiences with several
implementations This definition and an
accompanying
implementation document provide a mechanismto guide
future
implementationstoward increasedinterconnectivity
Keywords and Phrases
Network
Protocols,
DistributedFile SystemsComputing
ReviewSubject CodesC.2 2
[Computer-Communication
Networks]: Network Protocols Protocol architecture, C24[Computer-Communication
Networks]: Distributed Systems Distributed applications, D43
[Operating
Systems]. File Systems Management - Distributedfilesystems,1. Introduction
The Xerox Network
Systems (XNS)
architecturedefines
a series of protocols for use between systems ina
distributed computing
environment These protocols provide a mechanism forcommunicating
betweenavarietyofmachines across avariety oftransmission media, andencompass the full rangeofthe ISO/OSI
reference model
from
the physical through application layers. Application protocols are defined forfiling,
printing,network objectlookup
and userauthenticationThe Xerox Network Systems provide a general purpose
file
management system which is heirarchical innature andsupports a wide variety of
functions, including file
transfer, access control,file
location andenumeration, random access, serialization anddeserialization of
directory
heirarchies. TheFiling
Protocolrepresents a
formal
definitonofthisfile
systemas well as a guidefor accessing thesystem.As the network model
has
been refined, implementations of this model became more prevalent Itbecame
clear that there are manyoperating
systems and application processes which1)
have a specificneed
for
certainportions, orjusta subset, oftheFiling
functions and/or2)
do nothave
the requirementsor resources to support the
Filing
Protocol in its entirety. For example, a subset intended for simplefile
transfer and enumeration has a range of uses within the areas of distributed printing electronic
publishing
andinterconnectivity
ofheterogeneous
systems.Currently
several commercial implementations of theFiling
Protocol exist for different systemconfigurations. Although each ofthese implementations is based upon theXNS specification for
Filing,
inreality, each of these implementations
falls
short of the full implementation The result is a lack ofinterconnectivity
because there is no formal definition of a standardFiling
subset toguide coordination of the implementation schemesThis thesis is divided into several sections
documenting
the evolution of a subset of theFiling
Protocolfor use as a simple
file
transfer protocol The thesis was motivatedby
my inital experiences involvedwith providing compatible
file
transferfunctionality
between three existingFiling implementations
M\work resulted in the
formal definition
and incorporation of the FilingSubset Protocol into the XeroxFiling
Protocolandthedevelopment
oftheaccompanying implementor's
guide.Section 2
is
an overviewof theXNS architecture and therelationship
between the XNS protocolfamily
and the ISO/OSI
Reference
Model Section3 describes
the concepts and terms definedby
theFiling
Protocol as a
foundation
forunderstanding
the more detaileddiscussions
in later sections Section 4describes
severalexisting Filing
implementations and points out the incompatibilitiesevidenced betweenthem. This
description highlights
thedifficulty
inproviding interoperability
between variousimplementations. Section 5 presents a specific solution to the problems
from
these implementations ofthe
Filing
Protocol. The choices made in this section are then formalized into a subset of theFiling
Protocol that provides the intended
file
transferfunctionality
This formal specification of theFilingSubset Protocol is presented in Section
6.
Appendix A includes the FilingSubset Implementor'sGuide,
adetailed
implementation strategyfor
the FilingSubset Protocol. This strategy describes the implementation ofthe protocol from general perspective and describes specific support required on theUNIX and VMS
operating
systems. A copy of verion6
of the XeroxFiling
Protocol is included inAppendix B for reference This version contains the Xerox definition ofthe FilingSubset
Protocol,
whichisan edited version ofthe specification presented in Section
6
ofthis thesis2.
XNSArchitecture
The
XNS architecturedefines
afamily
of protocols and standards to provide for the exchange andhandling
ofinformation within a distributed network environment. This architecture is an outgrowth of the 3MB Ethernet used within Xeroxfrom
the early ^"O's into the 1980s. This experimental networkwas
developed
at Xerox's Palo Alto Research Center(PARC)
andhas
been the subject of numerouspublishedpapers.
The XNS protocols represent a refinement ofthe early research protocols As the architecture graduated
to the 10MB Ethernet and other transmission media, research continued into numerous application areas
and products weredevelopedto provide greater
diversity
andricherfunctionality
This
section presents an overview ofthe XNS architecture and its relationship to the ISO/OSI referencemodel The intent is to providethe reader with somebackground on the structured approach of the XNS
architecture and the
interrelationship
between the various protocols that it defines This interrelationship
is important in understanding the definitionand use oftheFiling
Protocol later in this thesis2.1. ISOModel
In 1981 the International Organization for Standardization
(ISO)
defined a reference model[11]
for OpenSystems Interconnection
(OSI) consisting
of"
layers
of protocols as shown in Figure 2 1 Each of theselayers offers distinct
functions
that depend upon the lower layers and in turn are relied uponby
thehigher layers. The layers included in thismodelare-
Layer 1: Physical This layer performs the actual transmission of data over the physical
communication medium
Layer 2 Data Link This layer provides reliable transmission
by organizing
the data intoframes
andproviding
error detectionandoptionally correctionUserProcess UserProcess
Application
Presentation
Session
Transport
Network
Data Link
Physical
Application Protocols
Presentation Protocols
Session Protocols
Transport Protocols
Network Protocols
Data Link Protocols
Physical Protocols
*- Application
i 1i
* Presentation
t
-
Session
a
Transport
t
? Network
t
^ Data Link a
* Physical
End SystemA
Layer 3: Network
Layer
4
TransportLayer 5: Session
Transmission Medium ncj System B
Figure 2 1 ISO/OSI Reference Model Protocols
The
responsibility of this layer is to organize higher level data intopackets which are transmitted to the recipient To perform this, the
network
layer
must provide for packetaddressing androuting
This
layer provides reliable end-to-end transmission independent ofany
intermediate
nodesThe session layer provides for the establishment, management,
svnehronization and terminationof a user level connection
from
sourceto destination This connection exists independent of the
underlying
transportconnections
Layer
6: Presentation This
layer translates userdata
objects into the form transmittedbetween systems Common translations may include data compression,
encryption and charactercode conversions.
Layer 7: Application This layer performs applications specific to the environment in which
thenetwork isused
The XNSarchitecture is organized into a series ofprotocol layers which closely resemble the ISO model
However,
inseveralinstances,
a single XNS layercorresponds to multipleISOlayers
The XNS layers and their associationtothe ISOmodel is depicted in Figure 2 22.2. Servers, Services
andClients
Two
terms usedquitefrequently
whendescribing
the XNSarchitecture are thoseofclientsandservers.Any device
attached to the networkfor
the purposes ofpro\ding
a service to network users is referred to as a server The collection of software which accomplishes a specific taskby following
a definedprotocol for interaction is commonly referred toasaservice
Several typesof servers are evident in the XNS environment A dedicated server performs a specifictask
and
nothing
else. A print server is an example of such a dedicated server A server may alsobe a generalpurpose computer capable of
providing
several services simultaneously, such asnaming
authenticationand mail services In addition, a user workstation
may
function as a network server on occasion, forexample,a
temporary file
service.The entity which makes requests of a service iscalled a client Clients typically perform work on behalf
of a user;
however,
services may in fact be clients of other services under certain conditions, such aswhen a
file
service contacts anauthentication service to validate user credentialsInterpress Mail Format
Raster Encoding Standard
Information Format
andEncoding Standards
Layer
7
Application
Printing
Protocol
Filing
Protocol
Mail Transport
Protocol
Gateway
Access Protocol
Basic Application Services
Clearing
house Protocol
Authenti cation
Protocol
Time Protocol
Font Standards
Character Code Standard
Application Support Environment
Layer
6
PresentationLayer
5
SessionCourier Message Stream Object Stream Block Stream
BulkData Transfer Protocol
Courier
Layer
4
TransportLayer
3
NetworkEcho Protocol
Sequenced Packet Protocol
Packet Exchange
Protocol
Error Protocol
Routing
Information Protocol
Internet Datagram Protocol
Internet Transport
ProtocolsLayer 2 Data Link
Layer 1 Physical
Ethernet Data Link Layer
Ethernet Physical Layer
Ethernet
X2s Virtual Circuit
S\nchrunous Point-to-Point
Protocol
RS-232, RS 449, X.21,
etc.Figure 2 2 XNS Protocols
2.3.
XNSProtocols
andStandards
2.3.1. Physical/Data
Link ProtocolsThe
primary transmission medium usedby
XNS is the Ethernet[7]. The
Ethernet specification describesboth the physical and
data
linklayers
asdefined by
the ISO model. XNS also supports other standardphysical interfaces
(RS-232, RS-449
and X21)
anddata
link protocols (X25
and synchronous point-to-point protocol).
2.3.2 Internet Transport
ProtocolsTypically,
a network consists ofmany sub-networkconfigurations which are connected in some mannerEach of these sub-networks may use a different physical transmission medium
However,
an internetprotocol provides the
functions
which allow these sub-networks to be addressed as a single uniformnetwork
The
XNS network,like
other packetswitching
networks, routes each packet, ordatagram,
individually
Thisconceptdiffersfrom
thatofa virtual circuit inthat noprior setup is necessary between the respective source and destination nodesbefore
data can be exchanged A transport protocol mustprovide the mechanisms to insure that packets are delivered to thereceiver in the same order in which
they
weresent, with noduplicationor omissionThe XNS Internet Transport Protocols
[9]
provide these services through several layered protocols, eachperforming
adistinct function.The Internet Datagram Protocol
defines
thefundamental
unit ofdata an internet packet, which is passedwithin the
internet,
and alsodefines
the means for these packets to be addressed, routed anddelivered
Each packet contains addressing information
(source
and destination addresses), control information(checksum, length,
packettype andtransportcontrol) anddata (encoded higher level protocoldata).The Sequenced Packet Protocol
(SPP)
providesfor
the reliabledelivery
of packetsfrom
source todestination. It is this protocol that guarantees the deliv cry of packets in order with no
duplication
orommission.
The Packet
Exchange
Protocol(PEP)
provides afacility for
efficient request-response orientedcommunication.
This
istypically
used when a single internet packet can contain the response data andthereliabilityachievedthroughtheuse ofthe Sequenced Packet Protocol isnot required
The Error Protocol providesa standard mechanism
for
errors to becommunicatedThe Routing Information
Protocol defines the meansby
which networkrouting
tables are maintained.Each network node must maintain a
routing
table which is used to route individual packetsfrom
onenetwork to another
This
protocol provides for the broadcast and maintenance of the informationcontained withinthe tables
The Echo
Protocoldefines
a simple means to verify the existence and correct operation ofany networkhost.
2.3.3
Courier(Remote
Procedure CallProtocol)
The Courier Protocol
[6] defines
the manner in which clients andservers interact within the distributedXNS environment Courier defines a single request reply, or transaction, mechanism upon which all
higher level XNSprotocols arebased
Courier is based upon the remote procedure call model, where an active client invokes operations
provided
by
a passive network server A Courier call is analagous to a subroutine call where argumentsare passed onthe call and values
may
beconveyed on the return,as shown in Figure 23
CALLprocedure arguments
RETIRN results
-or--
ABORTerror,arguments
Figure 2
3
Courier modelPassive
Courier is defined as consisting of three
layers
the block stream, the object stream and the messagestream The block stream encapsulates the
binary
data from higher layer packets for transmissionby
theSequenced
Packet Protocol.The
object stream imposes structure onto thisbinary data
in the form ofcommon
data
types(such
asbooleans,
cardinals, strings, etc). The message stream structures these datatypes into
Courier
procedure calls andrepliesThe
messageanddata
typessupportedby
Courieralsoform
thedefinition for
alanguage
in whichall XNSapplication
level
protocols are written. The formaldefinition for higher
level protocols consists oftransaction-orientedexpressions written inthisCourier
language
There may
be
instances where applicationsdesire
to send large amounts of data for which it does not make sense to pass the data as a procedure argument. For this reason, Courier also includes a Bulk DataProtocol
[2]
whichdefines
the mechanismfor transmitting
simple streams ofdata between two Courierapplications. For the purposes of transmission, this data
may be
viewed as a single Courier data objectwhich is interpreted
based
upon thecontextofarecent Couriercall Bulk data transfersmaytakeplace intwo forms:
immediate,
where the initiator is either the sender or receiver of the data and third party,wheretheinitiator causesthedatato
be
sent from aseparate sendertoanotherreceiver2.3.4 Application Protocols
The XNS application protocol layer consists ofa set of protocols and standards that support and enhance
those protocols. This layer is further subdivided into three distinct
levels,
the Application SupportEnvironment,
Basic Application Servicesand Information Format andEncoding
StandardsThe lowest
level,
the Application SupportEnvironment,
providesthose services usedby
themajority
ofhigher level applications
Specifically
this level provides thefollowing
functions to present a secure andreliable network forthe higher levels:
location of resources andindividuals withinthenetwork
userauthentication
acommon timebase
for
theentire networkacommon character
encoding
formatfor files
andCourierstringsstandardization
for
the use offonts
andfont
servicesThe Clearinghouse
Protocol[4] defines
the mechanismsfor
objectnaming
andaddressing
within thenetwork.
The Clearinghouse
service and associateddatabase
isdecentralized
and replicated throughoutthe network.
This
protocoldefines
the information storedby
the service and the means whereby userscanretrievetheinformation.
The
Authentication Protocol[1] defines
the methods usedby
clients and serverstoidentify
each other inasecure and reliable manner. This protocol defines the credentials which a user provides to gain access
to thenetworkservicesandthe proceduresemployed
by
clients and servicesto verifythese credentialsThe
Time
Protocol[14] defines
a standard format for the representation of time within the network andthemannerin which network clients receive thecurrent timefrom anetwork timeservice
The
Character Code Standard[3]
defines theencoding
of character data within the network Thisencoding
provides character assignments for Ascii and ISO646
characters as well as special charactersfrom many differentalphabets, mathematical symbols and graphics characters
Thesecond
level, consisting
ofthe Basic ApplicationProtocols,
defines the protocols neededby
users ofthenetwork ona regularbasis Theseprotocols provide the
following
commonapplicationsa global network
file
systemremote
printing
mailservices
interactiveterminal services
The
Printing
Protocol[12]
definesthe manner in which print requests are communicated to print serversandthe status ofprintrequests is determined
The Filing
Protocol[8]
definesa general purposedistributed file
system and the mechanismfortransferoffiles
withinthe network.The Gateway Access Protocol
supports terminal emulation andfile
exchange between non-XNS clientsandXNSservicesas well asXNSclients and non-XNSservices
The
Mail Protocoldefines
theformat
of mail messages and the means employed tosend and receive thesemessages.
The third
level, consisting
of the Information andEncoding Standards,
defines specific formats orlanguages for
theencoding
anddecoding
offiles
within the network This level provides a uniformformat for
similarfiles
in an effort to provide users with the ability to edit, print or transmit afile
anywhere withinthe network, regardless ofhost hardware or software
Interpress
[10] defines
a standard representation for documents which are to be printed It is thislanguage
that is interpretedby
a print service prior to the actual printing. Interpress provides dev iceindependence
for
the creators of printfiles
withinthe network.The Raster
Encoding
Standard is the definition of a general purposeencoding
for digital images Thisstandard is used to represent stand-alone images to be viewed as well as images included within
Interpress
files
3.
Filing
ProtocolOverview
The
Xerox NetworkSystems
provide a general purposefile
management system which is hierarchical innature and supports a wide variety of
functions, including file
transfer, access control,file
location andenumeration, randomaccess, serialization anddeserialization of
directory heirarchies
TheFiling
Protocolrepresents a
formal
definitonofthisfile
system as well as a guidefor accessing
thesystem.The
protocolbeing
definedby
this thesis evolved as a subset oftheFiling
Protocol because there wereexisting
implementations of theFiling
Protocol and compatability with these implementations could bepreserved. Since the
Filing
Protocol contained the level offunctionality desired
for the protocolbeing
defined,
thatfunctionality
simply needed tobe
separated from the full protocol into the definition of the subset.Abrief descriptionofthe
basic
concepts oftheFiling
Protocol is presentedhere
to provide abackgroundfor
the remainderofthe thesis Adetailed descriptionoftheprotocol is not intended, since many ofthesedetails
are not relevant to this thesis.Instead,
the complete Xerox specification oftheFiling
Protocol isincluded,
forreference, inAppendix B The descriptionofthe protocol thatfollows
defines the terms andconceptsintrinsicto understandingthework presentedlater
3.1 ClientsandServers
The Xerox
Filing
Protocol is a formal specification of a general purposefile
system It defines theinteraction that takes place betweena.
filing
client, an entity requesting work to be done on behalfof auser,and afileservice; the entity
accepting
requests for workAclient may havean explicit user
interface,
where specific user inputs controltheclient process actions,or it may
be
invokedduring
the executionof a process where there is no user interactionA
file
service mav, but is not required to, exist on a separate processor or server Multiple separatefile
services mav in fact reside on a single server A general
time-sharing
computer may provideafile
serviceto allow some levelof
file
access to users not resident onthat machineAll
files
within afile
service are organized in a heirarchical manner Each service contains a single rootdirectory
whichin turn contains various descendantsubdirectories andfiles
Allfiles
residingdirectly
ina
directory
are referred toas children ofthedirectory
file. Thedirectory
which contains afile is,
in turn,that
file's
parent.3.2 Procedures
The
Filing
Protocoldefines
a set of procedures for variouslevels
offile
access and transfer Theprocedures
defined
inthe Xerox specification areSession Management-
Logon
Logoff
Continue
establish a session
terminate asession
retainanopen session
during
a period ofinactivity-File Access--
Open
Close
open a
file
close a
file
Create create a
file
with no contentDelete deletea
file
Access Control Management-
ChangeControls
GetControls
UnifyAccessLists
Attribute Management-
ChangeAttributes
modify
thecontrols ineffectfora previously openedfile
retrieve thecontrols ineffect for apreviouslyopened
file
unifv theaccess
lists
for asubtreemodifv theattributes for a
file
GetAttributes
retrievethe attributesfor
afile
3.3
Remote
File Management-Copy
Move
File Transfer-
Retrieve
Store
Replace
Serialize
Deserialize
Random Access--
ReplaceBytes
RetrieveBytes
File Enumeration-
Find
List
Sessions
copy a
file
and itsdescendants
toanotherdirectory
move a
file
and itsdescendants
toanotherdirectorv
retrieve the contentsof a
file
create a
file
with contentsreplace thecontents ofan
existing file
encode a
file
and itsdescendants
into a streamofbvtes
reconstruct a
file
and itsdescendants froma stream ofbytes
overwriteor appendto the
existing
content of afile
read a range ofbytes from anexisting
file
locate
and open afile
inadirectory
return attributesabout
files
inadirectory
The
Filing
Protocol is a session oriented protocol, in that an explicit user logon must be performed toestablish a session, with a subsequent logoff
terminating
the session All procedure calls issuedby
theclient relative to the initial logon requesttakeplacein thecontext ofthatsession
A unique identifier called a session
handle
is usedby
both client and service processes to maintain theLIpon successful validation of the user credentials, the service the
session
handle
and returns it to the client. Thishandle
is then used on all subsequent client calls withinthe same session until a
logoff
occurs. The logoffsignals terminationof the session and causes the clientand serviceto
discard
thecorresponding
sessionhandle
Sessions
may
varygreatly
in theirduration and amount ofactivity Afile
service may terminatea sessionatanytimewhen a remote procedure call isnot in progress.
3.4 UsersandAuthentication
Each session requires that some user identification
be
presented to the service process TheFiling
Protocol provides
for
the use ofboth
primary and secondary credentials.Primary
credentials are in aform defined
in the Authentication Protocol[1]
and are validated against a network Authenticationservice.
Secondary
credentials are file service specific andmay be
required as neededby
the underlyingservice
operating
system The service performsthe necessary validation ofthecredentials presented as apartof
logging
onto theservice3.5
Files:content and attributesThe basic unit of operation within the
Filing
Protocol is that of afile
Afile
is a logicalgrouping
ofdatawhich isstored as a singleunit
Each
file
is viewed as eithertemporary
or permanentTemporary files
do not reside in anydirectory
andonly exist for the duration of all sessions which have the file open Permanent files reside in a specific
directory
and remainthere until explicitlydeleted
Each file consists oftwo distinct parts content and attributes The content of the file is the
data
actuallycontained in the
file
as a sequence of eight bitbytes
This data is uninterpretedby
thefile
serv ice exceptin thecase whereaspecific format is defined for the transferofthedata
Attributes areadditional data itemsassociated with a
file's
content that mav be usedto provide additionalidentification or description of a
file
Attributes may eitherbe interpreted,
in which casethey have
aspecific
meaning
to afile
service and result in a definedbehavior,
or uninterpreted, in which casethey
arestored onthe
file
servicebut interpreted onlyby
the clientEach attribute is
designated by
an attribute type, many of whichare definedby
theFiling
Protocol. Eachofthese
defined
attributetypesmustbe
interpretedby
allfile
servicesimplementing
theFiling
Protocol.Attributes
normally
are obtained and modifiedby
explicit client action;however,
certain proceduresdo
resultin
file
servicemodification ofattributes.Interpretedattributes existinseveraldifferentcategories;
identification related
filelD.
isDirectory, isTemporary. name, pathname, type andversioncontent related checksum,dataSize andstoredSize
parent related parentlD and position
event related createdBy, createdOn, modifiedBy, modifiedOn, readBy and readOn
directory
related childrenUniquelyNamed, numberOfChildren, ordering, subtreeSize and subtreeSizeLimitaccess related accessList anddefaultAccessI.ist
3.6 Handles
Filing
clients issue requests to afile
service to operate on files When a service creates a newfile
or opens anexistingfile
on behalfof aclient, afile handle
iscreated and returned to theclient Thishandle
is used
by
the client and service toidentify
thefile
within the context of a session Thehandle
isdiscardedoncethefile is closed or thesession is terminated
Theactual structure of a
file handle
is service specificand is only interpretedby
thefile
service3.7
ControlsA client
may
request access to afile
with certain access characteristics to be imposedby
the serviceThese characteristics, called controls, are presented with the request to open the
file
andspecify
theintended interaction with a
file by
the client. Controls canbe
usedby
the service to determine the levelofinteractionwith a
file
that can occur simultaneouslyby
several clients.Since
controls are relative to agiven
file handle, they
can alsobe
used to control accessby
the same client ifafile
is opened multipletimes inasingle session.
Specifically,
controls can designate:lock
timeout
access
atype oflock
(none,
share orexclusive)atimeout periodto
be
used inwaiting for
alocka set of access permissions requested fora
file
3.8 Scopes
When clients enumerate or locate
files, they
specify arguments, called scopes, todescribe
the selectioncriteriato use Scopescan specifythefollowing:
count
depth
direction
filters
the maximum numberof
files
topresent to the clientthe
nesting
level ofdescendantstoconsiderduring
the searchthe directionof examination, either from
beginning
toend or endtobeginning
the conditions on attributes to be used for identification (condition is True or
False,
condition equal toa constant, or alogical combination ofconditions)3.9
ErrorsConsistent with the Courier model, the
Filing
Protocol will return appropriate errors when a procedurecallcannotbeserviced correctly
Specifically,
thefollowing
classes oferrors may be returnedAccessError
ArgumentError
thedesired
file
access isnot possiblea specified argument
(attribute,
control or scope) type or value wasinvalid
AuthenticationError theusercould notbe validated
ConnectionError
HandleError
InsertionError
RangeError
ServiceError
SessionError
SpaceError
TransferError
UndefinedError
thebulk
data
connectioncouldnotbe
establishedthespecified
file handle
was invalidthespecified
file
could notbe inserted
into thedirectory
thespecified random access
byte
rangewasinvalidthe sessioncould not
be
created orterminatedthespecified session
handle
was invalidthespecified storage forthe
file
could notbeallocatedthebulk datatransferencountered a problem
an implementation dependantproblem occured
4. Implementation Descriptions
This
section presentsdescriptions
of severalexisting
implementations based upon the XeroxFiling
Protocol
definition. These descriptions
are intendedtodemonstrate
the potential areas ofincompatibility
arising from
thedifferences
ineachimplementor'schoice of a specific subset.This
section willdiscuss
thefollowing
implementations :1)
theXerox Network Systems803" File Serverand Xerox
Development
Environment FileTool client,2)
Implementation Afor
VAX/VMS and3)
Implementation B
for
VAX/4 2BSD UNLX and System V UNIX The anonymous identification of the lattertwo implementations results from the proprietary nature of the
corresponding
commercial productsThey
are included in the discussion becausethey
areworking
examples of differentimplementations,
eachof which attempted to support useful
functionality
.They
provide concrete examples of the variousforms
ofincompatibilities whichmaybe
experienced.The descriptions
presented will compare the implementations with regard to two categories: attributeacceptance/usage and procedure support The discussion of attribute acceptance and usage
focuses
onthe acceptance and retention of
Filing
attributesby
afile
service and the usage of attributesby
theclients. The discussion of procedure support
describes
where the implementations differ from theFiling
Protocol in their support
for Filing
procedures This description does not encompass the full detail ofthese
implementations,
rather, it is intended to provide a perspective on the alternatives available whenimplementing
a subset of the protocol and theinteroperability
problems which are a result of thesealternatives.
The problems pointed out in this section provide the motivation for this thesis
They forcibly
demonstrate the need for a single well
defined
protocol, in order to achieveinteroperability between
heterogeneous implementations Section 5 describes some of the specific choices made in
defining
thisstandard subset and Section
6
specifics theresulting Filing
Protocol subset which provides thedesired
filetransfer facility.
4.1 Attribute Acceptance
-Services
Table 4.1 lists
theattributes allowed on those procedures acceptedby
atleast
two of the various serverimplementations. From this table, it is evident that
only
a small subset of attributes is actually acceptedand
subsequently
retainedby
each ofthe implementationsandthatthe intersection ofall three representsan even smaller subset
4.1.1
Xerox8037
FileService
The
Xerox 803" File Service supports the fullFiling
Protocol with respect to attribute support The ListandGetAttributes proceduresallow specification ofany attributes and will return appropriate values for
theattributes requested. The Open and Storeprocedures allow
only
thoseattributes specified as legal intheseries oftables in Section
3
10oftheFiling
Protocol[8]
Attribute specification is also supported forthe
Copy, Deserialize,
Move and Replace attributes althoughthey
are not included in Table 4 1 sinceneitherthe VMSorUNIX implementationssupport theseprocedures
4.1.2
VAX/VMS File ServiceThe VAX/VMS service only supports those attributes which readily map into specific VMS
file
systemconstructs In addition, the range of attributes supported is not consistent across each of the procedures
implemented. Attributes that are not included in the table are not accepted and the
corresponding
procedure is rejected
However,
not all attributes accepted on various procedures are, in turn, retainedby
thefile
service.A List procedure is rejected if an attribute type other than createdBy, createdOn, dataSi/e
filell),
isDirectory,
modifiedOn, name, readOn, type or version is specified Appropriate values are returned foreachofthese attributes
The Open procedure only accepts the
filell),
name, parentlD and version attributes TheOpen
willbe
rejected ifthe parentlD valueis not nullfilerD
Procedure Xerox 8037 File Service VAX/VMS File Service
UNK FileService
ChangeAttrlbutes accessList checksum childrenUniquelyNamed
createdBy
createdOn
defaultAccessList
name
ordering
position
subtreeSizeLimit type version
procedurenot supported all attributetypes
Create accessList
checksum childrenUniquelyNamed
createdby
createdOn
dataSize defaultAccessList
isDirectory isTemporary
name
ordering
position subtreeSizeLimit
type version
procedurenot supported all attribute t\pcs
GetAttrlbutes (valuesreturnedfor
theseattributes)
all attribute types procedurenot supported dataSize isDirectun modifiedOn
name type
List
(valuesreturnedfor theseattributes)
all attributetypes createdBy
createdOn
dataSize filelD isDirectory
modifiedOn name readOn
type version
dataSize isDireann modifiedOn
name type
Table 4.1
Service acceptanceofattribute types
Procedure Xerox8037File Service VAX/VMS File Service
UNIX File Service
Open filelD
name parentlD pathname
version
file ID
name parentlD
version
allattribute types
Store accessList
checksum childrenUniquelyNamed
createdby
createdOn
dataSize defaultAccessList
isDirectory isTemporary
name
ordering
position subtreeSizeLimit
type version
createdBy
createdOn
dataSize isDirectory
name type version
all attributetypes
Table 4 1
(continued)
Serviceacceptanceof attributetypes
The Store procedure is rejected ifthe client specifies an attribute type other than createdBy, createdOn,
dataSize, isDirectory,
name, type or versionOnly
the attributes name, type and version are actuallyretained withthe
file;
valuesfortheother attributes arc acceptedbut ignoredThe
ChangeAttributes,
Create andGetAttributes
procedures are not supportedby
the VMSimplementation.
4.1.3
UNLX File ServiceThe UNLX
file
service supports a different subset ofFiling
attributesAgain,
only those attributes readilymapped into Unix
file
system constructs are supported and retained with thefiles
Thefile
service willaccept, but notretain, attributes whichit
docs
not supportThe ChangeAttributes
procedureonly
allows the name attribute tobe
specified. If the name attribute isnot specified, the procedure is rejected;
however,
specification of other attributesdoes
not cause theprocedurecallto
be
rejected.The Create,
Open andStore
procedures accept all attributes and do not reject the procedure callaccording
to thelegality
of the attributes as specified in theFiling
definition. Although specification ofthe
isDirectory
and name attributes arenecessary for theservice toprocess theOpen procedurecall, theprocedure is not rejected if either ofthese attributes are missing. All attributes specified on the Create
and
Store
procedures, withtheexceptionofisDirectory
andnameare not retainedThe dataSize, isDirectory,
modifiedOn, name and type attributes are acceptedby
the GetAttributes andList procedures and appropriate values returned Other attributes are accepted, but values are simply
omitted
from
thelist returned totheclient.4.2
Attribute Usage - ClientsTable
4.2
compares theuse of attributesby
clients on those proceduressupportedby
one or more clientsForeachprocedure, the client may use any combination oftheattributes listed This table in conjunction
withTable
4
1 is usefulinidentifying
theincomptabilities between the variousclients and services4.2.1
XDEFileToolThe Xerox FileTool uses a subset of the
defined Filing
attributesdepending
upon the higher level userfunction
being
performed. Forexample, theOpen procedure may specify the pathnameorfilelD
attributedepending
upon whetheraprevious GetAttributeswas performed to determine the filelD attribute value.The List procedureonly requests thoseattributesactually specified
by
an option in the user interfaceUsage ofattributes
by
the FileTool client is legal as definedby
the tables in Section 3. 10 of theFiling
Protocol
[8].
Procedure XDE FileTool VAX/VMS
Client UNLXClient
ChangeAttributes procedurenot used procedurenot used name
Create procedurenot used procedure not used name type
GetAttributes pathname procedurenot used dataSize
modifiedOn name
type
List createdBy
createdOn
dataSize
modifiedOn name pathname
readOn type version
dataSize
isDirectory
name type
dataSize
modifiedOn name
type
Open file ID
name pathname
name isDirectory
name
Store createdOn
dataSize
name type
dataSize
isDirectory
name type
dataSize
modifiedOn name
type
Table-4 2
Client usage of attribute types
4.2.2
VAX/VMSClientThe VAX/VMS client only uses those atributes necessary to
identify files
and maintain round-tripintegrity
ofthe data between Xeroxandcorresponding
VMS services Those attributes supported includedataSize, isDirectory,
name and type4.2.3
UNLX ClientThe UNLX client also makes use ofonly a small set of attributes for the same reasons as the VMS client