On Tue, May 03, 2011 at 10:00:16PM -0400, Paul Davis wrote: > On Tue, May 3, 2011 at 8:17 PM, Lieven Moors <lievenmoors@xxxxxxxxx> wrote: > > [ ... ] > > one warning: as you get deeper into this, you are going to run into > one of the more unfortunate aspects of OSC: it is really deeply > unsuited for use as a 2-way protocol. > > That is: it works very nicely when you have a controller that wants to > send a message to a receiver, without expecting a reply. It works very > nicely when you have an "engine" that wants to distribute information > on its state to someone who is listening for such changes. > > But it really starts to break down if you use it for the "send a > message and get a reply". Its not that it breaks down in a deep and > fundamental way, more that it becomes unreliable and requires another > entire almost-a-protocol-itself layer on top of OSC to ensure that you > actually collect the replies etc. etc. It gets even more complex if > the ordering is important. Hi, Paul An important remarque... I would like to understand better why this is the case. I guess the fundamental reason would be that UDP is an unsafe protocol, because it doesn't perform checks on the data sent or received. But would't that make it equally unsafe in both directions? Isn't this just two osc servers that are sending messages towards each other? I would expect to be reasonably sure that the reply makes it from one server to another, just as any other messages would. Wouldn't OSC or liblo be totally broken anyway if I couldn't rely on this sufficiently? I understand what you say, as far as it concerns the ordering of messages, and the convenience of using OSC for this kind of communication, but I'm not sure I understand the rest. greetings, lieven _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
