Results 1 to 1 of 1

Thread: VB6 - Transit Time Tester V2

Threaded View

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    VB6 - Transit Time Tester V2

    Attached is an upgraded version of Transit Time Tester utilizing a subset of SimpleSock.

    Users sometimes want to know how accessible a certain site is and how long it takes to get to it. The "ping" command has traditionally been used for that, but there are problems using this utility. The difficulty is created by the way that some routers handle Internet Control Message Protocol (ICMP) packets. These routers give ICMP packets the lowest priority, so the round trip time displayed is highly questionable.

    The TTL in "ping" packets does not actually represent a "Time To Live". It is a hop counter. To prevent a packet from going into an endless loop, the TTL is decremented as it goes through each router. If the counter gets to zero, the router is supposed to send a message back to the originator. "Tracert" utilizes this feature. The TTL is incremented for each ping packet that it sends out, so in theory it can track the packet as it goes through each router. Some routers have the feature turned off to prevent "Ping Floods" or if they are deemed too busy to handle them.

    One would expect that the return time would increase as the TTL is incremented. But that is often not the case, due to the fact that routers give these packets a lower priority and delay them.

    "Ping", (as well as "Tracert") utilize UDP packets, which do not establish a connection with the far end. Transit Time Tester uses TCP packets, which are initiated using a 3-way handshake. The client sends a SYN request, the server responds with a SYN-ACK, and the client completes the connection with an ACK. Transit Time Tester measures the time required to receive the SYN-ACK, and prevents the connection from being established by forcing an error.

    When it came time to write this description, the network was not that busy and the return times pretty well matched the ping times. Fortunately I had some historical data that represented the case.

    Using the "Ping command:
    C:\>ping 96.53.96.50
    Pinging 96.53.96.50 with 32 bytes of data:
    Reply from 96.53.96.50: bytes=32 time=52ms TTL=58
    Reply from 96.53.96.50: bytes=32 time=50ms TTL=58
    Reply from 96.53.96.50: bytes=32 time=52ms TTL=58
    Reply from 96.53.96.50: bytes=32 time=49ms TTL=58
    Ping statistics for 96.53.96.50:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 49ms, Maximum = 52ms, Average = 50ms

    Using "Transit Time Tester" as shown below yielded an average time of 47 ms. The "Ping" was returned by the router in front of the server (one less hop), and clearly demonstrates that the TCP packets had a higher priority.

    For the domain, you can use the domain name, the domain IP Address, or just copy and paste the URL. If the URL is used, the port is automatically adjusted to 80.

    J.A. Coutts
    Attached Images Attached Images  
    Attached Files Attached Files

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width