Bridge application: Best connectivity solution

[Lorn]

I'm undertaking wriitng a bridge application between a remote data
server API and multiple utility applications which pull and send data
to the API. The reason for a bridge is that the data server limits
connectivity to a single connection/account.

I already have the bridge->API connection functioning and now I need to
begin the multiple utilityApps->bridge connection. I have never
undertaken a task as this and I'm wondering what the best solution for
connecting these multiple apps to the bridge might be? Increasing speed
and minimizing latency is priority number one, so I don't mind doing
extra work to meet that goal.

Can anyone recommend a particular solution that I should consider?
Would a socket based approach be the best path? Thank you very much for
all input.

Lorn

 

[Victor Bazarov]

I'm undertaking wriitng a bridge application between a remote data
server API and multiple utility applications which pull and send data
to the API. The reason for a bridge is that the data server limits
connectivity to a single connection/account.

I already have the bridge->API connection functioning and now I need
to begin the multiple utilityApps->bridge connection. I have never
undertaken a task as this and I'm wondering what the best solution for
connecting these multiple apps to the bridge might be? Increasing
speed and minimizing latency is priority number one, so I don't mind
doing extra work to meet that goal.

Can anyone recommend a particular solution that I should consider?
Would a socket based approach be the best path? Thank you very much
for all input.

Just a thought: since C++ doesn't define sockets or any other networking
or [interprocess] communication mechanisms, you might want to consider
asking in a newsgroup for your OS. Just a thought...

V

 

[Andrew McDonagh]

I'm undertaking wriitng a bridge application between a remote data
server API and multiple utility applications which pull and send data
to the API. The reason for a bridge is that the data server limits
connectivity to a single connection/account.

I already have the bridge->API connection functioning and now I need to
begin the multiple utilityApps->bridge connection. I have never
undertaken a task as this and I'm wondering what the best solution for
connecting these multiple apps to the bridge might be? Increasing speed
and minimizing latency is priority number one, so I don't mind doing
extra work to meet that goal.

Can anyone recommend a particular solution that I should consider?
Would a socket based approach be the best path? Thank you very much for
all input.

Lorn

To keep the one connection/account whilst still allowing multiple
clients to connect, it sounds like the Message Dispatcher pattern is
what you need.

http://www.eaipatterns.com/MessageDispatcher.html

There may be other integration patterns that suit you here.

HTH

Andrew

 

[sandSpiderX]

Hi,

In my view, you should concentrate on data consistency, menaing prepare
good classes which include a bit of error trapping, prepare recovery
and real time statistics functions like speed, number of units
transferred...

communicating with server is just not about using API and sending,,,its
about proper and optimized algorithmic approach...and in C++ you need
to be sure where and how these objects are created and destroyed as it
may very soon lead to heap corruption and memory loss...

sandSpiderX

 

[Lorn]

ok, thank you all for your input. i didn't realize c++ had no native
communication functionalty... i suppose that makes sense as it would
differ per os. anyway, i'll take the suggestions to heart. thanks you
Andrew, for the link. i'm going to try this in the mfc group, as i now
realize it's most likely better suited there.

thanks again,
lorn

 

[Andrew McDonagh]

ok, thank you all for your input. i didn't realize c++ had no native
communication functionalty... i suppose that makes sense as it would
differ per os. anyway, i'll take the suggestions to heart. thanks you
Andrew, for the link. i'm going to try this in the mfc group, as i now
realize it's most likely better suited there.

thanks again,
lorn

No problem.

I'd try comp.software.patterns or comp.software-eng rather than MFC
group - unless you intent to use an MS library to do something.

Regards

Andrew