-I. CW2 (& CW1 in retrospect)
- Mostly about reading other people's code
- major part of contemporary programming
- Do that in lab this week.
- Lab this week will get you on top of networking / do half
the (mini-cw)
- Next week you have to submit this, then the following week
tutors will fix it in lab for you!
- DO NOT MISS LAB, even if you are behind! They are
there to help!
- CW2 & all these labs will help make sure you can
make CW3 really cool (and get a job).
- Going for 55% – The Lake Woebegone Paradox
- Where all the women are strong, all the men are good
looking...
- Nobody in education wants to rank students, but society
dictates it's (a small) part
of our job.
- 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.
- That's why we teach you things like eclipse which
aren't on exams, but make you closer to professional.
- There is not really a single ranking – it's good to find
out what your strengths are & to bring attention to
them.
- 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.
- And first year marks are not included in your final
degree outcome.
I. Networking: It's all just bits!! (zeros
& ones)
- What does it take to make the internet?
- computers,
- phone lines, (or some other means of transmission:
wireless (radio), optical)
- protocols (see a
definition -- there will be a lecture on this in two
weeks).
- (OK, modems help too...)
- hardware devices to translate the phone information
into computer bits & back.
- All information in a computer is just bits.
- 0s & 1s.
- This is true in memory, and also going across a phone
line.
- When you come down to it, there's not much difference
between a disk & a phone line from the perspective of
a CPU.
- You can think of networking as being pretty much like
file I/O.
- If an object is serializable for files, it's
serializable for networking.
- Most basic objects implement serializable.
For
example,
Component
does, so all the widgets in GUIs are serializable (more on
this in two weeks).
- The biggest difference between networking & files is
that even more can go wrong.
- Information gets lost or corrupted.
- Phone lines are noisy.
- So have to have redundant information, ways to check if
something changed, ways to ask for things that have gotten
lost or damaged.
- A protocol is a system for communicating between two
computers.
- Happens at many levels of abstraction.
- Application protocols are often human readable so that
they can be debugged. But lower level protocols are
only for machines.
- Will learn about these Thursday.
- Will talk more about how the internet works in general
Thursday or next week.
- Today we're going to just talk about the most basic case:
two
computers talking to each other.
II. Clients & Servers
- Sometime (in the 80's?) people noticed you didn't have to
have one big expensive computer do everything.
- Computers could be specialized to a task.
- Modularity:
making programs smaller makes the easier to code, debug
& maintain.
- A basic pattern: client / server.
- Server provides a service needed by many people,
programs or computers. E.g.
- file server
- database server
- web server
- Clients use the services.
- Now-a-days at least clients usually run locally on a
computer used exclusively by the user.
- But in the old days, some people used this
architecture even if everyone was on the same computer:
- made the code cleaner, and/or
- provided single point for security, file integrity
etc.
- Think about your coursework dungeon in terms of
this.
- Just to be more confusing, these days services can
also be served in a distributed way
- This is currently called cloud computing.
- You can think of the whole cloud as one server
though, at least from the client's perspective.
- The primary difference
between a client & a server is that the server starts first!
- The server sits on a particular address of the Internet,
and waits for clients to "knock on its door".
- It "listens" for this knocking, and when a client
comes...
- it forms a connection.
- Ordinarily, it gives it a thread & they build a
pipe together.
- Clients have to know the address where servers "live",
both the machine AND the port on that machine where the
server is "listening".
- 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).
- More on this Thursday, AND in lab.
- For coursework 2, you will split up a version of CW1 into
client & server.
- The old CW2 was a chat program.
- In that case, the main difference between the client
& the server will be which is already running (server)
& which goes looking for the server to attach to
(client.)
- Once they are connected, they both behave the same
way.
- But getting connected is the big deal, so you still
needed to think about both sorts of functionality.
- The server listens for a client to contact it, then
connects the two programs.
- 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.
- Networking works almost the same if both programs are on
the same machine as if they are on a different machine.
- The main difference from a programming perspective is
that the address you use for finding the other program is
longer.
- 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.
III. Sockets & Java
- Sockets are the most basic networking thing you need in
Java.
- They exist in any networking-capable language.
- Java hides more of the complexity / makes networking
easier to use than older languages.
- The sort of virtual wire that connects two programs is
called a pipe.
- In unix/linux you can create a pipe between two programs
on the command line using "|" -- so that character is
often called "a pipe".
- unix programs have three sort of `automatic' sockets,
named STDIN, STDOUT, STDERR
- (standard in, standard out, and standard error)
- Normally STDIN gets the keyboard, STDOUT goes to the
terminal, but you can redirect these either into files
or pipes.
- Example: % egrep jjb sent-mail | wc (note to JJB, do real
demo below)
- Assuming % is the prompt.
- 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.
- could also pipe it through "less" & see the lines
on the screen in a program that lets you go forwards
& backwards through the output.
- 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.
- A socket is what's at either end of a pipe.
- You can think of it as the hole in an application that
data goes through.
- A program will have one socket for every connection it
has open at one time.
- Often you might have two pipes going to the same other
program --- one for input & one for output.
- Of course, if pipe1 is input for application1, it is
output for application2!
- Then presumably pipe2 is output for application1 and
input for application2.
- I think this is why people find networking confusing,
but again like memory, it shouldn't be if you just draw
a picture!
- Java sockets will
handle both input & output for you, but split
these into two different streams.
- This should eliminate a lot of bugs concerning
connecting sockets up right...
- In Java, sockets live in java.net, along with a
whole lot of other useful networking things.
- To connect two applications, we need a full address,
- An IP address, or a name to look it up with,
and
- (IP is a protocol, more about that Thursday)
- A port number.
- A port number is an abstraction made up inside
the computer so that multiple applications can be
talking over the network at one time.
- Each socket has its own port number, so you can tell
which socket should get any particular infromation
packet.
- Need to pick a port number that's not being used by
anything else! So choose a big one (e.g. more than
10000).
- Better if you can look -- on unix/linux look at the
file /etc/services.
- 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.")
- 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
- These examples are taken from Learning
Java.
- You might also want to see their complete sample
programs for clients
& servers
(though more are coming in the next lecture!)
- 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.
- 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
- You have a basic introduction to what's going on with
networking.
- You learned about client/server architectures.
- You got an introduction to the code you need to
communicate between programs with Java.
- Hat tip to Sean
Eveson.
page author: Joanna
Bryson
5 March 2013