Evolution of Computer Networks: From ARPA to Internet

1. CSC383 Computer Networks Dr. Allen M. Johnson, Jr.

2. History… • 1st networks designed to share large-scale computational power • 1st commercially available network system was IBM’s PROFS system. (mainframes) • Late 1960s, ARPA started investigating data networking. • Idea of networking computers of different architectures • Thought to be a crazy idea by many

3. … History… • In the late 1970s inexpensive minicomputers provided time-sharing facilities to people within a department. • Organizations installed Local Area Networks (LANs) to interconnect these machines together.

4. …History… • ARPA chose to investigate a revolutionary approach, known as packet switching. • They hired people to work on network research and contractors to turn the designs into a working system called the ARPANET. • This was so successful that ARPA continued funding research into a networking technology called internetworking.

5. …History • By the 1970s, internetworking was the focus of ARPA research and the Internet had emerged. • ARPA continued funding research into the 1980s, • Internet became a commercial success in the 1990s.

6. Growth of Internet • The Internet has grown from an early research prototype into a global communications system that connects every country. • By 1999, the Internet was growing so fast that a new computer was added to the Internet every second.

7. Figure 2.1 …Growth of Internet

8. …Growth of Internet

9. Protocols and Layering • Computer networks are complex systems including both hardware and software. • Designers divided the communication problem into subparts, called layers, with the interfaces between the layers defined by protocols.

10. TCP/IP 5-layer Reference Model

11. TCP/IP Layered Model • physical layer corresponds to basic network hardware. • Network interface layer specifies how data is divided into frames for transmission over a network. • Internet layer protocols specify the format of packets sent across an internet as well as the mechanisms used to forward packets from a computer through one or more routers to a final destination. • Transport layer specifies how to provide reliable transfer and the Transmission Control Protocol (TCP) software also provides additional facilities required by higher-level applications. • Application layer specifies how applications use the Internet.

12. Probing the Internet • Simplest probing tool is the Packet InterNet Groper, or ping. • According to the Internet requirements document [RFC 1122] , every TCP/IP stack should implement such a program.

13. PING Command Example • penguin(101)% ping -c5 www.netbook.cs.purdue.edu PING lucan.cs.purdue.edu (128.10.19.20) from 193.61.29.127: 56(84) bytes of data 64 bytes from lucan.cs.purdue.edu (128.10.19.20): icmp_seq=1 ttl=235 time=131 ms 64 bytes from lucan.cs.purdue.edu (128.10.19.20): icmp_seq=2 ttl=235 time=131 ms 64 bytes from lucan.cs.purdue.edu (128.10.19.20): icmp_seq=3 ttl=235 time=131 ms 64 bytes from lucan.cs.purdue.edu (128.10.19.20): icmp_seq=4 ttl=235 time=131 ms 64 bytes from lucan.cs.purdue.edu (128.10.19.20): icmp_seq=5 ttl=235 time=131 ms --- lucan.cs.purdue.edu ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 4008ms rtt min/avg/max/mdev = 131.394/131.742/131.978/0.317 ms penguin(102)% • -c5 instructs ping to stop after sending five probes • summary on the first line indicates an alternative name for the target is lucan.cs.purdue.edu, that its IP address is 128.10.19.20, and it’s sending 56 bytes of data in an 84-byte IP datagram. • The next five lines are the responses received. These indicate that there are approximately 20 (= 255 - 235) hops between penguin.dcs.bbk.ac.uk and www.netbook.cs.purdue.edu, and that the average round-trip time is 131 ms.

14. What Good Is PING • Cons • Little info for average user • Not good as debug tool • Output occurs only when computer responds • Fails if network is congested • PING cannot determine cause of problem • Some companies configure systems to reject pings • Pros • Determine which part of network is still operating • Results help pinpoint failure quickley

15. Traceroute • Determine intermediate computers along the way • Uses same arguments as PING (remote computers name or address) • Shows how the hops between source and destination. • http://www.net.cmu.edu/cgi-bin/netops.cgi

16. Figure 2.6

17. Chapter 3 Introduction • Use of a network requires programs (and systems) that are “network-aware.” • Some applications are usually provided with machines (e.g. web clients, e-mail clients, file sharing). • New custom applications must use the interface (API) to the network facilities provided by the system. • We will look at a simple API and three sample applications (both the client and the server).

18. Network Communication • Networks are the mechanisms that transmit data from one point to another. • Logically, networks are (or should be) passive, and do not understand, act on, or modify the data being moved. • There are two ends of a network communication, each associated with an application program that understands the generation and interpretation of the data being moved across the network.

19. Client-Server Computing • The two applications that communicate using a network must locate each other. • Typically, one application (the server) starts and then waits for the other application (the client) to contact it. • This arrangement is usually called the client-server paradigm, or just client-server computing. • The client must, of course, be able to locate the server for this arrangement to work.

20. Addressing Internet Applications • Each network server application has a two-part address of the form (computer,application). • The computer part of the address identifies the particular computer on which the application is running. This can be provided in symbolic (e.g. apollo.unomaha.edu) or numeric (e.g. 137.48.1.12) form. • The application part of the address identifies the particular application. It, too, can be provided symbolically or numerically. • When transmitted on a network, the (computer,application) address is always sent in binary.

21. Communication Paradigm • Most Internet applications follow this basic sequence of operations for communication: • The server starts first, and waits for contact from a client. • The client contacts the server by specifying its location and requesting communication. • The client and the server exchange messages. • After they finish, the client and server each send an end-of-file to terminate communication. • Functions are provided in the class library on apollo to perform each of these tasks.

22. An Example Application Program Interface • The term “application program interface,” or API, is used to describe the set of operations available (in a particular programming domain) to a programmer. • The simplified API presented in the textbook hides much of the complexity in network programming, but also doesn’t provide the richness of the usual networking API. We will see more details in later chapters.

23. Example API Overview Operation Meaning await_contact used by server to wait for a contact make_contact used by client to contact a server cname_to_comp translate a computer name to an equivalent internal binary value appname_to_appnum translate a program name to an equivalent internal binary value send used by client or server to send data recv used by client or server to receive data send_eof used by client or server after all data has been sent.

24. An Intuitive Look at the API • The application actions usually follow this pattern: • The server calls await_contact to wait for contact from a client. The client calls make_contact to establish the connection. [The server is said to be blocked until the contact is made.] • Once contact is made, the applications use send and recv to exchange data. [The protocol dictates when each application sends or receives.] • Once the data exchange is complete, the client or the server terminates the connection by calling send_eof. The other application detects the termination of the communication when recv returns 0.

25. A Trivial Example

26. API Definition – Data Types • There are three data types (in addition to the usual integer, character, and real data types) used in the API: • appnum: a binary value used to identify an application [this is really a port number]. • computer: a binary value used to identify a computer [this is really an Internet Protocol address, or IP address.] • connection: a value used to identify one endpoint of a connection between a client and a server [normally this identifies a socket data structure].

27. API Definition – await_contact • A server calls await_contact to wait for a contact from a client. The function expects one argument of type appnum, and returns a connection which is then used in send, recv, and send_eof functions. connection await_contact (appnum a)

28. API Definition – make_contact • A client calls make_contact to establish contact with a server. The arguments identify the computer on which the server is running, and the application number to be contacted. The function returns a connection used for send, recv, and send_eof by the client. connection make_contact (computer c, appnum a)

29. API Definition – appname_to_appnum • This function is used to translate from a predefined human-readable name [character string] to a binary application number. Standard application names are defined in the /etc/services file on a UNIX system. It takes a string argument and returns the binary application number. appnum appname_to_appnum (char *name)

30. API Definition – cname_to_comp • This function translates a symbolic computer name (cname) to the equivalent binary form (which is returned) of type computer. computer cname_to_comp (char *cname)

31. API Definition – send • Send arranges to transmit data (a sequence of n bytes in a char array buf) over an established connection c, returning the number of bytes actually transmitted. The last argument is always 0 in this simplified API. int send (connection c, char *buf, int n, 0)

32. API Definition – recv • Recv receives at most n bytes of data from a connection c, placing it in a char array buf, and returning the number of bytes received and stored. Recv will return 0 only when the end of file is reached, and a negative value when an error occurred (e.g. recv without a valid connection). int recv (connection c, char *buf, int n)

33. API Definition – recvln • Recvln reads one line of data (terminated by an end of line character) from a connection c into a char array buf; no more than n-1 bytes will be read (allowing one byte for string termination). Recvln uses recv to read one byte at a time. int recvln (connection c, char *buf, int n)

34. API Definition – send_eof • Send_eof terminates the connection c, returning a negative number if an error occurred. int send_eof (connection c)

35. The ECHO Application • The ECHO application server merely resends each line it receives from a client. The server is started (from a command line) by typing the program name and a selected application number (usually in the range 1025 to 32767). • The client application is started by typing its name, the name of the computer on which the server is running, and the same application number. • Lines are then read by the client, echoed by the server, and displayed by the client, until an end of file (control-D on UNIX, or control-Z on Windows) is entered. • Illustration…

36. An Important Observation • If you examine the code for the echo client, you will find that it does not immediately read another line from the keyboard after reading data from the connection. This is because recv only returns as much data as it has actually read. • The reason for this is that the underlying network may send a group of data bytes in several different packets. Thus the received data may arrive in pieces with sizes different from those used when the data was sent.

37. The CHAT Application • The chat application is similar to the echo application. Here, however, the server displays the received data line and waits for a response from the user on that machine, which is then sent back to the client for display. • Either the user at the server machine or the user at the client machine may terminate the chat session by entering an end of file. • Illustration…

38. The WEB Application • Our final example is a simple text-mode web server and browser. Only two web pages are provided by the server: “/” and “/time”. It is easy, however, to extend this application to deliver arbitrary pages stored as files on the server machine. • The server and client both use the standard HTTP protocol, and the server delivers HTML documents with appropriate headers. Thus a commercial web browser could be used to contact our server. • Illustration…