On 29 October 2013 02:08, David T. Lewis <lewis@mail.msen.com> wrote:

I have some experience with this, not related to Smalltalk but maybe
still relevant. I have worked with systems that were designed around
networked message passing, implemented on platforms like MS-DOS with time
slicing kernels, Series I, OS/2, etc. These systems were designed to operate
with asynchronous message passing protocols. The asynchronous designs were
intended to support primitive OS environments, including MS-DOS with
software interrupts for multitasking.

These are production-critical manufacturing applications, and in the course
of modernizing them I have reimplemented the network protocols in Java and
moved them to new computing platforms. Along the way I have found that the
asynchronous designs could always be replaced by bidirectional send-receive
transactions running in the context of a thread or process. Even the systems
that appeared to be most complex have turned out to work perfectly well
when modeled as synchronous send-receive transactions on a bidirectional
communication channel. The software is much simpler to understand and debug
when structured in this manner.

My conclusion is that designing around asynchronous, loosely coupled
channels sounds like a good idea, but in practice it leads to unnecessary
complexity, and to systems that are difficult to debug and support.

$0.02

Dave

Example from my life: real-time voice over IP project.

From very starting, it was designed as a bidirectional connection between two peers.

Even though, that outgoing/incoming traffic was handled separately, the model was still there
and treated as 'single conversation channel'.

Later we wanted to introduce many-peer conversation and found that the above bi-directional model simply

does not fits.. everything falls apart.

Simple example: you have 3 peers A, B , C.
So, you can represent is in this way:
�� A<->B , A<->C , B<->C,

or this:

�� A -> (B,C)

�� B -> (A, C)

�� C -> (A,B)

The bidirectional model implies that you have symmetry in number of outgoing and incoming channels (hence <->)..

and if you send data over one of them, only single node will receive it.

Logically, that leads to sending same data to two different channels. So, at very beginning you nailing down

how the traffic is going to flow.

With unidirectional model, as illustrated when you sending data over one channel,
it will be delivered to all participants, and you don't have to do it yourself - the transport layer handles it for you.

The thing is, that the way how data gets to receivers is heavily depends on network topology:

imagine that two peers, B, C belong to same subnet, and latency between them is miniscule comparing
to latency between A and one of them. The logical choice then should be to route the signal from A
to either B or C and then broadcast from middle point to the listener which is left.

Not possible with bidirectional model, because A insists on having direct socket connection with both B and C.

Same goes for proxies: imagine that node A is connected via proxy..
and not directly to nodes B and C.. that means that to deliver its voice traffic to both of them it should
just send a single packet to proxy, and then proxy will broadcast it to listeners.

Not going to happen with bidirectional model, A will still send two very same packets to same proxy.. but with different destination
address.

Or even, it could be, that receiving traffic from A to C goes faster via B,

while sending traffic from C to A is faster to do directly..

So try to fit that into bidirectional model of communication and see where it goes.

Yes, i agree it is easier to put everything into sequential bidirectional model which makes everything so simple.
If it fits. But if its not, you should not even try to fit it..

My point is, that IP is inherently asynchronous and unidirectional.

--
Best regards,
Igor Stasenko.