Re: design problem, a general message passing class
On Jun 17, 10:36 pm, Ethan <ethan.li...@gmail.com> wrote:
the problem is to hide transport layer (tcp, raw ip, tibco, etc ) from
also, it's nice to be able to support unicast and multicast
any idea? thanks!!
You're a little vague as to exactly what you
are doing. Are you trying to create
a generic communications library? Or
are you implementing a specific protocol on
top of various transport protocols. Or
is there some specific data service,
available over networks, which you're trying
to make available via a client API that
will also handle the networking?
If you're creating a generic comms library,
you'll have the problem that different
transport protocols behave differently.
TCP and UDP, for instance, are very different,
and I don't see how these differences can
be made "transparent" to the application.
Even if you're just writing a client API
(analogous to, say, the Oracle client libraries),
"hiding" the data transport makes life a lot
harder for the application. In my work,
I've had to work with a number of such APIs,
and they were always unsatisfactory. Some
of the problems:
-- inadequate error reporting, or reporting
in a way that was incompatible with our
-- inadequate or non-existent monitoring
-- assumptions about network set-up which demand
special network configurations and extra code
to get around.
-- requirements on system set-up that were
incompatible with the rest of our applications.
(For example, requiring a specific directory
structure, specific files, etc.)
-- interface written assuming an application
structure that was incompatible with our applications.
Not to mention the usual ones: can't compile on
our system, crashes or hangs, can't handle our networks, etc.
I've actually (re-)implemented a "generic" comms
API for our applications at work, but I had the advantage
that I already knew our applications' requirements, I
already knew how we set up networks, and, since I
wrote it, if any new requirements come along, I just
modify the code.
And the API doesn't really hide the transport layer,
it just tries to set up a suite of calls that can be
used either for UDP or for TCP, albeit not always with
the same meaning.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]