design problem, a general message passing class

Discussion in 'C++' started by Ethan, Jun 18, 2009.

  1. Ethan

    Ethan Guest

    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!!

    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
    Ethan, Jun 18, 2009
    #1
    1. Advertising

  2. Ethan

    Guest

    On Jun 17, 10:36 pm, Ethan <> wrote:
    > 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


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
    , Jun 18, 2009
    #2
    1. Advertising

  3. Ethan wrote:
    > 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! ]
    Maxim Yegorushkin, Jun 18, 2009
    #3
  4. Ethan

    Tony Guest

    Ethan wrote:
    > 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/


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
    Tony, Jun 19, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    436
    Clint Hill
    Jul 25, 2005
  2. E11
    Replies:
    1
    Views:
    4,742
    Thomas Weidenfeller
    Oct 12, 2005
  3. Mike Oliver
    Replies:
    0
    Views:
    394
    Mike Oliver
    Feb 1, 2011
  4. Kurt Hill
    Replies:
    2
    Views:
    93
    Mark Schupp
    Dec 31, 2003
  5. michaaal
    Replies:
    2
    Views:
    98
    michaaal
    May 18, 2004
Loading...

Share This Page