[Pharo-dev] Tests with multiple processes

Igor Stasenko siguctua at gmail.com
Tue Oct 29 10:41:05 EDT 2013

On 29 October 2013 02:08, David T. Lewis <lewis at 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
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
Not going to happen with bidirectional model, A will still send two very
same packets to same proxy.. but with different destination

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131029/382ad22b/attachment-0002.html>

More information about the Pharo-dev mailing list