liblo-devel Mailing List for LibLO

You should be able to do this with pkg-config.

$ pkg-config --modversion liblo

and so on.

- Steve

On 27 Feb 2009, at 06:25, Mike Wozniewski wrote:

> Hey Steve,
>
> Is there ba way to test the version through the API? eg, can I do
> something like:
>
> #ifdef LO_VERSION_26
> ...
> #else
> ...
> #endif
>
> I would like to check if certain features are implemented and adjust  
> my
> program accordingly.
>
> Thanks,
> Mike
>
> Stephen Sinclair wrote:
>> Hello LibLo community,
>>
>> I just wanted to mention that I'm still planning on doing a 0.26
>> release soon.  One last thing I wanted to tackle before doing it is  
>> to
>> get LibLo compiling with Microsoft Visual Studio.  I've been working
>> on this, but it's taking a little longer than expected.  If I'm still
>> having trouble with it by next week I'll just leave it until 0.27.
>> The reason I wanted to do it right now is in case it happens to
>> require any API breakage, "now is the time" due to the soname update.
>>
>> (So far I haven't required any, though I have a patch waiting which
>> adds a return code to lo_bundle_add_message().  There may be a few
>> other places where memory allocation errors go unreported, so I'm
>> looking out for these..)
>>
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San  
>> Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the  
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source  
>> participation
>> -Receive a $600 discount off the registration fee with the source  
>> code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San  
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the  
> Enterprise
> -Strategies to boost innovation and cut costs with open source  
> participation
> -Receive a $600 discount off the registration fee with the source  
> code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hey Steve,

Is there ba way to test the version through the API? eg, can I do 
something like:

#ifdef LO_VERSION_26
...
#else
...
#endif

I would like to check if certain features are implemented and adjust my 
program accordingly.

Thanks,
Mike

Stephen Sinclair wrote:
> Hello LibLo community,
>
> I just wanted to mention that I'm still planning on doing a 0.26
> release soon.  One last thing I wanted to tackle before doing it is to
> get LibLo compiling with Microsoft Visual Studio.  I've been working
> on this, but it's taking a little longer than expected.  If I'm still
> having trouble with it by next week I'll just leave it until 0.27.
> The reason I wanted to do it right now is in case it happens to
> require any API breakage, "now is the time" due to the soname update.
>
> (So far I haven't required any, though I have a patch waiting which
> adds a return code to lo_bundle_add_message().  There may be a few
> other places where memory allocation errors go unreported, so I'm
> looking out for these..)
>
>
> Steve
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

Hello LibLo community,

I just wanted to mention that I'm still planning on doing a 0.26
release soon.  One last thing I wanted to tackle before doing it is to
get LibLo compiling with Microsoft Visual Studio.  I've been working
on this, but it's taking a little longer than expected.  If I'm still
having trouble with it by next week I'll just leave it until 0.27.
The reason I wanted to do it right now is in case it happens to
require any API breakage, "now is the time" due to the soname update.

(So far I haven't required any, though I have a patch waiting which
adds a return code to lo_bundle_add_message().  There may be a few
other places where memory allocation errors go unreported, so I'm
looking out for these..)


Steve

Hi all,

I guess I should mention one last thing about this topic in case someone 
looks over this thread in the future:

The fix that we did is for multicast only.

For broadcast, there is currently NO way to have 2 liblo processes 
listen on the same port. If someone is interested, then the easiest way 
to support this would be to write an lo_server_thread_new_broadcast() 
method, which would set SO_REUSEADDR and SO_REUSEPORT the same way as 
it's done for multicast. It should be noted that these servers will NOT 
be able to receive packets from unicast senders, so this feature needs 
to be optional. Some people may want to have a single-process 
lo_server_thread that is capable of listening to both broadcast and 
unicast, which is currently supported by liblo using the generic 
lo_server_thread_new() method.

-Mike


Stephen Sinclair wrote:
> I just put this in svn.
>
> Steve
>
> On Tue, Feb 17, 2009 at 1:59 PM, Stephen Sinclair <rad...@gm...> wrote:
>   
>> I'm okay with it if it seems to work for you.
>>
>> Steve
>>
>>
>> On Mon, Feb 16, 2009 at 4:41 PM, Mike Wozniewski <mi...@mi...> wrote:
>>     
>>> Hi Steve,
>>>
>>> I'm back on the SO_REUSEPORT issue, since multicast is not working on
>>> OSX for multiple processes listening on the same port. Note: works in Linux.
>>>
>>> So if possible, can we make a change to src/server.c ??
>>>
>>> Around line 317, where SO_REUSEADDR is set, can we also set SO_REUSEPORT
>>> for platforms that support it? Something like:
>>>
>>> #ifdef SO_REUSEPORT
>>>    setsockopt(s->socket,SOL_SOCKET,SO_REUSEPORT,&yes,sizeof(yes));
>>> #endif
>>>
>>> Let me know if you think this will cause any problems, or if you want an
>>> official patch.
>>>
>>> Thanks in advance,
>>> -Mike
>>>
>>>
>>>
>>> Stephen Sinclair wrote:
>>>       
>>>> On Thu, Feb 12, 2009 at 9:15 PM, Mike Wozniewski <mi...@mi...> wrote:
>>>>
>>>>         
>>>>> Hey Steve,
>>>>>
>>>>> Yeah, it seems like some machines here like SO_REUSEPORT, and some don't :(
>>>>>
>>>>> I'm finding that using broadcast for these types of things is really
>>>>> starting to be a pain, so I think I'm going to ditch it and change
>>>>> everything to multicast. Then I think SO_REUSEADDR is enough.
>>>>>
>>>>> So sorry, no sample code to give you.
>>>>>
>>>>>           
>>>> Cool, well I was going to suggest that, (I think maybe someone
>>>> suggested it previously), but it'd good to make the broadcast
>>>> implementation more robust.  These things just require so much testing
>>>> in many different environments however, it does become difficult to
>>>> find and solve these kinds of problems.
>>>>
>>>> For what it's worth, I've been using OSC-multicast with success,
>>>> though not necessarily always with the liblo implementation.  (Often
>>>> with the Max/MSP mxj objects.)  Please shout if you have trouble with
>>>> it, it hasn't had much testing.
>>>>
>>>>
>>>>
>>>>         
>>>>> However, I did write some simple Pd objects that might be of interest
>>>>> (much better than sendOSC and dumpOSC). You can find them here:
>>>>> http://www.cim.mcgill.ca/sresvn/audioscape/audioscape_resources/pdworks/src/OSCrxtx/
>>>>>
>>>>> The Makefile refers to the global 'pdworks' Makefile, so for ease of
>>>>> compilation, I'd suggest checking out the whole pdworks folder.
>>>>>
>>>>>           
>>>> Cool!
>>>> Have you posted about that on the Pd list?  They might be interested
>>>> to stick it in the Pd externals repository, or if not maybe we could
>>>> include it with LibLo.  (Well, I don't want to put all sorts of things
>>>> in there, but we've got oscsend and oscdump in there now, adding more
>>>> bindings might be interesting.)
>>>>
>>>>
>>>> Steve
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>> -Strategies to boost innovation and cut costs with open source participation
>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>> http://p.sf.net/sfu/XcvMzF8H
>>>> _______________________________________________
>>>> liblo-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>>
>>>>
>>>>         
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>> -Strategies to boost innovation and cut costs with open source participation
>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>       
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

I just put this in svn.

Steve

On Tue, Feb 17, 2009 at 1:59 PM, Stephen Sinclair <rad...@gm...> wrote:
> I'm okay with it if it seems to work for you.
>
> Steve
>
>
> On Mon, Feb 16, 2009 at 4:41 PM, Mike Wozniewski <mi...@mi...> wrote:
>> Hi Steve,
>>
>> I'm back on the SO_REUSEPORT issue, since multicast is not working on
>> OSX for multiple processes listening on the same port. Note: works in Linux.
>>
>> So if possible, can we make a change to src/server.c ??
>>
>> Around line 317, where SO_REUSEADDR is set, can we also set SO_REUSEPORT
>> for platforms that support it? Something like:
>>
>> #ifdef SO_REUSEPORT
>>    setsockopt(s->socket,SOL_SOCKET,SO_REUSEPORT,&yes,sizeof(yes));
>> #endif
>>
>> Let me know if you think this will cause any problems, or if you want an
>> official patch.
>>
>> Thanks in advance,
>> -Mike
>>
>>
>>
>> Stephen Sinclair wrote:
>>> On Thu, Feb 12, 2009 at 9:15 PM, Mike Wozniewski <mi...@mi...> wrote:
>>>
>>>> Hey Steve,
>>>>
>>>> Yeah, it seems like some machines here like SO_REUSEPORT, and some don't :(
>>>>
>>>> I'm finding that using broadcast for these types of things is really
>>>> starting to be a pain, so I think I'm going to ditch it and change
>>>> everything to multicast. Then I think SO_REUSEADDR is enough.
>>>>
>>>> So sorry, no sample code to give you.
>>>>
>>>
>>> Cool, well I was going to suggest that, (I think maybe someone
>>> suggested it previously), but it'd good to make the broadcast
>>> implementation more robust.  These things just require so much testing
>>> in many different environments however, it does become difficult to
>>> find and solve these kinds of problems.
>>>
>>> For what it's worth, I've been using OSC-multicast with success,
>>> though not necessarily always with the liblo implementation.  (Often
>>> with the Max/MSP mxj objects.)  Please shout if you have trouble with
>>> it, it hasn't had much testing.
>>>
>>>
>>>
>>>> However, I did write some simple Pd objects that might be of interest
>>>> (much better than sendOSC and dumpOSC). You can find them here:
>>>> http://www.cim.mcgill.ca/sresvn/audioscape/audioscape_resources/pdworks/src/OSCrxtx/
>>>>
>>>> The Makefile refers to the global 'pdworks' Makefile, so for ease of
>>>> compilation, I'd suggest checking out the whole pdworks folder.
>>>>
>>>
>>> Cool!
>>> Have you posted about that on the Pd list?  They might be interested
>>> to stick it in the Pd externals repository, or if not maybe we could
>>> include it with LibLo.  (Well, I don't want to put all sorts of things
>>> in there, but we've got oscsend and oscdump in there now, adding more
>>> bindings might be interesting.)
>>>
>>>
>>> Steve
>>>
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>> -Strategies to boost innovation and cut costs with open source participation
>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>

Yes. I currently have a modified version of liblo for OSX with this 
modification, and all has been working fine. If it's added to the svn, 
I'd be very appreciative ;)

Do you want an official patch? ... it seems simple enough to just throw 
in there. But don't forget the ifdef, because not all systems have 
SO_REUSEPORT.

-Mike

Stephen Sinclair wrote:
> I'm okay with it if it seems to work for you.
>
> Steve
>
>
> On Mon, Feb 16, 2009 at 4:41 PM, Mike Wozniewski <mi...@mi...> wrote:
>   
>> Hi Steve,
>>
>> I'm back on the SO_REUSEPORT issue, since multicast is not working on
>> OSX for multiple processes listening on the same port. Note: works in Linux.
>>
>> So if possible, can we make a change to src/server.c ??
>>
>> Around line 317, where SO_REUSEADDR is set, can we also set SO_REUSEPORT
>> for platforms that support it? Something like:
>>
>> #ifdef SO_REUSEPORT
>>    setsockopt(s->socket,SOL_SOCKET,SO_REUSEPORT,&yes,sizeof(yes));
>> #endif
>>
>> Let me know if you think this will cause any problems, or if you want an
>> official patch.
>>
>> Thanks in advance,
>> -Mike
>>
>>
>>
>> Stephen Sinclair wrote:
>>     
>>> On Thu, Feb 12, 2009 at 9:15 PM, Mike Wozniewski <mi...@mi...> wrote:
>>>
>>>       
>>>> Hey Steve,
>>>>
>>>> Yeah, it seems like some machines here like SO_REUSEPORT, and some don't :(
>>>>
>>>> I'm finding that using broadcast for these types of things is really
>>>> starting to be a pain, so I think I'm going to ditch it and change
>>>> everything to multicast. Then I think SO_REUSEADDR is enough.
>>>>
>>>> So sorry, no sample code to give you.
>>>>
>>>>         
>>> Cool, well I was going to suggest that, (I think maybe someone
>>> suggested it previously), but it'd good to make the broadcast
>>> implementation more robust.  These things just require so much testing
>>> in many different environments however, it does become difficult to
>>> find and solve these kinds of problems.
>>>
>>> For what it's worth, I've been using OSC-multicast with success,
>>> though not necessarily always with the liblo implementation.  (Often
>>> with the Max/MSP mxj objects.)  Please shout if you have trouble with
>>> it, it hasn't had much testing.
>>>
>>>
>>>
>>>       
>>>> However, I did write some simple Pd objects that might be of interest
>>>> (much better than sendOSC and dumpOSC). You can find them here:
>>>> http://www.cim.mcgill.ca/sresvn/audioscape/audioscape_resources/pdworks/src/OSCrxtx/
>>>>
>>>> The Makefile refers to the global 'pdworks' Makefile, so for ease of
>>>> compilation, I'd suggest checking out the whole pdworks folder.
>>>>
>>>>         
>>> Cool!
>>> Have you posted about that on the Pd list?  They might be interested
>>> to stick it in the Pd externals repository, or if not maybe we could
>>> include it with LibLo.  (Well, I don't want to put all sorts of things
>>> in there, but we've got oscsend and oscdump in there now, adding more
>>> bindings might be interesting.)
>>>
>>>
>>> Steve
>>>
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>> -Strategies to boost innovation and cut costs with open source participation
>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>
>>>       
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>     
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

I'm okay with it if it seems to work for you.

Steve


On Mon, Feb 16, 2009 at 4:41 PM, Mike Wozniewski <mi...@mi...> wrote:
> Hi Steve,
>
> I'm back on the SO_REUSEPORT issue, since multicast is not working on
> OSX for multiple processes listening on the same port. Note: works in Linux.
>
> So if possible, can we make a change to src/server.c ??
>
> Around line 317, where SO_REUSEADDR is set, can we also set SO_REUSEPORT
> for platforms that support it? Something like:
>
> #ifdef SO_REUSEPORT
>    setsockopt(s->socket,SOL_SOCKET,SO_REUSEPORT,&yes,sizeof(yes));
> #endif
>
> Let me know if you think this will cause any problems, or if you want an
> official patch.
>
> Thanks in advance,
> -Mike
>
>
>
> Stephen Sinclair wrote:
>> On Thu, Feb 12, 2009 at 9:15 PM, Mike Wozniewski <mi...@mi...> wrote:
>>
>>> Hey Steve,
>>>
>>> Yeah, it seems like some machines here like SO_REUSEPORT, and some don't :(
>>>
>>> I'm finding that using broadcast for these types of things is really
>>> starting to be a pain, so I think I'm going to ditch it and change
>>> everything to multicast. Then I think SO_REUSEADDR is enough.
>>>
>>> So sorry, no sample code to give you.
>>>
>>
>> Cool, well I was going to suggest that, (I think maybe someone
>> suggested it previously), but it'd good to make the broadcast
>> implementation more robust.  These things just require so much testing
>> in many different environments however, it does become difficult to
>> find and solve these kinds of problems.
>>
>> For what it's worth, I've been using OSC-multicast with success,
>> though not necessarily always with the liblo implementation.  (Often
>> with the Max/MSP mxj objects.)  Please shout if you have trouble with
>> it, it hasn't had much testing.
>>
>>
>>
>>> However, I did write some simple Pd objects that might be of interest
>>> (much better than sendOSC and dumpOSC). You can find them here:
>>> http://www.cim.mcgill.ca/sresvn/audioscape/audioscape_resources/pdworks/src/OSCrxtx/
>>>
>>> The Makefile refers to the global 'pdworks' Makefile, so for ease of
>>> compilation, I'd suggest checking out the whole pdworks folder.
>>>
>>
>> Cool!
>> Have you posted about that on the Pd list?  They might be interested
>> to stick it in the Pd externals repository, or if not maybe we could
>> include it with LibLo.  (Well, I don't want to put all sorts of things
>> in there, but we've got oscsend and oscdump in there now, adding more
>> bindings might be interesting.)
>>
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi Steve,

I'm back on the SO_REUSEPORT issue, since multicast is not working on 
OSX for multiple processes listening on the same port. Note: works in Linux.

So if possible, can we make a change to src/server.c ??

Around line 317, where SO_REUSEADDR is set, can we also set SO_REUSEPORT 
for platforms that support it? Something like:

#ifdef SO_REUSEPORT
    setsockopt(s->socket,SOL_SOCKET,SO_REUSEPORT,&yes,sizeof(yes));
#endif

Let me know if you think this will cause any problems, or if you want an 
official patch.

Thanks in advance,
-Mike



Stephen Sinclair wrote:
> On Thu, Feb 12, 2009 at 9:15 PM, Mike Wozniewski <mi...@mi...> wrote:
>   
>> Hey Steve,
>>
>> Yeah, it seems like some machines here like SO_REUSEPORT, and some don't :(
>>
>> I'm finding that using broadcast for these types of things is really
>> starting to be a pain, so I think I'm going to ditch it and change
>> everything to multicast. Then I think SO_REUSEADDR is enough.
>>
>> So sorry, no sample code to give you.
>>     
>
> Cool, well I was going to suggest that, (I think maybe someone
> suggested it previously), but it'd good to make the broadcast
> implementation more robust.  These things just require so much testing
> in many different environments however, it does become difficult to
> find and solve these kinds of problems.
>
> For what it's worth, I've been using OSC-multicast with success,
> though not necessarily always with the liblo implementation.  (Often
> with the Max/MSP mxj objects.)  Please shout if you have trouble with
> it, it hasn't had much testing.
>
>
>   
>> However, I did write some simple Pd objects that might be of interest
>> (much better than sendOSC and dumpOSC). You can find them here:
>> http://www.cim.mcgill.ca/sresvn/audioscape/audioscape_resources/pdworks/src/OSCrxtx/
>>
>> The Makefile refers to the global 'pdworks' Makefile, so for ease of
>> compilation, I'd suggest checking out the whole pdworks folder.
>>     
>
> Cool!
> Have you posted about that on the Pd list?  They might be interested
> to stick it in the Pd externals repository, or if not maybe we could
> include it with LibLo.  (Well, I don't want to put all sorts of things
> in there, but we've got oscsend and oscdump in there now, adding more
> bindings might be interesting.)
>
>
> Steve
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

On Thu, Feb 12, 2009 at 9:15 PM, Mike Wozniewski <mi...@mi...> wrote:
> Hey Steve,
>
> Yeah, it seems like some machines here like SO_REUSEPORT, and some don't :(
>
> I'm finding that using broadcast for these types of things is really
> starting to be a pain, so I think I'm going to ditch it and change
> everything to multicast. Then I think SO_REUSEADDR is enough.
>
> So sorry, no sample code to give you.

Cool, well I was going to suggest that, (I think maybe someone
suggested it previously), but it'd good to make the broadcast
implementation more robust.  These things just require so much testing
in many different environments however, it does become difficult to
find and solve these kinds of problems.

For what it's worth, I've been using OSC-multicast with success,
though not necessarily always with the liblo implementation.  (Often
with the Max/MSP mxj objects.)  Please shout if you have trouble with
it, it hasn't had much testing.


> However, I did write some simple Pd objects that might be of interest
> (much better than sendOSC and dumpOSC). You can find them here:
> http://www.cim.mcgill.ca/sresvn/audioscape/audioscape_resources/pdworks/src/OSCrxtx/
>
> The Makefile refers to the global 'pdworks' Makefile, so for ease of
> compilation, I'd suggest checking out the whole pdworks folder.

Cool!
Have you posted about that on the Pd list?  They might be interested
to stick it in the Pd externals repository, or if not maybe we could
include it with LibLo.  (Well, I don't want to put all sorts of things
in there, but we've got oscsend and oscdump in there now, adding more
bindings might be interesting.)


Steve

Hey Steve,

Yeah, it seems like some machines here like SO_REUSEPORT, and some don't :(

I'm finding that using broadcast for these types of things is really 
starting to be a pain, so I think I'm going to ditch it and change 
everything to multicast. Then I think SO_REUSEADDR is enough.

So sorry, no sample code to give you.

However, I did write some simple Pd objects that might be of interest 
(much better than sendOSC and dumpOSC). You can find them here:
http://www.cim.mcgill.ca/sresvn/audioscape/audioscape_resources/pdworks/src/OSCrxtx/

The Makefile refers to the global 'pdworks' Makefile, so for ease of 
compilation, I'd suggest checking out the whole pdworks folder.

-Mike


Stephen Sinclair wrote:
> I don't know off hand, but it might have something to do with the
> lo_client_sockets data structure, as you found previously, making it
> not use the expected socket.  Although, if you're setting it
> immediately before bind(), it sounds like the flag is definitely being
> set.  I would try it first with straight socket code and see if it
> works under normal conditions, and then see if anything's different
> when used in liblo.  Do you think you could submit a minimal test
> program (with liblo patch if necessary) showing how it doesn't work,
> so we can be use we're testing the same thing?
>
> You say that multiple processes are binding to this port but only one
> is receiving the data.  SO_REUSEPORT is a pretty esoteric flag, could
> it even be possible that it's a Linux bug?  I'd have to try it with
> dry socket code to be sure nothing in LibLo is confusing things.
>
> Steve
>
>
> On Thu, Feb 12, 2009 at 5:27 PM, Mike Wozniewski <mi...@mi...> wrote:
>   
>> Hey Steve,
>>
>> After some more digging, it seems that the SO_REUSEPORT flag that I want.
>>
>> See: http://www.developerweb.net/forum/archive/index.php/t-2987.html
>>
>> And from the man page:
>>
>>    SO_REUSEPORT allows completely duplicate bindings by multiple processes
>>    if they all set SO_REUSEPORT before binding the port.  This option per-
>>    mits multiple instances of a program to each receive UDP/IP multicast or
>>    broadcast datagrams destined for the bound port.
>>
>> So... this flag allowed me to have 2 liblo processes bind to the same
>> port. I set the flag in server.c, right before:
>> if ((ret = bind(s->socket, used->ai_addr, used->ai_addrlen)) < 0)
>>
>> However, when I send to the port, only the 1st process (in terms of
>> launch order) will see the message. It seems like the buffer gets eaten
>> and data is not available to the 2nd process. This is not what I want,
>> and it shouldn't happen if that flag is set.
>>
>> Can you think of anything in liblo that might be causing this?
>>
>> Thanks,
>> Mike
>>
>>
>>
>> Stephen Sinclair wrote:
>>     
>>> On Tue, Feb 10, 2009 at 9:47 PM, Mike Wozniewski <mi...@mi...> wrote:
>>>
>>>       
>>>> Hi all,
>>>>
>>>> I'd like to have multiple processes listen to the same port using liblo,
>>>> but it seems that the SO_REUSEADDR flag is only set for servers that are
>>>> created by lo_server_new_multicast().
>>>>
>>>> There needs to also be a way to set this flag for addresses receiving
>>>> broadcast messages. The option needs to be set using setsockopt() before
>>>> the bind() in the lo_server_new_with_proto_internal() in server.c.
>>>>
>>>> But how to specify that this should be set? A flag? Maybe a new proto
>>>> value for broadcast?
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks in advance!
>>>> -Mike
>>>>
>>>>         
>>> I'm not super familiar with using broadcast, but are there any cases
>>> where you would _not_ want to set SO_REUSEADDR when SO_BROADCAST is
>>> set?  If not, maybe it should just be set whenever the broadcast IP is
>>> detected.
>>>
>>>
>>> Steve
>>>
>>> ------------------------------------------------------------------------------
>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>> build responsive, highly engaging applications that combine the power of local
>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>
>>>       
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>     
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

I don't know off hand, but it might have something to do with the
lo_client_sockets data structure, as you found previously, making it
not use the expected socket.  Although, if you're setting it
immediately before bind(), it sounds like the flag is definitely being
set.  I would try it first with straight socket code and see if it
works under normal conditions, and then see if anything's different
when used in liblo.  Do you think you could submit a minimal test
program (with liblo patch if necessary) showing how it doesn't work,
so we can be use we're testing the same thing?

You say that multiple processes are binding to this port but only one
is receiving the data.  SO_REUSEPORT is a pretty esoteric flag, could
it even be possible that it's a Linux bug?  I'd have to try it with
dry socket code to be sure nothing in LibLo is confusing things.

Steve


On Thu, Feb 12, 2009 at 5:27 PM, Mike Wozniewski <mi...@mi...> wrote:
> Hey Steve,
>
> After some more digging, it seems that the SO_REUSEPORT flag that I want.
>
> See: http://www.developerweb.net/forum/archive/index.php/t-2987.html
>
> And from the man page:
>
>    SO_REUSEPORT allows completely duplicate bindings by multiple processes
>    if they all set SO_REUSEPORT before binding the port.  This option per-
>    mits multiple instances of a program to each receive UDP/IP multicast or
>    broadcast datagrams destined for the bound port.
>
> So... this flag allowed me to have 2 liblo processes bind to the same
> port. I set the flag in server.c, right before:
> if ((ret = bind(s->socket, used->ai_addr, used->ai_addrlen)) < 0)
>
> However, when I send to the port, only the 1st process (in terms of
> launch order) will see the message. It seems like the buffer gets eaten
> and data is not available to the 2nd process. This is not what I want,
> and it shouldn't happen if that flag is set.
>
> Can you think of anything in liblo that might be causing this?
>
> Thanks,
> Mike
>
>
>
> Stephen Sinclair wrote:
>> On Tue, Feb 10, 2009 at 9:47 PM, Mike Wozniewski <mi...@mi...> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to have multiple processes listen to the same port using liblo,
>>> but it seems that the SO_REUSEADDR flag is only set for servers that are
>>> created by lo_server_new_multicast().
>>>
>>> There needs to also be a way to set this flag for addresses receiving
>>> broadcast messages. The option needs to be set using setsockopt() before
>>> the bind() in the lo_server_new_with_proto_internal() in server.c.
>>>
>>> But how to specify that this should be set? A flag? Maybe a new proto
>>> value for broadcast?
>>>
>>> Any ideas?
>>>
>>> Thanks in advance!
>>> -Mike
>>>
>>
>> I'm not super familiar with using broadcast, but are there any cases
>> where you would _not_ want to set SO_REUSEADDR when SO_BROADCAST is
>> set?  If not, maybe it should just be set whenever the broadcast IP is
>> detected.
>>
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>> build responsive, highly engaging applications that combine the power of local
>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hey Steve,

After some more digging, it seems that the SO_REUSEPORT flag that I want.

See: http://www.developerweb.net/forum/archive/index.php/t-2987.html

And from the man page:

    SO_REUSEPORT allows completely duplicate bindings by multiple processes
    if they all set SO_REUSEPORT before binding the port.  This option per-
    mits multiple instances of a program to each receive UDP/IP multicast or
    broadcast datagrams destined for the bound port.

So... this flag allowed me to have 2 liblo processes bind to the same 
port. I set the flag in server.c, right before:
if ((ret = bind(s->socket, used->ai_addr, used->ai_addrlen)) < 0)

However, when I send to the port, only the 1st process (in terms of 
launch order) will see the message. It seems like the buffer gets eaten 
and data is not available to the 2nd process. This is not what I want, 
and it shouldn't happen if that flag is set.

Can you think of anything in liblo that might be causing this?

Thanks,
Mike



Stephen Sinclair wrote:
> On Tue, Feb 10, 2009 at 9:47 PM, Mike Wozniewski <mi...@mi...> wrote:
>   
>> Hi all,
>>
>> I'd like to have multiple processes listen to the same port using liblo,
>> but it seems that the SO_REUSEADDR flag is only set for servers that are
>> created by lo_server_new_multicast().
>>
>> There needs to also be a way to set this flag for addresses receiving
>> broadcast messages. The option needs to be set using setsockopt() before
>> the bind() in the lo_server_new_with_proto_internal() in server.c.
>>
>> But how to specify that this should be set? A flag? Maybe a new proto
>> value for broadcast?
>>
>> Any ideas?
>>
>> Thanks in advance!
>> -Mike
>>     
>
> I'm not super familiar with using broadcast, but are there any cases
> where you would _not_ want to set SO_REUSEADDR when SO_BROADCAST is
> set?  If not, maybe it should just be set whenever the broadcast IP is
> detected.
>
>
> Steve
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

Hi,

I added a patch which changes the value of LO_TT_IMMEDIATE to {0,1},
per the spec.  Please let me know if you notice this causing any
breakage.  I did have to fix one place in the server code where {0,0}
was assumed, to get testlo to run correctly.


Steve

On Tue, Feb 10, 2009 at 9:47 PM, Mike Wozniewski <mi...@mi...> wrote:
> Hi all,
>
> I'd like to have multiple processes listen to the same port using liblo,
> but it seems that the SO_REUSEADDR flag is only set for servers that are
> created by lo_server_new_multicast().
>
> There needs to also be a way to set this flag for addresses receiving
> broadcast messages. The option needs to be set using setsockopt() before
> the bind() in the lo_server_new_with_proto_internal() in server.c.
>
> But how to specify that this should be set? A flag? Maybe a new proto
> value for broadcast?
>
> Any ideas?
>
> Thanks in advance!
> -Mike

I'm not super familiar with using broadcast, but are there any cases
where you would _not_ want to set SO_REUSEADDR when SO_BROADCAST is
set?  If not, maybe it should just be set whenever the broadcast IP is
detected.


Steve

Hi all,

I'd like to have multiple processes listen to the same port using liblo, 
but it seems that the SO_REUSEADDR flag is only set for servers that are 
created by lo_server_new_multicast().

There needs to also be a way to set this flag for addresses receiving 
broadcast messages. The option needs to be set using setsockopt() before 
the bind() in the lo_server_new_with_proto_internal() in server.c.

But how to specify that this should be set? A flag? Maybe a new proto 
value for broadcast?

Any ideas?

Thanks in advance!
-Mike

Hi,

Please consider the current svn version of liblo a release candidate
for 0.26.  I've bumped the soname so if anyone has suggestions on API
changes now is a good time.

One thing:  After reviewing Alex's patch of Dominique Sacré's
suggestion for timestamps, I noticed he also posted a bug report about
LO_TT_IMMEDIATE being wrong according to the spec.

http://sourceforge.net/tracker/index.php?func=detail&aid=1721113&group_id=116064&atid=673869

Think we should change it?  It will break any current programs if they
use timestamps, but with bumping the API number, now's probably a good
time if we want to do this.  I'll try to review a few more of those
bug reports to see if there is any more low-hanging fruit before doing
a release.


Steve