liblo-devel Mailing List for LibLO

Great - thanks Steve, I can confirm that this fixes the buggy behaviour I observed.

>> I realized you aren't doing bi-directional communication as expected.

Yeah this test wasn’t really intended intended to use bidirectional communication, just to simply demonstrate the bug (which would affect bidirectional comms also).

thanks,
Joe

On 20 Mar, 2014, at 6:59 PM, Stephen Sinclair <rad...@gm...> wrote:

> Got it.  It was a weird and erroneous initialization of a loop count
> in lo_server_recv_raw_recv_stream().  Pull from the master on github.
> (Will push to sf soon)
> 
> Steve
> 
> 
> On Thu, Mar 20, 2014 at 6:26 PM, Stephen Sinclair <rad...@gm...> wrote:
>> I still think there is some unexpected behaviour here, but after
>> staring at it for a while I realized you aren't doing bi-directional
>> communication as expected.  Nonetheless it shouldn't block reception,
>> so something's going on when the address socket is added to the
>> server's socket list and I haven't quite figured it out yet.
>> 
>> However, you are creating two addresses targeted at the server's
>> "accept" socket, so both lo_send_from() calls should be expected to
>> create a new connection.  If you want to re-use the connection, it
>> must be based on an address returned from lo_message_get_source() in a
>> message handler.  This causes a lo_address to be returned representing
>> the individual connection socket rather than the accept socket.
>> 
>> Steve
>> 
>> 
>> On Mon, Mar 17, 2014 at 5:34 PM, Stephen Sinclair <rad...@gm...> wrote:
>>> Sorry, the gmail ctrl-enter "feature" sent my mail without warning
>>> before I was done...
>>> 
>>> On Mon, Mar 17, 2014 at 5:33 PM, Stephen Sinclair <rad...@gm...> wrote:
>>>> On Mon, Mar 17, 2014 at 3:16 PM, Joseph Malloch
>>>> <jos...@gm...> wrote:
>>>>> Hi all,
>>>>> 
>>>>> I've run into a problem: when using TCP, if a previously-unused lo_server is
>>>>> passed to lo_send_from() it can no longer receive at it's declared port. I
>>>>> have attached a simple test program showing this behaviour - tested on OSX
>>>>> 10.9.2
>>>> 
>>>> Hi Joe,
>>>> 
>>>> I looked at this a bit today but no success yet.  So, just
>>>> acknowledging for now.  FWIW, the output I get with Linux (64-bit) is
>>>> the following:
>>> 
>>> $ ./test_lo_send_from
>>> created server1: osc.tcp://haptics-PC:13375/
>>> created server2: osc.tcp://haptics-PC:14878/
>>> created address1: osc.tcp://haptics-PC:13375/
>>> created address2: osc.tcp://haptics-PC:14878/
>>>  lo_send_from() server2 -> address1
>>>    server1 received message /ping from osc.tcp://127.0.0.1:50979/
>>>  lo_send_from() server1 -> address2
>>>  lo_send_from() server2 -> address1
>>>    server1 received message /ping from osc.tcp://127.0.0.1:50979/
>>>  lo_send_from() server1 -> address2
>>>  lo_send() -> address1
>>>    server1 received message /ping from osc.tcp://127.0.0.1:50979/
>>>  lo_send() -> address2
>>>  lo_send() -> address1
>>>    server1 received message /ping from osc.tcp://127.0.0.1:50979/
>>>  lo_send() -> address2
>>> server1 url: osc.tcp://haptics-PC:13375/
>>> server2 url: osc.tcp://haptics-PC:14878/
>>> 
>>> 
>>> I think in your example you are expecting a "received message" line
>>> after each lo_send_from(), yes?  Definitely a bug.
>>> 
>>> Steve
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Got it.  It was a weird and erroneous initialization of a loop count
in lo_server_recv_raw_recv_stream().  Pull from the master on github.
(Will push to sf soon)

Steve


On Thu, Mar 20, 2014 at 6:26 PM, Stephen Sinclair <rad...@gm...> wrote:
> I still think there is some unexpected behaviour here, but after
> staring at it for a while I realized you aren't doing bi-directional
> communication as expected.  Nonetheless it shouldn't block reception,
> so something's going on when the address socket is added to the
> server's socket list and I haven't quite figured it out yet.
>
> However, you are creating two addresses targeted at the server's
> "accept" socket, so both lo_send_from() calls should be expected to
> create a new connection.  If you want to re-use the connection, it
> must be based on an address returned from lo_message_get_source() in a
> message handler.  This causes a lo_address to be returned representing
> the individual connection socket rather than the accept socket.
>
> Steve
>
>
> On Mon, Mar 17, 2014 at 5:34 PM, Stephen Sinclair <rad...@gm...> wrote:
>> Sorry, the gmail ctrl-enter "feature" sent my mail without warning
>> before I was done...
>>
>> On Mon, Mar 17, 2014 at 5:33 PM, Stephen Sinclair <rad...@gm...> wrote:
>>> On Mon, Mar 17, 2014 at 3:16 PM, Joseph Malloch
>>> <jos...@gm...> wrote:
>>>> Hi all,
>>>>
>>>> I've run into a problem: when using TCP, if a previously-unused lo_server is
>>>> passed to lo_send_from() it can no longer receive at it's declared port. I
>>>> have attached a simple test program showing this behaviour - tested on OSX
>>>> 10.9.2
>>>
>>> Hi Joe,
>>>
>>> I looked at this a bit today but no success yet.  So, just
>>> acknowledging for now.  FWIW, the output I get with Linux (64-bit) is
>>> the following:
>>
>> $ ./test_lo_send_from
>> created server1: osc.tcp://haptics-PC:13375/
>> created server2: osc.tcp://haptics-PC:14878/
>> created address1: osc.tcp://haptics-PC:13375/
>> created address2: osc.tcp://haptics-PC:14878/
>>   lo_send_from() server2 -> address1
>>     server1 received message /ping from osc.tcp://127.0.0.1:50979/
>>   lo_send_from() server1 -> address2
>>   lo_send_from() server2 -> address1
>>     server1 received message /ping from osc.tcp://127.0.0.1:50979/
>>   lo_send_from() server1 -> address2
>>   lo_send() -> address1
>>     server1 received message /ping from osc.tcp://127.0.0.1:50979/
>>   lo_send() -> address2
>>   lo_send() -> address1
>>     server1 received message /ping from osc.tcp://127.0.0.1:50979/
>>   lo_send() -> address2
>> server1 url: osc.tcp://haptics-PC:13375/
>> server2 url: osc.tcp://haptics-PC:14878/
>>
>>
>> I think in your example you are expecting a "received message" line
>> after each lo_send_from(), yes?  Definitely a bug.
>>
>> Steve

I still think there is some unexpected behaviour here, but after
staring at it for a while I realized you aren't doing bi-directional
communication as expected.  Nonetheless it shouldn't block reception,
so something's going on when the address socket is added to the
server's socket list and I haven't quite figured it out yet.

However, you are creating two addresses targeted at the server's
"accept" socket, so both lo_send_from() calls should be expected to
create a new connection.  If you want to re-use the connection, it
must be based on an address returned from lo_message_get_source() in a
message handler.  This causes a lo_address to be returned representing
the individual connection socket rather than the accept socket.

Steve


On Mon, Mar 17, 2014 at 5:34 PM, Stephen Sinclair <rad...@gm...> wrote:
> Sorry, the gmail ctrl-enter "feature" sent my mail without warning
> before I was done...
>
> On Mon, Mar 17, 2014 at 5:33 PM, Stephen Sinclair <rad...@gm...> wrote:
>> On Mon, Mar 17, 2014 at 3:16 PM, Joseph Malloch
>> <jos...@gm...> wrote:
>>> Hi all,
>>>
>>> I've run into a problem: when using TCP, if a previously-unused lo_server is
>>> passed to lo_send_from() it can no longer receive at it's declared port. I
>>> have attached a simple test program showing this behaviour - tested on OSX
>>> 10.9.2
>>
>> Hi Joe,
>>
>> I looked at this a bit today but no success yet.  So, just
>> acknowledging for now.  FWIW, the output I get with Linux (64-bit) is
>> the following:
>
> $ ./test_lo_send_from
> created server1: osc.tcp://haptics-PC:13375/
> created server2: osc.tcp://haptics-PC:14878/
> created address1: osc.tcp://haptics-PC:13375/
> created address2: osc.tcp://haptics-PC:14878/
>   lo_send_from() server2 -> address1
>     server1 received message /ping from osc.tcp://127.0.0.1:50979/
>   lo_send_from() server1 -> address2
>   lo_send_from() server2 -> address1
>     server1 received message /ping from osc.tcp://127.0.0.1:50979/
>   lo_send_from() server1 -> address2
>   lo_send() -> address1
>     server1 received message /ping from osc.tcp://127.0.0.1:50979/
>   lo_send() -> address2
>   lo_send() -> address1
>     server1 received message /ping from osc.tcp://127.0.0.1:50979/
>   lo_send() -> address2
> server1 url: osc.tcp://haptics-PC:13375/
> server2 url: osc.tcp://haptics-PC:14878/
>
>
> I think in your example you are expecting a "received message" line
> after each lo_send_from(), yes?  Definitely a bug.
>
> Steve

Sorry, the gmail ctrl-enter "feature" sent my mail without warning
before I was done...

On Mon, Mar 17, 2014 at 5:33 PM, Stephen Sinclair <rad...@gm...> wrote:
> On Mon, Mar 17, 2014 at 3:16 PM, Joseph Malloch
> <jos...@gm...> wrote:
>> Hi all,
>>
>> I've run into a problem: when using TCP, if a previously-unused lo_server is
>> passed to lo_send_from() it can no longer receive at it's declared port. I
>> have attached a simple test program showing this behaviour - tested on OSX
>> 10.9.2
>
> Hi Joe,
>
> I looked at this a bit today but no success yet.  So, just
> acknowledging for now.  FWIW, the output I get with Linux (64-bit) is
> the following:

$ ./test_lo_send_from
created server1: osc.tcp://haptics-PC:13375/
created server2: osc.tcp://haptics-PC:14878/
created address1: osc.tcp://haptics-PC:13375/
created address2: osc.tcp://haptics-PC:14878/
  lo_send_from() server2 -> address1
    server1 received message /ping from osc.tcp://127.0.0.1:50979/
  lo_send_from() server1 -> address2
  lo_send_from() server2 -> address1
    server1 received message /ping from osc.tcp://127.0.0.1:50979/
  lo_send_from() server1 -> address2
  lo_send() -> address1
    server1 received message /ping from osc.tcp://127.0.0.1:50979/
  lo_send() -> address2
  lo_send() -> address1
    server1 received message /ping from osc.tcp://127.0.0.1:50979/
  lo_send() -> address2
server1 url: osc.tcp://haptics-PC:13375/
server2 url: osc.tcp://haptics-PC:14878/


I think in your example you are expecting a "received message" line
after each lo_send_from(), yes?  Definitely a bug.

Steve

On Mon, Mar 17, 2014 at 3:16 PM, Joseph Malloch
<jos...@gm...> wrote:
> Hi all,
>
> I've run into a problem: when using TCP, if a previously-unused lo_server is
> passed to lo_send_from() it can no longer receive at it's declared port. I
> have attached a simple test program showing this behaviour - tested on OSX
> 10.9.2

Hi Joe,

I looked at this a bit today but no success yet.  So, just
acknowledging for now.  FWIW, the output I get with Linux (64-bit) is
the following:

Hi all,

I've run into a problem: when using TCP, if a previously-unused lo_server
is passed to lo_send_from() it can no longer receive at it's declared port.
I have attached a simple test program showing this behaviour - tested on
OSX 10.9.2

Thanks,
Joe

Joseph Malloch <http://www.josephmalloch.com/>
Postdoctoral Researcher
LRI <https://www.lri.fr/> - In|Situ| <http://insitu.lri.fr/> - IUT Orsay
Université Paris Sud - Bat. 650 (PCRI)
F-91405 ORSAY, FRANCE

And thus it can be a congestion issue.... I only see this behavior on
Windows platform....
++
Le 14 mars 2014 10:40, "nicolas bats" <sl1...@gm...> a écrit :

> sorry for the noise, liblo works like a charm...
> it was just the size of sent message that if they are too bigs introduce
> some delay..
>
> ++
>
>
> 2014-03-13 20:07 GMT+01:00 Stephen Sinclair <rad...@gm...>:
>
>> Ah! So, how are you compiling? Unfortunately there are a multitude of
>> compilers / environments on windows. Usually I test on msys/mingw and I do
>> my best to keep things working with visual studio ...
>>
>> Steve
>>  On Mar 13, 2014 7:32 PM, "nicolas bats" <sl1...@gm...> wrote:
>>
>>> Steve,
>>> After more test, it appears that it's not htonl() related...
>>> What's strange is that I successfully compiled a working liblo (e.g. no
>>> delay...) but I do not succeed in doing it again...
>>>
>>> So maybe it's something with the way I'm compiling...
>>>
>>> ++
>>> Le 13 mars 2014 18:32, "Stephen Sinclair" <rad...@gm...> a écrit
>>> :
>>>
>>>> It is strange, since a glance at the macros suggests that lo_htoo32()
>>>> should simply expand to htonl().  I'll try using gcc's -E flag to look
>>>> at post-preprocessor output and see if that's the case.
>>>>
>>>> Either way I can't see how such a macro would lead to delays..
>>>> interesting.  Could be something a bit subtle.  Which VM are you
>>>> using, Parallels?
>>>>
>>>> Steve
>>>>
>>>>
>>>> On Wed, Mar 12, 2014 at 12:26 PM, nicolas bats <sl1...@gm...>
>>>> wrote:
>>>> > so, after digging a little more....
>>>> > my problem does not come from lo_address_resolve(), so neither from
>>>> > getnameinfo().
>>>> > I'm sending bundle and delay come from lo_bundle_serialise().
>>>> > more precisely from the lo_htoo32() macro.
>>>> >
>>>> > I'm compiling liblo on a virtual windows box on a mac...
>>>> > I don't know if it's related but when I change lo_htoo32() to
>>>> htonl(), delay
>>>> > disappears and everything is smooth even for address that does not
>>>> exists on
>>>> > the network.
>>>> >
>>>> > does it make sense to you?
>>>> > ++
>>>> > Nicolas
>>>> >
>>>> >
>>>> > 2014-03-11 14:33 GMT+01:00 nicolas bats <sl1...@gm...>:
>>>> >
>>>> >> I've moved the lo_address_resolve() at address creation instead of
>>>> at the
>>>> >> send() moment and will be able to test at the end of the week.
>>>> >> Not great I suppose but I think it can be ok for my application...
>>>> >> Best regards,
>>>> >> Nicolas
>>>> >>
>>>> >> Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a
>>>> écrit :
>>>> >>
>>>> >>> The only thing I can think to suggest is that you step through
>>>> >>> lo_address_new() with the debugger and see where the delay actually
>>>> >>> happens.
>>>> >>>
>>>> >>> Steve
>>>> >>>
>>>> >>>
>>>> >>> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...
>>>> >
>>>> >>> wrote:
>>>> >>> > Hi,
>>>> >>> > any thoughts about the way to resolve/improve this?
>>>> >>> >
>>>> >>> > best regards,
>>>> >>> > Nicolas
>>>> >>> >
>>>> >>> >
>>>> >>> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
>>>> >>> >
>>>> >>> >> hello,
>>>> >>> >> first, here's how I initialize the address where I need to write:
>>>> >>> >>
>>>> >>> >> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
>>>> >>> >>
>>>> >>> >>     oscWriter_t* this_W = NULL;
>>>> >>> >>
>>>> >>> >>     struct common_Nodes *node, *tmp;
>>>> >>> >>
>>>> >>> >>     node = tmp = NULL;
>>>> >>> >>
>>>> >>> >> char* buff = NULL;
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>     if(NULL != recordedNodes)
>>>> >>> >>
>>>> >>> >>     {
>>>> >>> >>
>>>> >>> >>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
>>>> >>> >>
>>>> >>> >>             Indic_Error(UNEXPECTED, 0);
>>>> >>> >>
>>>> >>> >>             return;
>>>> >>> >>
>>>> >>> >>         }
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>         HASH_ITER(hh, recordedNodes, node, tmp) {
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
>>>> >>> >>
>>>> >>> >>         {
>>>> >>> >>
>>>> >>> >>             sprintf(buff, "%d", node->port);
>>>> >>> >>
>>>> >>> >>             this_W->addr = lo_address_new(node->ipData , buff);
>>>> >>> >>
>>>> >>> >>             this_W->addr_str = dupstr(node->ipData);
>>>> >>> >>
>>>> >>> >>             this_W->port_str = dupstr(buff);
>>>> >>> >>
>>>> >>> >>             this_W->isUsed = node->idt;
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>            //printf("add %s %s\n", this_W->addr_str,
>>>> >>> >> this_W->port_str);
>>>> >>> >>
>>>> >>> >>             LL_APPEND(writerServer,this_W);
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>         }
>>>> >>> >>
>>>> >>> >>         }
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>         FRI(buff);
>>>> >>> >>
>>>> >>> >>     }
>>>> >>> >>
>>>> >>> >>     return;
>>>> >>> >>
>>>> >>> >> }
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> so it's simply a lo_address_new() and I reuse the address from
>>>> >>> >> this_W->addr.
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...
>>>> >:
>>>> >>> >>
>>>> >>> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <
>>>> sl1...@gm...>
>>>> >>> >>> wrote:
>>>> >>> >>> > Hi,
>>>> >>> >>> > with the latest release (but I don't think it's 0.28 related)
>>>> I can
>>>> >>> >>> > see
>>>> >>> >>> > some
>>>> >>> >>> > behaviors on win that are not particulary desired...
>>>> >>> >>> >
>>>> >>> >>> > let me explain:
>>>> >>> >>> > my app create a server with lo_server_new(), so far so good,
>>>> and I
>>>> >>> >>> > use
>>>> >>> >>> > only
>>>> >>> >>> > UDP.
>>>> >>> >>> > the wifi is off and the firewalls are off.
>>>> >>> >>> > the network card address is 192.168.1.30
>>>> >>> >>> >
>>>> >>> >>> > if I send OSC message to address like 10.x.x.x, as the network
>>>> >>> >>> > can't be
>>>> >>> >>> > reached I don't see any lag, but, if I send OSC message to
>>>> >>> >>> > 192.168.1.x
>>>> >>> >>> > and
>>>> >>> >>> > there's no receiver, I see a huge lag, like if there's a
>>>> timeout or
>>>> >>> >>> > something like this.
>>>> >>> >>> > did you guys noticed the same behavior?
>>>> >>> >>> > any leads in order to find wich call is reponsible of lag?
>>>> >>> >>>
>>>> >>> >>> It would be good to know if it's a write() call for example.
>>>>  Also,
>>>> >>> >>> does the lag occur only the first time, or every time?
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> within my app, it happens all the time
>>>> >>> >>
>>>> >>> >>>
>>>> >>> >>>  I wonder if
>>>> >>> >>> it's more of a name resolution bug, could be something regarding
>>>> >>> >>> initializing a lo_address.
>>>> >>> >>>
>>>> >>> >>> What is "huge lag" exactly?  A few ms, a few seconds, a minute
>>>> or
>>>> >>> >>> more?
>>>> >>> >>
>>>> >>> >> let's say a few seconds, but more than your log shows
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> Possibly stepping through the code in gdb starting at lo_send()
>>>> might
>>>> >>> >>> help.
>>>> >>> >>>
>>>> >>> >>> Here on my Windows 7 machine I do see a short lag of a couple of
>>>> >>> >>> seconds when sending to an unknown address using oscsend.exe,
>>>> but it
>>>> >>> >>> seems to go away the second and third times I run it.  If I
>>>> change
>>>> >>> >>> the
>>>> >>> >>> last number of the IP address I get the lag again, only once.
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> even once it's a shame...
>>>> >>> >> can't we get rid of that?
>>>> >>> >>
>>>> >>> >>>
>>>> >>> >>>  Here is
>>>> >>> >>> a dump:
>>>> >>> >>>
>>>> >>> >>> (This is compiled with MingW, and one of my NICs is configured
>>>> to
>>>> >>> >>> 192.168.56.1 / 255.255.255.0)
>>>> >>> >>>
>>>> >>> >>> -------------------------------
>>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>>> >>> >>>
>>>> >>> >>> real    0m2.644s
>>>> >>> >>> user    0m0.000s
>>>> >>> >>> sys     0m0.015s
>>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>>> >>> >>>
>>>> >>> >>> real    0m0.037s
>>>> >>> >>> user    0m0.015s
>>>> >>> >>> sys     0m0.000s
>>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>>> >>> >>>
>>>> >>> >>> real    0m0.037s
>>>> >>> >>> user    0m0.015s
>>>> >>> >>> sys     0m0.000s
>>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>>> >>> >>>
>>>> >>> >>> real    0m2.596s
>>>> >>> >>> user    0m0.000s
>>>> >>> >>> sys     0m0.015s
>>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>>> >>> >>>
>>>> >>> >>> real    0m0.038s
>>>> >>> >>> user    0m0.000s
>>>> >>> >>> sys     0m0.015s
>>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>>> >>> >>>
>>>> >>> >>> real    0m0.040s
>>>> >>> >>> user    0m0.000s
>>>> >>> >>> sys     0m0.015s
>>>> >>> >>> -------------------------------
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> for the same address, mine shows 0m2.928s (more or less) every
>>>> time.
>>>> >>> >> the same as with new address
>>>> >>> >>
>>>> >>> >> ++
>>>> >>> >> NIcolas
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> Steve
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>>
>>>> ------------------------------------------------------------------------------
>>>> >>> >>> Flow-based real-time traffic analytics software. Cisco certified
>>>> >>> >>> tool.
>>>> >>> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
>>>> Analyzer
>>>> >>> >>> Customize your own dashboards, set traffic alerts and generate
>>>> >>> >>> reports.
>>>> >>> >>> Network behavioral analysis & security monitoring. All-in-one
>>>> tool.
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>>> >>> >>> _______________________________________________
>>>> >>> >>> liblo-devel mailing list
>>>> >>> >>> lib...@li...
>>>> >>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>> >>> >>
>>>> >>> >>
>>>> >>> >
>>>> >>> >
>>>> >>> >
>>>> >>> >
>>>> ------------------------------------------------------------------------------
>>>> >>> > Learn Graph Databases - Download FREE O'Reilly Book
>>>> >>> > "Graph Databases" is the definitive new guide to graph databases
>>>> and
>>>> >>> > their
>>>> >>> > applications. Written by three acclaimed leaders in the field,
>>>> >>> > this first edition is now available. Download your free book
>>>> today!
>>>> >>> > http://p.sf.net/sfu/13534_NeoTech
>>>> >>> > _______________________________________________
>>>> >>> > liblo-devel mailing list
>>>> >>> > lib...@li...
>>>> >>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>> >>> >
>>>> >>>
>>>> >>>
>>>> >>>
>>>> ------------------------------------------------------------------------------
>>>> >>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> >>> "Graph Databases" is the definitive new guide to graph databases and
>>>> >>> their
>>>> >>> applications. Written by three acclaimed leaders in the field,
>>>> >>> this first edition is now available. Download your free book today!
>>>> >>> http://p.sf.net/sfu/13534_NeoTech
>>>> >>> _______________________________________________
>>>> >>> liblo-devel mailing list
>>>> >>> lib...@li...
>>>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>> >
>>>> >
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > Learn Graph Databases - Download FREE O'Reilly Book
>>>> > "Graph Databases" is the definitive new guide to graph databases and
>>>> their
>>>> > applications. Written by three acclaimed leaders in the field,
>>>> > this first edition is now available. Download your free book today!
>>>> > http://p.sf.net/sfu/13534_NeoTech
>>>> > _______________________________________________
>>>> > liblo-devel mailing list
>>>> > lib...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and
>>>> their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/13534_NeoTech
>>>> _______________________________________________
>>>> liblo-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>

On Thu, Mar 13, 2014 at 9:05 PM, Alexandre Quessy <ale...@qu...> wrote:
> Hello dear friends, :)
>
> 2014-03-13 13:25 GMT-04:00 Stephen Sinclair <rad...@gm...>:
>
>>
>> Ah you're right, sorry.  Um, although I don't see anything in the code
>> that actually handles the error condition.  Is it possible it's just
>> crashing because it assumes server_ is valid?  Try setting a validity
>> flag from the OscReceiver::error() function.
>>
>
> That's right! Now, I fixed it temporarily using a static condition variable.
> It was crashing when I was calling lo_server_thread_add_method on an invalid
> server. (since the port was busy) How can check if the server is valid?
> Should it be simply NULL if the port is busy? That would be cleaner than
> using a static variable. (so that I can potentially have many OSC receivers
> in the same application)
>
> https://github.com/mapmapteam/mapmap/blob/video/OscReceiver.cpp#L26

Ah, I was going to suggest you use the error_context functions
mentioned in a previous email, but I just noticed there is an issue in
this particular case.  If the lo_server_thread hasn't yet initialized
there is no chance to call lo_server_set_error_context() before the
error handler gets called...

This actually leads to a crash in cpptest.cpp if the port isn't
available.  I'll have to add a null-check to the error handler.

Don't know if there's a solution to this. But in case case, it should
return null if it doesn't successfully initialize.


Steve

sorry for the noise, liblo works like a charm...
it was just the size of sent message that if they are too bigs introduce
some delay..

++


2014-03-13 20:07 GMT+01:00 Stephen Sinclair <rad...@gm...>:

> Ah! So, how are you compiling? Unfortunately there are a multitude of
> compilers / environments on windows. Usually I test on msys/mingw and I do
> my best to keep things working with visual studio ...
>
> Steve
>  On Mar 13, 2014 7:32 PM, "nicolas bats" <sl1...@gm...> wrote:
>
>> Steve,
>> After more test, it appears that it's not htonl() related...
>> What's strange is that I successfully compiled a working liblo (e.g. no
>> delay...) but I do not succeed in doing it again...
>>
>> So maybe it's something with the way I'm compiling...
>>
>> ++
>> Le 13 mars 2014 18:32, "Stephen Sinclair" <rad...@gm...> a écrit :
>>
>>> It is strange, since a glance at the macros suggests that lo_htoo32()
>>> should simply expand to htonl().  I'll try using gcc's -E flag to look
>>> at post-preprocessor output and see if that's the case.
>>>
>>> Either way I can't see how such a macro would lead to delays..
>>> interesting.  Could be something a bit subtle.  Which VM are you
>>> using, Parallels?
>>>
>>> Steve
>>>
>>>
>>> On Wed, Mar 12, 2014 at 12:26 PM, nicolas bats <sl1...@gm...>
>>> wrote:
>>> > so, after digging a little more....
>>> > my problem does not come from lo_address_resolve(), so neither from
>>> > getnameinfo().
>>> > I'm sending bundle and delay come from lo_bundle_serialise().
>>> > more precisely from the lo_htoo32() macro.
>>> >
>>> > I'm compiling liblo on a virtual windows box on a mac...
>>> > I don't know if it's related but when I change lo_htoo32() to htonl(),
>>> delay
>>> > disappears and everything is smooth even for address that does not
>>> exists on
>>> > the network.
>>> >
>>> > does it make sense to you?
>>> > ++
>>> > Nicolas
>>> >
>>> >
>>> > 2014-03-11 14:33 GMT+01:00 nicolas bats <sl1...@gm...>:
>>> >
>>> >> I've moved the lo_address_resolve() at address creation instead of at
>>> the
>>> >> send() moment and will be able to test at the end of the week.
>>> >> Not great I suppose but I think it can be ok for my application...
>>> >> Best regards,
>>> >> Nicolas
>>> >>
>>> >> Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a
>>> écrit :
>>> >>
>>> >>> The only thing I can think to suggest is that you step through
>>> >>> lo_address_new() with the debugger and see where the delay actually
>>> >>> happens.
>>> >>>
>>> >>> Steve
>>> >>>
>>> >>>
>>> >>> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...>
>>> >>> wrote:
>>> >>> > Hi,
>>> >>> > any thoughts about the way to resolve/improve this?
>>> >>> >
>>> >>> > best regards,
>>> >>> > Nicolas
>>> >>> >
>>> >>> >
>>> >>> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
>>> >>> >
>>> >>> >> hello,
>>> >>> >> first, here's how I initialize the address where I need to write:
>>> >>> >>
>>> >>> >> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
>>> >>> >>
>>> >>> >>     oscWriter_t* this_W = NULL;
>>> >>> >>
>>> >>> >>     struct common_Nodes *node, *tmp;
>>> >>> >>
>>> >>> >>     node = tmp = NULL;
>>> >>> >>
>>> >>> >> char* buff = NULL;
>>> >>> >>
>>> >>> >>
>>> >>> >>     if(NULL != recordedNodes)
>>> >>> >>
>>> >>> >>     {
>>> >>> >>
>>> >>> >>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
>>> >>> >>
>>> >>> >>             Indic_Error(UNEXPECTED, 0);
>>> >>> >>
>>> >>> >>             return;
>>> >>> >>
>>> >>> >>         }
>>> >>> >>
>>> >>> >>
>>> >>> >>         HASH_ITER(hh, recordedNodes, node, tmp) {
>>> >>> >>
>>> >>> >>
>>> >>> >>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
>>> >>> >>
>>> >>> >>         {
>>> >>> >>
>>> >>> >>             sprintf(buff, "%d", node->port);
>>> >>> >>
>>> >>> >>             this_W->addr = lo_address_new(node->ipData , buff);
>>> >>> >>
>>> >>> >>             this_W->addr_str = dupstr(node->ipData);
>>> >>> >>
>>> >>> >>             this_W->port_str = dupstr(buff);
>>> >>> >>
>>> >>> >>             this_W->isUsed = node->idt;
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >>            //printf("add %s %s\n", this_W->addr_str,
>>> >>> >> this_W->port_str);
>>> >>> >>
>>> >>> >>             LL_APPEND(writerServer,this_W);
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >>         }
>>> >>> >>
>>> >>> >>         }
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >>         FRI(buff);
>>> >>> >>
>>> >>> >>     }
>>> >>> >>
>>> >>> >>     return;
>>> >>> >>
>>> >>> >> }
>>> >>> >>
>>> >>> >>
>>> >>> >> so it's simply a lo_address_new() and I reuse the address from
>>> >>> >> this_W->addr.
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...
>>> >:
>>> >>> >>
>>> >>> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <
>>> sl1...@gm...>
>>> >>> >>> wrote:
>>> >>> >>> > Hi,
>>> >>> >>> > with the latest release (but I don't think it's 0.28 related)
>>> I can
>>> >>> >>> > see
>>> >>> >>> > some
>>> >>> >>> > behaviors on win that are not particulary desired...
>>> >>> >>> >
>>> >>> >>> > let me explain:
>>> >>> >>> > my app create a server with lo_server_new(), so far so good,
>>> and I
>>> >>> >>> > use
>>> >>> >>> > only
>>> >>> >>> > UDP.
>>> >>> >>> > the wifi is off and the firewalls are off.
>>> >>> >>> > the network card address is 192.168.1.30
>>> >>> >>> >
>>> >>> >>> > if I send OSC message to address like 10.x.x.x, as the network
>>> >>> >>> > can't be
>>> >>> >>> > reached I don't see any lag, but, if I send OSC message to
>>> >>> >>> > 192.168.1.x
>>> >>> >>> > and
>>> >>> >>> > there's no receiver, I see a huge lag, like if there's a
>>> timeout or
>>> >>> >>> > something like this.
>>> >>> >>> > did you guys noticed the same behavior?
>>> >>> >>> > any leads in order to find wich call is reponsible of lag?
>>> >>> >>>
>>> >>> >>> It would be good to know if it's a write() call for example.
>>>  Also,
>>> >>> >>> does the lag occur only the first time, or every time?
>>> >>> >>
>>> >>> >>
>>> >>> >> within my app, it happens all the time
>>> >>> >>
>>> >>> >>>
>>> >>> >>>  I wonder if
>>> >>> >>> it's more of a name resolution bug, could be something regarding
>>> >>> >>> initializing a lo_address.
>>> >>> >>>
>>> >>> >>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or
>>> >>> >>> more?
>>> >>> >>
>>> >>> >> let's say a few seconds, but more than your log shows
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> Possibly stepping through the code in gdb starting at lo_send()
>>> might
>>> >>> >>> help.
>>> >>> >>>
>>> >>> >>> Here on my Windows 7 machine I do see a short lag of a couple of
>>> >>> >>> seconds when sending to an unknown address using oscsend.exe,
>>> but it
>>> >>> >>> seems to go away the second and third times I run it.  If I
>>> change
>>> >>> >>> the
>>> >>> >>> last number of the IP address I get the lag again, only once.
>>> >>> >>
>>> >>> >>
>>> >>> >> even once it's a shame...
>>> >>> >> can't we get rid of that?
>>> >>> >>
>>> >>> >>>
>>> >>> >>>  Here is
>>> >>> >>> a dump:
>>> >>> >>>
>>> >>> >>> (This is compiled with MingW, and one of my NICs is configured to
>>> >>> >>> 192.168.56.1 / 255.255.255.0)
>>> >>> >>>
>>> >>> >>> -------------------------------
>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>> >>>
>>> >>> >>> real    0m2.644s
>>> >>> >>> user    0m0.000s
>>> >>> >>> sys     0m0.015s
>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>> >>>
>>> >>> >>> real    0m0.037s
>>> >>> >>> user    0m0.015s
>>> >>> >>> sys     0m0.000s
>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>> >>>
>>> >>> >>> real    0m0.037s
>>> >>> >>> user    0m0.015s
>>> >>> >>> sys     0m0.000s
>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>> >>>
>>> >>> >>> real    0m2.596s
>>> >>> >>> user    0m0.000s
>>> >>> >>> sys     0m0.015s
>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>> >>>
>>> >>> >>> real    0m0.038s
>>> >>> >>> user    0m0.000s
>>> >>> >>> sys     0m0.015s
>>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>> >>>
>>> >>> >>> real    0m0.040s
>>> >>> >>> user    0m0.000s
>>> >>> >>> sys     0m0.015s
>>> >>> >>> -------------------------------
>>> >>> >>
>>> >>> >>
>>> >>> >> for the same address, mine shows 0m2.928s (more or less) every
>>> time.
>>> >>> >> the same as with new address
>>> >>> >>
>>> >>> >> ++
>>> >>> >> NIcolas
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> Steve
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> ------------------------------------------------------------------------------
>>> >>> >>> Flow-based real-time traffic analytics software. Cisco certified
>>> >>> >>> tool.
>>> >>> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
>>> Analyzer
>>> >>> >>> Customize your own dashboards, set traffic alerts and generate
>>> >>> >>> reports.
>>> >>> >>> Network behavioral analysis & security monitoring. All-in-one
>>> tool.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>> >>> >>> _______________________________________________
>>> >>> >>> liblo-devel mailing list
>>> >>> >>> lib...@li...
>>> >>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> >>> >>
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> >
>>> ------------------------------------------------------------------------------
>>> >>> > Learn Graph Databases - Download FREE O'Reilly Book
>>> >>> > "Graph Databases" is the definitive new guide to graph databases
>>> and
>>> >>> > their
>>> >>> > applications. Written by three acclaimed leaders in the field,
>>> >>> > this first edition is now available. Download your free book today!
>>> >>> > http://p.sf.net/sfu/13534_NeoTech
>>> >>> > _______________________________________________
>>> >>> > liblo-devel mailing list
>>> >>> > lib...@li...
>>> >>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>> ------------------------------------------------------------------------------
>>> >>> Learn Graph Databases - Download FREE O'Reilly Book
>>> >>> "Graph Databases" is the definitive new guide to graph databases and
>>> >>> their
>>> >>> applications. Written by three acclaimed leaders in the field,
>>> >>> this first edition is now available. Download your free book today!
>>> >>> http://p.sf.net/sfu/13534_NeoTech
>>> >>> _______________________________________________
>>> >>> liblo-devel mailing list
>>> >>> lib...@li...
>>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Learn Graph Databases - Download FREE O'Reilly Book
>>> > "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> > applications. Written by three acclaimed leaders in the field,
>>> > this first edition is now available. Download your free book today!
>>> > http://p.sf.net/sfu/13534_NeoTech
>>> > _______________________________________________
>>> > liblo-devel mailing list
>>> > lib...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Hello dear friends, :)

2014-03-13 13:25 GMT-04:00 Stephen Sinclair <rad...@gm...>:

>
> Ah you're right, sorry.  Um, although I don't see anything in the code
> that actually handles the error condition.  Is it possible it's just
> crashing because it assumes server_ is valid?  Try setting a validity
> flag from the OscReceiver::error() function.
>
>
That's right! Now, I fixed it temporarily using a static condition
variable. It was crashing when I was calling lo_server_thread_add_method on
an invalid server. (since the port was busy) How can check if the server is
valid? Should it be simply NULL if the port is busy? That would be cleaner
than using a static variable. (so that I can potentially have many OSC
receivers in the same application)

https://github.com/mapmapteam/mapmap/blob/video/OscReceiver.cpp#L26

Best,
-- 
Alexandre Quessy
http://alexandre.quessy.net - Artiste en nouveaux médias
http://perte-de-signal.org - Membre de Perte de signal

Ah! So, how are you compiling? Unfortunately there are a multitude of
compilers / environments on windows. Usually I test on msys/mingw and I do
my best to keep things working with visual studio ...

Steve
 On Mar 13, 2014 7:32 PM, "nicolas bats" <sl1...@gm...> wrote:

> Steve,
> After more test, it appears that it's not htonl() related...
> What's strange is that I successfully compiled a working liblo (e.g. no
> delay...) but I do not succeed in doing it again...
>
> So maybe it's something with the way I'm compiling...
>
> ++
> Le 13 mars 2014 18:32, "Stephen Sinclair" <rad...@gm...> a écrit :
>
>> It is strange, since a glance at the macros suggests that lo_htoo32()
>> should simply expand to htonl().  I'll try using gcc's -E flag to look
>> at post-preprocessor output and see if that's the case.
>>
>> Either way I can't see how such a macro would lead to delays..
>> interesting.  Could be something a bit subtle.  Which VM are you
>> using, Parallels?
>>
>> Steve
>>
>>
>> On Wed, Mar 12, 2014 at 12:26 PM, nicolas bats <sl1...@gm...>
>> wrote:
>> > so, after digging a little more....
>> > my problem does not come from lo_address_resolve(), so neither from
>> > getnameinfo().
>> > I'm sending bundle and delay come from lo_bundle_serialise().
>> > more precisely from the lo_htoo32() macro.
>> >
>> > I'm compiling liblo on a virtual windows box on a mac...
>> > I don't know if it's related but when I change lo_htoo32() to htonl(),
>> delay
>> > disappears and everything is smooth even for address that does not
>> exists on
>> > the network.
>> >
>> > does it make sense to you?
>> > ++
>> > Nicolas
>> >
>> >
>> > 2014-03-11 14:33 GMT+01:00 nicolas bats <sl1...@gm...>:
>> >
>> >> I've moved the lo_address_resolve() at address creation instead of at
>> the
>> >> send() moment and will be able to test at the end of the week.
>> >> Not great I suppose but I think it can be ok for my application...
>> >> Best regards,
>> >> Nicolas
>> >>
>> >> Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a
>> écrit :
>> >>
>> >>> The only thing I can think to suggest is that you step through
>> >>> lo_address_new() with the debugger and see where the delay actually
>> >>> happens.
>> >>>
>> >>> Steve
>> >>>
>> >>>
>> >>> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...>
>> >>> wrote:
>> >>> > Hi,
>> >>> > any thoughts about the way to resolve/improve this?
>> >>> >
>> >>> > best regards,
>> >>> > Nicolas
>> >>> >
>> >>> >
>> >>> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
>> >>> >
>> >>> >> hello,
>> >>> >> first, here's how I initialize the address where I need to write:
>> >>> >>
>> >>> >> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
>> >>> >>
>> >>> >>     oscWriter_t* this_W = NULL;
>> >>> >>
>> >>> >>     struct common_Nodes *node, *tmp;
>> >>> >>
>> >>> >>     node = tmp = NULL;
>> >>> >>
>> >>> >> char* buff = NULL;
>> >>> >>
>> >>> >>
>> >>> >>     if(NULL != recordedNodes)
>> >>> >>
>> >>> >>     {
>> >>> >>
>> >>> >>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
>> >>> >>
>> >>> >>             Indic_Error(UNEXPECTED, 0);
>> >>> >>
>> >>> >>             return;
>> >>> >>
>> >>> >>         }
>> >>> >>
>> >>> >>
>> >>> >>         HASH_ITER(hh, recordedNodes, node, tmp) {
>> >>> >>
>> >>> >>
>> >>> >>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
>> >>> >>
>> >>> >>         {
>> >>> >>
>> >>> >>             sprintf(buff, "%d", node->port);
>> >>> >>
>> >>> >>             this_W->addr = lo_address_new(node->ipData , buff);
>> >>> >>
>> >>> >>             this_W->addr_str = dupstr(node->ipData);
>> >>> >>
>> >>> >>             this_W->port_str = dupstr(buff);
>> >>> >>
>> >>> >>             this_W->isUsed = node->idt;
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>            //printf("add %s %s\n", this_W->addr_str,
>> >>> >> this_W->port_str);
>> >>> >>
>> >>> >>             LL_APPEND(writerServer,this_W);
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>         }
>> >>> >>
>> >>> >>         }
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>         FRI(buff);
>> >>> >>
>> >>> >>     }
>> >>> >>
>> >>> >>     return;
>> >>> >>
>> >>> >> }
>> >>> >>
>> >>> >>
>> >>> >> so it's simply a lo_address_new() and I reuse the address from
>> >>> >> this_W->addr.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
>> >>> >>
>> >>> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <
>> sl1...@gm...>
>> >>> >>> wrote:
>> >>> >>> > Hi,
>> >>> >>> > with the latest release (but I don't think it's 0.28 related) I
>> can
>> >>> >>> > see
>> >>> >>> > some
>> >>> >>> > behaviors on win that are not particulary desired...
>> >>> >>> >
>> >>> >>> > let me explain:
>> >>> >>> > my app create a server with lo_server_new(), so far so good,
>> and I
>> >>> >>> > use
>> >>> >>> > only
>> >>> >>> > UDP.
>> >>> >>> > the wifi is off and the firewalls are off.
>> >>> >>> > the network card address is 192.168.1.30
>> >>> >>> >
>> >>> >>> > if I send OSC message to address like 10.x.x.x, as the network
>> >>> >>> > can't be
>> >>> >>> > reached I don't see any lag, but, if I send OSC message to
>> >>> >>> > 192.168.1.x
>> >>> >>> > and
>> >>> >>> > there's no receiver, I see a huge lag, like if there's a
>> timeout or
>> >>> >>> > something like this.
>> >>> >>> > did you guys noticed the same behavior?
>> >>> >>> > any leads in order to find wich call is reponsible of lag?
>> >>> >>>
>> >>> >>> It would be good to know if it's a write() call for example.
>>  Also,
>> >>> >>> does the lag occur only the first time, or every time?
>> >>> >>
>> >>> >>
>> >>> >> within my app, it happens all the time
>> >>> >>
>> >>> >>>
>> >>> >>>  I wonder if
>> >>> >>> it's more of a name resolution bug, could be something regarding
>> >>> >>> initializing a lo_address.
>> >>> >>>
>> >>> >>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or
>> >>> >>> more?
>> >>> >>
>> >>> >> let's say a few seconds, but more than your log shows
>> >>> >>>
>> >>> >>>
>> >>> >>> Possibly stepping through the code in gdb starting at lo_send()
>> might
>> >>> >>> help.
>> >>> >>>
>> >>> >>> Here on my Windows 7 machine I do see a short lag of a couple of
>> >>> >>> seconds when sending to an unknown address using oscsend.exe, but
>> it
>> >>> >>> seems to go away the second and third times I run it.  If I change
>> >>> >>> the
>> >>> >>> last number of the IP address I get the lag again, only once.
>> >>> >>
>> >>> >>
>> >>> >> even once it's a shame...
>> >>> >> can't we get rid of that?
>> >>> >>
>> >>> >>>
>> >>> >>>  Here is
>> >>> >>> a dump:
>> >>> >>>
>> >>> >>> (This is compiled with MingW, and one of my NICs is configured to
>> >>> >>> 192.168.56.1 / 255.255.255.0)
>> >>> >>>
>> >>> >>> -------------------------------
>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>> >>> >>>
>> >>> >>> real    0m2.644s
>> >>> >>> user    0m0.000s
>> >>> >>> sys     0m0.015s
>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>> >>> >>>
>> >>> >>> real    0m0.037s
>> >>> >>> user    0m0.015s
>> >>> >>> sys     0m0.000s
>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>> >>> >>>
>> >>> >>> real    0m0.037s
>> >>> >>> user    0m0.015s
>> >>> >>> sys     0m0.000s
>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>> >>> >>>
>> >>> >>> real    0m2.596s
>> >>> >>> user    0m0.000s
>> >>> >>> sys     0m0.015s
>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>> >>> >>>
>> >>> >>> real    0m0.038s
>> >>> >>> user    0m0.000s
>> >>> >>> sys     0m0.015s
>> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>> >>> >>>
>> >>> >>> real    0m0.040s
>> >>> >>> user    0m0.000s
>> >>> >>> sys     0m0.015s
>> >>> >>> -------------------------------
>> >>> >>
>> >>> >>
>> >>> >> for the same address, mine shows 0m2.928s (more or less) every
>> time.
>> >>> >> the same as with new address
>> >>> >>
>> >>> >> ++
>> >>> >> NIcolas
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> Steve
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> ------------------------------------------------------------------------------
>> >>> >>> Flow-based real-time traffic analytics software. Cisco certified
>> >>> >>> tool.
>> >>> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
>> Analyzer
>> >>> >>> Customize your own dashboards, set traffic alerts and generate
>> >>> >>> reports.
>> >>> >>> Network behavioral analysis & security monitoring. All-in-one
>> tool.
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>> >>> >>> _______________________________________________
>> >>> >>> liblo-devel mailing list
>> >>> >>> lib...@li...
>> >>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> ------------------------------------------------------------------------------
>> >>> > Learn Graph Databases - Download FREE O'Reilly Book
>> >>> > "Graph Databases" is the definitive new guide to graph databases and
>> >>> > their
>> >>> > applications. Written by three acclaimed leaders in the field,
>> >>> > this first edition is now available. Download your free book today!
>> >>> > http://p.sf.net/sfu/13534_NeoTech
>> >>> > _______________________________________________
>> >>> > liblo-devel mailing list
>> >>> > lib...@li...
>> >>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>> >
>> >>>
>> >>>
>> >>>
>> ------------------------------------------------------------------------------
>> >>> Learn Graph Databases - Download FREE O'Reilly Book
>> >>> "Graph Databases" is the definitive new guide to graph databases and
>> >>> their
>> >>> applications. Written by three acclaimed leaders in the field,
>> >>> this first edition is now available. Download your free book today!
>> >>> http://p.sf.net/sfu/13534_NeoTech
>> >>> _______________________________________________
>> >>> liblo-devel mailing list
>> >>> lib...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Learn Graph Databases - Download FREE O'Reilly Book
>> > "Graph Databases" is the definitive new guide to graph databases and
>> their
>> > applications. Written by three acclaimed leaders in the field,
>> > this first edition is now available. Download your free book today!
>> > http://p.sf.net/sfu/13534_NeoTech
>> > _______________________________________________
>> > liblo-devel mailing list
>> > lib...@li...
>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

I'm using wmware...
Le 13 mars 2014 18:32, "Stephen Sinclair" <rad...@gm...> a écrit :

> It is strange, since a glance at the macros suggests that lo_htoo32()
> should simply expand to htonl().  I'll try using gcc's -E flag to look
> at post-preprocessor output and see if that's the case.
>
> Either way I can't see how such a macro would lead to delays..
> interesting.  Could be something a bit subtle.  Which VM are you
> using, Parallels?
>
> Steve
>
>
> On Wed, Mar 12, 2014 at 12:26 PM, nicolas bats <sl1...@gm...>
> wrote:
> > so, after digging a little more....
> > my problem does not come from lo_address_resolve(), so neither from
> > getnameinfo().
> > I'm sending bundle and delay come from lo_bundle_serialise().
> > more precisely from the lo_htoo32() macro.
> >
> > I'm compiling liblo on a virtual windows box on a mac...
> > I don't know if it's related but when I change lo_htoo32() to htonl(),
> delay
> > disappears and everything is smooth even for address that does not
> exists on
> > the network.
> >
> > does it make sense to you?
> > ++
> > Nicolas
> >
> >
> > 2014-03-11 14:33 GMT+01:00 nicolas bats <sl1...@gm...>:
> >
> >> I've moved the lo_address_resolve() at address creation instead of at
> the
> >> send() moment and will be able to test at the end of the week.
> >> Not great I suppose but I think it can be ok for my application...
> >> Best regards,
> >> Nicolas
> >>
> >> Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a
> écrit :
> >>
> >>> The only thing I can think to suggest is that you step through
> >>> lo_address_new() with the debugger and see where the delay actually
> >>> happens.
> >>>
> >>> Steve
> >>>
> >>>
> >>> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...>
> >>> wrote:
> >>> > Hi,
> >>> > any thoughts about the way to resolve/improve this?
> >>> >
> >>> > best regards,
> >>> > Nicolas
> >>> >
> >>> >
> >>> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
> >>> >
> >>> >> hello,
> >>> >> first, here's how I initialize the address where I need to write:
> >>> >>
> >>> >> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
> >>> >>
> >>> >>     oscWriter_t* this_W = NULL;
> >>> >>
> >>> >>     struct common_Nodes *node, *tmp;
> >>> >>
> >>> >>     node = tmp = NULL;
> >>> >>
> >>> >> char* buff = NULL;
> >>> >>
> >>> >>
> >>> >>     if(NULL != recordedNodes)
> >>> >>
> >>> >>     {
> >>> >>
> >>> >>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
> >>> >>
> >>> >>             Indic_Error(UNEXPECTED, 0);
> >>> >>
> >>> >>             return;
> >>> >>
> >>> >>         }
> >>> >>
> >>> >>
> >>> >>         HASH_ITER(hh, recordedNodes, node, tmp) {
> >>> >>
> >>> >>
> >>> >>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
> >>> >>
> >>> >>         {
> >>> >>
> >>> >>             sprintf(buff, "%d", node->port);
> >>> >>
> >>> >>             this_W->addr = lo_address_new(node->ipData , buff);
> >>> >>
> >>> >>             this_W->addr_str = dupstr(node->ipData);
> >>> >>
> >>> >>             this_W->port_str = dupstr(buff);
> >>> >>
> >>> >>             this_W->isUsed = node->idt;
> >>> >>
> >>> >>
> >>> >>
> >>> >>            //printf("add %s %s\n", this_W->addr_str,
> >>> >> this_W->port_str);
> >>> >>
> >>> >>             LL_APPEND(writerServer,this_W);
> >>> >>
> >>> >>
> >>> >>
> >>> >>         }
> >>> >>
> >>> >>         }
> >>> >>
> >>> >>
> >>> >>
> >>> >>         FRI(buff);
> >>> >>
> >>> >>     }
> >>> >>
> >>> >>     return;
> >>> >>
> >>> >> }
> >>> >>
> >>> >>
> >>> >> so it's simply a lo_address_new() and I reuse the address from
> >>> >> this_W->addr.
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
> >>> >>
> >>> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <
> sl1...@gm...>
> >>> >>> wrote:
> >>> >>> > Hi,
> >>> >>> > with the latest release (but I don't think it's 0.28 related) I
> can
> >>> >>> > see
> >>> >>> > some
> >>> >>> > behaviors on win that are not particulary desired...
> >>> >>> >
> >>> >>> > let me explain:
> >>> >>> > my app create a server with lo_server_new(), so far so good, and
> I
> >>> >>> > use
> >>> >>> > only
> >>> >>> > UDP.
> >>> >>> > the wifi is off and the firewalls are off.
> >>> >>> > the network card address is 192.168.1.30
> >>> >>> >
> >>> >>> > if I send OSC message to address like 10.x.x.x, as the network
> >>> >>> > can't be
> >>> >>> > reached I don't see any lag, but, if I send OSC message to
> >>> >>> > 192.168.1.x
> >>> >>> > and
> >>> >>> > there's no receiver, I see a huge lag, like if there's a timeout
> or
> >>> >>> > something like this.
> >>> >>> > did you guys noticed the same behavior?
> >>> >>> > any leads in order to find wich call is reponsible of lag?
> >>> >>>
> >>> >>> It would be good to know if it's a write() call for example.  Also,
> >>> >>> does the lag occur only the first time, or every time?
> >>> >>
> >>> >>
> >>> >> within my app, it happens all the time
> >>> >>
> >>> >>>
> >>> >>>  I wonder if
> >>> >>> it's more of a name resolution bug, could be something regarding
> >>> >>> initializing a lo_address.
> >>> >>>
> >>> >>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or
> >>> >>> more?
> >>> >>
> >>> >> let's say a few seconds, but more than your log shows
> >>> >>>
> >>> >>>
> >>> >>> Possibly stepping through the code in gdb starting at lo_send()
> might
> >>> >>> help.
> >>> >>>
> >>> >>> Here on my Windows 7 machine I do see a short lag of a couple of
> >>> >>> seconds when sending to an unknown address using oscsend.exe, but
> it
> >>> >>> seems to go away the second and third times I run it.  If I change
> >>> >>> the
> >>> >>> last number of the IP address I get the lag again, only once.
> >>> >>
> >>> >>
> >>> >> even once it's a shame...
> >>> >> can't we get rid of that?
> >>> >>
> >>> >>>
> >>> >>>  Here is
> >>> >>> a dump:
> >>> >>>
> >>> >>> (This is compiled with MingW, and one of my NICs is configured to
> >>> >>> 192.168.56.1 / 255.255.255.0)
> >>> >>>
> >>> >>> -------------------------------
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>> >>>
> >>> >>> real    0m2.644s
> >>> >>> user    0m0.000s
> >>> >>> sys     0m0.015s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>> >>>
> >>> >>> real    0m0.037s
> >>> >>> user    0m0.015s
> >>> >>> sys     0m0.000s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>> >>>
> >>> >>> real    0m0.037s
> >>> >>> user    0m0.015s
> >>> >>> sys     0m0.000s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>> >>>
> >>> >>> real    0m2.596s
> >>> >>> user    0m0.000s
> >>> >>> sys     0m0.015s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>> >>>
> >>> >>> real    0m0.038s
> >>> >>> user    0m0.000s
> >>> >>> sys     0m0.015s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>> >>>
> >>> >>> real    0m0.040s
> >>> >>> user    0m0.000s
> >>> >>> sys     0m0.015s
> >>> >>> -------------------------------
> >>> >>
> >>> >>
> >>> >> for the same address, mine shows 0m2.928s (more or less) every time.
> >>> >> the same as with new address
> >>> >>
> >>> >> ++
> >>> >> NIcolas
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Steve
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> ------------------------------------------------------------------------------
> >>> >>> Flow-based real-time traffic analytics software. Cisco certified
> >>> >>> tool.
> >>> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
> Analyzer
> >>> >>> Customize your own dashboards, set traffic alerts and generate
> >>> >>> reports.
> >>> >>> Network behavioral analysis & security monitoring. All-in-one tool.
> >>> >>>
> >>> >>>
> >>> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> >>> >>> _______________________________________________
> >>> >>> liblo-devel mailing list
> >>> >>> lib...@li...
> >>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------------
> >>> > Learn Graph Databases - Download FREE O'Reilly Book
> >>> > "Graph Databases" is the definitive new guide to graph databases and
> >>> > their
> >>> > applications. Written by three acclaimed leaders in the field,
> >>> > this first edition is now available. Download your free book today!
> >>> > http://p.sf.net/sfu/13534_NeoTech
> >>> > _______________________________________________
> >>> > liblo-devel mailing list
> >>> > lib...@li...
> >>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>> >
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Learn Graph Databases - Download FREE O'Reilly Book
> >>> "Graph Databases" is the definitive new guide to graph databases and
> >>> their
> >>> applications. Written by three acclaimed leaders in the field,
> >>> this first edition is now available. Download your free book today!
> >>> http://p.sf.net/sfu/13534_NeoTech
> >>> _______________________________________________
> >>> liblo-devel mailing list
> >>> lib...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Steve,
After more test, it appears that it's not htonl() related...
What's strange is that I successfully compiled a working liblo (e.g. no
delay...) but I do not succeed in doing it again...

So maybe it's something with the way I'm compiling...

++
Le 13 mars 2014 18:32, "Stephen Sinclair" <rad...@gm...> a écrit :

> It is strange, since a glance at the macros suggests that lo_htoo32()
> should simply expand to htonl().  I'll try using gcc's -E flag to look
> at post-preprocessor output and see if that's the case.
>
> Either way I can't see how such a macro would lead to delays..
> interesting.  Could be something a bit subtle.  Which VM are you
> using, Parallels?
>
> Steve
>
>
> On Wed, Mar 12, 2014 at 12:26 PM, nicolas bats <sl1...@gm...>
> wrote:
> > so, after digging a little more....
> > my problem does not come from lo_address_resolve(), so neither from
> > getnameinfo().
> > I'm sending bundle and delay come from lo_bundle_serialise().
> > more precisely from the lo_htoo32() macro.
> >
> > I'm compiling liblo on a virtual windows box on a mac...
> > I don't know if it's related but when I change lo_htoo32() to htonl(),
> delay
> > disappears and everything is smooth even for address that does not
> exists on
> > the network.
> >
> > does it make sense to you?
> > ++
> > Nicolas
> >
> >
> > 2014-03-11 14:33 GMT+01:00 nicolas bats <sl1...@gm...>:
> >
> >> I've moved the lo_address_resolve() at address creation instead of at
> the
> >> send() moment and will be able to test at the end of the week.
> >> Not great I suppose but I think it can be ok for my application...
> >> Best regards,
> >> Nicolas
> >>
> >> Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a
> écrit :
> >>
> >>> The only thing I can think to suggest is that you step through
> >>> lo_address_new() with the debugger and see where the delay actually
> >>> happens.
> >>>
> >>> Steve
> >>>
> >>>
> >>> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...>
> >>> wrote:
> >>> > Hi,
> >>> > any thoughts about the way to resolve/improve this?
> >>> >
> >>> > best regards,
> >>> > Nicolas
> >>> >
> >>> >
> >>> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
> >>> >
> >>> >> hello,
> >>> >> first, here's how I initialize the address where I need to write:
> >>> >>
> >>> >> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
> >>> >>
> >>> >>     oscWriter_t* this_W = NULL;
> >>> >>
> >>> >>     struct common_Nodes *node, *tmp;
> >>> >>
> >>> >>     node = tmp = NULL;
> >>> >>
> >>> >> char* buff = NULL;
> >>> >>
> >>> >>
> >>> >>     if(NULL != recordedNodes)
> >>> >>
> >>> >>     {
> >>> >>
> >>> >>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
> >>> >>
> >>> >>             Indic_Error(UNEXPECTED, 0);
> >>> >>
> >>> >>             return;
> >>> >>
> >>> >>         }
> >>> >>
> >>> >>
> >>> >>         HASH_ITER(hh, recordedNodes, node, tmp) {
> >>> >>
> >>> >>
> >>> >>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
> >>> >>
> >>> >>         {
> >>> >>
> >>> >>             sprintf(buff, "%d", node->port);
> >>> >>
> >>> >>             this_W->addr = lo_address_new(node->ipData , buff);
> >>> >>
> >>> >>             this_W->addr_str = dupstr(node->ipData);
> >>> >>
> >>> >>             this_W->port_str = dupstr(buff);
> >>> >>
> >>> >>             this_W->isUsed = node->idt;
> >>> >>
> >>> >>
> >>> >>
> >>> >>            //printf("add %s %s\n", this_W->addr_str,
> >>> >> this_W->port_str);
> >>> >>
> >>> >>             LL_APPEND(writerServer,this_W);
> >>> >>
> >>> >>
> >>> >>
> >>> >>         }
> >>> >>
> >>> >>         }
> >>> >>
> >>> >>
> >>> >>
> >>> >>         FRI(buff);
> >>> >>
> >>> >>     }
> >>> >>
> >>> >>     return;
> >>> >>
> >>> >> }
> >>> >>
> >>> >>
> >>> >> so it's simply a lo_address_new() and I reuse the address from
> >>> >> this_W->addr.
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
> >>> >>
> >>> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <
> sl1...@gm...>
> >>> >>> wrote:
> >>> >>> > Hi,
> >>> >>> > with the latest release (but I don't think it's 0.28 related) I
> can
> >>> >>> > see
> >>> >>> > some
> >>> >>> > behaviors on win that are not particulary desired...
> >>> >>> >
> >>> >>> > let me explain:
> >>> >>> > my app create a server with lo_server_new(), so far so good, and
> I
> >>> >>> > use
> >>> >>> > only
> >>> >>> > UDP.
> >>> >>> > the wifi is off and the firewalls are off.
> >>> >>> > the network card address is 192.168.1.30
> >>> >>> >
> >>> >>> > if I send OSC message to address like 10.x.x.x, as the network
> >>> >>> > can't be
> >>> >>> > reached I don't see any lag, but, if I send OSC message to
> >>> >>> > 192.168.1.x
> >>> >>> > and
> >>> >>> > there's no receiver, I see a huge lag, like if there's a timeout
> or
> >>> >>> > something like this.
> >>> >>> > did you guys noticed the same behavior?
> >>> >>> > any leads in order to find wich call is reponsible of lag?
> >>> >>>
> >>> >>> It would be good to know if it's a write() call for example.  Also,
> >>> >>> does the lag occur only the first time, or every time?
> >>> >>
> >>> >>
> >>> >> within my app, it happens all the time
> >>> >>
> >>> >>>
> >>> >>>  I wonder if
> >>> >>> it's more of a name resolution bug, could be something regarding
> >>> >>> initializing a lo_address.
> >>> >>>
> >>> >>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or
> >>> >>> more?
> >>> >>
> >>> >> let's say a few seconds, but more than your log shows
> >>> >>>
> >>> >>>
> >>> >>> Possibly stepping through the code in gdb starting at lo_send()
> might
> >>> >>> help.
> >>> >>>
> >>> >>> Here on my Windows 7 machine I do see a short lag of a couple of
> >>> >>> seconds when sending to an unknown address using oscsend.exe, but
> it
> >>> >>> seems to go away the second and third times I run it.  If I change
> >>> >>> the
> >>> >>> last number of the IP address I get the lag again, only once.
> >>> >>
> >>> >>
> >>> >> even once it's a shame...
> >>> >> can't we get rid of that?
> >>> >>
> >>> >>>
> >>> >>>  Here is
> >>> >>> a dump:
> >>> >>>
> >>> >>> (This is compiled with MingW, and one of my NICs is configured to
> >>> >>> 192.168.56.1 / 255.255.255.0)
> >>> >>>
> >>> >>> -------------------------------
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>> >>>
> >>> >>> real    0m2.644s
> >>> >>> user    0m0.000s
> >>> >>> sys     0m0.015s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>> >>>
> >>> >>> real    0m0.037s
> >>> >>> user    0m0.015s
> >>> >>> sys     0m0.000s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>> >>>
> >>> >>> real    0m0.037s
> >>> >>> user    0m0.015s
> >>> >>> sys     0m0.000s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>> >>>
> >>> >>> real    0m2.596s
> >>> >>> user    0m0.000s
> >>> >>> sys     0m0.015s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>> >>>
> >>> >>> real    0m0.038s
> >>> >>> user    0m0.000s
> >>> >>> sys     0m0.015s
> >>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>> >>>
> >>> >>> real    0m0.040s
> >>> >>> user    0m0.000s
> >>> >>> sys     0m0.015s
> >>> >>> -------------------------------
> >>> >>
> >>> >>
> >>> >> for the same address, mine shows 0m2.928s (more or less) every time.
> >>> >> the same as with new address
> >>> >>
> >>> >> ++
> >>> >> NIcolas
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Steve
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> ------------------------------------------------------------------------------
> >>> >>> Flow-based real-time traffic analytics software. Cisco certified
> >>> >>> tool.
> >>> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
> Analyzer
> >>> >>> Customize your own dashboards, set traffic alerts and generate
> >>> >>> reports.
> >>> >>> Network behavioral analysis & security monitoring. All-in-one tool.
> >>> >>>
> >>> >>>
> >>> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> >>> >>> _______________________________________________
> >>> >>> liblo-devel mailing list
> >>> >>> lib...@li...
> >>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------------
> >>> > Learn Graph Databases - Download FREE O'Reilly Book
> >>> > "Graph Databases" is the definitive new guide to graph databases and
> >>> > their
> >>> > applications. Written by three acclaimed leaders in the field,
> >>> > this first edition is now available. Download your free book today!
> >>> > http://p.sf.net/sfu/13534_NeoTech
> >>> > _______________________________________________
> >>> > liblo-devel mailing list
> >>> > lib...@li...
> >>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>> >
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Learn Graph Databases - Download FREE O'Reilly Book
> >>> "Graph Databases" is the definitive new guide to graph databases and
> >>> their
> >>> applications. Written by three acclaimed leaders in the field,
> >>> this first edition is now available. Download your free book today!
> >>> http://p.sf.net/sfu/13534_NeoTech
> >>> _______________________________________________
> >>> liblo-devel mailing list
> >>> lib...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

It is strange, since a glance at the macros suggests that lo_htoo32()
should simply expand to htonl().  I'll try using gcc's -E flag to look
at post-preprocessor output and see if that's the case.

Either way I can't see how such a macro would lead to delays..
interesting.  Could be something a bit subtle.  Which VM are you
using, Parallels?

Steve


On Wed, Mar 12, 2014 at 12:26 PM, nicolas bats <sl1...@gm...> wrote:
> so, after digging a little more....
> my problem does not come from lo_address_resolve(), so neither from
> getnameinfo().
> I'm sending bundle and delay come from lo_bundle_serialise().
> more precisely from the lo_htoo32() macro.
>
> I'm compiling liblo on a virtual windows box on a mac...
> I don't know if it's related but when I change lo_htoo32() to htonl(), delay
> disappears and everything is smooth even for address that does not exists on
> the network.
>
> does it make sense to you?
> ++
> Nicolas
>
>
> 2014-03-11 14:33 GMT+01:00 nicolas bats <sl1...@gm...>:
>
>> I've moved the lo_address_resolve() at address creation instead of at the
>> send() moment and will be able to test at the end of the week.
>> Not great I suppose but I think it can be ok for my application...
>> Best regards,
>> Nicolas
>>
>> Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a écrit :
>>
>>> The only thing I can think to suggest is that you step through
>>> lo_address_new() with the debugger and see where the delay actually
>>> happens.
>>>
>>> Steve
>>>
>>>
>>> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...>
>>> wrote:
>>> > Hi,
>>> > any thoughts about the way to resolve/improve this?
>>> >
>>> > best regards,
>>> > Nicolas
>>> >
>>> >
>>> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
>>> >
>>> >> hello,
>>> >> first, here's how I initialize the address where I need to write:
>>> >>
>>> >> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
>>> >>
>>> >>     oscWriter_t* this_W = NULL;
>>> >>
>>> >>     struct common_Nodes *node, *tmp;
>>> >>
>>> >>     node = tmp = NULL;
>>> >>
>>> >> char* buff = NULL;
>>> >>
>>> >>
>>> >>     if(NULL != recordedNodes)
>>> >>
>>> >>     {
>>> >>
>>> >>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
>>> >>
>>> >>             Indic_Error(UNEXPECTED, 0);
>>> >>
>>> >>             return;
>>> >>
>>> >>         }
>>> >>
>>> >>
>>> >>         HASH_ITER(hh, recordedNodes, node, tmp) {
>>> >>
>>> >>
>>> >>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
>>> >>
>>> >>         {
>>> >>
>>> >>             sprintf(buff, "%d", node->port);
>>> >>
>>> >>             this_W->addr = lo_address_new(node->ipData , buff);
>>> >>
>>> >>             this_W->addr_str = dupstr(node->ipData);
>>> >>
>>> >>             this_W->port_str = dupstr(buff);
>>> >>
>>> >>             this_W->isUsed = node->idt;
>>> >>
>>> >>
>>> >>
>>> >>            //printf("add %s %s\n", this_W->addr_str,
>>> >> this_W->port_str);
>>> >>
>>> >>             LL_APPEND(writerServer,this_W);
>>> >>
>>> >>
>>> >>
>>> >>         }
>>> >>
>>> >>         }
>>> >>
>>> >>
>>> >>
>>> >>         FRI(buff);
>>> >>
>>> >>     }
>>> >>
>>> >>     return;
>>> >>
>>> >> }
>>> >>
>>> >>
>>> >> so it's simply a lo_address_new() and I reuse the address from
>>> >> this_W->addr.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
>>> >>
>>> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <sl1...@gm...>
>>> >>> wrote:
>>> >>> > Hi,
>>> >>> > with the latest release (but I don't think it's 0.28 related) I can
>>> >>> > see
>>> >>> > some
>>> >>> > behaviors on win that are not particulary desired...
>>> >>> >
>>> >>> > let me explain:
>>> >>> > my app create a server with lo_server_new(), so far so good, and I
>>> >>> > use
>>> >>> > only
>>> >>> > UDP.
>>> >>> > the wifi is off and the firewalls are off.
>>> >>> > the network card address is 192.168.1.30
>>> >>> >
>>> >>> > if I send OSC message to address like 10.x.x.x, as the network
>>> >>> > can't be
>>> >>> > reached I don't see any lag, but, if I send OSC message to
>>> >>> > 192.168.1.x
>>> >>> > and
>>> >>> > there's no receiver, I see a huge lag, like if there's a timeout or
>>> >>> > something like this.
>>> >>> > did you guys noticed the same behavior?
>>> >>> > any leads in order to find wich call is reponsible of lag?
>>> >>>
>>> >>> It would be good to know if it's a write() call for example.  Also,
>>> >>> does the lag occur only the first time, or every time?
>>> >>
>>> >>
>>> >> within my app, it happens all the time
>>> >>
>>> >>>
>>> >>>  I wonder if
>>> >>> it's more of a name resolution bug, could be something regarding
>>> >>> initializing a lo_address.
>>> >>>
>>> >>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or
>>> >>> more?
>>> >>
>>> >> let's say a few seconds, but more than your log shows
>>> >>>
>>> >>>
>>> >>> Possibly stepping through the code in gdb starting at lo_send() might
>>> >>> help.
>>> >>>
>>> >>> Here on my Windows 7 machine I do see a short lag of a couple of
>>> >>> seconds when sending to an unknown address using oscsend.exe, but it
>>> >>> seems to go away the second and third times I run it.  If I change
>>> >>> the
>>> >>> last number of the IP address I get the lag again, only once.
>>> >>
>>> >>
>>> >> even once it's a shame...
>>> >> can't we get rid of that?
>>> >>
>>> >>>
>>> >>>  Here is
>>> >>> a dump:
>>> >>>
>>> >>> (This is compiled with MingW, and one of my NICs is configured to
>>> >>> 192.168.56.1 / 255.255.255.0)
>>> >>>
>>> >>> -------------------------------
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>>
>>> >>> real    0m2.644s
>>> >>> user    0m0.000s
>>> >>> sys     0m0.015s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>>
>>> >>> real    0m0.037s
>>> >>> user    0m0.015s
>>> >>> sys     0m0.000s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>>
>>> >>> real    0m0.037s
>>> >>> user    0m0.015s
>>> >>> sys     0m0.000s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>>
>>> >>> real    0m2.596s
>>> >>> user    0m0.000s
>>> >>> sys     0m0.015s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>>
>>> >>> real    0m0.038s
>>> >>> user    0m0.000s
>>> >>> sys     0m0.015s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>>
>>> >>> real    0m0.040s
>>> >>> user    0m0.000s
>>> >>> sys     0m0.015s
>>> >>> -------------------------------
>>> >>
>>> >>
>>> >> for the same address, mine shows 0m2.928s (more or less) every time.
>>> >> the same as with new address
>>> >>
>>> >> ++
>>> >> NIcolas
>>> >>>
>>> >>>
>>> >>>
>>> >>> Steve
>>> >>>
>>> >>>
>>> >>>
>>> >>> ------------------------------------------------------------------------------
>>> >>> Flow-based real-time traffic analytics software. Cisco certified
>>> >>> tool.
>>> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>>> >>> Customize your own dashboards, set traffic alerts and generate
>>> >>> reports.
>>> >>> Network behavioral analysis & security monitoring. All-in-one tool.
>>> >>>
>>> >>>
>>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>> >>> _______________________________________________
>>> >>> liblo-devel mailing list
>>> >>> lib...@li...
>>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Learn Graph Databases - Download FREE O'Reilly Book
>>> > "Graph Databases" is the definitive new guide to graph databases and
>>> > their
>>> > applications. Written by three acclaimed leaders in the field,
>>> > this first edition is now available. Download your free book today!
>>> > http://p.sf.net/sfu/13534_NeoTech
>>> > _______________________________________________
>>> > liblo-devel mailing list
>>> > lib...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Thu, Mar 13, 2014 at 6:11 PM, Tristan Matthews
<le....@gm...> wrote:
> On Thu, Mar 13, 2014 at 12:30 PM, Stephen Sinclair <rad...@gm...>
> wrote:
>>
>> Hi Alex,
>>
>> I think it's probably because you're passing a C++ member function as
>> the error handler, which is a normal C function pointer.  Try making
>> it a static function.  You'll need to use the (relatively new)
>> lo_server_set_error_context() function if you want to pass in the
>> object pointer, retrieved via lo_error_get_context().
>
>
> It's already a static function (see the header file) so I think it's
> probably something else.

Ah you're right, sorry.  Um, although I don't see anything in the code
that actually handles the error condition.  Is it possible it's just
crashing because it assumes server_ is valid?  Try setting a validity
flag from the OscReceiver::error() function.

> Alex can you make a backtrace of the segfault?

That would help.

Steve

On Thu, Mar 13, 2014 at 12:30 PM, Stephen Sinclair <rad...@gm...>wrote:

> Hi Alex,
>
> I think it's probably because you're passing a C++ member function as
> the error handler, which is a normal C function pointer.  Try making
> it a static function.  You'll need to use the (relatively new)
> lo_server_set_error_context() function if you want to pass in the
> object pointer, retrieved via lo_error_get_context().
>

It's already a static function (see the header file) so I think it's
probably something else.
Alex can you make a backtrace of the segfault?


>
> ps., feel free to test-drive the new C++ bindings!
>

+1


>
> Steve
>
>
> On Wed, Mar 12, 2014 at 5:20 PM, Alexandre Quessy <ale...@qu...>
> wrote:
> > Hello everyone,
> > I wrote several C++ applications that can receive OSC messages using
> liblo.
> > If the port is already in use, for example when I launch a second
> instance
> > of the same application on GNU/Linux, the application segfaults.
> > How can I avoid such a segfault? Is there a simple way to look for port
> > availability with liblo? Otherwise, I should need to use low-level system
> > calls?
> >
> > Here is my code:
> > https://github.com/mapmapteam/mapmap/blob/master/OscReceiver.cpp
> >
> > Thanks a lot,
> > --
> > Alexandre Quessy
> > http://alexandre.quessy.net - Artiste en nouveaux médias
> > http://perte-de-signal.org - Membre de Perte de signal
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi Alex,

I think it's probably because you're passing a C++ member function as
the error handler, which is a normal C function pointer.  Try making
it a static function.  You'll need to use the (relatively new)
lo_server_set_error_context() function if you want to pass in the
object pointer, retrieved via lo_error_get_context().

ps., feel free to test-drive the new C++ bindings!

Steve


On Wed, Mar 12, 2014 at 5:20 PM, Alexandre Quessy <ale...@qu...> wrote:
> Hello everyone,
> I wrote several C++ applications that can receive OSC messages using liblo.
> If the port is already in use, for example when I launch a second instance
> of the same application on GNU/Linux, the application segfaults.
> How can I avoid such a segfault? Is there a simple way to look for port
> availability with liblo? Otherwise, I should need to use low-level system
> calls?
>
> Here is my code:
> https://github.com/mapmapteam/mapmap/blob/master/OscReceiver.cpp
>
> Thanks a lot,
> --
> Alexandre Quessy
> http://alexandre.quessy.net - Artiste en nouveaux médias
> http://perte-de-signal.org - Membre de Perte de signal
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hello everyone,
I wrote several C++ applications that can receive OSC messages using liblo.
If the port is already in use, for example when I launch a second instance
of the same application on GNU/Linux, the application segfaults.
How can I avoid such a segfault? Is there a simple way to look for port
availability with liblo? Otherwise, I should need to use low-level system
calls?

Here is my code:
https://github.com/mapmapteam/mapmap/blob/master/OscReceiver.cpp

Thanks a lot,
-- 
Alexandre Quessy
http://alexandre.quessy.net - Artiste en nouveaux médias
http://perte-de-signal.org - Membre de Perte de signal

so, after digging a little more....
my problem does not come from lo_address_resolve(), so neither from
getnameinfo().
I'm sending bundle and delay come from lo_bundle_serialise().
more precisely from the lo_htoo32() macro.

I'm compiling liblo on a virtual windows box on a mac...
I don't know if it's related but when I change lo_htoo32() to htonl(),
delay disappears and everything is smooth even for address that does not
exists on the network.

does it make sense to you?
++
Nicolas


2014-03-11 14:33 GMT+01:00 nicolas bats <sl1...@gm...>:

> I've moved the lo_address_resolve() at address creation instead of at the
> send() moment and will be able to test at the end of the week.
> Not great I suppose but I think it can be ok for my application...
> Best regards,
> Nicolas
> Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a écrit :
>
> The only thing I can think to suggest is that you step through
>> lo_address_new() with the debugger and see where the delay actually
>> happens.
>>
>> Steve
>>
>>
>> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...>
>> wrote:
>> > Hi,
>> > any thoughts about the way to resolve/improve this?
>> >
>> > best regards,
>> > Nicolas
>> >
>> >
>> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
>> >
>> >> hello,
>> >> first, here's how I initialize the address where I need to write:
>> >>
>> >> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
>> >>
>> >>     oscWriter_t* this_W = NULL;
>> >>
>> >>     struct common_Nodes *node, *tmp;
>> >>
>> >>     node = tmp = NULL;
>> >>
>> >> char* buff = NULL;
>> >>
>> >>
>> >>     if(NULL != recordedNodes)
>> >>
>> >>     {
>> >>
>> >>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
>> >>
>> >>             Indic_Error(UNEXPECTED, 0);
>> >>
>> >>             return;
>> >>
>> >>         }
>> >>
>> >>
>> >>         HASH_ITER(hh, recordedNodes, node, tmp) {
>> >>
>> >>
>> >>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
>> >>
>> >>         {
>> >>
>> >>             sprintf(buff, "%d", node->port);
>> >>
>> >>             this_W->addr = lo_address_new(node->ipData , buff);
>> >>
>> >>             this_W->addr_str = dupstr(node->ipData);
>> >>
>> >>             this_W->port_str = dupstr(buff);
>> >>
>> >>             this_W->isUsed = node->idt;
>> >>
>> >>
>> >>
>> >>            //printf("add %s %s\n", this_W->addr_str, this_W->port_str);
>> >>
>> >>             LL_APPEND(writerServer,this_W);
>> >>
>> >>
>> >>
>> >>         }
>> >>
>> >>         }
>> >>
>> >>
>> >>
>> >>         FRI(buff);
>> >>
>> >>     }
>> >>
>> >>     return;
>> >>
>> >> }
>> >>
>> >>
>> >> so it's simply a lo_address_new() and I reuse the address from
>> >> this_W->addr.
>> >>
>> >>
>> >>
>> >>
>> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
>> >>
>> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <sl1...@gm...>
>> >>> wrote:
>> >>> > Hi,
>> >>> > with the latest release (but I don't think it's 0.28 related) I can
>> see
>> >>> > some
>> >>> > behaviors on win that are not particulary desired...
>> >>> >
>> >>> > let me explain:
>> >>> > my app create a server with lo_server_new(), so far so good, and I
>> use
>> >>> > only
>> >>> > UDP.
>> >>> > the wifi is off and the firewalls are off.
>> >>> > the network card address is 192.168.1.30
>> >>> >
>> >>> > if I send OSC message to address like 10.x.x.x, as the network
>> can't be
>> >>> > reached I don't see any lag, but, if I send OSC message to
>> 192.168.1.x
>> >>> > and
>> >>> > there's no receiver, I see a huge lag, like if there's a timeout or
>> >>> > something like this.
>> >>> > did you guys noticed the same behavior?
>> >>> > any leads in order to find wich call is reponsible of lag?
>> >>>
>> >>> It would be good to know if it's a write() call for example.  Also,
>> >>> does the lag occur only the first time, or every time?
>> >>
>> >>
>> >> within my app, it happens all the time
>> >>
>> >>>
>> >>>  I wonder if
>> >>> it's more of a name resolution bug, could be something regarding
>> >>> initializing a lo_address.
>> >>>
>> >>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or
>> more?
>> >>
>> >> let's say a few seconds, but more than your log shows
>> >>>
>> >>>
>> >>> Possibly stepping through the code in gdb starting at lo_send() might
>> >>> help.
>> >>>
>> >>> Here on my Windows 7 machine I do see a short lag of a couple of
>> >>> seconds when sending to an unknown address using oscsend.exe, but it
>> >>> seems to go away the second and third times I run it.  If I change the
>> >>> last number of the IP address I get the lag again, only once.
>> >>
>> >>
>> >> even once it's a shame...
>> >> can't we get rid of that?
>> >>
>> >>>
>> >>>  Here is
>> >>> a dump:
>> >>>
>> >>> (This is compiled with MingW, and one of my NICs is configured to
>> >>> 192.168.56.1 / 255.255.255.0)
>> >>>
>> >>> -------------------------------
>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>> >>>
>> >>> real    0m2.644s
>> >>> user    0m0.000s
>> >>> sys     0m0.015s
>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>> >>>
>> >>> real    0m0.037s
>> >>> user    0m0.015s
>> >>> sys     0m0.000s
>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>> >>>
>> >>> real    0m0.037s
>> >>> user    0m0.015s
>> >>> sys     0m0.000s
>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>> >>>
>> >>> real    0m2.596s
>> >>> user    0m0.000s
>> >>> sys     0m0.015s
>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>> >>>
>> >>> real    0m0.038s
>> >>> user    0m0.000s
>> >>> sys     0m0.015s
>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>> >>>
>> >>> real    0m0.040s
>> >>> user    0m0.000s
>> >>> sys     0m0.015s
>> >>> -------------------------------
>> >>
>> >>
>> >> for the same address, mine shows 0m2.928s (more or less) every time.
>> >> the same as with new address
>> >>
>> >> ++
>> >> NIcolas
>> >>>
>> >>>
>> >>>
>> >>> Steve
>> >>>
>> >>>
>> >>>
>> ------------------------------------------------------------------------------
>> >>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> >>> Customize your own dashboards, set traffic alerts and generate
>> reports.
>> >>> Network behavioral analysis & security monitoring. All-in-one tool.
>> >>>
>> >>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>> >>> _______________________________________________
>> >>> liblo-devel mailing list
>> >>> lib...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>
>> >>
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Learn Graph Databases - Download FREE O'Reilly Book
>> > "Graph Databases" is the definitive new guide to graph databases and
>> their
>> > applications. Written by three acclaimed leaders in the field,
>> > this first edition is now available. Download your free book today!
>> > http://p.sf.net/sfu/13534_NeoTech
>> > _______________________________________________
>> > liblo-devel mailing list
>> > lib...@li...
>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>

I've moved the lo_address_resolve() at address creation instead of at the
send() moment and will be able to test at the end of the week.
Not great I suppose but I think it can be ok for my application...
Best regards,
Nicolas
Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a écrit :

> The only thing I can think to suggest is that you step through
> lo_address_new() with the debugger and see where the delay actually
> happens.
>
> Steve
>
>
> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...>
> wrote:
> > Hi,
> > any thoughts about the way to resolve/improve this?
> >
> > best regards,
> > Nicolas
> >
> >
> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
> >
> >> hello,
> >> first, here's how I initialize the address where I need to write:
> >>
> >> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
> >>
> >>     oscWriter_t* this_W = NULL;
> >>
> >>     struct common_Nodes *node, *tmp;
> >>
> >>     node = tmp = NULL;
> >>
> >> char* buff = NULL;
> >>
> >>
> >>     if(NULL != recordedNodes)
> >>
> >>     {
> >>
> >>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
> >>
> >>             Indic_Error(UNEXPECTED, 0);
> >>
> >>             return;
> >>
> >>         }
> >>
> >>
> >>         HASH_ITER(hh, recordedNodes, node, tmp) {
> >>
> >>
> >>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
> >>
> >>         {
> >>
> >>             sprintf(buff, "%d", node->port);
> >>
> >>             this_W->addr = lo_address_new(node->ipData , buff);
> >>
> >>             this_W->addr_str = dupstr(node->ipData);
> >>
> >>             this_W->port_str = dupstr(buff);
> >>
> >>             this_W->isUsed = node->idt;
> >>
> >>
> >>
> >>            //printf("add %s %s\n", this_W->addr_str, this_W->port_str);
> >>
> >>             LL_APPEND(writerServer,this_W);
> >>
> >>
> >>
> >>         }
> >>
> >>         }
> >>
> >>
> >>
> >>         FRI(buff);
> >>
> >>     }
> >>
> >>     return;
> >>
> >> }
> >>
> >>
> >> so it's simply a lo_address_new() and I reuse the address from
> >> this_W->addr.
> >>
> >>
> >>
> >>
> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
> >>
> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <sl1...@gm...>
> >>> wrote:
> >>> > Hi,
> >>> > with the latest release (but I don't think it's 0.28 related) I can
> see
> >>> > some
> >>> > behaviors on win that are not particulary desired...
> >>> >
> >>> > let me explain:
> >>> > my app create a server with lo_server_new(), so far so good, and I
> use
> >>> > only
> >>> > UDP.
> >>> > the wifi is off and the firewalls are off.
> >>> > the network card address is 192.168.1.30
> >>> >
> >>> > if I send OSC message to address like 10.x.x.x, as the network can't
> be
> >>> > reached I don't see any lag, but, if I send OSC message to
> 192.168.1.x
> >>> > and
> >>> > there's no receiver, I see a huge lag, like if there's a timeout or
> >>> > something like this.
> >>> > did you guys noticed the same behavior?
> >>> > any leads in order to find wich call is reponsible of lag?
> >>>
> >>> It would be good to know if it's a write() call for example.  Also,
> >>> does the lag occur only the first time, or every time?
> >>
> >>
> >> within my app, it happens all the time
> >>
> >>>
> >>>  I wonder if
> >>> it's more of a name resolution bug, could be something regarding
> >>> initializing a lo_address.
> >>>
> >>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or more?
> >>
> >> let's say a few seconds, but more than your log shows
> >>>
> >>>
> >>> Possibly stepping through the code in gdb starting at lo_send() might
> >>> help.
> >>>
> >>> Here on my Windows 7 machine I do see a short lag of a couple of
> >>> seconds when sending to an unknown address using oscsend.exe, but it
> >>> seems to go away the second and third times I run it.  If I change the
> >>> last number of the IP address I get the lag again, only once.
> >>
> >>
> >> even once it's a shame...
> >> can't we get rid of that?
> >>
> >>>
> >>>  Here is
> >>> a dump:
> >>>
> >>> (This is compiled with MingW, and one of my NICs is configured to
> >>> 192.168.56.1 / 255.255.255.0)
> >>>
> >>> -------------------------------
> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>>
> >>> real    0m2.644s
> >>> user    0m0.000s
> >>> sys     0m0.015s
> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>>
> >>> real    0m0.037s
> >>> user    0m0.015s
> >>> sys     0m0.000s
> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
> >>>
> >>> real    0m0.037s
> >>> user    0m0.015s
> >>> sys     0m0.000s
> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>>
> >>> real    0m2.596s
> >>> user    0m0.000s
> >>> sys     0m0.015s
> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>>
> >>> real    0m0.038s
> >>> user    0m0.000s
> >>> sys     0m0.015s
> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
> >>>
> >>> real    0m0.040s
> >>> user    0m0.000s
> >>> sys     0m0.015s
> >>> -------------------------------
> >>
> >>
> >> for the same address, mine shows 0m2.928s (more or less) every time.
> >> the same as with new address
> >>
> >> ++
> >> NIcolas
> >>>
> >>>
> >>>
> >>> Steve
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Flow-based real-time traffic analytics software. Cisco certified tool.
> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> >>> Customize your own dashboards, set traffic alerts and generate reports.
> >>> Network behavioral analysis & security monitoring. All-in-one tool.
> >>>
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> liblo-devel mailing list
> >>> lib...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

The only thing I can think to suggest is that you step through
lo_address_new() with the debugger and see where the delay actually
happens.

Steve


On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...> wrote:
> Hi,
> any thoughts about the way to resolve/improve this?
>
> best regards,
> Nicolas
>
>
> 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
>
>> hello,
>> first, here's how I initialize the address where I need to write:
>>
>> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
>>
>>     oscWriter_t* this_W = NULL;
>>
>>     struct common_Nodes *node, *tmp;
>>
>>     node = tmp = NULL;
>>
>> char* buff = NULL;
>>
>>
>>     if(NULL != recordedNodes)
>>
>>     {
>>
>>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
>>
>>             Indic_Error(UNEXPECTED, 0);
>>
>>             return;
>>
>>         }
>>
>>
>>         HASH_ITER(hh, recordedNodes, node, tmp) {
>>
>>
>>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
>>
>>         {
>>
>>             sprintf(buff, "%d", node->port);
>>
>>             this_W->addr = lo_address_new(node->ipData , buff);
>>
>>             this_W->addr_str = dupstr(node->ipData);
>>
>>             this_W->port_str = dupstr(buff);
>>
>>             this_W->isUsed = node->idt;
>>
>>
>>
>>            //printf("add %s %s\n", this_W->addr_str, this_W->port_str);
>>
>>             LL_APPEND(writerServer,this_W);
>>
>>
>>
>>         }
>>
>>         }
>>
>>
>>
>>         FRI(buff);
>>
>>     }
>>
>>     return;
>>
>> }
>>
>>
>> so it's simply a lo_address_new() and I reuse the address from
>> this_W->addr.
>>
>>
>>
>>
>> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
>>
>>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <sl1...@gm...>
>>> wrote:
>>> > Hi,
>>> > with the latest release (but I don't think it's 0.28 related) I can see
>>> > some
>>> > behaviors on win that are not particulary desired...
>>> >
>>> > let me explain:
>>> > my app create a server with lo_server_new(), so far so good, and I use
>>> > only
>>> > UDP.
>>> > the wifi is off and the firewalls are off.
>>> > the network card address is 192.168.1.30
>>> >
>>> > if I send OSC message to address like 10.x.x.x, as the network can't be
>>> > reached I don't see any lag, but, if I send OSC message to 192.168.1.x
>>> > and
>>> > there's no receiver, I see a huge lag, like if there's a timeout or
>>> > something like this.
>>> > did you guys noticed the same behavior?
>>> > any leads in order to find wich call is reponsible of lag?
>>>
>>> It would be good to know if it's a write() call for example.  Also,
>>> does the lag occur only the first time, or every time?
>>
>>
>> within my app, it happens all the time
>>
>>>
>>>  I wonder if
>>> it's more of a name resolution bug, could be something regarding
>>> initializing a lo_address.
>>>
>>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or more?
>>
>> let's say a few seconds, but more than your log shows
>>>
>>>
>>> Possibly stepping through the code in gdb starting at lo_send() might
>>> help.
>>>
>>> Here on my Windows 7 machine I do see a short lag of a couple of
>>> seconds when sending to an unknown address using oscsend.exe, but it
>>> seems to go away the second and third times I run it.  If I change the
>>> last number of the IP address I get the lag again, only once.
>>
>>
>> even once it's a shame...
>> can't we get rid of that?
>>
>>>
>>>  Here is
>>> a dump:
>>>
>>> (This is compiled with MingW, and one of my NICs is configured to
>>> 192.168.56.1 / 255.255.255.0)
>>>
>>> -------------------------------
>>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>>
>>> real    0m2.644s
>>> user    0m0.000s
>>> sys     0m0.015s
>>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>>
>>> real    0m0.037s
>>> user    0m0.015s
>>> sys     0m0.000s
>>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>>
>>> real    0m0.037s
>>> user    0m0.015s
>>> sys     0m0.000s
>>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>>
>>> real    0m2.596s
>>> user    0m0.000s
>>> sys     0m0.015s
>>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>>
>>> real    0m0.038s
>>> user    0m0.000s
>>> sys     0m0.015s
>>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>>
>>> real    0m0.040s
>>> user    0m0.000s
>>> sys     0m0.015s
>>> -------------------------------
>>
>>
>> for the same address, mine shows 0m2.928s (more or less) every time.
>> the same as with new address
>>
>> ++
>> NIcolas
>>>
>>>
>>>
>>> Steve
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Flow-based real-time traffic analytics software. Cisco certified tool.
>>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>>> Customize your own dashboards, set traffic alerts and generate reports.
>>> Network behavioral analysis & security monitoring. All-in-one tool.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi,
any thoughts about the way to resolve/improve this?

best regards,
Nicolas


2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:

> hello,
> first, here's how I initialize the address where I need to write:
>
> static void  new_osc_sender(struct common_Nodes* recordedNodes) {
>
>     oscWriter_t* this_W = NULL;
>
>     struct common_Nodes *node, *tmp;
>
>     node = tmp = NULL;
>
> char* buff = NULL;
>
>
>     if(NULL != recordedNodes)
>
>     {
>
>         if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
>
>             Indic_Error(UNEXPECTED, 0);
>
>             return;
>
>         }
>
>
>         HASH_ITER(hh, recordedNodes, node, tmp) {
>
>
>         if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
>
>         {
>
>             sprintf(buff, "%d", node->port);
>
>             this_W->addr = lo_address_new(node->ipData , buff);
>
>             this_W->addr_str = dupstr(node->ipData);
>
>             this_W->port_str = dupstr(buff);
>
>             this_W->isUsed = node->idt;
>
>
>
>            //printf("add %s %s\n", this_W->addr_str, this_W->port_str);
>
>             LL_APPEND(writerServer,this_W);
>
>
>
>         }
>
>         }
>
>
>
>         FRI(buff);
>
>     }
>
>     return;
>
> }
>
>
> so it's simply a lo_address_new() and I reuse the address from this_W->
> addr.
>
>
>
> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
>
> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <sl1...@gm...>
>> wrote:
>> > Hi,
>> > with the latest release (but I don't think it's 0.28 related) I can see
>> some
>> > behaviors on win that are not particulary desired...
>> >
>> > let me explain:
>> > my app create a server with lo_server_new(), so far so good, and I use
>> only
>> > UDP.
>> > the wifi is off and the firewalls are off.
>> > the network card address is 192.168.1.30
>> >
>> > if I send OSC message to address like 10.x.x.x, as the network can't be
>> > reached I don't see any lag, but, if I send OSC message to 192.168.1.x
>> and
>> > there's no receiver, I see a huge lag, like if there's a timeout or
>> > something like this.
>> > did you guys noticed the same behavior?
>> > any leads in order to find wich call is reponsible of lag?
>>
>> It would be good to know if it's a write() call for example.  Also,
>> does the lag occur only the first time, or every time?
>
>
> within my app, it happens all the time
>
>
>>  I wonder if
>> it's more of a name resolution bug, could be something regarding
>> initializing a lo_address.
>>
>> What is "huge lag" exactly?  A few ms, a few seconds, a minute or more?
>>
> let's say a few seconds, but more than your log shows
>
>>
>> Possibly stepping through the code in gdb starting at lo_send() might
>> help.
>>
>> Here on my Windows 7 machine I do see a short lag of a couple of
>> seconds when sending to an unknown address using oscsend.exe, but it
>> seems to go away the second and third times I run it.  If I change the
>> last number of the IP address I get the lag again, only once.
>
>
> even once it's a shame...
> can't we get rid of that?
>
>
>>  Here is
>> a dump:
>>
>> (This is compiled with MingW, and one of my NICs is configured to
>> 192.168.56.1 / 255.255.255.0)
>>
>> -------------------------------
>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>
>> real    0m2.644s
>> user    0m0.000s
>> sys     0m0.015s
>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>
>> real    0m0.037s
>> user    0m0.015s
>> sys     0m0.000s
>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>
>> real    0m0.037s
>> user    0m0.015s
>> sys     0m0.000s
>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>
>> real    0m2.596s
>> user    0m0.000s
>> sys     0m0.015s
>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>
>> real    0m0.038s
>> user    0m0.000s
>> sys     0m0.015s
>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>
>> real    0m0.040s
>> user    0m0.000s
>> sys     0m0.015s
>> -------------------------------
>>
>
> for the same address, mine shows 0m2.928s (more or less) every time.
> the same as with new address
>
> ++
> NIcolas
>
>>
>>
>> Steve
>>
>>
>> ------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one tool.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>
>

Hi,  

Im trying to find an OSC library that capable to use TCP on Windows and i found LibLo for this project. I compiled it with Cygwin and i got .la file and headers on Windows.  

Now when i include these library and headers to my project i get errors below :

Error 3 error C2894: templates cannot be declared to have 'C' linkage c:\program files (x86)\windows kits\8.0\include\um\wspiapi.h 53 1 emptyExample
Error 4 error C1083: Cannot open include file: 'initializer_list': No such file or directory c:\users\alinakipoglu\desktop\of_v0.8.0_vs_release\addons\ofxliblo\lib\include\lo\lo_cpp.h 14 1 emptyExample


Is there a way to fix this? I tried using both lo.h and lo_cpp.h.

Any help would be appreciated

Thanks.


Ali Nakipoğlu

+44 7415347748

Fiction
fiction.io