Re: [liblo] lo_server_thread_new_multicast time out?

Can you test the branch, "deferredhostname", on
http://github.com/radarsat1/liblo?

thanks,
Steve


On Fri, Sep 12, 2014 at 4:19 PM, Stéphane Letz <le...@gr...> wrote:
> Well i don't know the code enough to do that… but possibly.
>
> Are you going to correct that?
>
> Stéphane
>
>
> Le 12 sept. 2014 à 16:15, Stephen Sinclair <rad...@gm...> a écrit :
>
>> Right, so the server gets its own hostname so that it can provide a
>> URL for contacting it.  This may or may not be appropriate depending
>> on the network, but I guess the right fix would be to defer this
>> operation until the s->hostname field is needed.  Such a change was
>> already made for lo_address in the past.
>>
>> Steve
>>
>>
>> On Fri, Sep 12, 2014 at 4:05 PM, Stéphane Letz <le...@gr...> wrote:
>>> I found out that "gethostbyname" call in "lo_server_new_with_proto_internal" was the problem. Just removed the code for now, but don't think this is the real fix...
>>>
>>> Stéphane
>>>
>>> Le 12 sept. 2014 à 15:58, Stephen Sinclair <rad...@gm...> a écrit :
>>>
>>>> Is IPv6 enabled?  I believe there were some major slow-downs in DNS
>>>> lookups due to using getnameinfo(), so we disabled it unless IPv6 is
>>>> enabled.  Don't know if that is your problem, but it would be good to
>>>> eliminate it.
>>>>
>>>> Is it only the multicast variety that is slow?
>>>>
>>>> Steve
>>>>
>>>>
>>>> On Fri, Sep 12, 2014 at 1:58 PM, Stéphane Letz <le...@gr...> wrote:
>>>>> Hi,
>>>>>
>>>>> We are using liblo code on a completely autonomous wireless network (made by 2 Mac OSX laptop + iPad device  + Apple Aiport express)
>>>>>
>>>>> In this case the "lo_server_thread_new_multicast" takes a huge time to return since it seems an internal time-out is used somewhere to (DNS access? name resolution ? etc…)
>>>>>
>>>>> The same code works well as soon as the autonomous wireless in connected again on internet.
>>>>>
>>>>> Any idea how to solve this issue?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Stéphane Letz
>>>>> ------------------------------------------------------------------------------
>>>>> Want excitement?
>>>>> Manually upgrade your production database.
>>>>> When you want reliability, choose Perforce
>>>>> Perforce version control. Predictably reliable.
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> liblo-devel mailing list
>>>>> lib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want excitement?
>>>> Manually upgrade your production database.
>>>> When you want reliability, choose Perforce
>>>> Perforce version control. Predictably reliable.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> liblo-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want excitement?
>>> Manually upgrade your production database.
>>> When you want reliability, choose Perforce
>>> Perforce version control. Predictably reliable.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>