2000 DIS Project
Distributed Information Systems Course Project
Distributed Computing: Decrypt secret key by distributed clients
D89725004 潘育群 R89725052 劉宗原 D89725003 林潮文
2001/01/11
Page 1/17
2000 DIS Project
Contents
Distributed Information Systems Course Project ............................................................................................... 1
Contents ............................................................................................................................................................. 2
1. Introduction ............................................................................................................................................... 3
1.1.
Overview .................................................................................................................................. 3
1.2.
Gossip Architecture .................................................................................................................. 4
1.3.
Scenario .................................................................................................................................... 4
2. Component Details .................................................................................................................................... 6
2.1.
Server........................................................................................................................................ 6
2.1.1.
Overview .......................................................................................................................... 6
2.1.2.
Server Behavior ................................................................................................................ 6
2.1.3.
Java Class ......................................................................................................................... 6
2.2.
Problem Status .......................................................................................................................... 7
2.3.
Client ........................................................................................................................................ 8
2.3.1.
Overview .......................................................................................................................... 8
2.3.2.
Overall Client States ......................................................................................................... 9
2.3.3.
Problem Solving States................................................................................................... 11
2.3.4.
Problem Solving Thread ................................................................................................. 11
2.3.5.
Server Communication Thread ....................................................................................... 12
2.3.6.
Statistics Reporting Thread ............................................................................................ 12
3.
Project Demonstration ............................................................................................................................. 13
3.1.
Normal Case ........................................................................................................................... 13
3.2.
Stop-Failure Case.................................................................................................................... 13
3.3.
Link Broken Case ................................................................................................................... 13
4. Discussion ............................................................................................................................................... 14
4.1.
Scalability ............................................................................................................................... 14
4.2.
System Integration and Collaboration ..................................................................................... 14
4.3.
Merits ...................................................................................................................................... 14
5. Conclusion ............................................................................................................................................... 15
Appendix A – Operation manual ..................................................................................................................... 16
Appendix B – Java security policy file ............................................................................................................ 16
Appendix C – Server Configuration File ......................................................................................................... 17
Appendix D – Source Code & Documentation ................................................................................................ 17
Page 2/17
2000 DIS Project
1. Introduction
1.1. Overview
There are numerous problems that need large amounts of computing power. In past years, we assign this kind
of work to super computers. Nowadays, advances in network and personal computer technology have made
major progress that enabled the distributed system development that saves computing time and investment
cost.
As we know, there are many algorithms using divide and conquer, like dynamic programming to deal with
complex problems and approximation computing to NP problem. These problems can take advantage of
distributing computing system.
This project aims to demonstrate the power and availability of distributed computing using the Java RMI and
Java applet technology. In particular, we have selected the discovery of RC5 encryption keys as a test case
for our distributed problem-solving framework.
We have utilized many algorithms and techniques learnt in the distributed information systems project for this
project, and this project conforms to all the project requirements set out by the professor. A brief summary of
the project follows:
Topic: Decrypt secret key by distribute clients
Middleware : Java RMI
Features :
A: Multithread programming.
Client: The first thread handles computing, the second thread is responsible for getting new range and
periodically report to the server asynchronously. The third thread reports solving status to the screen.
B: Middleware used: Java RMI.
C: Component assignment:
1. Client ---------------------------------- by R89725052 劉宗原
2. Server --------------------------------- by D89725004 潘育群
3. Problem Status ------------------------ by D89725003 林潮文
D: Interface definition between components.
Client-Server: ds.ProblemDispatcher
Server-Server: ds.server.StateSynchronizer
For details please see Appendix D.
Page 3/17
2000 DIS Project
1.2. Gossip Architecture
In our problem-solving framework, there are one or many servers, and zero or many clients. The server
maintains a list of problems to be solved and the client will initiate its intention of assisting in solving a
problem.
In the steady state, all servers and clients work collaboratively in solving the same problem. Thus our
framework is limited in solving problems that could be solved in a divide-and-conquer approach. During the
problem solving state, each client will be instructed to solve a particular portion of the problem and will
report periodically to the server of its solving status. The client will request another portion of the problem
when it has solved its current portion, until any one of the clients have fully solved the problem.
Our problem-solving framework employs the gossip-architecture, such that all servers can handle client
connections and that the servers will gossip amongst themselves to maintain synchronized states.
.......
server1
server2
server3
Internet
.......
client1
Client2
Clinet n
Client3
圖表 1
1.3. Scenario
For our demonstration, we have set up two servers with the following configuration:
Server 1:
IP 140.112.3.58; OS: Windows 2000; JVM: Sun JDK1.3 Web Server: Jakarta Tomcat 3.2 listening on
port 8080; rmiregistry listening at port 1099
Server 2:
IP 140.112.3.114; OS: Red hat Linux 6.2; JVM: Sun JDK1.3 Web Server: Apache 1.3.9 listening on port
80; rmiregistry listening at port 1099;
Page 4/17
2000 DIS Project
We have enabled telnet on server 2 to demonstrate dynamic starting-up and shutting down of a server.
We have also written a homepage on server 2 which have links to our detailed documentation and for
downloading JRE 1.3 for Win32
圖表 2
Referring to the figure above, we outline the problem-solving scenario in the following eight steps:
1. Client reaches a server’s problem-serving page and downloads and runs the problem-solving applet.
2. The applet connects to the server, showing its intention of assistance in the problem-solving activity.
3. The server returns the appropriate problem-solving class (ProblemSolver) back to the client.
4. The client executes the problem-solver that will request a portion of the problem to be solved from the
server when appropriate.
5. The server will hand-down portions of the problem as appropriate and also the newest problem-solving
status when applicable.
6. The client will periodically report to the server of its solving status, in case that the communication link
could be broken, or that the client could have crashed.
7. Eventually a client will solve the problem and report that event to the server.
8. The servers will synchronize its states amongst themselves, in particular when a client signals the finding
of the solution. In that case, the procedure repeats (back to step 2) until all desired problems have been
solved.
Page 5/17
2000 DIS Project
2. Component Details
2.1. Server
2.1.1. Overview
The server is main program in the distributed system, provide the interface with the problem status
component and client component.
圖表 3
The interface with client is ProblemDispatcher which provide getProblemSolver(), getRange, periodResult,
and solved() method to client. Depend on clients report status to next step.
The interface with Problem Status is StateSynchronizer, which provide getTotalStates(),
updateTotalStates(),problemSolved().
2.1.2. Server Behavior
The server should read configuration file, for getting the problem which want to solve, and then init the RMI
registry, rebind the other servers to synchronize status if they exist.
After initial the server environment, server passively wait for client connection, if the problem status changed
or solved, Problem Status module will call back to server, then read the next problem to solved.
This will cause a loop till all problem solved.
2.1.3. Java Class
see java.doc on http://140.112.3.114
Page 6/17
2000 DIS Project
2.2. Problem Status
The problem status will keep the status of current problem and the data structures are showed in the figure
below:
RootStates : shared by servers, will be synced between servers
。。。
Server States : acquire from root
keep it in local, will be logged
Server States : acquire from root
keep it in local, will be logged
。。。
Client
Client
。。。
。。。
Client
Client
Client
。。。
Client
圖表 4 - Problem States
Referring to 圖 4, we can roughly describe the data structure of status in the following :
1. Use hierarchy structure to maintain status, in order to keep scalability, and the level of hierarchy can be
expanded if necessary.
2. RootStates : Record the status of each slot which will be dispatched to any server, and will be recorded
as either EMPTY, BOOKED or FINISHED, and it’s shared by all servers, therefore need to be
synchronized between servers.
3. Server States maintains the secondary level array, responsible for dispatching the slot to the client, update
the status when clients send periodical report back and it will log this array to disk in case crashed and
can be recovered.
4. Server does not keep the status of clients, and all the operations are idempotent.
Page 7/17
2000 DIS Project
2.3. Client
2.3.1. Overview
The client runs in three threads, not including the main user-interface (UI) thread, as showing in the figure
below.
UI
S
C
R
Current problem solving states
Overall client states
圖表 5
Thread S performs the actual problem-solving activity. It iterates through the portion of the problem space
dispatched by the server and updates the current problem solving states.
Thread C performs synchronous communication with the server and updates the current problem solving
states accordingly.
Thread R is responsible for reporting problem-solving statistics on the screen in fixed intervals.
All three threads and the UI thread will read the overall client state and may update the overall state if
applicable.
Page 8/17
2000 DIS Project
2.3.2. Overall Client States
The overall client states is maintained by the class ds.client.ProblemSolverManagerState and acts as the vital
shared memory object that co-ordinates the proper action of the different threads.
The main controlling mechanism is the eight states contained in the class and the possible state transitions are
shown in the figure below:
START
Getting
ProblemSolver
SOLVING
Fetched
ProblemSolver
Solved
Interrupting
INTERRUPTED
Finished
The meanings of the states are:
State
Description
Getting ProblemSolver In this initial state, a connection is made to
the server requesting for a new problem to
be solved. The server will return an
appropriate ProblemSolver class.
Fetched ProblemSolver
SOLVING
Notes
The client current forks only one
thread (out of the main UI thread) to
perform this task.
The user may interrupt the client at
this stage, forcing the state to go into
INTERRUPTED.
In this state, the server has returned the
Since the problem-solving activity has
appropriate ProblemSolver class, but the
not commenced, user interruption can
problem-solving activity has not started yet. force the state into INTERRUPTED
immediately.
This is the main state and the client will
In this state, the three threads will run
spend most of its time in this state. Actual concurrently, working in collaboration
problem-solving activity and periodic
to solve the current problem.
reports to the server will only happen in this Since it is expected that there will be
state. All working threads will end their
pending results not sent to the server,
activity as soon as possible if the state is no user interruption will change the state
longer in the SOLVING state.
into Interrupting to signal the
communication thread to send the last
results back to the server.
Page 9/17
2000 DIS Project
Solved
This stage is entered when the full solution User interruption is delayed in this
to the problem has been discovered. The
state until the communication thread
problem solving and the reporting thread
has successfully notify the server of
will terminate while the communication
the solved event.
thread will notify the server of this event.
Finished
This state signifies that both client and
server acknowledge that the solution to the
problem have been found, so in essence
meaning that the problem-solving activity
has finished.
The client will then start over again to solve
the next problem after a short delay
(allowing the server to ready itself for the
next problem).
Interrupting
In this state, the communication thread will
send pending solving states back to the
server before entering the INTERRUPTED
state.
INTERRUPTED
This state is entered into upon user
interruption. All threads are stopped and the
user has to restart the client to reinitiate the
problem-solving activity.
The ds.client.ProblemSolverManager class controls the overall client activity.
Page 10/17
2000 DIS Project
2.3.3. Problem Solving States
Most of the problem-solving states are kept in the ProblemSolver class and the class is synchronized for safe
concurrent access. The main states kept are the following:
Data
Description
Notes
queuePending
This data structure stores the ranges that the Implemented as a linked-list.
client still has to work through.
It is populated by the communication thread
and consumed by the problem-solving thread.
queueDone
This data structure stores ranges the have been Implemented as java.util.Vector to
tested by the client but not yet reported to the allow dynamic adding and
server.
removing of individual elements.
It is populated by the problem-solving thread
and consumed by the communication thread.
totalPending
This variable stores the number of solutions
that the client still has to work through. It is
equal to the sum of elements in queueDone
plus the remainder of the current range the
client is busy with.
totalSolved
This stores the total number of solutions that
the client has tested so far. It also assists in
calculating the approximate solving rate of the
client.
solutionsPerSecond
This variable stores an estimation of the
This variable in conjunction with
problem-solving rate of the client and is
totalPending allows pre-fetching of
updated periodically by the reporting thread. ranges from the server to maintain a
certain solution range buffer size. In
this way the client should nearly
always have some ranges to test
despite occasional communication
failures.
2.3.4. Problem Solving Thread
This is the main working thread and is expected to occupy most of the CPU time. The thread is entirely
CPU-bound.
This thread sits in a non-ending loop whilst the client state is in the SOLVING state. In the loop the thread:
 Gets a range to test from the queuePending queue.
 Iterate through the range and test each solution.
 Whilst iterating, update the problem-solving states periodically.
 Upon finding the solution, notifies other threads and change overall client state.
 After finishing testing the range, add that range to the queueDone queue.
Page 11/17
2000 DIS Project
2.3.5. Server Communication Thread
This thread performs the communication (with the server) activity and runs separately from the other thread
because it is expected that network latency times are large, and that failures (both server and link) can occur.
The activity is implemented in the ds.client. ClientSolutionRangeMessenger class and in the running state it
sits in a non-ending loop whilst the client state is in the SOLVING state. In the loop the thread will:
 Get new ranges from the server when necessary.
 Periodic report the client solving states to the server.
 Sleep for a while (currently set to 1 minute) to reduce loading on server.
When the client state is changed to Solved, this thread will attempt to send the solved solution to the server.
If the client state is Interrupting, it will send the last results to the server.
2.3.6. Statistics Reporting Thread
This thread runs in fixed intervals (currently one second) and reports the problem-solving statistics to the
user.
It maintains a timer and reads the solving statistics to estimate the problem-solving rate. This thread also has
the responsibility to check whether there is sufficient range buffer, and if not signals the server
communication thread to fetch more ranges from the server.
Page 12/17
2000 DIS Project
3. Project Demonstration
3.1. Normal Case
A: Different client will get different range :
Proof :
Client A : get rangeA
Client B: get rangeB
RangeA <> rangeB
B: Report Periodically
Proof :
Either from server consol, or client consol will show
C: When solved , client will notify server, in turns that server will notify other servers:, other clients will
discover this fact when reporting
Proof :
When client A’s console show “solved”, the server’s will show “solved” right after .
When client B reporting,, it will show “Solved by other client” on his screen
D: Can solve multi-problems
Proof :
1. Server A starts and solved the first problem continuously solving problem 2,
Start Server B which will jump to solve problem 2
2. Start client B, it will solve problem 2 ,
3.2. Stop-Failure Case
Server crash : restart  jump to new program optional read log file back
Client crash : restart  jump to new problem, or get new range
3.3. Link Broken Case
Client – Server link broken :  client will retry, server stateless no matter.
Server-server link broken  after the next connection , will synchronize
Page 13/17
2000 DIS Project
4. Discussion
4.1. Scalability
1. Client connection is stateless and infrequently report to the server, allowing server to handle hundreds
of clients.
2. Server is stateless of client, use timeout to detect stale states
3. Client can connect to any server, and server and server will gossip
4. Connection between servers is also seldom allowing server scalability.
4.2. System Integration and Collaboration
1. Between components have clear interfaces
2. All interfaces method’s parameters and return values are all clear defined.
4.3. Merits
1. Pure 100% java code provide portability.
2. Framework is well designed: allowing system to solve any problems.
3. Client is applet, it can fully utilize the client’s idle computing power in the background even while
client surfs another web page.
4. Client will pre-fetch the problem range to avoid the idle time while the link is broken.
5. Client has a special feature which will represents approximate 60 clients.
Page 14/17
2000 DIS Project
5. Conclusion
We have successfully implemented our proof of concept using the techniques leant in the distributed
information systems course. In this project, we have learnt:
 How to use Java RMI to write concise, object-oriented and maintainable client-server programs with
little effort.
 The importance and difficulties of distributed systems techniques in solving complex problems, such
as concurrency control, replication, fault-tolerance, communication.
 That clear interface definition is essential and beneficial in systems integration and group
collaboration work.
 The use of transparency to enable scalability, performance and fault-tolerance, for example by
hiding the server farm implementation from the client.
Although we were very successful in our implementation, fulfilling all requirements set out by our initial
proposal, we still felt that some improvements could have been made:
 Making the server’s range dispatching more flexible so that no client will be idle at any time.
 Enhancing the gossip architecture, perhaps using a tree (hierarchy) structure for maximum server
scalability.
Page 15/17
2000 DIS Project
Appendix A – Operation manual
Server1 side: (Win2000, Tomcat WebServer on port 8080 with JDK1.3)
1. Start rmiregistry :
start \jbuilder4\jdk1.3\bin\rmiregistry --------- C:\JBuilder4\DS\classes\a.bat
2. Start server: (argument 0: server id,
argument 1:configuration directory (see appendix C))
c:\jbuilder4\jdk1.3\bin\java -Djava.rmi.server.codebase=http://140.112.3.58:8080
/ds/classes/ -Djava.security.policy=C:\JBuilder4\jdk1.3\docs\guide\rmi\code\poli
cy ds.server.Server 0 D:\ --------------------- C:\JBuilder4\DS\classes\b.bat
Server2 side: (RedHat Linux, Apache WebServer with JDK1.3)
1. Start rmiregistry :
rmiregistry &
2. Start server: (argument 0: server id ,
argument 1:configuration directory (see below))
java -Djava.rmi.server.codebase=http://140.112.3.114
/ds/classes/ -Djava.security.policy=/home/peter/DS/classes/policy ds.server.Server 1
/home/peter/DS/classes
Client :
Use IE/Netscape got URL http://140.112.3.58:8080/ or http://140.112.3.114/
Run client from appletviewer --appletviewer http://140.112.3.58:8080/ds/classes/Client.html or
http://140.112.3.114/ds/classes/Client.html
Appendix B – Java security policy file
grant {
// Allow everything for now
permission java.security.AllPermission;
};
Page 16/17
2000 DIS Project
Appendix C – Server Configuration File
Servers=2
// Number of servers used
ServerName.1=140.112.3.58/pmsServer
// The server1 IP pmsServer : server name
ServerName.2=140.112.3.58/pmsServer2
// The server2 IP pmsServer : server name
#ServerName.2=140.112.3.114/pmsServer
// The server12 IP pmsServer : server
name
problemID.1=ds.rc5.RC5ProblemServer
bits.1=24
// The bits to solve
plaintext1.1=-4314597143509096999
// PlainText 1
ciphertext1.1=0x77a6b0cef347a3fb
plaintext2.1=0
// CipherText 1
// PlainText 2
ciphertext2.1=0x26f62060c8dc1cb8
key.1=3232889
// The first rc5 problem server
// CipherText 2
// The key
problemID.2=ds.rc5.RC5ProblemServer
// The second problem
bits.2=32
plaintext1.2=-6164277023983481459
ciphertext1.2=453101746671464696
plaintext2.2=0
ciphertext2.2=6511876537885064492
key.2=536936709
Appendix D – Source Code & Documentation
See http://140.112.3.114/ for all source code, scripts, configuration files and documentations for this project.
Page 17/17