design problem, a general message passing class

[Ethan]

the problem is to hide transport layer (tcp, raw ip, tibco, etc ) from
applications

I am thinking of to have a transceiver interface (abstract class),
which shall define some operations and callbacks.
The interface shall be sufficient for common communication task over
networks. different implementations, e.g. TcpTransceiver will be
derived from this interface.

user apps will only need to know this interface, completely separate
itself from the underlying technology.

I have little experience on this, I am looking for inputs on how the
interface should look like
I can think of some virtual functions, such as

sendMsg,
initConnection,
connectTo,

callbacks that users have to implement, such as onAccept, onConnect,
onReceive etc.
anything else?

also, it's nice to be able to support unicast and multicast
transparently too.

any idea? thanks!!

 

[AnonMail2005]

the problem is to hide transport layer (tcp, raw ip, tibco, etc ) from
applications

I am thinking of to have a transceiver interface (abstract class),
which shall define some operations and callbacks.
The interface shall be sufficient for common communication task over
networks. different implementations, e.g. TcpTransceiver will be
derived from this interface.

user apps will only need to know this interface, completely separate
itself from the underlying technology.

I have little experience on this, I am looking for inputs on how the
interface should look like
I can think of some virtual functions, such as

sendMsg,
initConnection,
connectTo,

callbacks that users have to implement, such as onAccept, onConnect,
onReceive etc.
anything else?

also, it's nice to be able to support unicast and multicast
transparently too.

any idea? thanks!!

--

Check out asio in boost. It probably has most of what you need. And
I believe it's extensible so you can add commercial "transports" like
tibco.

HTH

 

[Maxim Yegorushkin]

the problem is to hide transport layer (tcp, raw ip, tibco, etc ) from
applications

I am thinking of to have a transceiver interface (abstract class),
which shall define some operations and callbacks.
The interface shall be sufficient for common communication task over
networks. different implementations, e.g. TcpTransceiver will be
derived from this interface.

user apps will only need to know this interface, completely separate
itself from the underlying technology.

I have little experience on this, I am looking for inputs on how the
interface should look like
I can think of some virtual functions, such as

sendMsg,
initConnection,
connectTo,

callbacks that users have to implement, such as onAccept, onConnect,
onReceive etc.
anything else?

also, it's nice to be able to support unicast and multicast
transparently too.

You can achieve this quite easily using design based on interfaces and message
passing. In this particular case Bridge design pattern is what you need. Example:

struct MsgX { ... };
struct MsgY { ... };

struct Connection
{
struct Callback
{
virtual void connected(Connection*) = 0;
virtual void receive(MsgX) = 0;
virtual void receive(MsgY) = 0;
virtual void disconnected(Connection*, int err) = 0;

protected: // no polymorphic destruction required
~Callback() {}
};

virtual void send(MsgX) = 0;
virtual void send(MsgY) = 0;
virtual ~Connection() = 0;
};

std::auto_ptr<Connection> createTcpConnection(Connection::Callback* callback,
char const* host_port);
std::auto_ptr<Connection> createWhateverConnection(Connection::Callback*
callback, ...);

In this design Connection interface represents a connection. Factory functions
createTcpConnection() and createWhateverConnection() create an instance of a
(hidden) class which implements Connection interface. Normally, these factory
functions along with particular classes that implement Connection interface are
implemented by a shared library. That shared library only exposes the factory
functions.

Interface Connection::Callback is implemented by an application that uses
Connection. An application creates an object of a class that implements
Connection::Callback interface and passes the pointer to that object to one of
the Connection factory functions.

This way you achieve good decoupling between connection and its user
implementations, which is the essence of Bridge design pattern.

For simplicity, the server/acceptor interface and factory functions are not
shown here, but they would use the same design pattern.

--
Max



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Tony]

the problem is to hide transport layer (tcp, raw ip, tibco, etc ) from
applications

I am thinking of to have a transceiver interface (abstract class),
which shall define some operations and callbacks.
The interface shall be sufficient for common communication task over
networks. different implementations, e.g. TcpTransceiver will be
derived from this interface.

user apps will only need to know this interface, completely separate
itself from the underlying technology.

I have little experience on this, I am looking for inputs on how the
interface should look like
I can think of some virtual functions, such as

sendMsg,
initConnection,
connectTo,

callbacks that users have to implement, such as onAccept, onConnect,
onReceive etc.
anything else?

also, it's nice to be able to support unicast and multicast
transparently too.

any idea? thanks!!

Maybe this will help:

http://www.cs.wustl.edu/~schmidt/ACE.html

or maybe this:

http://qpid.apache.org/