-I. CW2 (& CW1 in retrospect) & life

1. Mostly about reading other people's code
1. major part of contemporary programming
2. Lab next week will get you on top of networking / do half the (mini-cw)
3. The week after next you have to submit this, then the following week (last week before break) tutors will fix it in lab for you!
1. DO NOT MISS LAB THAT WEEK, even if you are behind! 
   
1. The tutors are there to help!
   
2. And you will get NO MARKS if you don't turn up.
   
2. CW2 & all these labs will help make sure you can make CW3 really cool (and get a job).
4. Going for 55% – The Lake Woebegone Paradox
1. Where all the women are strong, all the men are good looking...
2. Nobody in education wants to rank students, but society dictates it's (a small) part of our job.
1. Most of the reason you are here is to learn, and most of the way Bath does well is by you looking great after you graduate.
2. That's why we teach you things like eclipse which aren't on exams, but make you closer to professional.
   
3. There is not really a single ranking – it's good to find out what your strengths are & to bring attention to them.
4. People who didn't already know how to program have to work harder in first year, but seriously are often better prepared for second year.
1. And first year marks are not included in your final degree outcome.
   

I. 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 -- there will be a lecture on this Thursday).
4. (OK, routers / modems help too...)
1. hardware devices to translate the phoneline 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 the interface serializable.  For example, Component does, so all the widgets in GUIs are serializable (more on this in a few weeks when we do applets & IP).
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 we 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. Application protocols are often human readable so that they can be debugged.  But lower level protocols are only for machines.
3. Will learn about these Thursday.
5. Will talk more about how the internet works in general Thursday.
   
6. Today we're going to just talk about the most basic case: two computers talking to each other.
   

II. 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 design 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.
3. Think about your coursework dungeon in terms of this.
3. Just to be more confusing, these days services can also be served in a distributed way
1. This is currently called cloud computing.
2. You can think of the whole cloud as one server though, at least from the client's perspective.
5. The primary difference between a client & a server is that the server starts first!
1. The server sits on a particular address of the Internet, and waits for clients to "knock on its door".
2. It "listens" for this knocking, and when a client comes...
1. it forms a connection.
2. Ordinarily, it gives it a thread & they build a pipe together.
   
3. Clients have to know the address where servers "live", both the machine AND the port on that machine where the server is "listening".
1. Client networking code is usually a little simpler though, since it generally only needs to connect once in its lifetime, while servers may take many clients concurrently (why we taught threads first).
   
4. More on this Thursday, AND in lab.
   
6. For coursework 2, you will split up a version of CW1 into client & server.
1. The old CW2/3 was a chat program.
   
1. In that case, the main difference between the client & the server was just which was 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. But getting connected is the big deal, so you still needed to think about both sorts of functionality.
2. For you, the server will have the game logic & the map of the dungeon.
3. We broke out CW2 to help make sure everyone gets their networking working, it's not meant to take you too much time.
   
2. The 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 clients playing your game in the same dungeon at the same time, you'll probably want the server to do the coordinating.
7. 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 the importance of incremental design, you should be sure to make networking work on the same machine before you try to get it working across different machines.
3. But do make sure you can make it work from different machines before submission!
   

III. 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 wire 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. unix programs have three sort of `automatic' sockets, named STDIN, STDOUT, STDERR
1. (standard in, standard out, and standard error)
   
2. Normally STDIN gets the keyboard, STDOUT goes to the terminal, but you can redirect these either into files or pipes.
   
3. Example:   % egrep jjb sent-mail | wc (note to JJB, do real demo below)
   
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. Demo:  do ls */*tex from tex directory, > to some file, wc that file, then show pipe.  man wc to show the different ways you can call it.
   
4. A socket is what's at either end of a pipe.  [draw simple & java sockets]
   
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.
3. I think this is why people find networking confusing, but again like memory, it shouldn't be if you just draw a picture!
   
4. Java sockets will handle both input & output for you, but split these into two different streams.
1. This should eliminate a lot of bugs concerning connecting sockets up right...
   
5. In Java, sockets live in java.net, along with a whole lot of other useful networking things. 
   
6. To connect two applications, we need a full address,
   
1. An IP address, or a name to look it up with, and
1. (IP is a protocol, more about that Thursday)
   
2. A port number.  [show the services file]
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 information 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... (Daniel Ijatomi emailed me "The command to get a list of used ports on a Windows pc is netstat-an. I think.")
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!
   

IV. 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 in the next lecture!)
   
2. Notice that most of the code below is showing several 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!

// 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 ("wupost.wustl.edu", 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("foo.bar.com", 1234);
    InputStream in = server.getInputStream();
    OutputStream out = server.getOutputStream();

    // write a byte
    out.write(42);
    
    // write a newline or carriage return delimited string
    PrintWriter pout = new PrintWriter (out, true);
    pout.println("Hello!");

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

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

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

// assume this is running on the machine foo.bar.com

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();
	OutputStream out = client.getOutputStream();
	
	// read a byte
	byte = someByte = (byte)in.read();

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

	// write a byte
	out.write(43);

	// say goodbye
	PrintWriter pout = new PrintWriter (out, true);
	p.out.println("Goodbye!");

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

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

V. Summary

1. You have a basic introduction to what's going on with networking.
2. You learned about client/server architectures.
3. You got an introduction to the code you need to communicate between programs with Java.
4. Hat tip to Sean Eveson.

---

page author: Joanna Bryson
5 March 2015