This page presents the source code for a C++ server that implements our file system and communicates with the client we wrote earlier. The code is fully functional, apart from the required interlocking for threads.

The server is remarkably free of code that relates to distribution: most of the server code is simply application logic that would be present just the same for a non-distributed version. Again, this is one of the major advantages of Ice: distribution concerns are kept away from application code so that you can concentrate on developing application logic instead of networking infrastructure.

On this page:

Implementing a File System Server in C++

We have now seen enough of the server-side C++ mapping to implement a server for our file system. (You may find it useful to review these Slice definitions before studying the source code.)

Our server is composed of two source files:

Server.cpp
This file contains the server main program.

FilesystemI.cpp
This file contains the implementation for the file system servants.
Back to Top ^

Server `main` Program in C++

Our server main program, in the file Server.cpp, consists of two functions, main and run. main creates and destroys an Ice communicator, and run uses this communicator instantiate our file system objects:

C++

#include <Ice/Ice.h>
#include <FilesystemI.h>

using namespace std;
using namespace Filesystem;

int run();

//
// Global variable for shutdownCommunicator
//
Ice::CommunicatorPtr communicator;

//
// Callback for CtrlCHandler
//
void
shutdownCommunicator(int)
{
    communicator->shutdown();
    cerr << "received signal, shutting down" << endl;
}

int
main(int argc, char* argv[])
{
    int status = 0;

    try
    {
        //
        // CtrlCHandler must be created before the communicator or any other threads are started
        //
        Ice::CtrlCHandler ctrlCHandler;

        //
        // CommunicatorHolder's ctor initializes an Ice communicator,
        // and it's dtor destroys this communicator.
        //
        Ice::CommunicatorHolder ich(argc, argv);
        communicator = ich.communicator();

        //
        // Shutdown communicator on Ctrl-C
        //
        ctrlCHandler.setCallback(&shutdownCommunicator);

        //
        // The communicator initialization removes all Ice-related arguments from argc/argv
        //
        if(argc > 1)
        {
            cerr << argv[0] << ": too many arguments" << endl;
            status = 1;
        }
        else
        {
            status = run();
        }
    }
    catch(const std::exception& ex)
    {
        cerr << ex.what() << endl;
        status = 1;
    }

    return status;
}

int
run()
{
    //
    // Create an object adapter.
    //
    Ice::ObjectAdapterPtr adapter =
        communicator->createObjectAdapterWithEndpoints("SimpleFilesystem", "default -h localhost -p 10000");

    //
    // Create the root directory (with name "/" and no parent)
    //
    DirectoryIPtr root = new DirectoryI("/", 0);
    root->activate(adapter);

    //
    // Create a file called "README" in the root directory
    //
    FileIPtr file = new FileI("README", root);
    Lines text;
    text.push_back("This file system contains a collection of poetry.");
    file->write(text);
    file->activate(adapter);

    //
    // Create a directory called "Coleridge" in the root directory
    //
    DirectoryIPtr coleridge = new DirectoryI("Coleridge", root);
    coleridge->activate(adapter);

    //
    // Create a file called "Kubla_Khan" in the Coleridge directory
    //
    file = new FileI("Kubla_Khan", coleridge);
    text.erase(text.begin(), text.end());
    text.push_back("In Xanadu did Kubla Khan");
    text.push_back("A stately pleasure-dome decree:");
    text.push_back("Where Alph, the sacred river, ran");
    text.push_back("Through caverns measureless to man");
    text.push_back("Down to a sunless sea.");
    file->write(text);
    file->activate(adapter);

    //
    // All objects are created, allow client requests now
    //
    adapter->activate();

    //
    // Wait until we are done
    //
    communicator->waitForShutdown();
    return 0;
}

There is quite a bit of code here, so let us examine each section in detail:

C++

#include <Ice/Ice.h>
#include <FilesystemI.h>

using namespace std;
using namespace Filesystem;

The code includes the header file FilesystemI.h. That file includes the header file that is generated by the Slice compiler, Filesystem.h.

Two using declarations, for the namespaces std and Filesystem, permit us to be a little less verbose in the source code.

The next part of the source code is the main function:

C++

    try
    {
        //
        // CtrlCHandler must be created before the communicator or any other threads are started
        //
        Ice::CtrlCHandler ctrlCHandler;

        //
        // CommunicatorHolder's ctor initializes an Ice communicator,
        // and it's dtor destroys this communicator.
        //
        Ice::CommunicatorHolder ich(argc, argv);
        communicator = ich.communicator();

        //
        // Shutdown communicator on Ctrl-C
        //
        ctrlCHandler.setCallback(&shutdownCommunicator);
        ...

We create a CtrlCHandler object which allows us to catch CTRL-C and similar signals in a portable fashion in C++. When the server receives such a signal, it shuts down the communicator. Shutting down the communicator in turn makes waitForShutdown return.

main later calls run, which is typically blocked on waitForShutdown:

C++

int
run()
{
    //
    // Create an object adapter.
    //
    Ice::ObjectAdapterPtr adapter = communicator->createObjectAdapterWithEndpoints(
        "SimpleFilesystem", "default -h localhost -p 10000");

    ...    
 

    //
    // All objects are created, allow client requests now
    //
    adapter->activate();

    //
    // Wait until we are done
    //
    communicator->waitForShutdown();

    return 0;
}

Much of this code is boiler plate that we saw previously: we create an object adapter, and, towards the end, activate the object adapter and call waitForShutdown.

The interesting part of the code follows the adapter creation: here, the server instantiates a few nodes for our file system to create the structure shown below:

A small file system.

As we will see shortly, the servants for our directories and files are of type DirectoryI and FileI, respectively. The constructor for either type of servant accepts three parameters: the communicator, the name of the directory or file to be created, and a handle to the servant for the parent directory. (For the root directory, which has no parent, we pass a null parent handle.) Thus, the statement

C++

DirectoryIPtr root = new DirectoryI(communicator(), "/", 0);

creates the root directory, with the name "/" and no parent directory. Note that we use the smart pointer class to hold the return value from new; that way, we avoid any memory management issues. The types DirectoryIPtr and FileIPtr are defined as follows in a header file FilesystemI.h:

C++

typedef IceUtil::Handle<DirectoryI> DirectoryIPtr;
typedef IceUtil::Handle<FileI> FileIPtr;

Here is the code that establishes the structure in the illustration above.

C++

        // Create the root directory (with name "/" and no parent)
        //
        DirectoryIPtr root = new DirectoryI(communicator(), "/", 0);
        root->activate(adapter);

        // Create a file called "README" in the root directory
        //
        FileIPtr file = new FileI(communicator(), "README", root);
        Lines text;
        text.push_back("This file system contains a collection of poetry.");
        file->write(text);
        file->activate(adapter);

        // Create a directory called "Coleridge"
        // in the root directory
        //
        DirectoryIPtr coleridge = new DirectoryI(communicator(), "Coleridge", root);
        coleridge->activate(adapter);

        // Create a file called "Kubla_Khan"
        // in the Coleridge directory
        //
        file = new FileI(communicator(), "Kubla_Khan", coleridge);
        text.erase(text.begin(), text.end());
        text.push_back("In Xanadu did Kubla Khan");
        text.push_back("A stately pleasure-dome decree:");
        text.push_back("Where Alph, the sacred river, ran");
        text.push_back("Through caverns measureless to man");
        text.push_back("Down to a sunless sea.");
        file->write(text);
        file->activate(adapter);

We first create the root directory and a file README within the root directory. (Note that we pass the handle to the root directory as the parent pointer when we create the new node of type FileI.)

After creating each servant, the code calls activate on the servant. (We will see the definition of this member function shortly.) The activate member function adds the servant to the ASM.

The next step is to fill the file with text:

C++

        FileIPtr file = new FileI(communicator(), "README", root);
        Lines text;
        text.push_back("This file system contains a collection of poetry.");
        file->write(text);
        file->activate(adapter);

Recall that Slice sequences map to STL vectors. The Slice type Lines is a sequence of strings, so the C++ type Lines is a vector of strings; we add a line of text to our README file by calling push_back on that vector.

Finally, we call the Slice write operation on our FileI servant by simply writing:

C++

        file->write(text);

This statement is interesting: the server code invokes an operation on one of its own servants. Because the call happens via a smart class pointer (of type FilePtr) and not via a proxy (of type FilePrx), the Ice run time does not know that this call is even taking place — such a direct call into a servant is not mediated by the Ice run time in any way and is dispatched as an ordinary C++ function call.

In similar fashion, the remainder of the code creates a subdirectory called Coleridge and, within that directory, a file called Kubla_Khan to complete the structure in the above illustration.

Back to Top ^

Servant Class Definitions in C++

We must provide servants for the concrete interfaces in our Slice specification, that is, we must provide servants for the File and Directory interfaces in the C++ classes FileI and DirectoryI. This means that our servant classes might look as follows:

C++

namespace Filesystem 
{
    class FileI : public virtual File 
    {
      // ...
    };

    class DirectoryI : public virtual Directory 
    {
       // ...
    };
}

This leads to the C++ class structure as shown:

File system servants using interface inheritance.

The shaded classes in the illustration above are skeleton classes and the unshaded classes are our servant implementations. If we implement our servants like this, FileI must implement the pure virtual operations it inherits from the File skeleton (read and write), as well as the operation it inherits from the Node skeleton (name). Similarly, DirectoryI must implement the pure virtual function it inherits from the Directory skeleton (list), as well as the operation it inherits from the Node skeleton (name). Implementing the servants in this way uses interface inheritance from Node because no implementation code is inherited from that class.

Alternatively, we can implement our servants using the following definitions:

C++

namespace Filesystem 
{
    class NodeI : public virtual Node 
    {
      // ...
    };

    class FileI : public virtual File, public virtual NodeI
    {
      // ...
    };

    class DirectoryI : public virtual Directory, public virtual NodeI
    {
      // ...
    };
}

This leads to the C++ class structure shown:

File system servants using implementation inheritance.

In this implementation, NodeI is a concrete base class that implements the name operation it inherits from the Node skeleton. FileI and DirectoryI use multiple inheritance from NodeI and their respective skeletons, that is, FileI and DirectoryI use implementation inheritance from their NodeI base class.

Either implementation approach is equally valid. Which one to choose simply depends on whether we want to re-use common code provided by NodeI. For the implementation that follows, we have chosen the second approach, using implementation inheritance.

Given the structure in the above illustration and the operations we have defined in the Slice definition for our file system, we can add these operations to the class definition for our servants:

C++

namespace Filesystem 
{
    class NodeI : public virtual Node
    {
    public:
        virtual std::string name(const Ice::Current&);
    };
  
    class FileI : public virtual File, public virtual NodeI
    {
    public:
        virtual Lines read(const Ice::Current&);
        virtual void write(const Lines&, const Ice::Current&);
    };
  
    class DirectoryI : public virtual Directory, public virtual NodeI 
    {
    public:
        virtual NodeSeq list(const Ice::Current&);
    };
}

This simply adds signatures for the operation implementations to each class. Note that the signatures must exactly match the operation signatures in the generated skeleton classes — if they do not match exactly, you end up overloading the pure virtual function in the base class instead of overriding it, meaning that the servant class cannot be instantiated because it will still be abstract. To avoid signature mismatches, you can copy the signatures from the generated header file (Filesystem.h), or you can use the --impl option with slice2cpp to generate header and implementation files that you can add your application code to.

Now that we have the basic structure in place, we need to think about other methods and data members we need to support our servant implementation. Typically, each servant class hides the copy constructor and assignment operator, and has a constructor to provide initial state for its data members. Given that all nodes in our file system have both a name and a parent directory, this suggests that the NodeI class should implement the functionality relating to tracking the name of each node, as well as the parent-child relationships:

C++

namespace Filesystem
{
    class DirectoryI;
    typedef IceUtil::Handle<DirectoryI> DirectoryIPtr;

    class NodeI : public virtual Node 
    {
    public:
        virtual std::string name(const Ice::Current&);
        NodeI(const Ice::CommunicatorPtr&, const std::string&, const DirectoryIPtr&);
        void activate(const Ice::ObjectAdapterPtr&);
    private:
        std::string _name;
        Ice::Identity _id;
        DirectoryIPtr _parent;
        NodeI(const NodeI&);                // Copy forbidden
        void operator=(const NodeI&);       // Assignment forbidden
    };
}

The NodeI class has a private data member to store its name (of type std::string) and its parent directory (of type DirectoryIPtr). The constructor accepts parameters that set the value of these data members. For the root directory, by convention, we pass a null handle to the constructor to indicate that the root directory has no parent. The constructor also requires the communicator to be passed to it. This is necessary because the constructor creates the identity for the servant, which requires access to the communicator. The activate member function adds the servant to the ASM (which requires access to the object adapter) and connects the child to its parent.

The FileI servant class must store the contents of its file, so it requires a data member for this. We can conveniently use the generated Lines type (which is a std::vector<std::string>) to hold the file contents, one string for each line. Because FileI inherits from NodeI, it also requires a constructor that accepts the communicator, file name, and parent directory, leading to the following class definition:

C++

namespace Filesystem 
{
    class FileI : public virtual File, public virtual NodeI 
    {
    public:
        virtual Lines read(const Ice::Current&);
        virtual void write(const Lines&, const Ice::Current&);
        FileI(const Ice::CommunicatorPtr&, const std::string&, const DirectoryIPtr&);
    private:
        Lines _lines;
    };
}

For directories, each directory must store its list of child notes. We can conveniently use the generated NodeSeq type (which is a vector<NodePrx>) to do this. Because DirectoryI inherits from NodeI, we need to add a constructor to initialize the directory name and its parent directory. As we will see shortly, we also need a private helper function, addChild, to make it easier to connect a newly created directory to its parent. This leads to the following class definition:

C++

namespace Filesystem 
{
    class DirectoryI : public virtual Directory, public virtual NodeI 
    {
    public:
        virtual NodeSeq list(const Ice::Current&) const;
        DirectoryI(const Ice::CommunicatorPtr&, const std::string&, const DirectoryIPtr&);
        void addChild(NodePrx child);
    private:
        NodeSeq _contents;
    };
}

Back to Top ^

Servant Header File Example

Putting all this together, we end up with a servant header file, FilesystemI.h, as follows:

C++

#include <Ice/Ice.h>
#include <Filesystem.h>

namespace Filesystem 
{
    class DirectoryI;
    typedef IceUtil::Handle<DirectoryI> DirectoryIPtr;
  
    class NodeI : public virtual Node 
    {
    public:
        virtual std::string name(const Ice::Current&);
        NodeI(const Ice::CommunicatorPtr&, const std::string&, const DirectoryIPtr&);
        void activate(const Ice::ObjectAdapterPtr&);
    private:
        std::string _name;
        Ice::Identity _id;
        DirectoryIPtr _parent;
        NodeI(const NodeI&);            // Copy forbidden
        void operator=(const NodeI&);   // Assignment forbidden
    };
  
    typedef IceUtil::Handle<NodeI> NodeIPtr;

    class FileI : public virtual File, public virtual NodeI
    {
    public:
        virtual Lines read(const Ice::Current&);
        virtual void write(const Lines&, const Ice::Current& = Ice::emptyCurrent);
        FileI(const Ice::CommunicatorPtr&, const std::string&, const DirectoryIPtr&);
    private:
        Lines _lines;
    };
  
    typedef IceUtil::Handle<FileI> FileIPtr;

    class DirectoryI : public virtual Directory, public virtual NodeI
    {
    public:
        virtual NodeSeq list(const Ice::Current&);
        DirectoryI(const Ice::CommunicatorPtr&, const std::string&, const DirectoryIPtr&);
        void addChild(const Filesystem::NodePrx&);
    private:
        Filesystem::NodeSeq _contents;
    };
}

Back to Top ^

The Servant Implementation in C++

The implementation of our servants is mostly trivial, following from the class definitions in our FilesystemI.h header file.

Implementing `FileI`

The implementation of the read and write operations for files is trivial: we simply store the passed file contents in the _lines data member. The constructor is equally trivial, simply passing its arguments through to the NodeI base class constructor:

C++

Filesystem::Lines
Filesystem::FileI::read(const Ice::Current&)
{
    return _lines;
}

void
Filesystem::FileI::write(const Filesystem::Lines& text, const Ice::Current&)
{
    _lines = text;
}

Filesystem::FileI::FileI(const Ice::CommunicatorPtr& communicator,
                         const string& name,
                         const DirectoryIPtr& parent)
    : NodeI(communicator, name, parent)
{
}

Back to Top ^

Implementing `DirectoryI`

The implementation of DirectoryI is equally trivial: the list operation simply returns the _contents data member and the constructor passes its arguments through to the NodeI base class constructor:

C++

Filesystem::NodeSeq
Filesystem::DirectoryI::list(const Ice::Current&)
{
    return _contents;
}

Filesystem::DirectoryI::DirectoryI(const Ice::CommunicatorPtr& communicator,
                                   const string& name,
                                   const DirectoryIPtr& parent)
    : NodeI(name, parent)
{
}

void
Filesystem::DirectoryI::addChild(const NodePrx child)
{
    _contents.push_back(child);
}

The only noteworthy thing is the implementation of addChild: when a new directory or file is created, the constructor of the NodeI base class calls addChild on its own parent, passing it the proxy to the newly-created child. The implementation of addChild appends the passed reference to the contents list of the directory it is invoked on (which is the parent directory).

Back to Top ^

Implementing `NodeI`

The name operation of our NodeI class is again trivial: it simply returns the _name data member:

C++

std::string
Filesystem::NodeI::name(const Ice::Current&)
{
    return _name;
}

The NodeI constructor creates an identity for the servant:

C++

Filesystem::NodeI::NodeI(const Ice::CommunicatorPtr& communicator,
                         const string& name,
                         const DirectoryIPtr& parent)
    : _name(name), _parent(parent)
{
    _id.name = parent ? IceUtil::generateUUID() : "RootDir";
}

For the root directory, we use the fixed identity "RootDir". This allows the client to create a proxy for the root directory. For directories other than the root directory, we use a UUID as the identity.

Finally, NodeI provides the activate member function that adds the servant to the ASM and connects the child node to its parent directory:

C++

void
Filesystem::NodeI::activate(const Ice::ObjectAdapterPtr& a)
{
    NodePrx thisNode = NodePrx::uncheckedCast(a->add(this, _id));
    if(_parent)
    {
        _parent->addChild(thisNode);
    }
}

This completes our servant implementation. The complete source code is shown here once more:

C++

#include <IceUtil/IceUtil.h>
#include <FilesystemI.h>

using namespace std;

// Slice Node::name() operation

std::string
Filesystem::NodeI::name(const Ice::Current&)
{
    return _name;
}

// NodeI constructor

Filesystem::NodeI::NodeI(const Ice::CommunicatorPtr& communicator,
                         const string& name,
                         const DirectoryIPtr& parent)
    : _name(name), _parent(parent)
{
    // Create an identity. The root directory has the fixed identity "RootDir"
    //
    _id.name = parent ? IceUtil::generateUUID() : "RootDir";
}

// NodeI activate() member function

void
Filesystem::NodeI::activate(const Ice::ObjectAdapterPtr& a)
{
    NodePrx thisNode = NodePrx::uncheckedCast(a->add(this, _id));
    if(_parent)
    {
        _parent->addChild(thisNode);
    }
}

// Slice File::read() operation

Filesystem::Lines
Filesystem::FileI::read(const Ice::Current&)
{
    return _lines;
}

// Slice File::write() operation

void
Filesystem::FileI::write(const Filesystem::Lines& text, const Ice::Current&)
{
    _lines = text;
}

// FileI constructor

Filesystem::FileI::FileI(const Ice::CommunicatorPtr& communicator,
                         const string& name,
                         const DirectoryIPtr& parent)
    : NodeI(communicator, name, parent)
{
}

// Slice Directory::list() operation

Filesystem::NodeSeq
Filesystem::DirectoryI::list(const Ice::Current& c)
{
    return _contents;
}

// DirectoryI constructor

Filesystem::DirectoryI::DirectoryI(const Ice::CommunicatorPtr& communicator,
                                   const string& name,
                                   const DirectoryIPtr& parent)
    : NodeI(communicator, name, parent)
{
}

// addChild is called by the child in order to add
// itself to the _contents member of the parent

void
Filesystem::DirectoryI::addChild(const NodePrx& child)
{
    _contents.push_back(child);
}

Back to Top ^

Example of a File System Server in C++98

Implementing a File System Server in C++

Server `main` Program in C++

Servant Class Definitions in C++

Servant Header File Example

The Servant Implementation in C++

Implementing `FileI`

Implementing `DirectoryI`

Implementing `NodeI`

See Also

Implementing a File System Server in C++

Server main Program in C++

Servant Class Definitions in C++

Servant Header File Example

The Servant Implementation in C++

Implementing FileI

Implementing DirectoryI

Implementing NodeI

See Also

Server `main` Program in C++

Implementing `FileI`

Implementing `DirectoryI`

Implementing `NodeI`