[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-common-dev
Subject:    Re: [Common-dev] Re: [Client-dev] CR: shared resolver address info
From:       Jamie Gordon <jgordon () real ! com>
Date:       2010-10-25 16:15:23
Message-ID: 4CC5AD1B.2060104 () real ! com
[Download RAW message or body]

We actually do already have DNS caching implemented which has long been
used by the common and server resolvers, but the client resolver
implementation doesn't use it! You should probably be able to just that
cache directly within the client resolver. One thing that might be a
little funky is that the client's resolver is still implemented via
the old net API (with a shim bridging to the newer API) and the cache
uses the new APIs. I think the only thing that matters as far as that
goes is for address passing.

Resolver cache is in common/netio, resolvecache.[h|cpp]. Resolvers using
it are in common/netio (iresolv.[h|cpp]) and server/engine/netio
(servresolvimp.[h|cpp] for reference.

-Jamie

On 10/25/2010 8:27 AM, Sheldon Fu wrote:
> DNS record has a TTL field to specify how long the DNS query result can
> be cached. We need to use that to determine how long we can keep the
> result, instead of an arbitrary constant, to be conforming to the DNS
> spec. DNS load balance is widely deployed now. We need to respect what
> the server wants.
>
> And I think this caching logic should be implemented in the resolver
> itself, not http filesystem. All the changes here are generic to the
> resolving logic, not related to http at all.
>
> Also according to some online discussion, Android's resolver (in bionic)
> already has a caching mechanism. Not sure how Helix resolver is
> implemented. It might be that we are not calling the correct API.
>
> For this particular httplive use case though, instead of having this DNS
> caching enhancement, it might be more beneficial to implement the logic
> to re-use the socket connection (http persistent connection) because
> even with dns caching, you'll have to do that still.
>
> fxd
>
> Qiang Luo wrote:
>> Overview:
>> Helix file system creates resolver to do dns lookup for each
>> connection.  It doesn't cache the address info data.  This haven't been
>> any issue until recently where we need to create httpfileobj frequently
>> to handle httplive streaming's usage.  For httplive streaming, there can
>> be 3 httpfsys connections, playlist update, ts segment file downloading,
>> decryption key downloading for each segment.  The typical segment
>> duration is 6 to10 seconds.  In this case, a resolver-addressInfo cache
>> would be beneficial in improve the httpfilesystem performance.
>>
>> In this implementation, we create a sheared map to store the address
>> info data/objects.  Instead of having a global map for a process, we
>> create a single map for the singleton media platform.
>>
>> Branches:
>> head, hxclient_3_1_0_atlas
>>
>> files added:
>> common/include/ihxaddressinfomap.h
>> common/util/hxaddrinfomap.cpp
>> common/util/pub/hxaddrinfomap.h
>>
>> files modified:
>> common/util/Umakefil
>> client/medpltfm/chxmedpltfm.cpp
>> client/medpltfm/dlliids.cpp
>> client/medpltfm/pub/chxmedpltfm.h
>> filesystem/http/factory.cpp
>> filesystem/http/httpfsys.cpp
>> filesystem/http/httpfsys.h
>>
>> Please review the implementation
>>
>> Thanks,
>> Qiang
>>
>
>
> _______________________________________________
> Common-dev mailing list
> Common-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/common-dev

_______________________________________________
Common-dev mailing list
Common-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/common-dev
[prev in list] [next in list] [prev in thread] [next in thread]