> On 29 October 2013 02:08, David T. Lewis <le...@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. >
You give an excellent counter example, and I agree with what you are saying. I am reminded of the quote attributed to Einstein, saying that things should be "as simple as possible but no simpler". For the examples that I gave, simple was good enough. But that is not the case for all such problems ;-) Dave
