[ENet-discuss] icmp/tracert/discovering network topology?

Mon Jan 11 06:26:59 PST 2010

Aha, you're not on the original computer. :)
In that case, depending on how many computers need to check how many
computers, I'd opt for algorithm #1. Counting hops doesn't really say much I
think, also depending on how much you know of the topology involved. If all
computers are under your control, counting hops can work, but I assume
you're talking about computers randomly on the internet?

Ruud

  _____  

Van: enet-discuss-bounces at cubik.org [mailto:enet-discuss-bounces at cubik.org]
Namens Jay Sprenkle
Verzonden: Monday, January 11, 2010 14:58
Aan: Discussion of the ENet library
Onderwerp: Re: [ENet-discuss] icmp/tracert/discovering network topology?

Thanks for the help but I think you misunderstood the problem  :)

I'm trying to determine if machine 'X' could communicate more quickly to
machine 'Y' or machine 'Z' (and you're on machine 'A'). 'A' pinging 'Z'
won't tell you the time for 'X' pinging 'Z'. etc.

I could:

Get machine X to ping machine Y and Z. This algorithm would be "here's a
list of machines, you figure it out."  If there are a lot of machines in the
list this could be problematic and very slow to discover good connections.

or 

Machine 'A' tracert's machine 'X', 'Y', and 'Z'. It now knows the physical
layout of the network and can calculate how many hops there are between the
machines (assuming there's only one path between any two points on the
internet). This algorithm would be "here's my best guess about which
machines will get the best response time from your machine"

The second algorithm is based on some assumptions that may be wrong and uses
the assumption "more hops = bad". Some combination of the two might be
better. 

On Mon, Jan 11, 2010 at 7:36 AM, Ruud van Gaal <ruud at racer.nl> wrote:

Ping is what most, if not all games use to determine client-server
'distance'. The number of hops doesn't say anything since the hardware
involved can be different greatly, resulting in processing times that vary
in many magnitudes.
The only way to be sure is to use ping, which is in fact relatively stable
in practice. Keep pinging as things progress so you always update the latest
ping time (taking care to avoid spikes, so slowly progressing ping time to a
stable value). Don't just calculate ping time once.

I would not know of any method that relates X hops to any useful time value.
If one route is 9 hops, the other 20, it's certainly not sure whether one is
faster than the other...

Ruud

  _____  

Van: enet-discuss-bounces at cubik.org [mailto:enet-discuss-bounces at cubik.org]
Namens Jay Sprenkle

Verzonden: Monday, January 11, 2010 14:12 

Aan: Discussion of the ENet library

Onderwerp: Re: [ENet-discuss] icmp/tracert/discovering network topology?

I would think the actual ping time would not be that useful. It would vary
considerably over time. What I was thinking was the length of the route in
routed hops, not physical distance, was what I needed to sort by. These
might measure roughly the same thing but physical organization only needs
one measurement.

On Mon, Jan 11, 2010 at 3:37 AM, Ruud van Gaal <ruud at racer.nl> wrote:

Hi,

Isn't the ping time more important? In that case, keep ping times on the
server (probably already done by ENet, search the ENetPeer class) and get
the list from the server ordered by ping.
I wouldn't say the distance in computers is of much use for most situations.

Cheers,
Ruud

  _____  

Van: enet-discuss-bounces at cubik.org [mailto:enet-discuss-bounces at cubik.org]
Namens Jay Sprenkle
Verzonden: Sunday, January 10, 2010 20:09
Aan: Discussion of the ENet library
Onderwerp: [ENet-discuss] icmp/tracert/discovering network topology?

Good morning,

I'm considering adding some extra features to my enet based peer to peer
application. I'd like the main server to be smart enough to discover which
peers have the shortest connection path to each other. When a peer requests
a list of other peers to connect to then the server can deliver an optimal
list. The only way I could think of to implement this would be to do a
tracert to each peer and sort the list of peers by what common paths they
share. Has anyone done icmp packets with enet? I know it's not it's intended
function but it doesn't seem like it would be difficult to hack together. If
anyone has any better ideas on how to implement this I'd love to hear them.

Thanks!
Have a good weekend

_______________________________________________
ENet-discuss mailing list
ENet-discuss at cubik.org
http://lists.cubik.org/mailman/listinfo/enet-discuss

-- 
Cause united breaks guitars
http://www.youtube.com/watch?v=5YGc4zOqozo

_______________________________________________
ENet-discuss mailing list
ENet-discuss at cubik.org
http://lists.cubik.org/mailman/listinfo/enet-discuss

-- 
Cause united breaks guitars
http://www.youtube.com/watch?v=5YGc4zOqozo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20100111/863965b5/attachment-0001.htm>