CM10228 / Programming Ib:   Lecture 11

Networking, Protocols & the Internet

I.  Buffering

  1. A buffer is a piece of memory that holds a local copy of something that you really want to read or write to somewhere else.
  2. The reason you have them is so that you don't waste too much time waiting on slow processes, like writing or reading from a disk or network.
  3. You have probably seen a little bar representing a buffer fill up when you run a video from the Internet, e.g. on quicktime. 
    1. For quicktime, when the buffer seems to be full enough that you can probably watch to the end of the movie, it lets you start seeing the movie.
    2. But if the network gets unexpectly worse / slower, then the movie will stop & you will have to wait until the buffer refills.
  4. Because writing is often buffered, if you want to make sure that what you have written has gone to the screen, you have to give a command to flush the buffer (see code below).
    1. This is also a big issue if you add printlines to debug a program.  Be sure to flush them right away, or the program may crash before the message you wanted to print get sent to the screen, even if the printline was executed succesfully.

II. Clients for the date & echo services:

  1. Note most of the below doesn't work these days, because services have been turned off.
    1. This is due to security concerns.
    2. I've left the below in for you to see anyway as example clients, it's just that you aren't going to get to run them & try it yourself.
    3. Unless you download (or write) a service server yourself and run it on your own machine!
    4. Note to lecturer: this lecture combines two old ones & so runs long
      1. go through this quickly for history, but  basically skip the clients and get to the line server, demo telnet off of that.
      2. probably showed /etc/services in the previous lecture.
  2. In order to make clients and servers more clear to you, here are some examples based on standard services.
  3. The example servers are standard internet services, which are provided by at least unix / linux computers.
    1. Standard services have standard port numbers.
    2. On unix machines (including mac OS X) you can find these in /etc/services
    3. There is also an internet site detailing all standard port-number assignments.
    4. From that page:
      The port numbers are divided into three ranges: the Well Known Ports,
      the Registered Ports, and the Dynamic and/or Private Ports.

      The Well Known Ports are those from 0 through 1023.

      DCCP Well Known ports SHOULD NOT be used without IANA registration.
      The registration procedure is defined in [RFC4340], Section 19.9.

      The Registered Ports are those from 1024 through 49151

      DCCP Registered ports SHOULD NOT be used without IANA registration.
      The registration procedure is defined in [RFC4340], Section 19.9.

      The Dynamic and/or Private Ports are those from 49152 through 65535
    5. So when you pick a port for your own application, pick one bigger than 49152!
  4. The example client is a program called telnet, which is a generic client which can connect to any service. 
    1. The thing is, you have to type in the side of the protocol that the server expects.
    2. That's because telnet (being generic) won't know about it.
    3. So you are kind of being a fake client, and telnet is just helping you out.
    1. Since there are a lot of different actors in these examples I'm using colour coding.
      1. Sorry if you are colour blind.  You can try looking at the html source to see which colours I used!
      2. Green is me.
      3. Blue is the telnet program.
      4. Reds & oranges are the servers (there are different ones.)
      5. Black is the unix shell.  (the operating system)
    2. Here I am turning the services on & talking to them on for my linux box:
      [root@sydney etc]# telnet localhost 7
      telnet: connect to address Connection refused
      [root@sydney etc]# /sbin/chkconfig daytime on
      [root@sydney etc]# telnet localhost 15
      telnet: connect to address Connection refused
      [root@sydney etc]# less services # this let me see what the different services were & find the right number
      [root@sydney etc]# telnet localhost 13
      Connected to localhost.
      Escape character is '^]'.
      17 MAR 2004 21:50:15 GMT
      Connection closed by foreign host.
      [root@sydney etc]# less services
      [root@sydney etc]# /sbin/chkconfig echo on
      [root@sydney etc]# telnet localhost 7
      Connected to localhost.
      Escape character is '^]'.
  5. Notice a couple of things here:
    1. I've tapped into the server with a program called "telnet".  
      1. Telnet basically just lets you talk to ports directly. 
      2. It used to be used to login for sessions, but it's too insecure.  Nowadays we use ssh instead.
      3. I'll be showing you how you can use telnet to fake internet / application protocols in a couple weeks (assuming *that* hasn't been shut down).
    2. Mostly because of security, but also because in class I won't be networked, I'm talking to my own machine as if it's a machine on the internet.
      1. Your own machine can be accessed with the special IP address
      2. it's DNS name is "localhost" (as well as any other name you've given it.)
      3. Again, I'll probably explain DNS & how the internet routes packets in two weeks.
    3. I happen to be in the /etc directory, so the file that tells you the right port number for things is just "services".
    4. I have to be root to turn the services on.
    5. More hacky notes like these are here.
  6. The first server, daytime (port 13), kicked me out after giving me the information it gives.
    1. I didn't have to type anything at all.
    2. very simple protocol.
  7. The second server, echo (port 7) responded to what I typed. 
    1. But there's no way to quit it!
    2. To quit I had to talk to telnet directly, so I had to type the telnet escape command, ^].
  8. Assuming you can find a computer that will let you talk to its daytime server, then you can run this program (which is taken with only a slight modification from Object-Oriented Programming with Java by David Barnes, Chapter 19 (on Networking!):

    // Contact the daytime server running on hostname.
    public class DaytimeClient {
    // Contact the server at the appropriate port and set
    // the socket attribute for the run() method to use.
    public DaytimeClient(String hostname) throws Exception {
    // The well-known port of the TCP daytime service.
    final int DaytimePort = 13;
    socket = new Socket(hostname,DaytimePort);
    catch(UnknownHostException e){
    throw new Exception("Unknown host: "+e.getMessage());
    catch(IOException e){
    throw new Exception("IOException on socket creation: "+e.getMessage());

    // Obtain the time of day from the daytime server.
    public void run() {
    Socket daytime = getSocket();
    // Get the stream used by the server to send data.
    InputStream inStream = daytime.getInputStream();
    // Wrap the stream in a BufferedReader.
    BufferedReader reader = new BufferedReader(
    new InputStreamReader(inStream));

    // The server will only send a single line.
    String response = reader.readLine();
    // Close the connection now it is finished with.
    catch(IOException e){

    protected Socket getSocket(){
    return socket;

    private final Socket socket;

    public static void main(String[] args) {
    if(args.length == 1){
    DaytimeClient client = new DaytimeClient(args[0]);;
    catch(Exception e){
    System.err.println("Exception: "+e.getMessage());
    System.err.println("You must supply the name of a host to contact.");

  9. Here's one that talks to echo...

    /* author david barnes & joanna bryson

    // Contact the echo server running on hostname.
    class TCPEchoClient {
    // Contact the server at the appropriate port and set
    // the socket attribute for the run() method to use.
    public TCPEchoClient(String hostname) throws Exception {
    // The well-known port of the TCP echo service.
    final int EchoPort = 7;
    socket = new Socket(hostname,EchoPort);
    catch(UnknownHostException e){
    throw new Exception("Unknown host: "+e.getMessage());
    catch(IOException e){
    throw new Exception("IOException on socket creation: "

    protected Socket getSocket(){
    return socket;

    private final Socket socket;

    public static void main(String[] args) {

    try {
    TCPEchoClient eClient = new TCPEchoClient("localhost");

    // now you know stdin is really a socket too!
    BufferedReader stdin =
    new BufferedReader(new InputStreamReader(;
    String myEchoString;

    System.out.print("Welcome to the echo client. The prompt looks like >>."
    + "\n >> ");

    // Wrap the input stream in a BufferedReader.
    BufferedReader reader = new BufferedReader(
    new InputStreamReader(eClient.getSocket().getInputStream()));
    // Wrap the output stream in a BufferedWriter.
    BufferedWriter writer = new BufferedWriter(
    new OutputStreamWriter(eClient.getSocket().getOutputStream()));

    // read a string from stdin & send it to echo
    while ((myEchoString=stdin.readLine()) != null) {
    System.out.println("Sending: "+myEchoString);

    // Make sure the data is flushed to the stream.

    // Read the response.
    String response = reader.readLine();
    System.out.println("The response is: "+response);
    System.out.print("\n >> ");
    } // while strings
    // Close the connection
    catch(IOException ioe){
    catch(Exception e) {

    } // main()

    } // class TCPEchoClient
  10. Sorry I didn't color those creatively, but if you look at them in emacs (or eclipse) it should color them for you.
    1. If your BUCS unix server emacs isn't making pretty colors for you, you should put this in your .emacs file
      ; stick colour in old versions of emacs --

      ;; Are we running XEmacs or Emacs?
      (defvar running-xemacs (string-match "XEmacs\\|Lucid" emacs-version))

      ;; Turn on font-lock mode for Emacs
      (cond ((not running-xemacs)
      (global-font-lock-mode t)

      ; -- ( colour stuff from Adam Dziedzic ) --
    2. Notice:  emacs is written in lisp!
    3. You might want to look at ~cssjjb/.emacs for more random stuff

III. Servers

  1. As mentioned in Lecture 10, servers:
    1. have to start running first.
    2. need a port to listen for clients on.
  2. But once a server has made the connection to the client, it's really just the same.
  3. Here is yet more code from David Barnes -- this time I left the main as he wrote it (in another class) though I really don't see the advantage... (so no comment claiming I'm a coauthor!)
  4. The server class

    // A simple server that accepts a client connection
    // and sends back the length of the strings it
    // receives from the client.
    class LineLengthServer {
    public LineLengthServer(int port) throws Exception {
    // Listen on the given port.
    serverSocket = new ServerSocket(port);
    catch(BindException e){
    throw new Exception("Failed to create a server socket: "+

    // Read strings and return their length (as a String)
    // to the client.
    public void run() throws Exception {
    ServerSocket serverSocket = getServerSocket();
    Socket clientSocket = null;
    System.out.println("Listening for a client on port: "+
    // Wait for a client to make contact.
    clientSocket = serverSocket.accept();
    // Contact ...
    System.out.println("A client has arrived.");

    // Wrap the input stream in a BufferedReader.
    BufferedReader reader = new BufferedReader(
    new InputStreamReader(clientSocket.getInputStream()));
    // Wrap the output stream in a BufferedWriter.
    BufferedWriter writer = new BufferedWriter(
    new OutputStreamWriter(clientSocket.getOutputStream()));

    // Read lines until the client terminates.
    String request = reader.readLine();
    while(request != null){
    // Write the length of the line as a String.
    request = reader.readLine();
    catch(IOException e){
    throw new Exception("IOException talking to the client: "+
    if(clientSocket != null){
    System.out.println("The client has gone.");
    // Close the socket to the client.

    protected ServerSocket getServerSocket(){
    return serverSocket;

    // The socket on which the listening is done.
    private final ServerSocket serverSocket;
  5. The "main" class
            // An example of a simple server that reads lines from
    // clients and sends back the length of each line
    // it receives.
    public class LineLengthServerMain {
    public static void main(String[] args){
    // An arbitrary port number to listen on. This should be
    // larger than 1024 for user-written servers.
    final int port = 24101;
    LineLengthServer server = new LineLengthServer(port);;
    catch(Exception e){
    System.err.println("Exception: "+e.getMessage());

  6. Running it from linux
    [joanna@sydney Networks]$ javac
    [joanna@sydney Networks]$ java LineLengthServer
    Exception in thread "main" java.lang.NoSuchMethodError: main
    [joanna@sydney Networks]$ java LineLengthServerMain
    Listening for a client on port: 24101
    [2]+ Stopped java LineLengthServerMain
    [joanna@sydney Networks]$ bg
    [2]+ java LineLengthServerMain &
    [joanna@sydney Networks]$ telnet localhost 24101
    A client has arrived.
    Connected to localhost.
    Escape character is '^]'.
    hi there
    have you ever thought
    this isn't really measuring the line length...
    Ah ha!

    telnet> .
    ?Invalid command
    telnet> quit
    Connection closed.
    The client has gone.
    [2]+ Done java LineLengthServerMain
    [joanna@sydney Networks]$
    1. Notice I used telnet as a client again (see colour code mentioned earlier).
    2. And also, I suspended the server process (with ^Z) and then backgrounded it by typing bg
      1. This made it start running run, but leaving me STDIN to use with telnet.
      2. You can also type fg and get right back where you were.
      3. You could also start the server in the background in the first place by typing an & afterwards like this:  j2bryson$ java LineLengthServerMain &
      4. Note both programs now shared STDOUT!
    3. Consequently, both programs were printing to the screen at the same time -- telent I made blue, the server red, and what I typed green.
    4. I also forgot the telnet protocol / commands -- I thought you killed it with a .
      1. mail quits with a .
      2. I got it right the second guess though.
      3. Don't be afraid to hack!
  7. If you want to make a server accept more than one connection, just put a while loop in so it looks again (see the outlined server back in section I.)
  8. If you want to have the server accept new clients while it's still servicing old ones, you need to use threads!
    1. You need this for coursework 2.
  9. Here's an example of that, again from Barnes (hey, he writes good examples! This is from RandomServiceListener)
        public void listen() throws Exception {
    ServerSocket serverSocket = getServerSocket();
    // Wait up to 30 minutes for new clients.
    final int timeToWait = 1*60*1000;
    boolean keepWaiting = true;

    // Wait for a client to make contact.
    Socket clientSocket = serverSocket.accept();
    // Let a separate Thread handle it. QUIZ why are there 2 news?
    new Thread(new RandomService(clientSocket)).start();
    catch(InterruptedIOException e){
    // We timed out waiting for a client.
    keepWaiting = false;
    catch(IOException e){
    throw new Exception("IOException: "+ e.getMessage());
    // No more clients, so close the socket.
    1. Notice not only the threading, but the fact it handles interupts, so it can eventually be killed!
    2. It also sets a timeout so that it will effectively interrupt itself if it's been waiting too long (as well as accepting terminate signals, e.g. from the keyboard.)
    3. it also creates a Thread object just to access "start" (answer to quiz)

IV. Protocols

  1. A protocol is a system / procedure for communicating between two computers.
  2. As with military & diplomatic protocols, it's designed to make certain that mistakes or misunderstandings don't happen.
    1. Computers are even stupider than people, so computer protocols have to be followed very precisely.
    2. For both humans and computers, failure to follow correct protocol is one way to spot intruders.
      1. Example from "From Russia with Love"
      2. James Bond: Pardon me, do you have a match?
        Agent: I use a lighter.
        James Bond: Better still.
        Agent: Until they go wrong.
        James Bond: Exactly.
      3. Actually, in the movie, this protocol is run several times, with Bond taking the part of either agent. 
        1. The purpose of the protocol is for two agents who don't know each other to make certain they are talking to the right person before they reveal anything.
        2. It doesn't matter which agent goes first, what matters is
          1. that the conversation could be started with anyone, but
          2. it would be unlikely to be completed correctly except by another program / agent that is running the same protocol.
  3. In computers, protocols happen at many different levels simultaneously
  4. From's tutorials:

    a picture of 7 layers, you're not
                missing anything!

    The seven layers of the OSI Basic Reference Model are (from bottom to top):

    1. The Physical Layer describes the physical properties of the various communications media, as well as the electrical properties and interpretation of the exchanged signals. Ex: this layer defines the size of Ethernet coaxial cable, the type of BNC connector used, and the termination method.
    2. The Data Link Layer describes the logical organization of data bits transmitted on a particular medium. Ex: this layer defines the framing, addressing and checksumming of Ethernet packets.
    3. The Network Layer describes how a series of exchanges over various data links can deliver data between any two nodes in a network. Ex: this layer defines the addressing and routing structure of the Internet.
    4. The Transport Layer describes the quality and nature of the data delivery. Ex: this layer defines if and how retransmissions will be used to ensure data delivery.
    5. The Session Layer describes the organization of data sequences larger than the packets handled by lower layers. Ex: this layer describes how request and reply packets are paired in a remote procedure call.
    6. The Presentation Layer describes the syntax of data being transferred. Ex: this layer describes how floating point numbers can be exchanged between hosts with different math formats.
    7. The Application Layer describes how real work actually gets done. Ex: this layer would implement file system operations.

    The original Internet protocol specifications defined a four-level model, and protocols designed around it (like TCP) have difficulty fitting neatly into the seven-layer model. Most newer designs use the seven-layer model.

  5. Actually having this many layers of protocol is controversial, because it may slow things down, and it's unclear that it brings much advantage. 
    1. The five-layer TCP/IP model skips the presentation & session layer above.
  6. But it is useful to have at least a few layers, e.g.
    1. The machine / hardware layer (get the bits into the right format for the wires / computer).
    2. The communication / networking layer, on the internet typically TCP/IP (check & route the packets).
    3. The application layer.
  7. Application protocols are often human readable so that they can be debugged.  But lower level protocols are only for machines.
  8. Java's basic sockets provide a connection-oriented protocol which will make sure no data is lost for you.
    1. connection is maintained even when no data is going down it.
    2. In particular, Java uses TCP (the Transmission Control Protocol).
    3. This works on top of IP (the Internet Protocol) which is what handles the packets 
      1.  are little chunks the data gets broken into so no big / slow chunk risks getting lost or blocking other actions
      2. packets include some other useful information such as the address they're going to.
      3. having the apacketsddress in every packet is redundant, so the size of packets has to be traded off with other networking considerations.
  9. An example of a human-readable protocol is the Send Mail Transfer Protocol (SMTP).    You sometimes see parts of it in messages that have bounced.
  10. You can also use it through telnet (see the last networking lecture for more on telnet!)
  11. Here's an example of me forging mail to myself, from my other (older) self.
    1. I start out trying to be Elvis, but the mail server is on to this trick these days!
      [jjb@jjb op.papers]$  telnet XXXXX 25
      Connected to (138.38.XXX.XXX).
      Escape character is '^]'.
      220 ESMTP Exim 4.30 Tue, 16 Mar 2004 08:00:12 +0000
      214-Commands supported:
      RCPT TO:
      503 sender not yet given
      MAIL FROM:
      250 OK
      RCPT TO:
      550 RFCs mandate HELO/EHLO before mail may be sent
      501 Syntactically invalid HELO argument(s)
      214-Commands supported:
      250 Hello []
      RCPT TO:
      503 sender not yet given
      MAIL FROM:
      250 OK
      RCPT TO:
      550-Verification failed for
      550-Unrouteable address
      550 Sender verify failed
      RCPT FROM:
      500-unrecognized command
      500 Too many syntax or protocol errors
      Connection closed by foreign host.
      [jjb@jjb op.papers]$ telnet XXXXXX 25
      Connected to (138.38.XXXXXX).
      Escape character is '^]'.
      220 ESMTP Exim 4.30 Tue, 16 Mar 2004 08:04:01 +0000
      250 Hello []
      RCPT TO:
      503 sender not yet given
      MAIL FROM:
      250 OK
      503 valid RCPT command must precede DATA
      RCPT TO:
      250 Accepted
      354 Enter message, ending with "." on a line by itself
      Hi Dr. Bryson, this is me pretending to be myself at MIT.
      250 OK id=1B39ZG-0004yz-DU
      221 closing connection
      Connection closed by foreign host.

      (and then in my mail spool I got...)

      Received: from air ([unix socket])
      by air (Cyrus v2.1.15) with LMTP; Tue, 16 Mar 2004 08:05:15 +0000
      X-Sieve: CMU Sieve 2.2
      Delivery-date: Tue, 16 Mar 2004 08:05:15 +0000
      Received: from [] (
      by with smtp (Exim 4.30)
      id 1B39ZG-0004yz-DU
      for; Tue, 16 Mar 2004 08:05:15 +0000
      X-Spam-Score: 2.9 (++)

      Hi Dr. Bryson, this is me pretending to be myself at MIT.
    2. Notice this doesn't actually mention -- although I needed a valid address to send mail, it didn't get stuck into the Return-Path 
      1. I probably could have put it in with a few more arguments buried in the DATA.
      2. But that wouldn't have generated a full path through the internet.
      3. This is something spam assassin looks for!  Notice I got a high spam score without saying any bad words.
    3. This example was run in 2004 -- in lecture I'll show you that it's not much different in 2010.
      1. No I won't – by  2014 the security folks notice if a machine is using their mailer but isn't in their domain.
  12. The interesting thing is that the SMTP protocol is only the numbers & letters + their arguments.  
    1. You know there can be many different mail clients that use this protocol, you've probably used a few different ones (pine, gmail, outlook, mail).
    2. People can also write different servers!  For example, here's the mail server that's built into my Linux laptop (Redhat 9)
      [joanna@sydney CM10135]$ telnet localhost 25
      Connected to localhost.
      Escape character is '^]'.
      220 localhost.localdomain ESMTP Sendmail 8.12.8/8.12.8; Thu, 18 Mar 2004 14:08:45 GMT
      250 localhost.localdomain Hello localhost.localdomain [], pleased to meet you
    3. The geeks who wrote this program chose to add ", pleased to meet you" after the formal protocol, because the spec told them it didn't matter what they said.  
      1. Or possibly the geeks that wrote the other mailer chose to drop that part off, so it would look more professional, knowing that no one bothered to parse that bit.
      2. Either way, the point is that the protocol is what matters, the clients & servers can change as long as they observe it.
  13. You may also want to look at this lecture on internet applications from Dave Hollinger

V. How Internet Addressing Works

  1. See the Wikipedia entry in IP Addresses.
  2. Here are some great lecture notes on IP Addresses & DNS for Java (in PDF), and some decent ones on the Architecture of the Internet (in HTML).
  3. Internet invented by Al Gore, no seriously, by Larry Roberts & Tom Merrill (see the Brief History of the Internet)
    1. who in 1965 connected a computer at MIT with one from Stanford (? CA anyway, maybe some DARPA lab), 
    2. they invented the idea of breaking data into packets & resending ones that got lost.
    3. Most research was funded by the US Military, "ARPANET" 
      1. so the government could survive nuclear war.
      2. very decentralized -- any computer that gets a packet knows how to send it to another computer that can
    4. Larry Roberts also invented email in 1972.
    5. MILNET (for the US military) & ARPANET split in 1983, the same time as TCP/IP was adopted as main protocol 
      1. 1983 is also when I got my first email account, coincidently.
      2. When we used to use email in the 80's, email took a day to get around the world.
        1. We thought this was amazing!
        2. Links in the internet phoned each other maybe once every hour or two to see if there were any bits to send.
    6. Al Gore did help get a lot of US taxpayer money into developing/expanding the Internet for commercial use --- politics does matter.
  4. Internet addresses currently are four 8-bit numbers (so each goes up to 28, or 256), so there can be 4,294,967,296 unique IP addresses -- probably not enough for 7,000,000,000 people!
  5. Getting a packet to the right place:
    1. first get it to a machine that matches the first number,
    2. that machine should be able to get it to a machine that matches the second number...
    3. so routers only need to know how to get to 4*256 machines, (1024), not 4 billion.
    4. logarithmic!  divide & conquer!
  6. Traceroute will show you how packets have to travel --- again, if you can find a machine that still runs it (I had to go to MIT... in 2004!)
    1. It works from a coffeeshop in 2014, but is weirdly slow.  But below is the 2004 one.
      /home/ai/joanna % traceroute
      traceroute to (, 30 hops max, 40 byte packets
      1 net-chex ( 1 ms 1 ms 1 ms
      2 anacreon ( 2 ms 3 ms 1 ms
      3 radole ( 2 ms 76 ms 74 ms
      4 B24-RTR-2-LCS.MIT.EDU ( 70 ms 109 ms 72 ms
      5 EXTERNAL-RTR-2-BACKBONE.MIT.EDU ( 89 ms 105 ms 87 ms
      6 ( 95 ms 84 ms 80 ms
      7 ( 91 ms 99 ms 98 ms
      8 ( 73 ms 118 ms 115 ms
      9 ( 175 ms 109 ms 133 ms
      10 ( 129 ms 143 ms 148 ms
      11 ( 150 ms 134 ms 143 ms
      12 ( 173 ms 153 ms 163 ms
      13 ( 141 ms 191 ms 201 ms
      14 ( 191 ms 186 ms *
      15 ( 156 ms 167 ms 138 ms
      16 ( 138 ms 158 ms 161 ms
      17 ( 143 ms 193 ms *
      18 ( 174 ms 153 ms 155 ms
      19 ( 166 ms 168 ms 171 ms
      20 ( 209 ms 184 ms 184 ms
    1. JA is the JANET, the UK's main network.
    2. It used to be really annoying, because it made all the addresses backwards, e.g.
    3. lots of clients & servers would get confused translating, even though they should have known better
      1. Mail to would wind up in Antigua!
    4. Moral:  Even when there's a clear protocol, making things too tricky confuses programmers & things break.
  7. What about going to Hong Kong?
    /home/ai/joanna % traceroute
    traceroute to (, 30 hops max, 40 byte packets
    1 net-chex ( 1 ms 1 ms 1 ms
    2 anacreon ( 2 ms 1 ms 1 ms
    3 radole ( 2 ms 111 ms 109 ms
    4 B24-RTR-2-LCS.MIT.EDU ( 114 ms 90 ms 118 ms
    5 EXTERNAL-RTR-2-BACKBONE.MIT.EDU ( 118 ms 103 ms 84 ms
    6 ( 91 ms 104 ms 107 ms
    7 ( 130 ms 112 ms 126 ms
    8 ( 148 ms 162 ms 121 ms
    9 ( 123 ms 134 ms 135 ms
    10 ( 146 ms 149 ms 141 ms
    11 ( 122 ms 150 ms 126 ms
    12 ( 175 ms 137 ms 163 ms
    13 ( 152 ms 153 ms 166 ms
    14 ( 269 ms 276 ms 258 ms
    15 ( 290 ms 320 ms 334 ms
    16 ( 308 ms 318 ms 330 ms
    17 ( 360 ms 347 ms 360 ms
    18 ( 335 ms 364 ms 383 ms
    19 ( 433 ms 457 ms 418 ms
    20 ( 385 ms 391 ms 373 ms
    21 ( 483 ms 402 ms 453 ms
    22 ( 395 ms 382 ms 342 ms
    23 ( 478 ms 556 ms 588 ms
    24 ( 529 ms 588 ms 620 ms
    25 * * *
    26 * * *
    27 * * *
    /home/ai/joanna % 
  8. The path out of MIT is the same, but we spend some time on a big internet backbone crossing the USA before hopping to Japan, then Taiwan, then Hong Kong.  DNS doesn't have names for the last few machines! 
  9. That was from 2004 or so --- in 2010 we go directly to HK from asia netcom
    1. and also, BATH is giving out a lot less dns info!
    2. This traceroute was taken the day moved to Hong Kong, note their traceroute is way more efficient (I wonder how they do that?)
      1. 18 very quick hops...
      2.  1  fire-private (  0.917 ms  0.284 ms  0.318 ms
         2  gw (  0.814 ms  0.620 ms  0.707 ms
         3 (  0.852 ms  0.606 ms  0.485 ms
         4 (  1.473 ms  1.929 ms  1.464 ms
         5 (  2.499 ms  2.211 ms  2.227 ms
         6 (  7.771 ms  7.933 ms  8.680 ms
         7 (  9.543 ms  9.148 ms  9.381 ms
         8 (  9.335 ms  9.245 ms  9.193 ms
         9 (  9.542 ms  9.740 ms  9.607 ms
        10 (  9.962 ms (  9.952 ms (  9.870 ms
        11 (  84.140 ms  84.225 ms  84.322 ms
        12 (  98.936 ms (  105.018 ms (  108.268 ms
        13 (  119.369 ms  121.651 ms (  115.884 ms
        14 (  121.752 ms  115.770 ms (  117.308 ms
        15 (  120.919 ms (  130.899 ms (  118.196 ms
        16 (  122.741 ms  116.697 ms  122.691 ms
  10. Similarly, here's going from Chapel Arts Centre (in Bath) to Stanford.  Note only two hops to get across the USA now, but a bunch to get out of the broadband service (which seems to be run in London)
    1. mo:~ joanna$ traceroute
      traceroute to (, 64 hops max, 52 byte packets
       1  dsldevice (  43.776 ms  99.619 ms  99.885 ms
       2 (  15.632 ms  15.311 ms  16.121 ms
       3 (  17.602 ms  15.671 ms  15.277 ms
       4 (  17.988 ms
 (  16.538 ms
 (  42.563 ms
       5 (  19.874 ms
 (  20.228 ms
 (  23.467 ms
       6 (  19.891 ms
 (  20.071 ms
 (  23.572 ms
       7 (  20.051 ms  28.343 ms  24.892 ms
       8 (  32.591 ms  20.296 ms  20.643 ms
       9 (  89.471 ms  85.546 ms  86.432 ms
      10 (  112.392 ms  111.764 ms  103.148 ms #chicago
      11 (  160.020 ms  163.949 ms  156.372 ms #palo alto
      12 (  155.276 ms  155.860 ms  153.913 ms
      13 (  158.808 ms  160.090 ms  160.832 ms
      14  west-rtr-vlan9.sunet (  157.810 ms  165.541 ms  161.424 ms
      15  * * *
      16 (  170.619 ms  159.798 ms  158.929 ms

VI.  Finding out what your local machine's address is:

  1. Another useful program potentially for your coursework, again from David Barnes (the bit that matters is in blue):
    // Print out Internet address information about the local machine.

    public class PrintInetDetails {
    public static void main(String[] args){
    if(args.length == 0){
    InetAddress myDetails = InetAddress.getLocalHost();
    System.out.println("The local host is called: "+
    " and its address is: "+
    catch(UnknownHostException e){
    System.err.println("Unknown host: "+e.getMessage());
    for(int i = 0; i < args.length; i++){
    InetAddress details = InetAddress.getByName(args[i]);
    System.out.println("The host is called: "+
    " and its address is: "+
    catch(UnknownHostException e){
    System.err.println("Unknown host: "+e.getMessage());

  2. When/if I show it to you running on my laptop, it only says lamely the standard localhost address, but here's what it did on my desktop donkeys' years ago when I first wrote these lecture notes (alas, is no more!):
    [jjb@jjb Networks]$ java PrintInetDetails
    The local host is called: and its address is:
    [jjb@jjb Networks]$ java PrintInetDetails
    The host is called: and its address is:
    The host is called: and its address is:
    [jjb@jjb Networks]$ java PrintInetDetails
    The host is called: and its address is:
    The host is called: and its address is:
  3. Notice that the two MIT AI lab addresses are very similar, as you'd expect.

V. Summary

  1. Don't forget about Buffers!
  2. A lot of examples of clients & servers
  3. A little bit of a feel for how to use unix/linux, and
  4. how telnet can be used to fake one side of a client. Important for your coursework!
  5. About protocols, layers & the Internet
  6. And something about how security is changing...
  7. Of course, there's loads more to this story 
    1. For example, look at the notes I linked to above for pictures of packets.
    2. Or take networking in your final year!

page author: Joanna Bryson
20 March 2014