Software Design Lecture Notes
Fall 2004


Distributed Programming
-----------------------

Hints for designing distributed programs using remote objects:

1) start by designing the program as if all the objects
   were part of the same process
 
2) split the objects up into separate processes
 
3) figure out which objects need to be available for remote invocation
 
4) don't get hung up on what's a client and what's a server
 
   any process that makes an object available for RMI is a server
 
   any process that accesses an object by RMI is a client

5) think about if and where you need to run something in a new thread


Example: chat room

people join and leave a communication channel

on each channel, n to n communication


Design decisions:

1) how do we create new channels?

2) how do people find and join channels?

3) how do people send a message?

4) how does the message get updated?

5) how do people leave a channel?


The answers to these questions define a protocol.

From the Hacker's dictionary:

protocol /n./

As used by hackers, this never refers to niceties about the proper
form for addressing letters to the Papal Nuncio or the order in which
one should use the forks in a Russian-style place setting; hackers
don't care about such things. It is used instead to describe any set
of rules that allow different machines or pieces of software to
coordinate with each other without ambiguity. So, for example, it does
include niceties about the proper form for addressing packets on a
network or the order in which one should use the forks in the Dining
Philosophers Problem. It implies that there is some common message
format and an accepted set of primitives or commands that all parties
involved understand, and that transactions among them follow
predictable logical sequences. See also handshaking, do protocol.