Re: [liblo] windows weird...

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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
>>
>>
>