linuxaudio.org

On Wed, May 04, 2011 at 09:53:59AM -0400, Paul Davis wrote:

quoted text
> On Wed, May 4, 2011 at 9:38 AM, Lieven Moors  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).

Thanks! That cleared things up for me.
For now, I think we're good.
Of course, on a professional level, we already have lots of possible

race conditions, but let's just see how far we get with what we have...
As I see it, we can get the necessary info, in order to control an OSC

app (type-signatures, documentation), and start sending out the right

messages in a convenient way. The next step would be to make a

pseudographical interface that would update itself continually with

#current-value queries. But as you say, OSC might not be sufficient

to do that in a reliable way.
BTW: liblo seems to make it very easy to use TCP...
Thanks again for your advice in this,
lieven
_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-user