This example shows you how to build a server that listens on multiple ports. The basic structure is very similar to the Basic Echo Server
example and you should go and read about that first and have a good understanding of how everything fits together. This document will only cover the differences between the Basic Echo Server
example and this example.
This example is shipped with all licensed versions of The Server Framework and it requires the core server framework libraries (see here
for licensing options). You can always download the latest version of this example from here
; and although you will need the correct libraries to be able to build it you can look at the example code and see how it works and perhaps get ideas from it. A compiled, unicode release, build of this example is available on request if you require it for performance analysis of the framework.
This example shows you how you can share resources between mutliple servers in a single executable and how you can control a group of servers easily using a server collection
. Although the example uses multiple instances of the same server you're more likely to have instances of different server classes; the example should be easy to adjust to such a situation.
The bulk of our
file is the same as normal, however, at the point where we create our server object we introduce a new class.
unsigned short port = commandLine.Port();
commandLine.NoWelcomeMessage() ? "" : "Welcome to echo server 1\r\n",
commandLine.NoWelcomeMessage() ? "" : "Welcome to echo server 2\r\n",
is, as you'd expect, a collection of servers. It implements a list of servers and can either "own" or simply refer to a server. The collection owns a server if it is added by pointer and it will delete the server when the collection goes out of scope. The collection refers to a server if it the server is added by reference and it will not delete the server when the collection goes out of scope.
As you can see from the code, we add multiple instances of our server object to the collection. Each instance shares the same allocators and the same I/O pool. This makes each server pretty light weight. We also use JetByteTools::Socket::CStreamSocketServerEx
as our base class for our server and so we do not incurr the cost of an accept thread per server as we would if we used JetByteTools::Socket::CStreamSocketServer
for more details).
CServerCollection object implements JetByteTools::Socket::IServerControl
which is also implemented by all of our server objects, this allows us to treat our server collection in the same way as a single server. This means that code like the following remains unchanged.
If you have slightly more complex requirements you might find that a named server collection
is more appropriate. This version of the server collection allows you to associate a name with each server that you add, such as "POP3 server", "Secure POP3 server", "Configuration web server" or whatever. You can then retrieve servers by name (to reconfigure them individually, perhaps) or remove them by name.