This project has moved and is read-only. For the latest updates, please go here.

System Description

The system is built up around two distinct technologies :

1- A wcf server that provides the mechanism to transfer the configuration data between the server and the client.
2- Mailslots (windows ipc) are used to do the automatic discovery of the server. See MSDN for mailslots informations.

It uses the broadcasting feature of mailslots to send a single message to all the servers of an entire domain. The server that manages the requested environment is the only one having a mailslot of that name so it will be the unique recipient for that message.

Here is how it works :

Server
The server is splitted in two parts; a mailslot server and a wcf service.
In this implementation, the configuration data to be served is kept in the config file of the server. It could easily be modified to use a more sophisticated store like a sqlite database but for now I wanted to keep things simple.
The data is grouped by environments and subdivised in sections. The server reads the data at startup and keeps it in memory. When there is a request for data, the timestamp of the config file is validated and if it is newer, the data is reloaded in memory. So you can change the data in the config file without having to restart the server process.
Dictionaries are used to keep and serve the data. At the top level, there is a dictionary of environments; each environment is a dictionary of sections and each section is a dictionary of configuration items.
The wcf service publishes methods to get the data at any level; an individual item, a section or a whole environment.
To keep things simple, the service is configured with no security but that can be changed by fiddling in the config file of the server.
If a client is aware of the endpoint address of the service, you can directly target it with no discovery; this is the most performant way to use it but you loose the advantage of automatic discovery (changing server on the fly, changing server endpoint adresses etc).

The mailslot server part is responsible of the discovery process. The server opens a mailslot for each environment that it serves; the mailslots are named with the environment name.
It is very important that only one server manage a specific environment; otherwise you will end up with multiple mailslots with the same name in your network. When a request message is written in a mailslot, it contains the address of a remote mailslot on the client searching for that environment. The server reply to the remote mailslot with a message containing the information about its wcf service (endpoint address, name, port etc). That's how the client discover the service infos for a specific environment.

Client
The client is made of two sections as well; a wcf client and a mailslot client.
The minimum thing that you need to provide to instantiate a client is an environment name. If you only provide that, the client will create a local mailslot and broadcast a message on the network for a mailslot of the requested environment name. It will then wait for an answer in its local mailslot from the server taking care of that environment. The default timeout is 10 seconds but you can also give a specific time in milliseconds.
If you also pass a server name at the instantiation, the mailslot mechanism will also be used but the message will not be broadcast at large, it will only be sent to the specific server.
To validate that you did not timed out when the constructor returns, check with the isConnected flag.
If you provide a service endpoint address at instantiation, the mailslot mechanism is totally bypassed and the isConnected flag is defaulted to true. We assume that you know what you are doing.
After instantiation, the client has the necessary information to consume the wcf service. From there you just make calls to the GetConfigItem method to retrieve the configuration data.
There is an internal cache in the client; the first time that you make a request for an item to the client, the entire section for that item will be requested from the server and saved in the cache. So any subsequent requests for items of the same section will be returned from the cache instead of making a round-trip to the server.
The client does not generate exceptions when it is not connected or if it cannot find the items in its dictionary; it will return empty strings.
Since the main goal of the project was to keep the client footprint minimal, the client wcf configuration (security, transport etc) is hard coded in the client so you do not need to configure anything in your client application. So if you change something of that nature on the server, you will need to update the client(client.cs) accordingly.
To use the client you can use a reference to the nadaconfig assemly or you can just add the file "NadaConfigClient.cs" to your project and add a reference to the ServiceModel .net assembly.

The file "NadaConfigClient.cs" is not part of the nadaconfig assembly; it is a merge of all the classes needed by the client so you can build your project without the nadaconfig assembly. Since it is a code duplication, if you change something in the files of the assembly, you should update "NadaConfigClient.cs" accordingly.

Troubleshooting
Mailslots are using the netbios protocol; UDP 137, 138 and TCP 139. You can easily open these ports in your firewall by putting an exception for "File and Printer Sharing".

Usage
Simple Usage

Last edited Aug 29, 2011 at 9:05 PM by jmjulien, version 4

Comments

No comments yet.