|
|
|
|
|
Project 1: Project Source Setup
Out: Monday March 26
Due: Wednesday April 4 (midnight)
Turnin: Online
Teams: Pairs
1. Overview of The Code
The Server
The server is implemented by file Server.java, which is part of Eclipse project
timingframing. You don't have to modify it in any way.
When started, the server creates N sockets and then waits for client connections to arrive on them.
(In the baseline, N=9.) The sockets are numbered 46101, 46102, ..., 46109. Each socket has a
pre-determined server sending rate associated with it. For instance, if a client connects to socket
46101, a single character is sent to it every 1 msec.; if it connects to 46102, every 2 msec.; etc.
(The set of rates used is in file Properties.java.) So, in Project 1 you vary
the server's send rate by choosing which of its sockets to connect the client to.
You may see references to "negotiation" in the the source and its javadoc, and notice that the
server actually also listens on port 46100. The server implements a facility where the client
can tell it at what rate to send characters, rather than the rate being determined by the port
number. This is a harbinger of Project 2, and can be ignored in Project 1.
The Client
File Client.java, also in project timingframing, implements the client
that communicates with the server. The client connects to a server port and then reads characters
in two ways. The first is that it simply reads data from the TCP connection with the server,
meaning it sees a new character when, and only when, a new character arrives on that connection.
When it receives a character, it places it in a one character buffer. The second way it reads characters
is asynchronously. When the first character arrives from the server, the client sets up a timer
that fires every K milliseconds. When it fires, a handler is run that simply reads whatever character
is in the buffer written by the sychronous reads.
The client does not have a UI. Instead, every time a character is read, either sychronously
or asynchronously, it fires an event. Two distinct implementations exist that listen for these events,
one providing console (text) output, and the other implementing an Adroid UI.
The Console Client
The console client is in file ConsoleClient.java,
again in project timingframing.
It doesn't actually do very much. The most important part is its main(), which
implements code to facilitate performing the experiments needed by your analysis: it accepts
arguments that determine which server port to connect to, runs repeated trials (each trial ends
when an error in the asynchronous stream is detected), and prints information about how many characters
were received correctly.
The Android Client
The Android client is also a listener to Client events. It's UI has two parts, and input part
that lets the user specific parameters like which server port to connect to, and an output part.
This client connects only once. As it reads characters from the server, it displays them in two
scrolling text boxes, one for synchronously and one for asynchronously received data.
You should run this client at least once after completing the two lines of code in the Client.
It is not handy for doing repeated experiments, though, and so won't be very useful for completing
the analysis.
2. Making the Code Work
You need to change two lines of code in method connect() in file Client.java
to get the application working. They're marked by a large comment that mentions Project 1. (Ignore for
now all comments mentioning Project 2.)
In particular, they're these lines:
mClientSocket = null;
InputStream is = null;
Follow the instructions in the big comment to fix them.
Eclipse compiles as you edit, and will mark lines that have compile time errors. You must fix them
before trying to run.
3. Running the Code
The Server
You have at least two choices.
First, we are running a server, 24/7, on machine cse461.cs.washington.edu.
The clients try to connect to that server by default.
This is handy because you should never have to launch a server.
The second choice is to run your own server. There are many legitimate reasons to
want to do this, including debugging (and the possibility that our server has crashed).
The server is started by invoking the main
of class edu.uw.cs.cse461.sp12.timingframing.Server. It takes no arguments.
The distribution includes a script to help launch the server (and console client) on Linux:
run.sh in subdirectory lib/. To start the server, say:
$ ./run.sh server
Alternatively, you can just start the server however you want. Note, though, that it requires
a set of jar files (also located in lib/). Look inside run.sh
to see just what it requires.
For experiments for the analysis, you must use a server running on a different machine than
the client. Even for debugging you're urged to do that: if they run on the same machine, they
can go a long time before an error occurs, making any kind of experimenting tedious.
The Console Client
You now have three reasonable choices. The first two are analagous to those for the server, use the
script ($ run.sh client [args]) or launch by hand (main of class edu.uw.cs.cse461.12sp.timingframing.ConsoleClient).
The third choice is to use Eclipse, which has the
benefit that it provides a built-in debugger.
If you use the run.sh script to launch the client,
you must rebuild the jar file that contains it each time you modify the code. Do that by
right-clicking on timingframing.jardesc, below project timingframing
in Eclipse, and then Create JAR.
You do not need to rebuild the jar if you're running in the Eclipse debugger.
The console client accepts many command line arguments:
$ ./run.sh client -h
New listener:
usage: edu.uw.cs.cse461.sp12.timingframing.ConsoleClient
-h,--help Print this message
-i,--intersymboltime Time between successive symbols in msec.
(Default: 1)
-p,--serverport Server port number (Default: 46101)
-s,--serverhost Host name or IP address of server (Default:
cse461.cs.washington.edu)
-t,--trials Number of trials to run (Default: 40)
The -i argument is ignored when using the ports enabled in this assignment,
46101-46109.
Note: Remember that the client code will not run sensibly as is. You'll see a stream of exception tracebacks
until you "make the code work."
The Android Client
Make sure you have gone through the Android launch procedures on the setup page,
as there are some first-time issues that can arise, and a first-time-in-a-session issue that can persist.
In Eclipse, right-click on project timingFramingAndroid, then Debug As, then Android Application.
If you haven't connected a phone by USB and have no Android emulator running, Eclipse will launch an emulator.
If an emulator is running (but no phone is attached) it will be used. You can close the emulator after each run,
but you save emulator startup time by just leaving it running. If a phone is attached, it will be used.
Note: You can run the Android client before you modify the Client code to make it work.
The Start button will cause it to crash, though.
Once the Client code works, the Android client should work fully. (Connect to the slowest port, 46109, to
be sure you see what it does.)
|
CSE Home
