On Mon, 13 Nov 2006 10:48:43 +0100, Capstar rearranged some electrons to
form:
> Hi NG,
>
> I'm trying to develop some application that communicate via the network.
> One application (say A) basically sends a command to another (say B),
> which will reply with OK or NOT-OK. This is easy enough.
> The problem is that application B can also send messages on it's on
> initiative to application A. These are events based on actual hardware
> events.
> The requirements I have are that a command-reply sequence is blocking.
> So application A will wait until it gets a reply from application B. If
> an event is received a function should be called on a seperate thread.
>
> However application A will not continuously monitor the socket to see if
> events are received. So I think (pretty sure) that application A should
> have another thread that does monitor the socket continuously and
> notifies the main thread when a reply occurs.
>
> This seems a bit messy to me so I was wondering if there's a standard
> way of dealing with synchronous and asynchronous communication available?
>
> Can anyone give me some tips on how to continue?
> Thank
> Mark
We've done something similar using multiple processess... one to receive
and one to send.
You might also consider using HTTP requests to implement your messaging,
that has worked for us in the past as well.
There are many ways to implement something like this.
http://tldp.org/LDP/lpg/node7.html
http://howtos.linux.com/guides/lpg/node46.shtml
--
David M (dmacchiarolo)
http://home.triad.rr.com/redsled
T/S 53
sled351 Linux 2.4.18-14 has been up 46 days 19:20