liblo-devel Mailing List for LibLO

Hi Steve,

Passes every tests for git commit 3478c4c freshly cloned on my Mac running Moutain Lion 10.8.4.

Best,
Cam

On 23 juin 2013, at 20:02, Stephen Sinclair <rad...@gm...> wrote:

> Okay, both of these issues are not what I'm seeing on my laptop, *and*
> they are not what was reported on the LAD mailing list.  Looks like
> there are a few things to iron out here... I'll have to try to get
> access to an x86-64 machine because I can't replicate these problems.
> 
> thanks,
> Steve
> 
> 
> On Sun, Jun 23, 2013 at 6:59 PM, Simon Newton <li...@no...> wrote:
>> test_bidirectional_tcp seems to block forever on  Debian Wheezy x86_64:
>> 
>> ./test_bidirectional_tcp
>> 0xf33010.server fd: 3
>> 0xf33010.receiving1..
>> 0xf34720.sending thread
>> 0xf34720.message sent
>> 0xf34720.sending thread waiting
>> 0xf33010./test, from TCP::
>> 0xf33010.address fd: 0
>> 0xf33010.reply sent
>> 0xf33010.done receiving1
>> 0xf33010.receiving2..
>> 
>> It's stuck in a poll loop:
>> 
>> poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
>> events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000) = 0 (Timeout)
>> poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
>> events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000) = 0 (Timeout)
>> poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
>> events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000
>> 
>> 
>> Simon
>> 
>> 
>> On Sun, Jun 23, 2013 at 9:36 AM, Stephen Sinclair <rad...@gm...> wrote:
>>> Hi,
>>> 
>>> After my initial publication of 0.27, a couple of serious bugs in the
>>> TCP implementation were posted, which have now been fixed.
>>> 
>>> I think it's worth publishing a bug-fix release just for this, before
>>> 0.27 gets into any linux distributions.  However, there was also a
>>> complaint on the LAD mailing list about "make test" failing for
>>> someone on an x86-64 Suse Linux machine.
>>> 
>>> I don't know whether the recent fixes were related, so I'll contact
>>> the author and check with him whether it is now fixed.  However, can
>>> anyone confirm that "make test" is successful on an x86-64 machine?
>>> My laptop is 32-bit, so I don't currently have access to one.
>>> 
>>> (I will note that I had tested it on a 64-bit Mac prior to the
>>> release.. I thought there were no issues.)
>>> 
>>> Steve
>>> 
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>> 
>>> Build for Windows Store.
>>> 
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> 
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>> 
>> Build for Windows Store.
>> 
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Okay, both of these issues are not what I'm seeing on my laptop, *and*
they are not what was reported on the LAD mailing list.  Looks like
there are a few things to iron out here... I'll have to try to get
access to an x86-64 machine because I can't replicate these problems.

thanks,
Steve


On Sun, Jun 23, 2013 at 6:59 PM, Simon Newton <li...@no...> wrote:
> test_bidirectional_tcp seems to block forever on  Debian Wheezy x86_64:
>
> ./test_bidirectional_tcp
> 0xf33010.server fd: 3
> 0xf33010.receiving1..
> 0xf34720.sending thread
> 0xf34720.message sent
> 0xf34720.sending thread waiting
> 0xf33010./test, from TCP::
> 0xf33010.address fd: 0
> 0xf33010.reply sent
> 0xf33010.done receiving1
> 0xf33010.receiving2..
>
> It's stuck in a poll loop:
>
> poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
> events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000) = 0 (Timeout)
> poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
> events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000) = 0 (Timeout)
> poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
> events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000
>
>
> Simon
>
>
> On Sun, Jun 23, 2013 at 9:36 AM, Stephen Sinclair <rad...@gm...> wrote:
>> Hi,
>>
>> After my initial publication of 0.27, a couple of serious bugs in the
>> TCP implementation were posted, which have now been fixed.
>>
>> I think it's worth publishing a bug-fix release just for this, before
>> 0.27 gets into any linux distributions.  However, there was also a
>> complaint on the LAD mailing list about "make test" failing for
>> someone on an x86-64 Suse Linux machine.
>>
>> I don't know whether the recent fixes were related, so I'll contact
>> the author and check with him whether it is now fixed.  However, can
>> anyone confirm that "make test" is successful on an x86-64 machine?
>> My laptop is 32-bit, so I don't currently have access to one.
>>
>> (I will note that I had tested it on a 64-bit Mac prior to the
>> release.. I thought there were no issues.)
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

test_bidirectional_tcp seems to block forever on  Debian Wheezy x86_64:

./test_bidirectional_tcp
0xf33010.server fd: 3
0xf33010.receiving1..
0xf34720.sending thread
0xf34720.message sent
0xf34720.sending thread waiting
0xf33010./test, from TCP::
0xf33010.address fd: 0
0xf33010.reply sent
0xf33010.done receiving1
0xf33010.receiving2..

It's stuck in a poll loop:

poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000) = 0 (Timeout)
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000) = 0 (Timeout)
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}, {fd=6,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 10000


Simon


On Sun, Jun 23, 2013 at 9:36 AM, Stephen Sinclair <rad...@gm...> wrote:
> Hi,
>
> After my initial publication of 0.27, a couple of serious bugs in the
> TCP implementation were posted, which have now been fixed.
>
> I think it's worth publishing a bug-fix release just for this, before
> 0.27 gets into any linux distributions.  However, there was also a
> complaint on the LAD mailing list about "make test" failing for
> someone on an x86-64 Suse Linux machine.
>
> I don't know whether the recent fixes were related, so I'll contact
> the author and check with him whether it is now fixed.  However, can
> anyone confirm that "make test" is successful on an x86-64 machine?
> My laptop is 32-bit, so I don't currently have access to one.
>
> (I will note that I had tested it on a 64-bit Mac prior to the
> release.. I thought there were no issues.)
>
> Steve
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Sun, Jun 23, 2013 at 9:36 AM, Stephen Sinclair <rad...@gm...>wrote:

> Hi,
>
> After my initial publication of 0.27, a couple of serious bugs in the
> TCP implementation were posted, which have now been fixed.
>
> I think it's worth publishing a bug-fix release just for this, before
> 0.27 gets into any linux distributions.  However, there was also a
> complaint on the LAD mailing list about "make test" failing for
> someone on an x86-64 Suse Linux machine.
>
> I don't know whether the recent fixes were related, so I'll contact
> the author and check with him whether it is now fixed.  However, can
> anyone confirm that "make test" is successful on an x86-64 machine?
> My laptop is 32-bit, so I don't currently have access to one.
>
> (I will note that I had tested it on a 64-bit Mac prior to the
> release.. I thought there were no issues.)
>
> Steve
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>


Tests pass, but the test program hangs after the following:

Server URL: osc.udp://sire.sire.net:16169/
validation
Address of us: osc.udp://sire.sire.net:16169/
/foo/bar <- f:0.123457, i:23
Reply sent to osc.udp://127.0.0.1:16169/

Address of us: osc.udp://sire.sire.net:16169/
/foo/bar <- f:0.123457, i:23
Reply sent to osc.udp://127.0.0.1:16169/

liblo server error 9912 in /: Invalid message received (expected)
Reply received from osc.udp://127.0.0.1:16169/
Reply received from osc.udp://127.0.0.1:16169/

Is that expected?

make test works on this debian amd64 machine, at 3478c4c.

I have updating debian liblo on my todo list, but I haven't got around
to it yet.

On Sun, Jun 23, 2013 at 12:36 PM, Stephen Sinclair <rad...@gm...> wrote:
> Hi,
>
> After my initial publication of 0.27, a couple of serious bugs in the
> TCP implementation were posted, which have now been fixed.
>
> I think it's worth publishing a bug-fix release just for this, before
> 0.27 gets into any linux distributions.  However, there was also a
> complaint on the LAD mailing list about "make test" failing for
> someone on an x86-64 Suse Linux machine.
>
> I don't know whether the recent fixes were related, so I'll contact
> the author and check with him whether it is now fixed.  However, can
> anyone confirm that "make test" is successful on an x86-64 machine?
> My laptop is 32-bit, so I don't currently have access to one.
>
> (I will note that I had tested it on a 64-bit Mac prior to the
> release.. I thought there were no issues.)
>
> Steve
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel



-- 

Saludos,
Felipe Sateler

Hi,

After my initial publication of 0.27, a couple of serious bugs in the
TCP implementation were posted, which have now been fixed.

I think it's worth publishing a bug-fix release just for this, before
0.27 gets into any linux distributions.  However, there was also a
complaint on the LAD mailing list about "make test" failing for
someone on an x86-64 Suse Linux machine.

I don't know whether the recent fixes were related, so I'll contact
the author and check with him whether it is now fixed.  However, can
anyone confirm that "make test" is successful on an x86-64 machine?
My laptop is 32-bit, so I don't currently have access to one.

(I will note that I had tested it on a 64-bit Mac prior to the
release.. I thought there were no issues.)

Steve

"message too long" is given by lo_address_errstr().

++
Nicolas


2013/6/20 Stephen Sinclair <rad...@gm...>

> There is an upper limit on UDP packet sizes but I expected it to be
> bigger than that, more like 64 kB.  (Wikipedia says 65,507 bytes.)
>
> https://en.wikipedia.org/wiki/User_Datagram_Protocol
>
> But, not sure how this interacts with the MTU tbh...
>
> Anyways lo_send_bundle_from() returns the number of bytes sent or -1
> on error.  Maybe you can call lo_address_errstr() to get more info?
>
> Steve
>
>
> On Thu, Jun 20, 2013 at 3:36 PM, nicolas bats <sl1...@gm...> wrote:
> > Camille,
> > thank you for your answer.
> >
> > for what I understand, it's not very complicated to transform my existing
> > upd server to a tcp one, but will I still able to talk with app that do
> use
> > a udp server?
> >
> > best regards
> >
> >
> > 2013/6/20 Camille Troillard <ca...@os...>
> >>
> >> Hi Nicolas,
> >>
> >> It seems that you are hitting the network MTU, and that yours was
> >> configured as a jumbo frame (> 9000 bytes).
> >>
> >> You should use TCP instead of UDP, or fragment your bundle in several
> >> ones, each sent separately in one packet.
> >>
> >> --
> >> Cam
> >>
> >> On 20 juin 2013, at 14:44, nicolas bats <sl1...@gm...> wrote:
> >>
> >> Hi,
> >> first of all, thank you for the new release!!
> >>
> >> I'm facing an issue in my app as apparently the bundle I'm building is
> too
> >> long.
> >>
> >> lo_send_bundle_from() return the length of the bundle when everything is
> >> fine (lo_bundle_length = 9196) and -1 when I exceed 9196.
> >>
> >> I'm wondering if I can use the new lo_bundle_add_bundle() to bypass this
> >> limitation?
> >>
> >> if so, do you have an example of how I can do that (usage of incref and
> >> so)?
> >>
> >>
> >> thanx,
> >>
> >> best regards,
> >>
> >> Nicolas
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF.net email is sponsored by Windows:
> >>
> >> Build for Windows Store.
> >>
> >> http://p.sf.net/sfu/windows-dev2dev
> >>
> >> _______________________________________________
> >> liblo-devel mailing list
> >> lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF.net email is sponsored by Windows:
> >>
> >> Build for Windows Store.
> >>
> >> http://p.sf.net/sfu/windows-dev2dev
> >> _______________________________________________
> >> liblo-devel mailing list
> >> lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

There is an upper limit on UDP packet sizes but I expected it to be
bigger than that, more like 64 kB.  (Wikipedia says 65,507 bytes.)

https://en.wikipedia.org/wiki/User_Datagram_Protocol

But, not sure how this interacts with the MTU tbh...

Anyways lo_send_bundle_from() returns the number of bytes sent or -1
on error.  Maybe you can call lo_address_errstr() to get more info?

Steve


On Thu, Jun 20, 2013 at 3:36 PM, nicolas bats <sl1...@gm...> wrote:
> Camille,
> thank you for your answer.
>
> for what I understand, it's not very complicated to transform my existing
> upd server to a tcp one, but will I still able to talk with app that do use
> a udp server?
>
> best regards
>
>
> 2013/6/20 Camille Troillard <ca...@os...>
>>
>> Hi Nicolas,
>>
>> It seems that you are hitting the network MTU, and that yours was
>> configured as a jumbo frame (> 9000 bytes).
>>
>> You should use TCP instead of UDP, or fragment your bundle in several
>> ones, each sent separately in one packet.
>>
>> --
>> Cam
>>
>> On 20 juin 2013, at 14:44, nicolas bats <sl1...@gm...> wrote:
>>
>> Hi,
>> first of all, thank you for the new release!!
>>
>> I'm facing an issue in my app as apparently the bundle I'm building is too
>> long.
>>
>> lo_send_bundle_from() return the length of the bundle when everything is
>> fine (lo_bundle_length = 9196) and -1 when I exceed 9196.
>>
>> I'm wondering if I can use the new lo_bundle_add_bundle() to bypass this
>> limitation?
>>
>> if so, do you have an example of how I can do that (usage of incref and
>> so)?
>>
>>
>> thanx,
>>
>> best regards,
>>
>> Nicolas
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>>
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

thanx.

++
Nicolas


2013/6/20 Camille Troillard <ca...@os...>

> Only if you can change the other app to use TCP, otherwise you can't mix
> protocols.
>
>
> --
> Cam
>
> On 20 juin 2013, at 15:36, nicolas bats <sl1...@gm...> wrote:
>
> Camille,
> thank you for your answer.
>
> for what I understand, it's not very complicated to transform my existing
> upd server to a tcp one, but will I still able to talk with app that do use
> a udp server?
>
> best regards
>
>
> 2013/6/20 Camille Troillard <ca...@os...>
>
>> Hi Nicolas,
>>
>> It seems that you are hitting the network MTU, and that yours was
>> configured as a jumbo frame (> 9000 bytes).
>>
>> You should use TCP instead of UDP, or fragment your bundle in several
>> ones, each sent separately in one packet.
>>
>> --
>> Cam
>>
>> On 20 juin 2013, at 14:44, nicolas bats <sl1...@gm...> wrote:
>>
>> Hi,
>> first of all, thank you for the new release!!
>>
>> I'm facing an issue in my app as apparently the bundle I'm building is
>> too long.
>>
>> lo_send_bundle_from() return the length of the bundle when everything is
>> fine (lo_bundle_length = 9196) and -1 when I exceed 9196.
>>
>> I'm wondering if I can use the new lo_bundle_add_bundle() to bypass this
>> limitation?
>>
>> if so, do you have an example of how I can do that (usage of incref and
>> so)?
>>
>>
>> thanx,
>>
>> best regards,
>>
>> Nicolas
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>>
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Only if you can change the other app to use TCP, otherwise you can't mix protocols. 


--
Cam

On 20 juin 2013, at 15:36, nicolas bats <sl1...@gm...> wrote:

> Camille,
> thank you for your answer.
> 
> for what I understand, it's not very complicated to transform my existing upd server to a tcp one, but will I still able to talk with app that do use a udp server?
> 
> best regards
> 
> 
> 2013/6/20 Camille Troillard <ca...@os...>
>> Hi Nicolas,
>> 
>> It seems that you are hitting the network MTU, and that yours was configured as a jumbo frame (> 9000 bytes).
>> 
>> You should use TCP instead of UDP, or fragment your bundle in several ones, each sent separately in one packet.
>> 
>> --
>> Cam
>> 
>> On 20 juin 2013, at 14:44, nicolas bats <sl1...@gm...> wrote:
>> 
>>> Hi,
>>> first of all, thank you for the new release!!
>>> 
>>> I'm facing an issue in my app as apparently the bundle I'm building is too long.
>>> lo_send_bundle_from() return the length of the bundle when everything is fine (lo_bundle_length = 9196) and -1 when I exceed 9196.
>>> 
>>> I'm wondering if I can use the new lo_bundle_add_bundle() to bypass this limitation?
>>> 
>>> if so, do you have an example of how I can do that (usage of incref and so)?
>>> 
>>> 
>>> 
>>> thanx,
>>> 
>>> best regards,
>>> 
>>> Nicolas
>>> 
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>> 
>>> Build for Windows Store.
>>> 
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> 
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>> 
>> Build for Windows Store.
>> 
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Camille,
thank you for your answer.

for what I understand, it's not very complicated to transform my existing
upd server to a tcp one, but will I still able to talk with app that do use
a udp server?

best regards


2013/6/20 Camille Troillard <ca...@os...>

> Hi Nicolas,
>
> It seems that you are hitting the network MTU, and that yours was
> configured as a jumbo frame (> 9000 bytes).
>
> You should use TCP instead of UDP, or fragment your bundle in several
> ones, each sent separately in one packet.
>
> --
> Cam
>
> On 20 juin 2013, at 14:44, nicolas bats <sl1...@gm...> wrote:
>
> Hi,
> first of all, thank you for the new release!!
>
> I'm facing an issue in my app as apparently the bundle I'm building is too
> long.
>
> lo_send_bundle_from() return the length of the bundle when everything is
> fine (lo_bundle_length = 9196) and -1 when I exceed 9196.
>
> I'm wondering if I can use the new lo_bundle_add_bundle() to bypass this
> limitation?
>
> if so, do you have an example of how I can do that (usage of incref and
> so)?
>
>
> thanx,
>
> best regards,
>
> Nicolas
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Hi Nicolas,

It seems that you are hitting the network MTU, and that yours was configured as a jumbo frame (> 9000 bytes).

You should use TCP instead of UDP, or fragment your bundle in several ones, each sent separately in one packet.

--
Cam

On 20 juin 2013, at 14:44, nicolas bats <sl1...@gm...> wrote:

> Hi,
> first of all, thank you for the new release!!
> 
> I'm facing an issue in my app as apparently the bundle I'm building is too long.
> lo_send_bundle_from() return the length of the bundle when everything is fine (lo_bundle_length = 9196) and -1 when I exceed 9196.
> 
> I'm wondering if I can use the new lo_bundle_add_bundle() to bypass this limitation?
> 
> if so, do you have an example of how I can do that (usage of incref and so)?
> 
> 
> 
> thanx,
> 
> best regards,
> 
> Nicolas
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,
first of all, thank you for the new release!!

I'm facing an issue in my app as apparently the bundle I'm building is too
long.

lo_send_bundle_from() return the length of the bundle when everything is
fine (lo_bundle_length = 9196) and -1 when I exceed 9196.

I'm wondering if I can use the new lo_bundle_add_bundle() to bypass this
limitation?

if so, do you have an example of how I can do that (usage of incref and so)?


thanx,

best regards,

Nicolas