On Fri, Mar 14, 2008 at 11:33 AM, Dean Willis <[EMAIL PROTECTED]> wrote: > > > On Mar 14, 2008, at 11:28 AM, John Buford wrote: > > > Regarding Henning's comment that DHT lookup seems sufficient > > for handling service lookups, there have been a number of > > papers which directly use the DHT for > > - serving DNS records > > - locating relay peers in an overlay, including discovery > > by network position > > - location telephony feature serving peers in an overlay > > - locating servers for other service discovery mechanisms like SLP > > > > no modification to the DHT or overlay protocol was needed to > > support these cases. as long as you can describe a service > > with a key that all participating peers understand, the DHT should > > work for service lookup. > > > > there are some cases where the service-related resource's > > availability is dynamic (e.g., relay load for admission control), > > which could be part of the advertisement. then there is a > > tradeoff between updating the DHT-stored advertisement when > > the load changes or leaving it for service invocation time for > > the invoking peer to find out. > > It is, however, more difficult to provide weighting and/or adaptive > load balancing to services using a DHT lookup than it might be with > other techniques.
I agree but I don't see that load balancing in the DHT is strictly a problem for service lookup > > It is also difficult to rank services on their network-path > optimaility unless such a ranking is implicit in the underlying DHT. > Finding a network path efficient relay is very important for reducing > latency in real-time media flows. > One dimension of the network path (relative position to the endpoints) can be accomdated using the DHT, for example using an internet coordinate system. e2e capacity of the path is another dimension which could involve post-discovery steps. John _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
