liblo-devel Mailing List for LibLO

On Tue, Jun 14, 2016 at 10:38 AM, jpff <jp...@co...> wrote:
> Excuse my ignorance but there seems to be no example of setting up
> multicast sending in the source tree.  I looked at the documentation
> and found low-level lo_server_new_multicast and high-level
> lo_address_set_ttl but no indication of how to use.  At present I have
> no call to lo_server_new but lo_server_thread_new -- but no equivalent
> ...new_multicast in the documentation; just found in
> lo_serverthread.h. but missed in earlier grep.  I would appreciate
> advice, if only the "do your homework" response so loved in another
> forum.


No problem.

If you check the "lo_lowlevel.h" API, you'll see the following function:

  lo_server lo_server_new_multicast (const char *group, const char
*port, lo_err_handler err_h)

You can specify as the first parameter a multicast group for the
server to join, as a string containing an IP address.  You can also
use lo_server_new_multicast_iface() if you want control over which
internet NIC is selected for checking for incoming messages.

Alternatively you can use lo_server_new_from_url() and specify the
group as the hostname in the provided URL.

As for sending, you only need to create a lo_address pointed at the IP
address associated with a multicast group.

Additionally, there is lo_address_set/get_ttl():  This sets the "time
to live" integer associated with the number of hops a multicast UDP
message is allowed to survive.  By default it is 1, meaning it should
only bounce to the local router and back.

These functions are all documented at
http://liblo.sourceforge.net/docs/group__liblolowlevel.html

True, it would perhaps be interesting to have a multicast example in
the examples folder.  You should make sure you understand a bit about
the functionality and limitations of using multicast UDP.

Hope that helps!
Steve

Excuse my ignorance but there seems to be no example of setting up
multicast sending in the source tree.  I looked at the documentation
and found low-level lo_server_new_multicast and high-level
lo_address_set_ttl but no indication of how to use.  At present I have
no call to lo_server_new but lo_server_thread_new -- but no equivalent
...new_multicast in the documentation; just found in
lo_serverthread.h. but missed in earlier grep.  I would appreciate
advice, if only the "do your homework" response so loved in another
forum.

==John ffitch

On Wed, Jun 1, 2016 at 2:48 AM, John Paul Adrian Glaubitz
<gla...@ph...> wrote:
> Control: reopen -1
> Control: severity -1 normal
>
>> Closing because liblo is no longer in sparc, and will not be built again there.
>
> Re-opening because in Debian we don't "fix bugs" by sweeping them under the
> carpet. Also, we're currently making sparc64 fit for release and there is
> a very active upstream.

That's a good attitude, currently I don't know anyone using sparc64
with liblo nor do I have access to such a machine, so reproducing and
testing, and therefore fixing, this bug is not possible for me.  So, I
look forward to your contribution.

>> It appears the problem is that in sparc, you can't just say
>> *(datatype*)data. Depending on datatype, 'data' has to be aligned at a
>> certain number of bytes from the original block (4 for int, 8 for
>> int64):
>
> Which is absolutely not specific to SPARC. The moment you are recasting
> a pointer that way, you are leaving the territory of the C99 specification
> which explicitly states that declarations which refer to the same object must
> have compatible types, otherwise the behavior is undefined (C99, 6.2.7/2) [1].

It is a good point.  If you have some examples where this fails it
would be a good contribution to our unit testing.  (testlo.c)

At the moment no one has actually complained about this bug, and
therefore I can only assume it has not actually been encountered and
remains an entirely theoretical bug, but I do welcome ideas for how to
fix it nonetheless, because compatibility with future architectures is
certainly a desirable goal.

> The code in question is therefore buggy and has to be fixed anyway as there
> is otherwise no guarantee it will work on future architectures or compilers.
>
> I'll have a look at this issue, it's a common programming mistake.

Unfortunately one that seems to be baked into the liblo API, but
perhaps there is a way to fix it without sacrificing efficiency, at
least on unaffected architectures.

If not, perhaps it can be fixed in a future API-breaking version of
liblo.  Proposals welcome.

Steve