[e2e] Closestnode.com announcement

Emin Gun Sirer egs+e2e at cs.cornell.edu
Thu Nov 3 20:12:55 PST 2005


Hi Amr,

Good point - finding a centrally located node is often critical. Game
servers would benefit from being centrally located (frankly, we thought
of it purely as a performance enhancement since everyone would see lower
server ping times, but your note points out that central leader election
is _required_ to avoid giving some people an unfair advantage!). Content
distribution/streaming multicast services may want to pick centrally
located nodes for internal nodes of a distribution tree. 

The system we built, Meridian, that enables closestnode.com to return
the closest node to a client can also be used for selecting a centrally
located node. This is one of the three applications we implemented and
measured for our SIGCOMM paper when evaluating Meridian (namely, the
apps are closest node selection "find the closest server to me", central
leader election "find the most central node among this given set of
nodes", and multiple constraints "find a node within 50 ms. of the
speakeasy colocation cluster in seattle, 30 ms. of cornell, and 25ms
from the at&t peering point in virginia"). You can check it out through
the "central leader election" demo here
(http://www5.cs.cornell.edu/~bwong/deployment2.html).

closestnode.com is a generic DNS front-end for the closest node
application only. If you want to look up the most central node within a
single set of nodes, we could create a new service called
"centralleader.com" and run the central leader election algorithm in
response to lookups for, say, mygame.centralleader.com. If this would be
useful, we will be happy to support it.

I suspect, though, that you will want to do central leader election from
within sets that vary with each query. I.e. each query will have to
specify the set of nodes among which it is trying to select the most
central node. There is no way to do this elegantly with a DNS lookup, so
you would be better off picking up the Meridian code (it's GPL'ed), and
use it in your game clients to find centrally located nodes. We'll
gladly help if you choose this route and have questions/suggestions etc.

Best,
Gun,
Bernard & 
Alex.

On Thu, 2005-11-03 at 18:35 -0800, Amr A. Awadallah wrote:
> Very cool.
> 
> Does ClosetNode provide support for finding a server that is closest to 
> multiple-clients at same time ?
> 
> Specifically, for multiplayer clan matches, suppose there is 16 players 
> (8 on each team), and there is 2000 game host servers distributed across 
> the world available for hosting the match. Can we find where is the 
> closet node to all 16 players such that the ping-differential between 
> the players is minimized ? (note that a node that is actually further 
> away on average, but reduces the delta between the players is preferred).
> 
> The reason ping-differential is so important is to ensure fairness, 
> otherwise certain players get the updates from the game server before 
> other players (and hence can kill the other players in their future 
> before they even see them !)
> 
> Thanks,
> 
> -- amr
> 
> Bernard Wong wrote:
> 
> > We are writing to announce closestnode.com, a free, non-commercial 
> > service that we have recently deployed for directing clients to servers 
> > and peers that are close to them.
> > 
> > Closestnode.com can be used for mapping clients to the closest DHT node, 
> > for selecting a nearby mirror a user can download content from, or for 
> > finding the closest game server a user can connect to in multiplayer 
> > online games.
> > 
> > The service is very simple to use:  You register a unique application 
> > name with us on the web (e.g. mycoolapp) and either link our library 
> > into your application or run our standalone program along your server 
> > nodes. Once that is done, any node performing a DNS lookup for 
> > mycoolapp.closestnode.com will receive the IP address of the the closest 
> > (lowest latency) node to itself that is currently running the mycoolapp 
> > application.
> > 
> > Closestnode.com can be used to implement a generic anycast service. It 
> > supports hosts behind firewalls and NAT boxes. One caveat is that a cold 
> > lookup with unprimed caches may take up to a few hundred ms, so this 
> > system is best suited for distributed systems where sessions last a few 
> > seconds or more.
> > 
> > More information, code and demos are available at 
> > http://www.closestnode.com. The system is an offshoot of recent research 
> > at Cornell university, described in the following paper:
> > 
> >      http://www.cs.cornell.edu/people/egs/papers/meridian-sigcomm05.pdf
> > 
> > Don't hesitate to contact us if you have any questions.
> > 
> > Best,
> > Bernard,
> > Alex,
> > Gun.
> 



More information about the end2end-interest mailing list