Re: [liblo] Patch for TCP server

On Mon, Feb 27, 2012 at 3:38 PM, Stephen Sinclair <rad...@gm...>wrote:

> Hi J.,
>
> Nice feedback and great-looking project.  It actually reminds me a
> little of what we're working in my lab, although the goals are
> different, I wonder if there might be some common ground.
>
> Our "big project" with liblo right now is libmapper, a library for
> managing "mapping connections" between programs.  This is a little
> different than session management -- in fact managing restoration of
> state is a current issue for us, so it's nice to see ideas like you
> show in that video, maybe we could use something like that.
>
> Basically libmapper is about having multiple processes that can send
> OSC messages to each other, however instead of each process having to
> know what kinds of messages are valid for one other, the idea is that
> each process announces on a multicast bus what messages they support
> for input and output.  Then we use a GUI to instruct one device to
> start sending messages to another, with some optional transformation
> of the data.  So the devices never actually send their output message,
> instead they transform it to the format required by the destination.
> It's all decentralized and works across networks.  The idea is to
> build up a bit of an ecosystem of libmapper programs for different
> kinds of input devices and audio software, so that any device can be
> mapped to any synthesizer.
>
> Anyways, could be interesting for you, dunno. If you want more info,
> check http://libmapper.org
>

Ha. Yes, I saw that recently. I wasn't aware you were the one working on
it. I actually took a couple of days to implement something similar for Non
(going into the next release). The difference is that I don't use multicast
(peers discover eachother through NSM), and a central authority (NSM)
assigns the symbolic names for each peer. Therefore, all the connections
are internal to the session. I have outputs, inputs, listing, automatic
syncing with notifications of signal ports being destroyed and created,
renamed etc. All signals have range limits and one output can connect to
multiple inputs and inputs receiving signal data from multiple outputs do
additive mixing. So, basically, I'm emulating the exact features I had with
Control Voltage signals over JACK, but in a lower data rate with OSC and
calling it Control Signals.

I think the only things I'm lacking are the formula, and I don't think that
should go in the system anyway, as you could always have a device sit
between two peers and do transformations.

If it weren't for the multicast stuff and the lack of an obvious way to
assign specific peer names by a central authority, I would have probably
just used libmapper... It certainly would have been less trouble, I'm sure.

Anyway, you'll be able to see what I've done in the next release of Non*.
Maybe we can find some ways to bring the two systems together in a
compatible way. IMHO, OSC is practically useless for audio software control
purposes without some kind of signal layer like libmapper provides, so I'm
all for helping its adoption, even if I do seem a little Gung Ho by
implementing my own. It's just usually faster for me to do it myself than
deal with external dependencies.

I'll just have a look through your points...
>
> > 1). Liblo can't automatically assign more than 16 port numbers per
> > nominal second because the random number generation is based on
> > seconds since epoc. I think I've seen patches for this already on the
> > list. I just want to emphasize that a fix should definitely go into
> > the next release because right now I have to throttle server creation
> > to work around it.
>
> Definitely an issue, the code has a big comment saying that it should
> be improved but I never had an issue since I don't use random ports
> very often. Should really at least use a seed based on microseconds or
> something. I'll look back to see what patches have been proposed that
> I might have missed.
>

Just adding + getpid() in the equation would probably fix it. However, I
think one of the patches I saw relied on the OS to assign the port number,
which is probably even better.


> > 2. Bi-directional TCP is lacking, and it would be nice to have.
>
> Main problem here is API.  I'm not sure how it should be done in terms
> of how specific the relationship between a server and address.  There
> were some tentative ideas on the list previously but nothing concrete.
>  Something about lo_address_new_for_server() or something to that
> effect, or maybe lo_server_get_address().. hm. Or maybe
> lo_send_message_from() would be enough to do this.
>

I don't see what lo_send_from couldn't.


>
> > 3. There's no call that I can see in the API to (always) get an IP
> > address out of a lo_address handle.
>
> There is lo_address_get_hostname() which returns a string that could
> be passed into gethostbyname().  It could be nice to add a function
> that returns the already-resolved address, although it would have to
> smoothly handle both IPv4 and IPv6.
>

Specifically, my issue has to do with storing peer addresses in tables and
comparing them with incoming messages. Even just an API function to compare
two lo_addresses would be fine, but I think getting the IP is more general
(and yes I know I'm ignoring NAT and all that stuff).

> 4. I'm not sure that I understand why lo_send can't always behave like
> lo_send_from.

 I'm not sure what you mean here, lo_send() doesn't take the same
> arguments as lo_send_from()?  The idea is to be able to send a message
> that is not associated with a server.
>

You're right. My fault. Let me say it another way: I don't see why
lo_send() should be in the API ;-)


>
> > 5. Multithreading semantics aren't articulated in the documentation.
> > Is it save to call lo_send_from on the same server that's being recv'd
> > on in another thread?
>
> Documentation could be improved.  Personally I'm not a fan of using
> any threading with liblo, I try to keep my liblo calls on the same
> thread, so I never use the lo_server_thread API.
> As for the specific question, lo_send_from() only accesses the
> server's fd, which doesn't change so I can't think of any threading
> issues here.
>

I'm not really talking about lo_server_thread (I don't use it either). Just
about what is threadsafe and what isn't.