nameserv::protocol(3tcl)

💖 nameserv::protocol 💖

okay bestie, so this is a page from the Name service facility manual, and it's literally all about the client/server protocol for nameserv — you know, the vibes-level spec for how the client and the server talk to each other. Let's get into it. 🦋

---

✨ 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 — and, no cap, unprotected — name service facility. It's meant for small, trusted environments, bestie. Like, do not deploy this in a hostile network and expect it to fight for you. 🙈

Please read Name service facility, introduction first. It's giving required reading. 📚

This document is the spec of the network protocol that the client and server use to talk to each other. The whole point is that it lets people implement the exact same protocol in other languages. Iconic, honestly. ✨

---

👑 NANO NAME SERVICE PROTOCOL VERSION 1 👑

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

💅 BASIC LAYER 💅

The basic communication between client and server runs over the remote-execution protocol specified by the Tcl package comm. The document that specs its on-the-wire protocol lives in comm_wire.

Every script swapped over this protocol is a single command in list form, which means you can just read them as plain messages instead of Tcl commands. The commands/messages listed in the next section are the only commands the server-side understands. And listen — command and variable substitutions are not allowed within the messages, so arguments have to be literal values. Periodt. 🔥

The protocol is synchronous. Which means: for every message sent, a response is expected, and it has to be generated. All messages are sent by the client. The server does not send messages — it only sends responses to messages. That's the whole dynamic. 💜

🎀 MESSAGE LAYER 🎀

• Bind name data — the client sends this when it registers itself with the service using a name and some associated data. If the name is already in use, the server has to send an error response. Otherwise the response has to be an empty string. Also, the server has to accept multiple names for the same client. She's flexible like that. 💅
• Release — the client sends this to unregister all the names it's known under at the service. The response has to be an empty string, always. No exceptions, no drama. 🫶
• Search pattern — the client sends this to search the service for names matching the glob-pattern. The response has to be a dictionary with the matching names as keys, mapping them to the data associated with them at Bind-time. 🍓
• ProtocolVersion — the client sends this to ask the service for the highest version of the name service protocol it supports. The response has to be a positive integer number. Servers that only support Nano Name Service Protocol Version 1 have to return 1. 📌
• ProtocolFeatures — the client sends this to ask the service which 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 called the Search/Continuous feature. It adds extra 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 that supports this feature has to put the feature name Search/Continuous into the list of features returned by the message ProtocolFeatures. iykyk. 👑

For this extension the protocol is asynchronous. No direct response is expected for any of the messages in the extension. On top of that, the server will start sending messages on its own — instead of only responses to messages — and the client has to be able to handle those notifications. Main character server energy, fr fr. 😭

• Search/Continuous/Start tag pattern — the client sends this 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 additions and removals 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 — instead, the client expects to be notified of changes via explicit Search/Continuous/Result messages generated by the service.

It's also expected that the tag information is passed unchanged into the Search/Continuous/Result messages. This tagging of the results is what lets clients start multiple searches and tell the different results apart. So handy. 💖

• Search/Continuous/Stop tag — the client sends this to stop the continuous search identified by the tag. 🛑
• Search/Continuous/Change tag add|remove response — the service sends this message 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 make sure that happens, 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, mapping them to the data associated with them at Bind-time. The argument that comes before the response tells the client whether the names in the response were added to 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 them in the category nameserv of the Tcllib Trackers: [http://core.tcl.tk/tcllib/reportlist]. And please also report any ideas for enhancements you have for either the package and/or the documentation. We love ideas. 🫶

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

Also note: attachments are strongly preferred over inlined patches. You can attach stuff by going to the Edit form of the ticket right after it's created, and then using the left-most button in the secondary navigation bar. Easy. ✨

---

🔥 SEE ALSO 🔥

• comm_wire(3tcl)
• nameserv(3tcl)
• nameserv::server(3tcl)

---

⭐ KEYWORDS ⭐

comm, name service, protocol

---

🌈 CATEGORY 🌈

Networking

---

💜 COPYRIGHT 💜

Copyright (c) 2007-2008 Andreas Kupries <andreas_kupries@users.sourceforge.net>

---

and that's the whole page, bestie 🎀 this one's from tcllib, version 0.2, and it's the nameserv::protocol(3tcl) page — go forth and implement protocols, you absolute icon 👑💖