liblo-devel Mailing List for LibLO

Hm, well I can't think of an easy way to do that with the current API.
It could be something to consider for a future version of liblo.
Currently the maximum message size is a global compile-time variable.
It could potentially be changed to a run-time global, but some of the
buffering code would definitely need to be changed so as to avoid
large stack allocations.  Additionally there is the security
consideration that an attacker could cause problems by sending a
never-ending message stream.

Steve


On Thu, Aug 14, 2014 at 5:34 PM,  <to...@tr...> wrote:
> On Wed, August 13, 2014 23:57, Stephen Sinclair wrote:
>> On Tue, Aug 12, 2014 at 8:12 PM,  <to...@tr...> wrote:
>>
>>>
>>> Hi,
>>>
>>>
>>> i use liblo for OSC for some time and it works very well.
>>>
>>> Now i start looking into sending messages via TCP. I couldn't send
>>> larger messages than around 32KB. Looking at lo/lomacros.h revealed
>>>
>>> // \brief Maximum length of UDP messages in bytes
>>> #define LO_MAX_MSG_SIZE 32768
>>>
>>>
>>> And in src/send.c:
>>>
>>>
>>> if (data_len > LO_MAX_MSG_SIZE) { a->errnum = 99; a->errstr = "Attempted
>>> to send message in excess of maximum " "message size";
>>> return -1; }
>>>
>>>
>>> I wondered if it would be possible to not limit the size of TCP
>>> messages so it would be possible to send large messages.
>>>
>>> #define LO_MAX_MSG_SIZE_TCP 100000000
>>>
>>>
>>> if (a->protocol == LO_UDP && data_len > LO_MAX_MSG_SIZE) { a->errnum =
>>> 99;
>>> a->errstr = "Attempted to send message in excess of maximum " "message
>>> size"; return -1; }
>>> else if (a->protocol == LO_TCP && data_len > LO_MAX_MSG_SIZE_TCP) {
>>> a->errnum = 99; a->errstr = "Attempted to send message in excess of
>>> maximum " "message size";
>>> return -1; }
>>>
>>>
>>> A small test tool seems to happily send a message exceeding the limit
>>> set for UDP messages (netcal -l on the receiver side).
>>>
>>> Does this make any sense or did i miss something? Thanks
>>>
>>
>> Hi Tom,
>>
>>
>> It does make sense.  I'm surprised there's ever a need for OSC
>> messages greater than 32k, what are you sending?  in any case, in principle
>> there should be no real limit for TCP.  The limit just simplifies much of
>> the programming, and I'd have to check over the code again to be sure it
>> doesn't cause any ill effects to increase the limit.  Increasing this
>> variable likely causes liblo to allocate much larger buffers, so I'm not
>> sure that's an appropriate fix, even if it works.
>>
>> Steve
>>
>>
>
> Hello Steve,
>
> thanks for the clarification. It's indeed not a regular case to send
> messages > 32k. However if this limit is gone for TCP, other usecases for
> OSC are thinkable, using it as an application level packager for data of
> any size (i.e. in a blob) using the arguments as metadata.
> Some tests have shown that the connection is more reliable when sending
> large chunks compared to many small chunks when stressing the system with
> multiple network plug outs. Plugging out a cable while a large OSC TCP
> transfer is going on behaves differently when doing the same while 1000s
> of OSC TCP messages arrive. I can't tell why yet but with large chunks the
> recovery and low-level TCP handling seems more reliable. (This is how i
> came to change the limit in the first place). Of course large chunks bring
> latency but that must not be an issue for every usecase.
> It's a great library either way. It there are no side-effects having the
> limit for TCP extended would be wishful.
>
> Cheers,
> Tom
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Wed, August 13, 2014 23:57, Stephen Sinclair wrote:
> On Tue, Aug 12, 2014 at 8:12 PM,  <to...@tr...> wrote:
>
>>
>> Hi,
>>
>>
>> i use liblo for OSC for some time and it works very well.
>>
>> Now i start looking into sending messages via TCP. I couldn't send
>> larger messages than around 32KB. Looking at lo/lomacros.h revealed
>>
>> // \brief Maximum length of UDP messages in bytes
>> #define LO_MAX_MSG_SIZE 32768
>>
>>
>> And in src/send.c:
>>
>>
>> if (data_len > LO_MAX_MSG_SIZE) { a->errnum = 99; a->errstr = "Attempted
>> to send message in excess of maximum " "message size";
>> return -1; }
>>
>>
>> I wondered if it would be possible to not limit the size of TCP
>> messages so it would be possible to send large messages.
>>
>> #define LO_MAX_MSG_SIZE_TCP 100000000
>>
>>
>> if (a->protocol == LO_UDP && data_len > LO_MAX_MSG_SIZE) { a->errnum =
>> 99;
>> a->errstr = "Attempted to send message in excess of maximum " "message
>> size"; return -1; }
>> else if (a->protocol == LO_TCP && data_len > LO_MAX_MSG_SIZE_TCP) {
>> a->errnum = 99; a->errstr = "Attempted to send message in excess of
>> maximum " "message size";
>> return -1; }
>>
>>
>> A small test tool seems to happily send a message exceeding the limit
>> set for UDP messages (netcal -l on the receiver side).
>>
>> Does this make any sense or did i miss something? Thanks
>>
>
> Hi Tom,
>
>
> It does make sense.  I'm surprised there's ever a need for OSC
> messages greater than 32k, what are you sending?  in any case, in principle
> there should be no real limit for TCP.  The limit just simplifies much of
> the programming, and I'd have to check over the code again to be sure it
> doesn't cause any ill effects to increase the limit.  Increasing this
> variable likely causes liblo to allocate much larger buffers, so I'm not
> sure that's an appropriate fix, even if it works.
>
> Steve
>
>

Hello Steve,

thanks for the clarification. It's indeed not a regular case to send
messages > 32k. However if this limit is gone for TCP, other usecases for
OSC are thinkable, using it as an application level packager for data of
any size (i.e. in a blob) using the arguments as metadata.
Some tests have shown that the connection is more reliable when sending
large chunks compared to many small chunks when stressing the system with
multiple network plug outs. Plugging out a cable while a large OSC TCP
transfer is going on behaves differently when doing the same while 1000s
of OSC TCP messages arrive. I can't tell why yet but with large chunks the
recovery and low-level TCP handling seems more reliable. (This is how i
came to change the limit in the first place). Of course large chunks bring
latency but that must not be an issue for every usecase.
It's a great library either way. It there are no side-effects having the
limit for TCP extended would be wishful.

Cheers,
Tom

On Tue, Aug 12, 2014 at 8:12 PM,  <to...@tr...> wrote:
>
> Hi,
>
> i use liblo for OSC for some time and it works very well.
>
> Now i start looking into sending messages via TCP. I couldn't send larger
> messages than around 32KB. Looking at lo/lomacros.h revealed
>
> // \brief Maximum length of UDP messages in bytes
> #define LO_MAX_MSG_SIZE 32768
>
> And in src/send.c:
>
> if (data_len > LO_MAX_MSG_SIZE) {
>         a->errnum = 99;
>         a->errstr = "Attempted to send message in excess of maximum "
>             "message size";
>         return -1;
> }
>
> I wondered if it would be possible to not limit the size of TCP messages
> so it would be possible to send large messages.
>
> #define LO_MAX_MSG_SIZE_TCP 100000000
>
>     if (a->protocol == LO_UDP && data_len > LO_MAX_MSG_SIZE) {
>         a->errnum = 99;
>         a->errstr = "Attempted to send message in excess of maximum "
>             "message size";
>         return -1;
>     }
>     else if (a->protocol == LO_TCP && data_len > LO_MAX_MSG_SIZE_TCP) {
>         a->errnum = 99;
>         a->errstr = "Attempted to send message in excess of maximum "
>             "message size";
>         return -1;
>     }
>
> A small test tool seems to happily send a message exceeding the limit set
> for UDP messages (netcal -l on the receiver side).
>
> Does this make any sense or did i miss something? Thanks

Hi Tom,

It does make sense.  I'm surprised there's ever a need for OSC
messages greater than 32k, what are you sending?  in any case, in
principle there should be no real limit for TCP.  The limit just
simplifies much of the programming, and I'd have to check over the
code again to be sure it doesn't cause any ill effects to increase the
limit.  Increasing this variable likely causes liblo to allocate much
larger buffers, so I'm not sure that's an appropriate fix, even if it
works.

Steve

Hi,

i use liblo for OSC for some time and it works very well.

Now i start looking into sending messages via TCP. I couldn't send larger
messages than around 32KB. Looking at lo/lomacros.h revealed

// \brief Maximum length of UDP messages in bytes
#define LO_MAX_MSG_SIZE 32768

And in src/send.c:

if (data_len > LO_MAX_MSG_SIZE) {
        a->errnum = 99;
        a->errstr = "Attempted to send message in excess of maximum "
            "message size";
        return -1;
}

I wondered if it would be possible to not limit the size of TCP messages
so it would be possible to send large messages.

#define LO_MAX_MSG_SIZE_TCP 100000000

    if (a->protocol == LO_UDP && data_len > LO_MAX_MSG_SIZE) {
        a->errnum = 99;
        a->errstr = "Attempted to send message in excess of maximum "
            "message size";
        return -1;
    }
    else if (a->protocol == LO_TCP && data_len > LO_MAX_MSG_SIZE_TCP) {
        a->errnum = 99;
        a->errstr = "Attempted to send message in excess of maximum "
            "message size";
        return -1;
    }

A small test tool seems to happily send a message exceeding the limit set
for UDP messages (netcal -l on the receiver side).

Does this make any sense or did i miss something? Thanks

Best regards,
Thomas