Last time we talked about cyberspace as a finite-but-unbounded, digital, information cloud. This time, we'll wax slightly less poetic and discuss the packet-switching side of our digital universe.
Modern computer networks are purveyors of "packets" - individually wrapped pieces of digital information. Each time a computer sends information over the net, it first wraps the information with layers of header and control information which reveal such vital information as the destination address, how the original message must be assembled from the individual packets, how it is encoded, how to determine whether the message has been corrupted, and so forth.
Once the packets are on the net, they take on a life of their own for awhile as they are routed along networks and sub-networks to their ultimate destination. These routings make take several things into consideration including distance to destination, traffic patterns on the net, priority of the message, and so forth.
Eventually, the packets get through to their destination. The layers of header information are stripped from them in reverse order, and the core data is re-assembled into the original message. The techniques for adding and deleting these layers of header information are defined by a network "protocol". When several different protocols are used together at different stages of packet preparation, they are called a "protocol suite". The most popular protocol suite on the Internet is called TCP/IP.
IP stands for Internet Protocol. This is the lower-level protocol of the pair. IP is a "connectionless" protocol, meaning that it is not concerned with the actual receipt of the message - just the integrity of the data it contains. IP Packets are the basic unit of transmission. Each IP packet is layered with header information from each successive network computer which handles it.
TCP is short for Transmission Control Protocol. It is a "connection-oriented" protocol. This means that it is concerned with the actual delivery of the packets to the intended destination. Delivery is a problem because of the bandwidth limitations of the networks.
Any network has an upper bound on the number of packets that it can handle in a unit of time. If that limit is exceeded, it must discard the excess. This means that some pieces of transmitted messages are lost forever.
TCP comes to the rescue. Each packet has a sender address. An acknowledgement is sent to this sender address it is received in proper form. If the receiving TCP software doesn't send the acknowledgement within a certain period of time, the sending TCP software sends another copy. In this way, all of the packets will get through sooner or later.
Once the packets get through, the TCP software eliminates duplicate packets, strips the IP header off of the packet, and re-assembles the data back into the form of the original message. All TCP/IP messages are handled in this way. This includes Email messages, remote procedure calls for interacting with programs which run on distant computers, and radio programs broadcast over Internet Talk Radio, to name just a few. All communication over the Internet which uses TCP/IP works the same way regardless of content.
For those of us who are connected (or connecting) to the Internet, TCP/IP comes into our lives in the form of a TCP/IP program stack purchased from a service provider or vendor. Neither Aunt Jane's birthday note nor our favorite shareware utility will go on the Internet without first passing through the TCP/IP program. There are dozens of companies which market TCP/IP software under as many names, details about which may be obtained from an Internet service provider, ads in the popular trade magazines or shareware servers.
While we expect certain things from TCP/IP software, it also expects some things from us. It needs to know where we are on the network. This logical location is called an IP address. Each computer which is connected to the Internet has an IP address. For example, the workstation that I'm working at right now has an IP address of 126.96.36.199. Any other computer which wants to communicate with this workstation has to use this address on the packets.
Since humans find IP addresses clumsy, they generally prefer to associate an IP address with character-based computer name. The conversion between this "domain name" and the IP address required on the packets is accomplished by a table-lookup Domain Name System, copies of which are continuously distributed to the many Domain Name Servers on the Internet. Thus, the second thing the TCP/IP software expects is the IP address of the closest Domain Name Server. Without this connection, manual IP addressing will be required.
Other information which will likely be required include the closest router which connects your local network to the next larger one of which it is a part and a subnet mask which identifies your relative location within your local network. Any additional information (and their is a ton of it) will usually be provided by your network administrator or service provider. A brief glance at your TCP/IP .INI file will reveal gobs of arcane information which you really don't want to know about.
Two of the most exciting developments in modern Web clients are multi-threading and multi-windowing.
Serious surfing requires these features. Multi-threading is essential because of the extensive use of images, animations and sound on the Internet. These files push the Internet bandwidth to the max and turn your workstation into a boat anchor without multi-threading. Basic arithmetic explains why.
Suppose that I want to download a 100 kilobit WAV file off the Internet. My workstation might be connected to a generic coax LAN, which in turn is connected to a metro or regional WAN which has a gateway access to the Internet. If so, I may expect continuous, sustained throughput of maybe 10 kilobits/second (individual packets actually transfer much faster but the entire packet cluster is slowed by the resource sharing). That's 10 seconds of download time for the file during which the client navigator/browser is for all intents and purposes unusable. That, in turn, translates in 10 wasted seconds of my time. If you want to download an MPEG file, you might as well go out for dinner or take a catnap.
But multi-threading saves the day. In this case, you may continue your surfing expedition or use other client resources while waiting for the complete download. For those who haven't used multi-threaded clients, take it from the chief cybernaut - it's the only way to go. For your information, the only multi- threaded products out there at this writing are Windows programs (which is kind of ironic since Windows lacks genuine multitasking, but that's another story altogether). They are InterNetworks and Win Tapestry (see inset).
The second "must" is multi-windowing. This is a consequence of multi-threading. Multi-threading gives you the capability of running several concurrent sessions only one of which is viewable without multi-windowing. One variation on multi-windowing is a multi-paning which accomplishes the same task but with re-sizable panes within a single window.
Figures 1 and 2 illustrate the use of multithreading and multi- paning in the InterNetworks product. Note the organizational simplicity in navigating and browsing for AI literature and home- oriented information for the family and kids.
Multi-threading and multi-widowing. It's the only way to go.
More to come. Stay tuned to the cyberscene through Cybernautica.
[note: Hal Berghel is technical editor of PC AI and a frequent contributor to the literature on cyberspace. His url is http://berghel.net. Send questions and comments to hlb -at- berghel dot net . For further reading see his article "Cyberspace Navigation" in the Sept. 1994 issue of PC AI or his forthcoming article "OS/2, Unix, Windows and the Mosaic War" in the May, 1995 issue of OS/2 Magazine.]
BERGHEL'S URL PEARLS
For Barney lovers everywhere: http://www.galcit.caltech.edu//~ta/barney
And something from Barbie: http://deepthought.armory.com/~zenugirl/
On the serious side, one of the finest information sources around: http://nearnet.gnn.com/gnn/gnn.html
Everything that you wanted to know about Vermont: http://www.cybermalls.com/cymont/cymonmal.htm