Calculating subnet distance. - Networking

This is a discussion on Calculating subnet distance. - Networking ; Hi , I have a requirement to do in my application as below. 1. I have a list of Sites from where I can download. 2. Calcualte the nearest site from the host , which can be used to download. ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Calculating subnet distance.

  1. Calculating subnet distance.

    Hi ,
    I have a requirement to do in my application as below.
    1. I have a list of Sites from where I can download.
    2. Calcualte the nearest site from the host , which can be used to
    download.
    3. Nearest site can be calcualted on the basis of geogriphical
    distance and bandwidth.


    Problems:
    - I cannot use ICMP protocol as may be some sites have disabled ping.
    - I cannot use raw socket over UDP as came to know that raw sockets on
    windows will be over soon.
    - I have to write multiplatform common code (windows , UNIX type).

    Can anyone suggest me simple and effective method to determine the
    nearest site ?

    Thanks,
    Pramod

  2. Re: Calculating subnet distance.

    On Thu, 10 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article ,
    pramodsharma08@gmail.com wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.

    >I have a requirement to do in my application as below.
    >1. I have a list of Sites from where I can download.
    >2. Calcualte the nearest site from the host , which can be used to
    >download.
    >3. Nearest site can be calcualted on the basis of geogriphical
    >distance and bandwidth.


    The nearest site is RARELY based on geographical distance. It depends
    on who your upstream connects to, and who the upstream of the remote
    connects to. A few seconds playing with the 'ping' command (yes,
    many sites block ping) and looking at the TTL of the responses will
    provide such a clue. Try a ping to Mission College, verses one to
    yahoo, google, DeAnza or Bezerkeley.

    >Problems:
    >- I cannot use ICMP protocol as may be some sites have disabled ping.
    >- I cannot use raw socket over UDP as came to know that raw sockets on
    >windows will be over soon.


    windoze is not our problem. I wouldn't recommend UDP as that may also
    be blocked, or routed with lower priority.

    >- I have to write multiplatform common code (windows , UNIX type).


    Look at the TTL of the returning packets. Generally speaking, most O/S
    use one of five initial TTLs on a TCP packets: 32 (rare, but some
    versions of windoze), 60 (some old IRIX and True64 boxes), 64, 128, or
    255. Few places on the Internet are more than 30 hops away. Thus, if
    you receive a packet with a TTL of 46, it _PROBABLY_ came from a box
    18 hops away with an initial TTL of 64.

    >Can anyone suggest me simple and effective method to determine the
    >nearest site ?


    You _are_ posting from a search engine - and it's not as if this idea
    is brand new. While TTL is universal, it's not the only thing in the
    packet headers that can be used. Looking at RFC1323 _might_ be worth
    the effort.

    Old guy

  3. Re: Calculating subnet distance.

    On Apr 12, 12:54*am, ibupro...@painkiller.example.tld (Moe Trin)
    wrote:
    > On Thu, 10 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    > article ,
    >
    > pramodsharm...@gmail.com wrote:
    >
    > NOTE: Posting from groups.google.com (or some web-forums) dramatically
    > reduces the chance of your post being seen. *Find a real news server.
    >
    > >I have a requirement to do in my application as below.
    > >1. I have a list of Sites from where I can download.
    > >2. Calcualte the nearest site from the host , which can be used to
    > >download.
    > >3. Nearest site can be calcualted on the basis of geogriphical
    > >distance and bandwidth.

    >
    > The nearest site is RARELY based on geographical distance. It depends
    > on who your upstream connects to, and who the upstream of the remote
    > connects to. *A few seconds playing with the 'ping' command (yes,
    > many sites block ping) and looking at the TTL of the responses will
    > provide such a clue. *Try a ping to Mission College, verses one to
    > yahoo, google, DeAnza or Bezerkeley.
    >
    > >Problems:
    > >- I cannot use ICMP protocol as may be some sites have disabled ping.
    > >- I cannot use raw socket over UDP as came to know that raw sockets on
    > >windows will be over soon.

    >
    > windoze is not our problem. *I wouldn't recommend UDP as that may also
    > be blocked, or routed with lower priority.
    >
    > >- I have to write multiplatform common code (windows , UNIX type).

    >
    > Look at the TTL of the returning packets. Generally speaking, most O/S
    > use one of five initial TTLs on a TCP packets: 32 (rare, but some
    > versions of windoze), 60 (some old IRIX and True64 boxes), 64, 128, or
    > 255. Few places on the Internet are more than 30 hops away. * Thus, if
    > you receive a packet with a TTL of 46, it _PROBABLY_ came from a box
    > 18 hops away with an initial TTL of 64.
    >
    > >Can anyone suggest me simple and effective method to determine the
    > >nearest site ?

    >
    > You _are_ posting from a search engine - and it's not as if this idea
    > is brand new. While TTL is universal, it's not the only thing in the
    > packet headers that can be used. Looking at RFC1323 _might_ be worth
    > the effort.
    >
    > * * * * Old guy




    Yes , Ping is not an option for me and it's already rejected because
    of the same reason.

    So If I understand correctlly ,
    - you are saying do socket with TCP instead of UDP ?
    - Look at the TTL value of the returning packet . I am not an expert
    of network programming . Will I be abe to look at the TTL value
    writing a C program and opening a TCP socket and sending data ?

    I am going through this RFC and trying to understand what you said and
    how will I implement. Will update.

    Thanks,
    Pramod

  4. Re: Calculating subnet distance.

    On Fri, 11 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article <045cce39-79d3-4557-8174-9f634d5381d6@z24g2000prf.googlegroups.com>,
    pramodsharma08@gmail.com wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.

    >Yes , Ping is not an option for me and it's already rejected because
    >of the same reason.


    Still, using ping will demonstrate the principle of looking at TTLs to
    determine distance.

    >So If I understand correctlly ,
    >- you are saying do socket with TCP instead of UDP ?


    I'm suggesting TCP rather than UDP, because when you reach a decision,
    you will be using TCP to do the data transfer, not UDP. Therefore, what
    happens to UDP (or even ICMP) is not of relevance to your eventual data
    transfer.

    >- Look at the TTL value of the returning packet . I am not an expert
    >of network programming . Will I be abe to look at the TTL value
    >writing a C program and opening a TCP socket and sending data ?


    TTL is in the IP header, so you will need to be able to view that header
    by what-ever method you use. Plenty of other applications have done this,
    such as ping, tcpdump, traceroute, hping2 (and hping3), mtr, and so on,
    so there is plenty of code to use as a reference.

    >I am going through this RFC and trying to understand what you said and
    >how will I implement. Will update.


    You may want to look at the Usenet newsgroup 'comp.protocols.tcp-ip'
    where it's probably closer to "on target".

    comp.protocols.tcp-ip TCP and IP network protocols.

    RFC1323 discusses using timestamps, which can give you absolute time
    of transmission. TTLs are normally decremented at each router, giving
    you the number of hops to the destination.(RFC1812 section 5.2.1). A
    problem with this is that there is nothing that guarantees the the
    route taken from "you" to some remote host will be the same as the
    route taken from the remote host back to "you". Routing is NOT
    symmetrical.

    Old guy

+ Reply to Thread