nameserv::protocol(n) Name service facility nameserv::protocol(n) ______________________________________________________________________________
NAME
nameserv::protocol - Name service facility, client/server protocol
SYNOPSIS
Bind name data
Release
Search pattern
ProtocolVersion
ProtocolFeatures
Search/Continuous/Start tag pattern
Search/Continuous/Stop tag
Search/Continuous/Change tag add|remove response
_________________________________________________________________
DESCRIPTION
The packages nameserv::server, nameserv, and nameserv::common provide a
simple unprotected name service facility for use in small trusted envi-
ronments.
Please read Name service facility, introduction first.
This document contains the specification of the network protocol which
is used by client and server to talk to each other, enabling implemen-
tations of the same protocol in other languages.
NANO NAME SERVICE PROTOCOL VERSION 1
This protocol defines the basic set of messages to be supported by a
name service, also called the Core feature.
BASIC LAYER
The basic communication between client and server is done using the
remote-execution protocol specified by the Tcl package comm. The rele-
vant document specifying its on-the-wire protocol can be found in
comm_wire.
All the scripts exchanged via this protocol are single commands in list
form and thus can be interpreted as plain messages instead of as Tcl
commands. The commands/messages specified in the next section are the
only commands understood by the server-side. Command and variable sub-
stitutions are not allowed within the messages, i.e. arguments have to
be literal values.
The protocol is synchronous. I.e. for each message sent a response is
expected, and has to be generated. All messages are sent by the client.
The server does not sent messages, only responses to messages.
MESSAGE LAYER
Bind name data
The client sends this message when it registers itself at the
service with a name and some associated data. The server has to
send an error response if the name is already in use. Otherwise
the response has to be an empty string.
The server has to accept multiple names for the same client.
Release
The client sends this message to unregister all names it is
known under at the service. The response has to be an empty
string, always.
Search pattern
The client sends this message to search the service for names
matching the glob-pattern. The response has to be a dictionary
containing the matching names as keys, and mapping them to the
data associated with it at Bind-time.
ProtocolVersion
The client sends this message to query the service for the high-
est version of the name service protocol it supports. The
response has to be a positive integer number.
Servers supporting only Nano Name Service Protocol Version 1
have to return 1.
ProtocolFeatures
The client sends this message to query the service for the fea-
tures of the name service protocol it supports. The response has
to be a list containing feature names.
Servers supporting only Nano Name Service Protocol Version 1
have to return {Core}.
NANO NAME SERVICE PROTOCOL EXTENSION: CONTINUOUS SEARCH
This protocol defines an extended set of messages to be supported by a
name service, also called the Search/Continuous feature. This feature
defines additional messages between client and server, and is otherwise
identical to version 1 of the protocol. See the last section for the
details of our foundation.
A service supporting this feature has to put the feature name
Search/Continuous into the list of features returned by the message
ProtocolFeatures.
For this extension the protocol is asynchronous. No direct response is
expected for any of the messages in the extension. Furthermore the
server will start sending messages on its own, instead of only
responses to messages, and the client has to be able to handle these
notifications.
Search/Continuous/Start tag pattern
The client sends this message to start searching the service for
names matching the glob-pattern. In contrast to the regular
Search request this one asks the server to continuously monitor
the database for the addition and removal of matching entries
and to notify the client of all such changes. The particular
search is identified by the tag.
No direct response is expected, rather the clients expect to be
notified of changes via explicit Search/Continuous/Result mes-
sages generated by the service.
It is further expected that the tag information is passed
unchanged to the Search/Continuous/Result messages. This tagging
of the results enables clients to start multiple searches and
distinguish between the different results.
Search/Continuous/Stop tag
The client sends this message to stop the continuous search
identified by the tag.
Search/Continuous/Change tag add|remove response
This message is sent by the service to clients with active con-
tinuous searches to transfer found changes. The first such mes-
sage for a new continuous search has to contains the current set
of matching entries.
To ensure this a service has to generate an add-message with an
empty response if there were no matching entries at the time.
The response has to be a dictionary containing the matching
names as keys, and mapping them to the data associated with it
at Bind-time. The argument coming before the response tells the
client whether the names in the response were added or removed
from the service.
BUGS, IDEAS, FEEDBACK
This document, and the package it describes, will undoubtedly contain
bugs and other problems. Please report such in the category nameserv
of the Tcllib SF Trackers [http://source-
forge.net/tracker/?group_id=12883]. Please also report any ideas for
enhancements you may have for either package and/or documentation.
SEE ALSO
comm_wire(n), nameserv(n), nameserv::server(n)
KEYWORDS
comm, name service, protocol
CATEGORY
Networking
COPYRIGHT
Copyright (c) 2007-2008 Andreas Kupries <andreas_kupries@users.sourceforge.net>
nns 0.1 nameserv::protocol(n)
Mac OS X 10.8 - Generated Mon Sep 10 15:35:44 CDT 2012