Re: [Boost-users] [ASIO] Newbie question - Bidirectional communication example

Subject: Re: [Boost-users] [ASIO] Newbie question - Bidirectional communication example
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-02-11 00:44:18

On 10/02/2016 11:05, Davies, John wrote:
> Now I want to put Process 1 and Process 2 on separate computers. My
> intent is to transfer the messages over TCP to the opposite computer
> without changing Process 1 or 2.
>
> So I thought I’d create two connector programs. Connector 1 creates a
> message queue that pretends to be the Process 2 message queue. When it
> gets a message, it send it over TCP the Connector 2. Connector 2 gets
> the message and puts it into the real Process 2 message queue.
>
> And the reverse if Process 2 has an outgoing message.
>
> I just can’t find a good example to steal from. Everything I can find
> are more like Process 1 makes a request and Process 2 responds.
>
> So I think I have a fundamental misunderstanding of how ASIO works.

The thing to decide first is what you want the connection strategy to be 
between the two machines.

A "server" passively waits for a connection; once established, it can 
read from or write back to the other end.

A "client" actively connects to another machine; once established, it 
can read from or write back to the other end.

(In both cases you can read or write in any order, or even concurrently 
-- the examples do it in a particular way due to the application 
protocol that they're demonstrating.)

A server has a particular port that it listens on, but doesn't need to 
know who is going to connect to it.  (Depending how you write it, it can 
handle one connection at a time or multiple.)

A client connects to a particular IP and port, so it does need to know 
what to connect to.  (Again, a client can connect to a single server, or 
multiple servers either in turn or concurrently with separate connections.)

A client can connect, send one message, and disconnect (which is how 
older HTTP works), or it can stay connected and send/receive multiple 
messages (which is how newer HTTP works).  A server can't send anything 
to a client unless the client has left the connection open.

You could design one program to be a server and another to be a client, 
or have one program that contains both a server and a client (although 
this is unusual, because now you need to tell both of them the address 
of the other, and you're effectively "wasting" half the connection of 
each -- but it does make things more symmetric, which is sometimes useful).

Another possibility to consider is to use UDP instead, where there is no 
connection and both ends can just listen for and send messages at any 
time, and messages are already discrete entities instead of being 
smooshed into a continuous stream.  The main downside of this is that 
the maximum data size is smaller and the messages might arrive in a 
different order than sent, or even not at all -- so often you find 
yourself adding acknowledgement mechanisms etc that are already part of TCP.

There are examples for all of these things in ASIO, you just need to 
work out how you want things to behave and then use those as a starting 
point.