mirror of https://github.com/mabam/CAP.git
233 lines
10 KiB
Plaintext
233 lines
10 KiB
Plaintext
|
|
NBP in the UNIX environment.
|
|
|
|
Charlie C. Kim
|
|
User Services Group
|
|
Academic Information Services Division
|
|
Libraries and Center for Computing Activities (Scholarly Information Center)
|
|
Columbia University
|
|
|
|
Draft: July 12, 1986
|
|
|
|
INTRODUCTION
|
|
|
|
The NBP protocol specification (June 1986 version) assumes that the
|
|
NBP database within a particular machine is accessible by any process
|
|
in that machine. In the Unix environment, this is possible, but
|
|
probably not the best idea (would be easy in System V with shared
|
|
memory, would be easy with shared files in BSD 4.2). We extend and
|
|
modify NBP for the Unix in the following ways.
|
|
|
|
Our goal is quite simple. We wish to provide a name data base for a
|
|
particular unix node which is reliable and secure. To achieve this
|
|
goal, the information in the database should be correct and timely.
|
|
In addition, we should be able to prevent "malicious" or "ignorant"
|
|
users from inserting invalid or deleting correct information.
|
|
|
|
Since there is a need for a privileged process acting as a name
|
|
information socket (NIS) listener in any event, we leverage our
|
|
position by extending the functionality of this listener. We modify
|
|
its simple purpose of answering NBP lookup requests to that of acting
|
|
as the NBP database for a particular unix node (or set of nodes).
|
|
|
|
SPECIFICATION
|
|
|
|
We now outline the actions the client and server must take, in the
|
|
unix environment of course, to register and deregister a name. We
|
|
also outline an optional method for maintain the validity of the
|
|
database.
|
|
|
|
Note that the Unix NBP server differs from the standard NBP
|
|
specification in that it WILL respond to NBP Lookups from itself.
|
|
Under a shared table os environment like the MacIntosh it is
|
|
reasonable to impose this restriction. Under the independent process
|
|
environment of Unix, we do not belive the restriction to be reasonable.
|
|
In addition, we are assuming the overhead involved on the Ethernet-Unix
|
|
end to be smaller (relatively speaking that the overhead on the
|
|
AppleTalk-MacIntosh end).
|
|
|
|
First, we shall note that the table the NBP server keeps contains a
|
|
list of the various "local" NVEs and the associated client process
|
|
NBP addresses.
|
|
|
|
Name registration
|
|
--------------
|
|
|
|
We first extend the range of NBP control types to include NBPRegister
|
|
and NBPStatusReply. The standard NBP packet format is used for
|
|
NBPRegister. The name to be registered goes into the NBP tuple. Note
|
|
that exactly one entity can be registered with a single NBP register
|
|
message and the contents of the NBP packet tuple count field must be
|
|
zero (note: actually the tuple count field is used for something else,
|
|
but we'll ignore that and say that it should be zero for now).
|
|
NBPStatusReply uses the same packet, but overloads the usage of the
|
|
tuple count field - it is now used to indicate a status.
|
|
|
|
The transaction for a register is as follows. [Note: The client is
|
|
responsible for checking whether the name is already in use within the
|
|
specified zone and should do this before sending the NBPRegister
|
|
message to the internal server.] Build a NBP Register message with
|
|
the correct entity name encoded in the NBP tuple area. The address
|
|
placed there should be that of the local process's NBP manager. The
|
|
message is then sent out on the socket which the name should be
|
|
registered. This requirement assures us that the service is available
|
|
and the agency requesting the service is responsible if the service
|
|
applies to a WKS. [Note: it does confuse things a little though].
|
|
|
|
The NBP server, upon receiving a registration message, will first
|
|
check the name encoded in the incoming NVE is not already in use
|
|
within its table. If the name is already in use, we know that a
|
|
"valid" NVE exists (entries in table are assumed valid). We know
|
|
check the "valid" NVE's address against the address of the incoming
|
|
NVE. If the addresses match, a valid name registration update event
|
|
has occurred. [Note: we cannot do otherwise - the process sending the
|
|
message "owns" that socket - if there was a previous owner then
|
|
tough].
|
|
|
|
At this point, up to three conditions may be in effect. We have a
|
|
valid name registration event, a valid name registration update event,
|
|
or the NVE may already be in use. For the third condition, we simply
|
|
respond to the NBP client with a NBP Status Reply with a code
|
|
indicating the name was already in use.
|
|
|
|
For a valid name registration event, we must insert the new item into
|
|
our table. Since we can't use the trick of the MacIntosh's NBP to use
|
|
memory allocated to the client process, we must be prepared to deal
|
|
with table/memory overflow. If this happens, a NBP server must send a
|
|
NBP Status Reply message with the code "table overflow". Otherwise,
|
|
all is okay and we send a NBP Status Reply to the client NBP process
|
|
with condition all okay.
|
|
|
|
For a valid name registration update event, we need only update the
|
|
address of the client NBP and send a NBP Status Reply to the client
|
|
NBP process with the condition all okay.
|
|
|
|
The client is responsible for sending NBP registration messages to the
|
|
server until some retry count is exceed or a NBP Status Reply is
|
|
received. Our semantics for the NBP registration attempt ensures that
|
|
the client will always receive the correct reply from the server no
|
|
matter how many times the server receive the NBP registration message.
|
|
|
|
Note: we maintain the NBP id and the server MUST respond with the
|
|
same NBP id as the registration request.
|
|
|
|
|
|
Name deletion
|
|
-------------
|
|
|
|
The client sends a NBP deletion message to the server with the
|
|
specified NVE encoded the NBP packet tuple area. The server upon
|
|
receiving the message will attempt to look up the specified NVE.
|
|
[Note: it will use the address that it received the packet from as the
|
|
client address!]. If the NVE does not exist, the NBP server will send
|
|
back a NBP Status Reply message with the condition "no error". If the
|
|
NVE exists in the server's tables, the server will validate the
|
|
deletion request by checking the address of the NBP client against the
|
|
NBP client address associated with the NVE in the table. If the
|
|
addresses do not match, the server will respond with a "permission
|
|
denied" NBP Status Reply message. Otherwise, we have reached the
|
|
final case and the NBP server will remove the NVE from its tables and
|
|
send a NBP Status reply message with condition "no error".
|
|
|
|
Note: we do not specify the NBP deletion request be sent from the
|
|
socket the NVE exists upon to allow the client to close down the
|
|
socket before it sends the name deletion request. If a client has
|
|
opened the socket and wishes to delete the name and has received a
|
|
"permission denied", the client should send a NBP register message
|
|
(which is probably all it ever wanted to do unless it's some sort of
|
|
maintenance program) to override the previous owner.
|
|
|
|
Note: we maintain the NBP id and the server MUST respond with the
|
|
same NBP id as the deletion request.
|
|
|
|
Note: deleting a name not in table returns no error so multiple delete
|
|
requests won't return an error (since we need to be able to rexmit)
|
|
|
|
|
|
|
|
Name table maintenance (optional)
|
|
----------------------
|
|
|
|
We need a method of ensuring that some or all of the names held by the
|
|
NBP server process are valid. How? We can require that the client
|
|
process "tickle" the server process at regular intervals. Also, less
|
|
satisfying is to require the NBP server process to tickle the client
|
|
process of each NVE at regular intervals and have the client process
|
|
respond.
|
|
|
|
|
|
We take the following approach. The client may note that name will be
|
|
"tickled" by encoding a flag in the NBP tuple count field on a name
|
|
registration (note: we may require that all NVEs using dynamic sockets
|
|
do this - enforcement would come from server: either it would timeout
|
|
NVEs which didn't respond or it would reject the registration
|
|
message). The server will then age NVEs based upon NBP "tickle"
|
|
messages from client. When the NVE is in danger of timing out - the
|
|
server will send a NBP "tickle" to the NBP address of the client
|
|
associated with the NVE. The client can validate the server "NVE" by
|
|
checking the socket - since it is a privileges socket we know that
|
|
the message is valid. The client must respond it desires to keep the
|
|
NVE active by sending a tickle packet.
|
|
|
|
Note that the client may send a list of tuple in NBP tickle packet.
|
|
|
|
|
|
Finding the NBP server
|
|
----------------------
|
|
|
|
We have assumed throughout the above discourse that the NBP server
|
|
address is known. We leave this unspecified - allowing the NBP server
|
|
to reside on a different node than the client. The current Unix
|
|
implementation assumes that the NBP server is running on the same node
|
|
as the NBP client.
|
|
|
|
|
|
POSSIBLE ENHANCEMENTS
|
|
|
|
NBP Lookup server
|
|
-----------------
|
|
To reduce the number of message flying across the bridge/gateway to
|
|
the Appletalk network, we could have the NBP server do lookups and
|
|
keep track of NVEs it finds. The clients would then be required to do
|
|
a NBPConfirm to ensure the NVE (since we must assume early binding in
|
|
this situation).
|
|
|
|
We would in this case look at the NBP server (for the limited purpose
|
|
of this discussion) as the NBP lookup server. The server would do look
|
|
ups on its own infrequently (app. 5-10 minutes would be frequently).
|
|
The server, upon receiving a lookup request from one of its lookup
|
|
clients that it could not satisfy or involved wildcards, would check
|
|
to see when it last did a lookup - if less than a small interval (say
|
|
10-30 seconds) would issue another NBP lookup request to the zone.
|
|
|
|
Note: when we're dealing with wildcards, it's probably best for the
|
|
client to issue its own request instead of going through the lookup
|
|
server.
|
|
|
|
Priviledged is priviledged
|
|
--------------------------
|
|
|
|
Allowed a name registration request from a WKS override a name used by
|
|
someone else. Should allow for notification too; possibly the message
|
|
used in maintenace to inform of a name going away should be extended
|
|
to allow a message which say that a name has gone away.
|
|
|
|
|
|
NBP Delete all message
|
|
----------------------
|
|
|
|
An NBP delete all message from a client would specify that all names
|
|
"owned" by the client be removed - useful for a closing down state.
|
|
In addition, a message to remove all names based on (network
|
|
address,socket) pairs would be useful. These two functions would be
|
|
encoded by using the NBP tuple count field as a flag field.
|
|
|
|
|
|
Combining with internet server
|
|
------------------------------
|
|
|
|
Would be nice to integrate this with the internet name server. In
|
|
particular, it would nice to be able to register TCP/IP hosts.
|
|
|
|
|