4 May
2011
4 May
'11
8:18 p.m.
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(a)gmail.com> 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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user