Ok, enough definitions for a while. Let's now take a rather common example, using a browser to access a remote site, and see exactly what happens, step by step, and in what order:
Figuring out who to call. You either choose a URL from your browser menu or type it in by hand and hit Enter.
Taking out your phone list. Your browser queries the TCP layer for the IP of the URL you've just requested.
Looking through your phone list. The TCP layer checks whether the URL is in the hosts cache.
Calling directory assistance. If it is not, the TCP layer now contacts your ISP's name server.
The operator looks for the number. The name server looks up the URL in its records. The records indicate which servers in the Domain Name System have "authoritative" data on the URL.
The operator says "please hold". If the data is not cached at this local name server because of an earlier request, the name server now contacts one of the authoritative name servers for the information.
The operator your operator just called also says "please hold". As this is a referral system, the above process can iterate several times until the data is found.
Your operator finally comes back. When the data is found, it is returned to your ISP's name server and then to the TCP layer in your local machine.
You dial the number. The TCP layer now gives the data to your browser, and the browser can now attempt to connect to the URL.
Please note that the above process must be repeated each and every time you attempt to access any URL, even if you've accessed that URL before: you have to use a "phone book". The operator at directory assistance did not rush to your house and write the number down for you; the operator cannot know if you will ever need that number again. Likewise, the TCP layer does not store the URLs it finds anywhere on your computer - you have to do that yourself.
Computers are fast, but they're not that fast, and this isn't a matter of computer speed either: this is usually a matter of a modem connection dealing not in nanoseconds but intervals several thousand times larger.
And that's where CIP comes in. CIP manages your "phone list". Steps 4 - 7 are circumvented if the URL should be found locally. Steps 4 - 7 are the real time consuming steps as well - they all deal with remote connections, with calling "directory assistance". By using CIP to store your most often visited URLs locally you can save considerable time on every connection, just as you would if you used a phone list at home.
You need call directory assistance only once for each number - once you have it you write it down and have that number for future use. CIP is like doing a "batch job" with the directory assistance operator - handing over a list of perhaps a few thousand phone numbers and saying you want them all.
CIP takes each URL in turn and resolves it - to an IP - and stores the pair in your hosts cache - your "phone list". This is a lot faster than hanging on the line while the directory assistance operator looks up one thousand numbers. It's computerized. It's fast. And whereas getting a number from directory assistance always takes roughly the same time, using CIP is the equivalent of having a few dozen friends all call different operators at the same time and getting the job done thirty or forty times faster for you. The process is not per query any faster than steps 4 - 7 above, but it can be done concurrently with any number of other DNS queries.
(Sales pitch: Here is where CIP really pulls away from the competition. Most IP checkers on the market can only manage one DNS query at a time - they're no faster than you getting one number at a time from the directory assistance operator. And if any particular number is hard to find, you just stand there and wait - not a pleasant prospect. In the context of the Internet, your IP checker application will "hang" or "freeze up" and leave you waiting, waiting, waiting... One "bottlenet" and the whole show comes to a standstill.)
But because CIP can handle a great number of DNS queries concurrently its speed is dramatic: CIP can complete over thirty (30) DNS resolutions per second. To run through a list of 10,000 URLs takes only five minutes.
Copyright © 2001 radsoft.net. All rights reserved.