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. -- Best regards, Igor Stasenko.
