Hi, This is interesting; however, I wonder whether it is really relevant to the problem we are trying to solve here. As I understand it, we want to: * Get a list of parameters from the engine in order to populate the interface. * Send parameter changes to the engine. * Listen for parameter changes and other events coming from the engine. There is two-way communication but it does not closely depend on an action-query-response-query-response-action sequence. In other words we are using both schemas Paul described--- sending control events and listening for external events--- without both really needing to be closely linked. Or am I misunderstanding something? Cheers, S.M. On Wed, May 04, 2011 at 09:53:59AM -0400, Paul Davis wrote: > On Wed, May 4, 2011 at 9:38 AM, Lieven Moors <lievenmoors@xxxxxxxxx> wrote: > > > 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? > > there are two issues. one is the issue of UDP not being "reliable". > the other is that OSC messages have no serial number on them. if you > end up sending the same request twice and get two different responses, > you have no idea which one actually came first unless you simply don't > use a reliable transport layer. in that case, the one that arrived > first is the response to the earlier request. but now you've got an > unreliable transport layer. > > > 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? > > if you're using OSC with UDP transport, you have absolutely no > guarantee of this. of course, if you are working with a wired LAN, > this is really deeply unlikely to be an issue. but move into a > wireless LAN let alone WAN configurations and the possibility that a > UDP packet will simply fail to arrive gets high enough that you do > have to take it into consideration. > > the simple answer, of course, is to use OSC over TCP which I *think* > liblo can do (and if it can't, it should be easy to make it). but this > still doesn't address the ordering issue, because OSC itself has no > concept of serial delivery (or even time). > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user -- _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
