liblo-devel Mailing List for LibLO

On Wed, Apr 26, 2017 at 6:03 PM, Erik Ronström <er...@om...> wrote:
> Thanks for your answer!
>
>> You can also avoid threading issues by not using them at all.  If you use the lo_server
>> interface instead of lo_server_thread, no threads will be created, and
>> you can check for new messages using lo_server_recv() or
>> lo_server_recv_noblock().
>
> That’s great advice; I’ll probably go with that solution!
>
> A followup question: if I call lo_server_recv(), it reads and dispatches messages directly, on the same thread. Lets assume a TCP connection from a client, the client sends a message, it is dispatched to a handler, and the handler ”answers” by sending an osc message back to the client. Now, if the client has disconnected, or is busy, or for whatever reason doesn’t read its incoming TCP messages fast enough – would this mean that the message handler in the server would block, when the underlying TCP buffer is full? Would there be any way to prevent this from happening?

I would use UDP whenever you can get away with it, but the TCP
implementation uses buffering during receive.  It doesn't presume that
a single call to recv() is sufficient, and if less than a whole
message is read before it must return, it will not block but leave the
data in a buffer until next time.

The send code is a little less sophisticated, it does indeed loop
until the whole message is transmitted.  Only way around that without
improving liblo is to use threads.

I should mention that there is an open issue in that it is easy to DoS
a liblo server -- you can overload it with messages.  I was working on
it for a while but didn't finish anything significant.

>> There is no way to get the message source without receiving a message
>
> I was thinking that maybe it’s possible to get the client address just from the client *connecting* to the server – but I don’t have enough knowledge of TCP/IP to tell if that would be possible at all.

I see.  If you look in lo_types_internal.h you'll see that the sources
are just an array of lo_address called "sources" in the lo_server data
structure, indexed by socket number.  But there is no public accessor
for this list at the moment.  You could propose one if it seems
useful.  Note that because of how it's indexed not all entries are
valid, so be careful using it.

>> char *url = lo_address_get_url(source);
>> lo_address stored_address = lo_address_new_from_url(url);
>> free(url);
>
> I actually patched liblo with the following function (in address.c):
>
> lo_address lo_address_new_from_copy(lo_address source)
> {
>     lo_address a = calloc(1, sizeof(struct _lo_address));
>     if (!a) return NULL;
>     lo_address_copy(a, source);
>     return a;
> }
>
> I now see that was not necessary :)

I already added a _clone function for messages, perhaps it makes sense
for address too.  Feel free to propose lo_address_clone(), it's likely
more efficient than using an intermediate string.

regards,
Steve

Thanks for your answer!

> You can also avoid threading issues by not using them at all.  If you use the lo_server
> interface instead of lo_server_thread, no threads will be created, and
> you can check for new messages using lo_server_recv() or
> lo_server_recv_noblock().

That’s great advice; I’ll probably go with that solution!

A followup question: if I call lo_server_recv(), it reads and dispatches messages directly, on the same thread. Lets assume a TCP connection from a client, the client sends a message, it is dispatched to a handler, and the handler ”answers” by sending an osc message back to the client. Now, if the client has disconnected, or is busy, or for whatever reason doesn’t read its incoming TCP messages fast enough – would this mean that the message handler in the server would block, when the underlying TCP buffer is full? Would there be any way to prevent this from happening?

> There is no way to get the message source without receiving a message

I was thinking that maybe it’s possible to get the client address just from the client *connecting* to the server – but I don’t have enough knowledge of TCP/IP to tell if that would be possible at all.

> char *url = lo_address_get_url(source);
> lo_address stored_address = lo_address_new_from_url(url);
> free(url);

I actually patched liblo with the following function (in address.c):

lo_address lo_address_new_from_copy(lo_address source)
{
    lo_address a = calloc(1, sizeof(struct _lo_address));
    if (!a) return NULL;
    lo_address_copy(a, source);
    return a;
}

I now see that was not necessary :)

Erik



> 25 apr. 2017 kl. 23:05 skrev Stephen Sinclair <rad...@gm...>:
> 
> On Wed, Apr 19, 2017 at 5:52 AM, Erik Ronström <er...@om...> wrote:
>> Hi all,
>> 
>> I have an OSC server, which ”answers” to incoming osc messages using lo_send_from. But I also need to send notifications to the client about things that don’t originate in incoming osc messages: hardware setup changes etc. So these messages are not sent from the liblo server thread. So far, I have been using a mutex to prevent threading issues, but my questions is if this is really needed, or if there is any way to avoid this setup!
>> 
>> And another question: in the message handlers, I use the following pattern:
>> 
>> int some_handler(const char *path, const char *types, lo_arg ** argv, int argc, lo_message message, void *user_data)
>> {
>>  lo_send_from(lo_message_get_source(message), (lo_server)user_data, LO_TT_IMMEDIATE, …)
>> }
>> 
>> That is, I get the client address from the incoming message using lo_message_get_source. But when sending ”asynchronous” osc messages (i.e. not from a message handler), that is obviously not possible, and so far I have solved this by caching the address in one of the message handlers. That is hardly an optimal solution (for one thing, simply because I can’t send any such messages until that message handler has been called the first time). Is there a better way?
>> 
> 
> Hi, sorry for the delay.  Using a mutex is fine.  You can also avoid
> threading issues by not using them at all.  If you use the lo_server
> interface instead of lo_server_thread, no threads will be created, and
> you can check for new messages using lo_server_recv() or
> lo_server_recv_noblock().  Any incoming messages will be dispatched
> (i.e. the message handlers will be called) before these functions
> return, on the same thread.
> 
> There is no way to get the message source without receiving a message,
> so if you have no alternative way to get the destination where you'd
> like to send a message, then storing the result of
> lo_message_get_source(message) is indeed correct, except that the data
> it points to may be temporary in the handler, so you should make a
> copy using
> 
> char *url = lo_address_get_url(source);
> lo_address stored_address = lo_address_new_from_url(url);
> free(url);
> 
> How you store and organize these addresses (only one, or a queue, or a
> limited array, or an expandable std::vector, etc) is up to you, and
> depends on the use case.
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Wed, Apr 19, 2017 at 5:52 AM, Erik Ronström <er...@om...> wrote:
> Hi all,
>
> I have an OSC server, which ”answers” to incoming osc messages using lo_send_from. But I also need to send notifications to the client about things that don’t originate in incoming osc messages: hardware setup changes etc. So these messages are not sent from the liblo server thread. So far, I have been using a mutex to prevent threading issues, but my questions is if this is really needed, or if there is any way to avoid this setup!
>
> And another question: in the message handlers, I use the following pattern:
>
> int some_handler(const char *path, const char *types, lo_arg ** argv, int argc, lo_message message, void *user_data)
> {
>   lo_send_from(lo_message_get_source(message), (lo_server)user_data, LO_TT_IMMEDIATE, …)
> }
>
> That is, I get the client address from the incoming message using lo_message_get_source. But when sending ”asynchronous” osc messages (i.e. not from a message handler), that is obviously not possible, and so far I have solved this by caching the address in one of the message handlers. That is hardly an optimal solution (for one thing, simply because I can’t send any such messages until that message handler has been called the first time). Is there a better way?
>

Hi, sorry for the delay.  Using a mutex is fine.  You can also avoid
threading issues by not using them at all.  If you use the lo_server
interface instead of lo_server_thread, no threads will be created, and
you can check for new messages using lo_server_recv() or
lo_server_recv_noblock().  Any incoming messages will be dispatched
(i.e. the message handlers will be called) before these functions
return, on the same thread.

There is no way to get the message source without receiving a message,
so if you have no alternative way to get the destination where you'd
like to send a message, then storing the result of
lo_message_get_source(message) is indeed correct, except that the data
it points to may be temporary in the handler, so you should make a
copy using

char *url = lo_address_get_url(source);
lo_address stored_address = lo_address_new_from_url(url);
free(url);

How you store and organize these addresses (only one, or a queue, or a
limited array, or an expandable std::vector, etc) is up to you, and
depends on the use case.

Steve

Hi all,

I have an OSC server, which ”answers” to incoming osc messages using lo_send_from. But I also need to send notifications to the client about things that don’t originate in incoming osc messages: hardware setup changes etc. So these messages are not sent from the liblo server thread. So far, I have been using a mutex to prevent threading issues, but my questions is if this is really needed, or if there is any way to avoid this setup!

And another question: in the message handlers, I use the following pattern:

int some_handler(const char *path, const char *types, lo_arg ** argv, int argc, lo_message message, void *user_data)
{
  lo_send_from(lo_message_get_source(message), (lo_server)user_data, LO_TT_IMMEDIATE, …)
}

That is, I get the client address from the incoming message using lo_message_get_source. But when sending ”asynchronous” osc messages (i.e. not from a message handler), that is obviously not possible, and so far I have solved this by caching the address in one of the message handlers. That is hardly an optimal solution (for one thing, simply because I can’t send any such messages until that message handler has been called the first time). Is there a better way?

Regards
Erik

On Sat, Apr 15, 2017 at 12:10 PM, cristiano piatti
<cri...@gm...> wrote:
> Good morning,
> how can i receive OSC data through UDP from localhost ?
> Could someone please make me an example ?

The basic examples in the "examples" directory do this.  Just run
example_server in one terminal window and example_client in the other.
It is the default behaviour if you pass NULL as the first argument to
lo_address_new.  (For sending.)  To receive, nothing special is
necessary as far as I remember.

Steve

What environment?  We do  it simply in Csound.  So more details please.

⁣Sent from TypeApp ​

On 15 Apr 2017, 16:11, at 16:11, cristiano piatti <cri...@gm...> wrote:
>Good morning,
>how can i receive OSC data through UDP from localhost ?
>Could someone please make me an example ?
>Thanks a lot.
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>_______________________________________________
>liblo-devel mailing list
>lib...@li...
>https://lists.sourceforge.net/lists/listinfo/liblo-devel

Good morning,
how can i receive OSC data through UDP from localhost ?
Could someone please make me an example ?
Thanks a lot.