The distributed whiteboard application allows multiple geographically
distributed users to communicate with each other
by drawing to a common Whiteboard server. In the peer to peer implementation, each
Whiteboard is both a client and a server.
The functionality of a stand-alone Whiteboard is described here.
A user starts a Whiteboard that functions as a server. Other users are
then able to start up their Whitebords as clients. Client Whiteboards connect to the server. The server and client
Whiteboards are able to draw shapes and have them appear on every Whiteboard.
When a connection by the client is first made, the server tells the new client about any shapes created before
the client obtained a connection; these shapes could have been created by
the the server, or another client. Once the client is running, any shapes drawn on the client are sent to the server.
The server draws the shape on its Whiteboard and broadcast it to all other clients.
Once the server is connected to one or more clients, it broadcasts the creation and deletion of shapes to each of
the clients. In summary, when a shape is added or deleted from any Whiteboard, the change is reflected on all
other Whiteboards. Ignoring network latency, the server and clients should display same contents.
Exiting any of the applications does not disturb any other one, except that messages will npo longer be sent to the
"dead" application. Exiting the server causes all the remaining clients to run in stand-alone mode.
Each Whitebord is now a servent - acting as both a client and a server concurrently. To join a session, a Whiteboard is
not required to connect to a dedicted server, but instead may connect to any whiteboard peer that is a part of the
session.
When the shapes are added or removed from a peer, the peer is not only responsible for informing its parent server about
the change, but also all its clients (since each Whiteboard is a server as well).