liblo-devel Mailing List for LibLO

On Mon, Aug 20, 2012 at 6:00 AM, Camille Troillard
<ca...@os...> wrote:
> Hi Stephen,
>
> On 11 juil. 2012, at 23:54, Stephen Sinclair <rad...@gm...> wrote:
>
>>> For data input (lo_server), you said that the incomplete message could be stored while we wait on lo_wait. If this is correct, I can try to implement something.  Right now, I have no idea of how this could be implemented for message sending.
>>
>> I think the right approach is to wrap send() and recv() into a
>> buffered approach at the byte level.  Basically the liblo semantics
>> need to be given an asynchronous API.  For reading, we need to read
>> all ready bytes into a buffer and dispatch as needed.  That should be
>> straightforward.
>>
>> For send(), we need to copy sending bytes to a buffer, and send as
>> much as possible.  Since lo_send() assumes a completely synchronous
>> semantics, if not all the data is sent we need to loop on send() until
>> it all goes.
>>
>> However, this can block programs, so it would be nice to provide an
>> alternative lo_send_async() command which returns even if a message
>> was not completely sent.  It can return for example a boolean
>> indicating whether the send was completed, indicating to the calling
>> program that it should call lo_send_async() again in the near future.
>> (There its parameters need to be optional!!  It is not necessarily
>> called for queueing up new messages, but also to continue sending old
>> messages.)  Note this also means copying the message data, or we could
>> retain a pointer to the lo_message and simply specify that the user is
>> not to free that memory until lo_send_async() returns 0.
>>
>> What do you think?
>
> I am not sure if I understood correctly: so, this version of lo_send_async would call "send" and then return even if the call fails, am I right?
> If so, it seems that this is a blocking approach, not asynchronous, because send does not necessarily return right away.

No no, I'm suggesting that lo_send_async() would return right away if
it's not ready to send.  Using select() to check.  If it _is_ ready to
send, it _still_ may not be able to send the whole message, and must
call select() again and return if it's not ready.  In that case it
still needs to be able to access previously unsent bytes.

> I believe one way to properly send messages asynchronously would be to use a message queue on which messages would be copied.

Yeah, either copied or just maintain pointers.  It might be nice to do
it at the byte level and just queue things up in a big byte buffer,
like you are suggesting, although I guess that means an error message
if the buffer fills up.


> In fact, this queue does not even need to be implemented into liblo as long as lo_send is designed to loop over "send" until there is no more bytes to send or an error occurred.  A user could implement its own queue and run loop.  So I think lo_send_async is sugar for the future, we don't need it right now.

Right, except that means changing the semantics of lo_send(), which is
why I was suggesting a new function.  Because currently lo_send() can
only return 0 for success or -1 for error.  I suppose we could change
it to use a positive number to indicate that some number of bytes
still need to be sent -- this would be sort of backwards compatible
since old code would error out if the whole message wasn't sent,
assuming old code checked "!=0" rather than "<0" or "==-1".  However
I'm not sure we have that guarantee.

>> It's a bit more than I have time for at the moment however.  A loop
>> around send() should do the trick for the synchronous API.  If we're
>> tricky about it, in the bidirectional case we could use select() to
>> read any incoming data while waiting to write.
>
> I haven't though about this, thanks for pointing that out.
> It's becoming quite complex.

Unfortunately.  I don't see a problem introducing new functions to get
around current limitations however, we can always consider an API
overhaul in the future for a major version update.

Steve

Yeah I guess github supports 'organizations' now so it's possible to
create master repositories, but I'll just use my own account for now I
think.

https://github.com/radarsat1/liblo

On Thu, Aug 23, 2012 at 3:43 AM, Nicholas Humfrey <nj...@ae...> wrote:
> Good move :-)
>
> Would be good to have a 'canonical' repo on GitHub, so people know which to fork from.
>
> Sent from my phone
>
>
> On 23 Aug 2012, at 02:46, Stephen Sinclair <rad...@gm...> wrote:
>
>> Hi,
>>
>> By popular request, I am moving the liblo repository to git.  I am
>> staying with sourceforge so that we can use it for the small website
>> and to host the mailing list, release files, etc.  So I set up
>> sourceforge's git support, which worked quite well.  You can clone it
>> at:
>>
>> git clone git://liblo.git.sourceforge.net/gitroot/liblo/liblo
>>
>> However I'm going to continuing updating the mirror at gitorious, and
>> I'll probably mirror it on github too since I use it quite often.  So
>> you can use either of those sites to send pull requests, or please
>> feel free to post patches to the mailing list via 'git format-patch'.
>> I think the latter is preferable to me, but feel free to use either
>> method.  I may end up wanting to use github's issue tracker in the
>> future, as it's somewhat more wieldy than sourceforge's interface, but
>> in general I prefer the mailing list to discuss bugs.
>>
>> I considered removing svn metadata from old commits, but I decided to
>> leave it since some of the old commit messages refer to specific
>> revision numbers.  Unfortunately that means the email addresses will
>> be a bit mangled in old commits, due to the way 'git svn' appends a
>> GUID to the username to form an email address, but in the future
>> committers emails will be maintained, making it no longer necessary
>> for me to add their name to the end of the commit message.
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Good move :-)

Would be good to have a 'canonical' repo on GitHub, so people know which to fork from.

Sent from my phone


On 23 Aug 2012, at 02:46, Stephen Sinclair <rad...@gm...> wrote:

> Hi,
> 
> By popular request, I am moving the liblo repository to git.  I am
> staying with sourceforge so that we can use it for the small website
> and to host the mailing list, release files, etc.  So I set up
> sourceforge's git support, which worked quite well.  You can clone it
> at:
> 
> git clone git://liblo.git.sourceforge.net/gitroot/liblo/liblo
> 
> However I'm going to continuing updating the mirror at gitorious, and
> I'll probably mirror it on github too since I use it quite often.  So
> you can use either of those sites to send pull requests, or please
> feel free to post patches to the mailing list via 'git format-patch'.
> I think the latter is preferable to me, but feel free to use either
> method.  I may end up wanting to use github's issue tracker in the
> future, as it's somewhat more wieldy than sourceforge's interface, but
> in general I prefer the mailing list to discuss bugs.
> 
> I considered removing svn metadata from old commits, but I decided to
> leave it since some of the old commit messages refer to specific
> revision numbers.  Unfortunately that means the email addresses will
> be a bit mangled in old commits, due to the way 'git svn' appends a
> GUID to the username to form an email address, but in the future
> committers emails will be maintained, making it no longer necessary
> for me to add their name to the end of the commit message.
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

By popular request, I am moving the liblo repository to git.  I am
staying with sourceforge so that we can use it for the small website
and to host the mailing list, release files, etc.  So I set up
sourceforge's git support, which worked quite well.  You can clone it
at:

git clone git://liblo.git.sourceforge.net/gitroot/liblo/liblo

However I'm going to continuing updating the mirror at gitorious, and
I'll probably mirror it on github too since I use it quite often.  So
you can use either of those sites to send pull requests, or please
feel free to post patches to the mailing list via 'git format-patch'.
I think the latter is preferable to me, but feel free to use either
method.  I may end up wanting to use github's issue tracker in the
future, as it's somewhat more wieldy than sourceforge's interface, but
in general I prefer the mailing list to discuss bugs.

I considered removing svn metadata from old commits, but I decided to
leave it since some of the old commit messages refer to specific
revision numbers.  Unfortunately that means the email addresses will
be a bit mangled in old commits, due to the way 'git svn' appends a
GUID to the username to form an email address, but in the future
committers emails will be maintained, making it no longer necessary
for me to add their name to the end of the commit message.

Steve

Yes, it might make sense to permanently move to git.  It's probably
even possible to stick with sourceforge but just move things to git on
SF and keep mirrors on gitorious and github.

I'm considering it, it wouldn't be a very big deal and might allow
more easily-accessible experimental branches, which could be useful.

Steve

On Mon, Aug 20, 2012 at 5:38 AM, Camille Troillard
<ca...@os...> wrote:
> Hi Stephen,
>
> Back from holidays, and catching up old email.
>
> I have been using liblo's gitorious repository for a while now.
> My question was mainly about pull-requests, I thought the repository should be natively in git so pull-requests would work.
>
> Also, I did not know that you could send pull-request from one website to another, this is awesome!
>
>
> Best,
> Cam
>
>
> On 11 juil. 2012, at 22:59, Stephen Sinclair <rad...@gm...> wrote:
>
>> The svn repository is already mirrored regularly in gitorious.org:
>>
>> http://gitorious.org/projects/liblo
>>
>> I do this because I use git-svn anyways, so every time I "git svn
>> dcommit", I also push the new master to gitorious.
>>
>> One thing I like about this workflow is that it keeps the history
>> linear, but it also makes merging more annoying, and destroys author
>> information. And linear history is over-rated.
>>
>> I have a github account anyways so I would be willing to mirror the
>> gitorious repository over there.  On the other hand, now that
>> sourceforge supports git, I don't see why we can't just switch to it
>> there.  You'd be free to send me pull requests via github and I can
>> merge them and push them to github/gitorious and sourceforge, where SF
>> would remain the official version.
>>
>> I'll look into SF's git resources when I get a chance.  I do prefer
>> git after all.
>>
>> The reason I originally chose gitorious over github was because it's
>> open source AGPL and has better size limits, but since then I've
>> become a pretty regular github user.  The nice thing about git is that
>> in the end it doesn't really matter where it's hosted.
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Stephen,

On 11 juil. 2012, at 23:54, Stephen Sinclair <rad...@gm...> wrote:

>> For data input (lo_server), you said that the incomplete message could be stored while we wait on lo_wait. If this is correct, I can try to implement something.  Right now, I have no idea of how this could be implemented for message sending.
> 
> I think the right approach is to wrap send() and recv() into a
> buffered approach at the byte level.  Basically the liblo semantics
> need to be given an asynchronous API.  For reading, we need to read
> all ready bytes into a buffer and dispatch as needed.  That should be
> straightforward.
> 
> For send(), we need to copy sending bytes to a buffer, and send as
> much as possible.  Since lo_send() assumes a completely synchronous
> semantics, if not all the data is sent we need to loop on send() until
> it all goes.
> 
> However, this can block programs, so it would be nice to provide an
> alternative lo_send_async() command which returns even if a message
> was not completely sent.  It can return for example a boolean
> indicating whether the send was completed, indicating to the calling
> program that it should call lo_send_async() again in the near future.
> (There its parameters need to be optional!!  It is not necessarily
> called for queueing up new messages, but also to continue sending old
> messages.)  Note this also means copying the message data, or we could
> retain a pointer to the lo_message and simply specify that the user is
> not to free that memory until lo_send_async() returns 0.
> 
> What do you think?

I am not sure if I understood correctly: so, this version of lo_send_async would call "send" and then return even if the call fails, am I right?
If so, it seems that this is a blocking approach, not asynchronous, because send does not necessarily return right away.

I believe one way to properly send messages asynchronously would be to use a message queue on which messages would be copied.

In fact, this queue does not even need to be implemented into liblo as long as lo_send is designed to loop over "send" until there is no more bytes to send or an error occurred.  A user could implement its own queue and run loop.  So I think lo_send_async is sugar for the future, we don't need it right now.


> It's a bit more than I have time for at the moment however.  A loop
> around send() should do the trick for the synchronous API.  If we're
> tricky about it, in the bidirectional case we could use select() to
> read any incoming data while waiting to write.

I haven't though about this, thanks for pointing that out.
It's becoming quite complex.


Best,
Cam

Hi Stephen,

Back from holidays, and catching up old email.

I have been using liblo's gitorious repository for a while now.
My question was mainly about pull-requests, I thought the repository should be natively in git so pull-requests would work.

Also, I did not know that you could send pull-request from one website to another, this is awesome!


Best,
Cam


On 11 juil. 2012, at 22:59, Stephen Sinclair <rad...@gm...> wrote:

> The svn repository is already mirrored regularly in gitorious.org:
> 
> http://gitorious.org/projects/liblo
> 
> I do this because I use git-svn anyways, so every time I "git svn
> dcommit", I also push the new master to gitorious.
> 
> One thing I like about this workflow is that it keeps the history
> linear, but it also makes merging more annoying, and destroys author
> information. And linear history is over-rated.
> 
> I have a github account anyways so I would be willing to mirror the
> gitorious repository over there.  On the other hand, now that
> sourceforge supports git, I don't see why we can't just switch to it
> there.  You'd be free to send me pull requests via github and I can
> merge them and push them to github/gitorious and sourceforge, where SF
> would remain the official version.
> 
> I'll look into SF's git resources when I get a chance.  I do prefer
> git after all.
> 
> The reason I originally chose gitorious over github was because it's
> open source AGPL and has better size limits, but since then I've
> become a pretty regular github user.  The nice thing about git is that
> in the end it doesn't really matter where it's hosted.
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Shouldn't it only test that the last octet is 255?

ie,

if (ip[3] == 255) {


-Mike

On 12-08-07 11:54 AM, Camille Troillard wrote:
> On 7 août 2012, at 17:43, Stephen Sinclair wrote:
>
>> Sure, I didn't thoroughly research how to use SO_BROADCAST before
>> making that patch, it wouldn't surprise me if there are some bad
>> assumptions.  I'll look at your suggestions soon.  I have a major
>> deadline coming up next Tuesday so I'll be able to get back to work on
>> liblo soon after that.
> Alright Steve, take you time!
>
> If I understood correctly, SO_BROADCAST flag is used as a security feature to prevent unintended broadcasting of datagrams packets.  By default it is off.  If the user really knows that he wants to broadcast, then the flag must be explicitly added.
>
> So, we could either consider it is ok to broadcast UDP datagrams by default in liblo and always set the flag, or we can make this an optional setting of lo_server (and lo_address ?).
>
> I would personally opt for the first approach because it is more simple and there are many use cases where it is desirable to broadcast OSC packets over UDP.  It could be a security problem though, but I doubt.
>
> (in all cases, the current implementation does not seem right to me (testing if the ip address is 255.255.255.255)).
>
>
>
> Cam
>
>
>
>> On Tue, Aug 7, 2012 at 6:09 AM, Camille Troillard <ca...@os...> wrote:
>>> Here is a suggested patch that enables the SO_BROADCAST option on the lo_server socket when UDP is used.
>>>
>>>
>>>
>>>
>>>
>>> On 7 août 2012, at 11:57, Camille Troillard wrote:
>>>
>>>> Hi,
>>>>
>>>> I believe there is a small regression with the current liblo code.
>>>>
>>>> On UDP, when using lo_send_message_from with a broadcast IP address, the SO_BROADCAST flag is not set.
>>>>
>>>> I managed to have this work by moving some code from create_socket to send_data.
>>>> However it raises two questions:
>>>>
>>>> Shouldn't this test:
>>>>
>>>>               if (ip[0] == 255 && ip[1] == 255 && ip[2] == 255 && ip[3] == 255) {
>>>>
>>>> Rather be:
>>>>
>>>>               if (ip[0] == 255 || ip[1] == 255 || ip[2] == 255 || ip[3] == 255) {
>>>>
>>>> ?
>>>>
>>>> The broadcast address I want to use is 10.0.0.255 and does not work with the first test.
>>>>
>>>>
>>>> Second question: why bother setting the SO_BROADCAST flag in the send_data function and not merely on any socket created (lo_server or lo_address created socket)?  I am not sure to understand the consequences of setting this flag at all times, any guidance would be appreciated.
>>>>
>>>>
>>>> Best,
>>>> Camille
>>>>
>>>>
>>>>
>>>> PS: Stephen, I have seen your latest replies and just got back from vacation, I will promptly answer in the following days.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> liblo-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On 7 août 2012, at 17:43, Stephen Sinclair wrote:

> Sure, I didn't thoroughly research how to use SO_BROADCAST before
> making that patch, it wouldn't surprise me if there are some bad
> assumptions.  I'll look at your suggestions soon.  I have a major
> deadline coming up next Tuesday so I'll be able to get back to work on
> liblo soon after that.

Alright Steve, take you time!

If I understood correctly, SO_BROADCAST flag is used as a security feature to prevent unintended broadcasting of datagrams packets.  By default it is off.  If the user really knows that he wants to broadcast, then the flag must be explicitly added.

So, we could either consider it is ok to broadcast UDP datagrams by default in liblo and always set the flag, or we can make this an optional setting of lo_server (and lo_address ?).

I would personally opt for the first approach because it is more simple and there are many use cases where it is desirable to broadcast OSC packets over UDP.  It could be a security problem though, but I doubt. 

(in all cases, the current implementation does not seem right to me (testing if the ip address is 255.255.255.255)).



Cam



> On Tue, Aug 7, 2012 at 6:09 AM, Camille Troillard <ca...@os...> wrote:
>> Here is a suggested patch that enables the SO_BROADCAST option on the lo_server socket when UDP is used.
>> 
>> 
>> 
>> 
>> 
>> On 7 août 2012, at 11:57, Camille Troillard wrote:
>> 
>>> Hi,
>>> 
>>> I believe there is a small regression with the current liblo code.
>>> 
>>> On UDP, when using lo_send_message_from with a broadcast IP address, the SO_BROADCAST flag is not set.
>>> 
>>> I managed to have this work by moving some code from create_socket to send_data.
>>> However it raises two questions:
>>> 
>>> Shouldn't this test:
>>> 
>>>              if (ip[0] == 255 && ip[1] == 255 && ip[2] == 255 && ip[3] == 255) {
>>> 
>>> Rather be:
>>> 
>>>              if (ip[0] == 255 || ip[1] == 255 || ip[2] == 255 || ip[3] == 255) {
>>> 
>>> ?
>>> 
>>> The broadcast address I want to use is 10.0.0.255 and does not work with the first test.
>>> 
>>> 
>>> Second question: why bother setting the SO_BROADCAST flag in the send_data function and not merely on any socket created (lo_server or lo_address created socket)?  I am not sure to understand the consequences of setting this flag at all times, any guidance would be appreciated.
>>> 
>>> 
>>> Best,
>>> Camille
>>> 
>>> 
>>> 
>>> PS: Stephen, I have seen your latest replies and just got back from vacation, I will promptly answer in the following days.
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> 

Hi,

Sure, I didn't thoroughly research how to use SO_BROADCAST before
making that patch, it wouldn't surprise me if there are some bad
assumptions.  I'll look at your suggestions soon.  I have a major
deadline coming up next Tuesday so I'll be able to get back to work on
liblo soon after that.

thanks,
Steve

On Tue, Aug 7, 2012 at 6:09 AM, Camille Troillard <ca...@os...> wrote:
> Here is a suggested patch that enables the SO_BROADCAST option on the lo_server socket when UDP is used.
>
>
>
>
>
> On 7 août 2012, at 11:57, Camille Troillard wrote:
>
>> Hi,
>>
>> I believe there is a small regression with the current liblo code.
>>
>> On UDP, when using lo_send_message_from with a broadcast IP address, the SO_BROADCAST flag is not set.
>>
>> I managed to have this work by moving some code from create_socket to send_data.
>> However it raises two questions:
>>
>> Shouldn't this test:
>>
>>               if (ip[0] == 255 && ip[1] == 255 && ip[2] == 255 && ip[3] == 255) {
>>
>> Rather be:
>>
>>               if (ip[0] == 255 || ip[1] == 255 || ip[2] == 255 || ip[3] == 255) {
>>
>> ?
>>
>> The broadcast address I want to use is 10.0.0.255 and does not work with the first test.
>>
>>
>> Second question: why bother setting the SO_BROADCAST flag in the send_data function and not merely on any socket created (lo_server or lo_address created socket)?  I am not sure to understand the consequences of setting this flag at all times, any guidance would be appreciated.
>>
>>
>> Best,
>> Camille
>>
>>
>>
>> PS: Stephen, I have seen your latest replies and just got back from vacation, I will promptly answer in the following days.
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Here is a suggested patch that enables the SO_BROADCAST option on the lo_server socket when UDP is used.

Hi,

I believe there is a small regression with the current liblo code.

On UDP, when using lo_send_message_from with a broadcast IP address, the SO_BROADCAST flag is not set.

I managed to have this work by moving some code from create_socket to send_data.
However it raises two questions:

Shouldn't this test:

		if (ip[0] == 255 && ip[1] == 255 && ip[2] == 255 && ip[3] == 255) {

Rather be:

		if (ip[0] == 255 || ip[1] == 255 || ip[2] == 255 || ip[3] == 255) {

?

The broadcast address I want to use is 10.0.0.255 and does not work with the first test.


Second question: why bother setting the SO_BROADCAST flag in the send_data function and not merely on any socket created (lo_server or lo_address created socket)?  I am not sure to understand the consequences of setting this flag at all times, any guidance would be appreciated.


Best,
Camille



PS: Stephen, I have seen your latest replies and just got back from vacation, I will promptly answer in the following days.