Product: OpenFusion TAO
Version: ALL

Below is an explanation of the contents of the files created by the TAO Name Service when the –u option is used. This will enable you to decode the files yourself.

All these files are human readable (ASCII records one per line, all sizes and counts are stored via ASCII decimal values, the only binary values stored are non-ASCII characters that form part of a bindings name or type, if these are created by the user). Basically you can open them in a text editor and read their contents.

When the Naming Service starts, it uses the existing NameService file to load a ready populated root-context. If this file does not exist it is created with a header record that states there are no current bindings. A second file will be created NameService_global), if this does not exist, that will hold the current count of the number of new naming contexts that have been created so far. This count is used to generate filenames that do not clash with each other. The count is never reset by the naming service and is incremented (and the global file re-written) after each new naming context that is created.

When a new naming context is created it gets it's own file named NameService_0 (for the first one), NameService_1 (for the second one) and so on. These files are exactly like the original root context (NameService) in the way they work. If a context is destroyed, its file is deleted, this is the only time these files are deleted, one by one as each naming context has its own destroy method called (note that a naming context can only be destroyed successfully IF it is empty of ALL bindings). If a binding is added into the context, its file will increase in size; if a binding is unbound, its file size will decrease (however a file's size will not necessary change with each individual bind/unbind as the file is allocated in discrete blocks within the OS, i.e. they CAN contain a small amount of slack space at the end).

These NameServer files are structured as follows. They start with a header record stating how many bindings they hold, and an extra "reserved" 0 value. This header is then followed by any binding records; these are simply concatenated onto this header and form the rest of the file. A binding starts with a type code (0 for a naming context, 1 for a final name binding), a count of the number of characters in the binding ID followed by this ID, a count of the number of characters in the binding Kind followed by this Kind, and a count of the number of characters and the value of the NamingContext Internal/filename (for a NamingContext) or IOR (for a final name binding record).


Here is an example which has been annotated and split into records for emphasis:

-------------------
{# of Bindings} 2
{Reserved-Zero} 0
-------------------
{NamingContext} 0
{IDSize} 28
{ID} Siemens_AG/NetMPeerGR-MODULE
{KindSize} 11
{Kind} EmsInstance
{ContextSize} 13
{ContextFile} NameService_4
-------------------
{FinalBinding} 1
{IDSize} 28
{ID} Siemens_AG/NetMPeerGR-WMSIS2
{KindSize} 19
{Kind} EmsSessionFactory_I
{IORSize} 380
{IOR} IOR:010000003f00000049444c3a6d746e6d2e746d666f72756d2e6f72672f656d7353657373696f6e466163746f72792f456d7353657373696f6e466163746f72795f493a312e300000010000000000000068000000010102000d0000004e4d363234574f4d53495332002af82a1b00000014010f0052535451e27344449508000100000001000000020000007602000000000000000800000001c80604004f4154010000001400000001c8060401000100000000000901010000000000
-------------------

This would actually be stored in the file thus:

2
0
0
28
Siemens_AG/NetMPeerGR-MODULE
11
EmsInstance
13
NameService_4
1
28
Siemens_AG/NetMPeerGR-WMSIS2
19
EmsSessionFactory_I
380
IOR:010000003f00000049444c3a6d746e6d2e746d666f72756d2e6f72672f656d7353657373696f6e466163746f72792f456d7353657373696f6e466163746f72795f493a312e300000010000000000000068000000010102000d0000004e4d363234574f4d53495332002af82a1b00000014010f0052535451e27344449508000100000001000000020000007602000000000000000800000001c80604004f4154010000001400000001c8060401000100000000000901010000000000