# OOP Network Layer

This topic is 4646 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm working on a network layer for Winsock TCP (could be extended to any protocol), and this is the design I've come up with so far:
class INetwork
{
public:
virtual ~INetwork() {}

static const char * GetFactoryName()
{
return "CreateNetwork";
}

virtual bool Initialize(HWND) = 0;
virtual bool Shutdown() = 0;

virtual void ProcessEvents() = 0;

virtual IConnector * CreateConnector() = 0;
};

class IConnector
{
public:
class Callback
{
public:
virtual void OnConnectSuccess(IConnection *) = 0;
virtual void OnConnectError(const string & error) = 0;
};

public:
virtual ~IConnector() {}

virtual void BindCallback(Callback * callback) = 0;

virtual bool Connect(const char * ip, u16 port) = 0;
virtual bool Listen(u16 port) = 0;
};

class IConnection
{
public:
class Callback
{
public:
virtual void OnDisconnect() = 0;
};

public:
virtual ~IConnection() {}

virtual void BindCallback(Callback * callback) = 0;

virtual void Disconnect() = 0;
};

You'd create an INetwork and call Initialize, then to actually get stuff happening, you'd call INetwork::CreateConnector(). At this point, you'd BindCallback() to some user-defined object which implements the IConnector::Callback interface. Upon connection completion, OnConnectSuccess is called, and a new IConnection object is provided. Connection errors cause an OnConnectError with the reason for failure. Once you have an IConnection, you'd bind it to an IConnection::Callback-derived object, which (at this point) handles disconnection events. I'm wondering if this design could be improved (or completely rewritten [grin]). Are there any glaring mistakes in the design that I've missed?

##### Share on other sites
Well, one thing that seems to be missing is... How does one send and receive stuff over the connection? :) You seem to indicate that it will be included, but without it really there isn't much to judge how easy the thing would be to use.

If you would like to, check out the Wiki for MUD Game Programming book. There, in the downloads section, you will find the Download Sources link, and in the archive there is a folder MUDLibs/SocketLib. The SocketLib thingey is essentially an OO wrapper for sockets that can support different protocols. It is rasonably flexible. You might want to check out that code and compare it to how you thought about implementing it, and think about the merits and drawbacks of either implementation.

##### Share on other sites
I have several qualms about your code. First, why is it an interface? Do you anticipate having different implementations that need to be swapped out at runtime? Secondly, I'd much rather use a functor as a callback rather than having to derive from a base.

##### Share on other sites
Quote:
 Well, one thing that seems to be missing is... How does one send and receive stuff over the connection? :) You seem to indicate that it will be included, but without it really there isn't much to judge how easy the thing would be to use.

This'll be done later, and use the same basic model as the rest.

Quote:
 I have several qualms about your code. First, why is it an interface? Do you anticipate having different implementations that need to be swapped out at runtime?

The network layer is in a DLL.

Quote:
 Secondly, I'd much rather use a functor as a callback rather than having to derive from a base.

Good point. I'll look into that.

##### Share on other sites
It might be worth looking at the designs being worked on for boost in the Boost Wiki (unofficial).

Specifically, Boost.Sockets and Boost.Net (and maybe Boost.Multiplexing) (again, none of these is "official", but they're worth at least looking at)

##### Share on other sites
Is it just the Network Layer you're looking at? And is it the OSI model or TCP/IP model?

I was wondering about how you were going to deal with the other layers, especially as you're using TCP/IP, which refers to the Transport and Session layers IIRC.