4 May
2011
4 May
'11
4:50 p.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(a)gmail.com> wrote:
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
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).