CM10135 / Programming II:   Lecture 15

Networking Basics

I. Coursework 2 & Iterative Development.

  1. People have been getting overly worried about CW2.  I want to address some falicies:
    1. Q: CW2 involves knowing and doing too many different things!
      1. A:  CW2 only suggests doing a lot of things.  You only need to do 3 or 4 of them to get an excellent mark.
    2. Q: you need to already know Java to do well on CW2.
      1. A: No, you can learn enough to do well if you've been keeping up with lectures & you have been putting the time you are supposed to (about 7 hours a week) into the course work.
      2. A: The reason there are so many different things you can do is that you can pick which parts of the most recent content are most interesting to you & try to get extra marks with them.  Though some things are mandatory.
    3. Q:  But it does help if you already know how to do Java.
      1. A:  Yes, and it helps your mark in Spanish if you're already fluent in Spanish / go to Spain every summer.
        1. That's the way it ought to be --- the whole point of assessing coursework is to see if you know how to program, not to find out where you learned!
        2. Though that is one reason why MIT used to teach people Scheme instead of a  more popular language.
    4. Q:  Now you've dumbed down CW2 too much, it's too easy!  (be sure to look at the assignment again!)
      1. A:  It was always meant to be pretty easy, though I did make it easier to get 40% (threads are now optional.)
      2. A: The point isn't just to get marks.
        1. The main point is to learn.  That's why you're here.
        2. If you build something cooler than you can get marks for, you can always put it on your web page & show it off to potential employers, your parents, or (geeky) dates.
        3. Don't forget you may never get credited with marks for any of this anyway.   See my teaching page for updates on the industrial action.
  2. The most important thing for tackling a big problem like CW2 is to develop the code iteratively.
    1. Think about what you need to do & what you want to do.
    2. Figure out a piece you can do first, that you can test without having gotten everything else working.
    3. Build that piece.
    4. Test that piece & fix it until it works.
    5. Now go back to step I.2.1!
      1. You'll have learned things about the problem and the solution, so you want to think about the problem again before you choose the next piece to do.
  3. Don't forget this is a double unit.
    1. Counts for twice as much as your other units.
    2. Should get twice as much of your time.
  4. Programming is an art.  Practicing is the only way to get better.

II. Networking:  It's all just bits!!  (zeros & ones)

  1. What does it take to make the internet?
    1. computers,
    2. phone lines, (or some other means of transmission:  wireless (radio), optical)
    3. protocols (see a definition).
    4. (OK, modems help too...)
      1. hardware devices to translate the phone information into computer bits & back.
  2. All information in a computer is just bits.
    1. 0s & 1s.
    2. This is true in memory, and also going across a phone line.
    3. When you come down to it, there's not much difference between a disk & a phone line from the perspective of a CPU.
    4. You can think of networking as being pretty much like file I/O.
    5. If an object is serializable for files, it's serializable for networking.
    6. Most basic objects implement serializable.  For example, Component does, so all the widgets in GUIs are serializable.
      java inheritance network
  3. The biggest difference between networking & files is that even more can go wrong.
    1. Information gets lost or corrupted.
    2. Phone lines are noisy.
    3. So have to have redundant information, ways to check if something changed, ways to ask for things that have gotten lost or damaged.
  4. A protocol is a system for communicating between two computers.
    1. Happens at many levels of abstraction.
    2. For example, you can sometimes see parts of the sendmail protocol in messages that have bounced.
    3. Here's an example of sendmail protocol from a lecture on internet applications from Dave Hollinger:
    4. 220 ESMTP Sendmail 8.8.8/8.8.8; Sat, 14 Mar 1998 21:28:41 -0500 (EST)
      250 Hello [], pleased to meet you
      MAIL FROM:
      250 Sender ok
      RCPT TO:
      250 Recipient ok (will queue)
      354 Enter mail, end with "." on a line by itself
      Hi Dave - this message is a test of SMTP
      My name is really Joe Smith and I think you are going to get
      fired to teaching us how to forge email! Do you have any idea who
      will be your replacement?

      250 VAA07541 Message accepted for delivery
  5. Application protocols are often human readable so that they can be debugged.  But lower level protocols are only for machines.
    1. Hardware protocols for communicating e.g. from the modem to the computer.
    2. Networking protocols for communicating any data over a line.
  6. Will talk more about how the internet works on Thursday.
  7. Today we're going to just talk about the most basic case: two computers talking to each other.

III. Clients & Servers.

  1. Sometime (in the 80's?) people noticed you didn't have to have one big expensive computer do everything.
  2. Computers could be specialized to a task.
  3. Modularity: making programs smaller makes the easier to code, debug & maintain.
  4. A basic pattern:  client / server.
    1. Server provides a service needed by many people, programs or computers.  E.g.
      1. file server
      2. database server
      3. web server
    2. Clients use the services.
      1. Now-a-days at least clients usually run locally on a computer used exclusively by the user.
      2. But in the old days, some people used this architecture even if everyone was on the same computer:
        1. made the code cleaner, and/or
        2. provided single point for security, file integrity etc.
  5. For coursework 2, the only difference between the client & the server is which is already running (server) & which goes looking for the server to attach to (client.)
    1. Once they are connected, they both behave the same way.
    2. Server listens for a client to contact it, then connects the two programs.
    3. Servers often provide multiple connections:  if you are going to try to have multiple chat lines, you'll probably want the server to do the coordinating.
  6. Networking works almost the same if both programs are on the same machine as if they are on a different machine.
    1. The main difference from a programming perspective is that the address you use for finding the other program is longer.
    2. Given what I said about incremental design, you should probably try to make networking work on the same machine before you try to get it working across different machines.

IV. Sockets & Java

  1. Sockets are the most basic networking thing you need in Java.
  2. They exist in any networking-capable language.
    1. Java hides more of the complexity / makes networking easier to use than older languages.
  3. The sort of virtual line that connects two programs is called a pipe.
    1. In unix/linux you can create a pipe between two programs on the command line using "|" -- so that character is often called a pipe.
    2. Example:   % egrep jjb sent-mail | wc
      1. Assuming % is the prompt.
      2. This finds all the lines in your file sent-mail that have the word "jjb" in them, then pipes the output into a program that will count the lines (& words & letters) so you can see how many times you've emailed me.
      3. could also pipe it through "less" & see the lines on the screen in a program that lets you go forwards & backwards through the output.
  4. A socket is what's at either end of a pipe.
    1. You can think of it as the hole in an application that data goes through.
    2. A program will have one socket for every connection it has open at one time.
    3. Often you might have two pipes going to the same other program --- one for input & one for output.
      1. Of course, if pipe1 is input for application1, it is output for application2!
      2. Then presumably pipe2 is output for application1 and input for application2.
    4. Java sockets will handle both input & output for you, but split these into two different streams.
      1. This is probably because people used to always get really confused connecting their sockets up right...
  5. In Java, sockets live in, along with a whole lot of other useful networking things. 
  6. 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. packets are little chunks the data gets broken into so no big / slow chunk risks getting lost
      2. packets include some other useful information such as the address they're going to.
      3. having the address in every packet is redundant, so the size of packets has to be traded off with other networking considerations.
  7. To connect two applications, we need a full address,
    1. An IP address, or a name to look it up with, and
    2. A port number
      1. A port number is an abstraction made up  inside the computer so that multiple applications can be talking over the network at one time.
      2. Each socket has its own port number, so you can tell which socket should get any particular packet.
      3. Need to pick a port number that's not being used by anything else!  So choose a big one (e.g. more than 10000).
        1. Better if you can look -- on unix/linux look at the file /etc/services.
        2. If anyone knows where to look on Microsoft, let me know...
        3. What you really want to do also is to write down that you're using a port, but you guys won't have permission to do this... but you should if you are building a real service for a company!

V. Code

  1. These examples are taken from Learning Java
    1. You might also want to see their complete sample programs for clients & servers (though more are coming Thursday!)
  2. Notice that most of the code below is showing various ways to read & write to the socket, only one of which you'll need for coursework 2.
  3. Notice also though that you have to be careful to always read & write in the right order!
  4. It may still be easiest to use more than one socket...
// these examples are taken from Learning Java, pp. 335--337

// to open a client socket, we need to name the machine & the port the
// socket will be on. We also have to catch a couple exceptions...

try {
Socket sock = new Socket ("", 25);
} catch (UnknownHostException e) {
System.out.println("Can't find host.");
} catch ( IOException e) {
System.out.println("Error connecting to host.");

// Here's a client that reads & writes!

try {
Socket server = new Socket("", 1234);
InputStream in = server.getInputStream();
Output Stream out = server.getOutputStream();

// write a byte

// write a newline or carriage return delimited string
PrintWriter pout = new PrintWriter (out, true);

//read a byte
byte back = (byte);

// read a newline or carriage return delimited string
BufferedReader bin =
new Buffered Reader (new Input StreamReader(in));
String response = bin.readLine();

// send a serialized java object
ObjectOutputStream oout = new ObjectOutputStream (out);
oout.writeObject(new java.util.Date());
} catch (IOException e) {...} // every one of these operations could have died!

// server code (for the same conversation! Notice these have to be in
// order...)

// assume this is running on the machine

try {
// note: ServerSocket is a subclass of Socket that knows how to listen...
ServerSocket listener = new ServerSocket (1234);

while (!finished) {
Socket client = listener.accept (); // this waits for a connection

InputStream in = client.getInputStream();
OutputStrewam out = client.getOutputStream();

// read a byte
byte = someByte = (byte);

// read a newline or carriage-return-delimited string
BufferedReader bin =
new BufferedReader(new InputStreamReader(in));
String someString = bin.readLine();

// write a byte

// say goodbye
PrintWriter pout = new PrintWriter (out, true);

// read that serialized Java object
ObjectInputStream oin = new ObjectInputStream(in);
Date date = (Date)oin.readObject();



} catch (IOException e) {...}
catch (ClassNotFoundException e2) {...}

V. Summary

  1. When I started programming, we didn't have any of these sissy 'icons'
    and 'Windows.'All we had were zeros and ones -- and sometimes we didn't
    even have ones. I wrote an entire database program using only zeros. You
    had zeros? We had to use the letter "O".
    -Dilbert (Scott Adams)
  2. You have a basic introduction to what's going on with networking.
  3. You learned about client/server architectures.
  4. You learned about the code you need to communicate between programs with Java.

page author: Joanna Bryson
17 March 2004