In an ideal world, where system administrators are either

A. all doping on happy pills and are highly cooperative or
B. they do not exist

The DNS solution is the best solution i think. Random thought: make a small DNS server available to the app.

Random thought #2

Assuming that either topology could fit into memory, the topology entity should be a data structure (in C) with a CRUD API. Config files or other ways to manage the toplogy would be built on top of the CRUD API. Internally, listener functions will bi-directionally sync the topology data structure with the actual topology of the network. The data structure could also publish changes to an INPROC, IPC, or TCP connection so that you could build real-time visualizations of the topology.

If the fits-in-memory assumption is too strong for your taste, then I vote for DNS or mini-DNS .

Either way, it seems like a separate project from nanomsg.

I suppose the worst case here really is parallel testing of the same application — let's say we want to run tests for all branches of an application (on push).

The second point basically just goes to the possibility of isolating test configuration from "real" configuration — I think partially related to your point 3 (identification), but a bit broader, I think. Let's assume that I want to run tests for two (or more) applications (in parallel or otherwise) or multiple instances of the same application. Is there some way to have:

• a different setup for each application such that they won't conflict regardless of whatever setup they require (ports, endpoints, etc.)?
• can they run in parallel?
• can I modify the application's networking topology (configuration) without having to reconfigure the (physical) build slaves or messing around with a separate configuration "database" (DNS, DHCP, …)? Ideally, I'd like to be able to bundle the configuration with the code to avoid external dependencies. External dependencies in tests make for very fragile tests in my experience. Building/testing multiple branches of the same application in parallel is also a use case here.
• can I use identical build slaves to run all my tests? (Matters for performance of building/multiple branches of the same application on every checkin.)
• can I avoid nanomsg-specific (manual) setup on my development machine?

AFAICT a simple configuration file (not globally installed) lets one support all of these scenarios, but any kind of "global" configuration (DNS, DHCP, etc.) could place severe limits on what can be done in these cases.

(There's a lot of overlap between these issues and the issues with integration testing against "real" databases.)

Maybe I've just missed something, though. I just wanted to bring your attention to these issues before it's too late :)

As for the other point, I don't really follow. May you elaborate?

There are (at least) two annoyances in (integration) testing with current networking stacks:

• If you want to run tests in parallel you need to somehow pick an unused port. This is the case even if you're testing different applications (if you're running tests on a CI server, for example) which just happen to use overlapping sets of ports. This is actually a huge annoyance in practice even though it's actually not a theoretically difficult problem by any stretch.
• If you have any even remotely complicated setup you may be forced into setting up your CI build slaves with complicated networking setups.

Given that nanomsg really "just" provides a virtual network on top of IP, it seems to me that omitting a "user provides all configuration" (via files or whatever) option would be a mistake when it comes to testing support. Such configuration would actually also have to be per-context (in ZMQ terminology) to enable parallel testing without spawning multiple instances of the application — usually spawning separate instances of the application would not be a problem, but it is a big problem if you're running with a managed runtime (JVM or .Net equivalent, for example) because of the startup time.

HTH

http://2004.eurobsdcon.org/uploads/media/EBSD04_slides_41.pdf

As a historical analogy, consider that once it must have been inconceivable that you could simply speak to any other box by specifying only its address: "You know, this new IP thing makes me feel uneasy. Just imagine that the admins are supposed to re-arrange the network without understanding how the applications work. And with no changes to the code. It seems like Vint and Bob are completely off the track."

Thus, let's treat it as a challenge. At the moment we have no way to build network-layout-unaware applications. Wouldn't it be nice to have that one day?

1. The software is generic. It will be sold to multiple customers…
Agreed.

2. The software is single-purpose and will be deployed at a single site…
I'm not sure I agree with your ~10 years assertion, but I get the point you're trying to make. It just makes me a little nervous that someone can potentially reorganise a system topology without a full understanding of how it works. And without any changes to the code. I just don't think this fits with reality.

1. The software is generic. It will be sold to multiple customers and deployed in their environments. Programmer has no idea what will those networks look like.

2. The software is single-purpose and will be deployed at a single site the programmer is familiar with. Even in such case, time has to be taken into account. Typical lifespan of an enterprise product is ~10 years. During that time the underlying network is going to change significantly. Companies grow and merge, new technologies are introduced etc. In short, when writing the software, the programmer has no idea what network it will be running on in the future.

Anyway, as for separation of core functionality and configuration functionality, I am much in favor of that, however, I don't know how to do that without hurting user experience much (see one of my comments above).

It sounds like you have a totally different view on this, presumably based on feedback you've received that people really want to write generic components that can be glued together in various configurations by a team of people who don't necessarily have intimate knowledge of how these components work.

Anyway, my point was that I hope nanomsg continues to offer a simple interface for connecting and binding sockets while perhaps supporting an additional interface to support a richer feature set for socket configuration. It sounds like this is your plan so that makes me happy :-)

As for bound/connected it's seen often in the wild. Say, in dev env you bind a service a let clients connect to it. In prod env you start a device and let the service connect to it.

I also disagree with your assertion that admins demand the power to dictate whether sockets are bound or connected. Of course, things like connect addresses, ports, etc should be under the control of admins but it sounds like you'd like to delegate topology decisions and architectural design to a group of people who would perhaps consider it the system developers responsibility to build a sane, fault resistant and scalable system.

This is certainly my experience when building backend systems at scale. I would rather submit a newly developed system that has been architecturally designed against a topology model that's been peer reviewed, than to simply hand over a collection of components and say "we'll, it's up to you now…".

The problem with that is that that way you would get 2 sets of APIs:

nn_socket vs. nn_config_socket, nn_connect vs. nn_config_connect etc.

That in turn means that every language binding would have to split into 2 projects, one providing access to the library, other one providing access to the config service.

I tend to believe that the fewer roles a component has the better it is. Then ability to compose several pieces together at will is Freedom.

I still haven't got time to dive deep into the source of nanomsg, but what appealed to me from the outside was its name, that it is written in c, has minimal api and a modular protocol system.

It would be nice to have another beautiful piece of software dedicated to solve the specific problem of configuring network topologies but I think it should be fully decorelated from nanomsg.

Thanks again for your blog and your work on nanomsg.

https://docs.google.com/file/d/0Byd_FTQksoKLY3lyZnlQalFtRnc/edit

As for the dynamic updates, that's basically the DNS solution. You update the DNS records and they get automatically propagated everywhere.

As for the local configuration of the library, that's why "pluggable" configaration service was discussed. The idea was that you can plug in a component that reads the config info from a config file, one that reads it from DNS or yet another that reads if from MySQL.

That being said, there are some questions to answer about local config files. Specifically, as Jiri Sedlacek notes above, if the configuration file is local, why not make it part of the application's config file. That defintely makes sense, but kills the idea of having a single generic mechanism for retrieving config into (the format of app's config file can be different for each app).

FTL uses a JSON configuration format. Which I think is a reasonable way to go with nanomsg. The library could provide a simple API for getting that JSON from somewhere else (mongodb, a rest api, a web server, …) as a URL, providing the JSON as a string, or building library elements manually.

If you want to go a step further, FTL provides dynamic updates, where changes made at the central server are pushed out to the clients.

Anyway, I think FTL offers a nice model for this option and is worth looking at.

As an analogy, let's think of TCP/IP stack. Once it was not integral part of the operating system, rather a stand-alone library.

Back then it could be argued that it's not the task of the library to configure itself. Rather, every application should supply all IP configuration options itself.

Fortunately, that's not what happened. Today, IP is configured on the machine-wide basis and applications can simply use it without having to deal with the configuration of the stack.

My thinking about it is that the topology and the application are conceptually different entities. For example, you can have a pub/sub topology for distributing weather forecasts that can be used by many different applications. Someone sets the topology first, makes sure that the data flow through etc. Then the applications can be written to consume the data from the topology.

In other words, topology is a full-blown stand-alone entity. It exists even if no application is connected to it, same way as network infrastructure exists even though no data is passed through at the moment.

That said, I think there's a certain elegance to storing the connection information as SRV records in DNS. :) Then you just need to configure applications to look for a well known service name to get the connection details. On the other hand, that's not really flexible enough to distribute anything more than host/port information, so you still need admin configuration files…

On the third hand, nanomsg is fundamentally a library, and it's not the "role" of the library to configure itself. That's the responsibility of the host application it's integrated with. I personally dislike the notion that log4j has its own separate configuration file in every Java app I deploy, for example (while the log4j config format is consistent across apps, the actual configuration data is very app specific, so there's no real benefit to it being in a separate configuration file!). Perhaps the goal of nanomsg is to make the API amenable to easy configuration (though I'm not sure exactly what that means!)?

Anyway, this is random drive-by commenting from an outsider, who doesn't understand the broader conversation, so feel free to take it with a pinch of salt. ;-)