nameserv::protocol(n)

💖 NAME 💖

nameserv::protocol — the name service facility's client/server protocol, bestie. It's the manual page from the n section, and it's literally the whole spec for how clients and servers gossip with each other. 🦋

---

✨ 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 🌸

So the packages nameserv::server, nameserv, and nameserv::common give you a simple, unprotected name service facility, meant for use in small trusted environments. No cap. 🫶

Okay but fr fr, read Name service facility, introduction first. It's giving required reading.

This document right here contains the specification of the network protocol that client and server use to talk to each other — which means you can implement the same protocol in other languages. Iconic, honestly. 💅

---

👑 NANO NAME SERVICE PROTOCOL VERSION 1 👑

This protocol defines the basic set of messages a name service has to support, also known as the Core feature. Periodt.

🧚 BASIC LAYER 🧚

The basic communication between client and server happens using the remote-execution protocol specified by the Tcl package comm. The relevant 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, so they can be interpreted as plain messages instead of as Tcl commands. The commands/messages listed in the next section are the only commands understood by the server-side. Command and variable substitutions 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 send 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. No exceptions, bestie.
• 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 highest 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 features 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 a name service has to support, also known as 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. Not me realizing the server just starts yapping unprompted 😭 — but that's literally the design, so slay.

• 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 messages 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. Chef's kiss. 👑

• 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 continuous searches to transfer found changes. The first such message for a new continuous search has to contain 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. Like, obviously. Please report such in the category nameserv of the Tcllib Trackers [http://core.tcl.tk/tcllib/reportlist]. Please also report any ideas for enhancements you may have for either package and/or documentation. We love ideas, fr fr. 🫶

When proposing code changes, please provide unified diffs, i.e. the output of diff -u.

Note further that attachments are strongly preferred over inlined patches. Attachments can be made by going to the Edit form of the ticket immediately after its creation, and then using the left-most button in the secondary navigation bar.

---

🦋 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>

---

And that's the whole thing — tcllib version 0.2 of nameserv::protocol(n), dropping straight from my heart to your terminal. Go forth and speak the protocol, bestie. 💅✨