Michael Bayne
04f3aacab2
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@15 542714f4-19e9-0310-aa3c-eee0fc999fb1
83 lines
3.2 KiB
Plaintext
83 lines
3.2 KiB
Plaintext
Cher Mk3 Design -*- outline -*-
|
|
|
|
* Why Cher?
|
|
The basic function of this layer is to allow the sharing (Cher-ing) of
|
|
information among different nodes in the network. Plus, I don't think Cher
|
|
has ever had a software system named after her and it's high time. Imagine
|
|
Cher as the social lubricant that allows the party goers to communicate.
|
|
|
|
* A note on thread-safety
|
|
|
|
Distributed objects are designed only to be accessed from one thread. On
|
|
the server, there is a distributed object dispatch thread on which 95% of
|
|
all activity takes place anyway. It would be questionable to require that
|
|
thread to access distributed object members through synchronized members
|
|
just so that the few places where it is convenient to access dobjs off of
|
|
the dobjmgr thread are simplified. Instead we've opted for the performance
|
|
and care must be taken not to access distributed objects outside of the
|
|
dobjmgr thread.
|
|
|
|
Events can be generated from any thread, but values should not be read
|
|
from the distributed object on other threads because they are subject to
|
|
change at any time and could be half changed when some other thread goes
|
|
to read them.
|
|
|
|
On the client, care is taken to combine the AWT and dobj threads so that
|
|
life is simple from a synchronization standpoint. None the less, the same
|
|
care should be taken when other threads are introduced (IntervalManager
|
|
for example) not to read values from a distributed object on those other
|
|
threads.
|
|
|
|
This is easy enough to do. Simply copy the values you care about out of
|
|
the object before passing the information on to another thread (take care
|
|
to copy non-primitive values like arrays and OidLists). If you find the
|
|
need to fetch values from a distributed object after another thread has
|
|
already started, you'll just have to rethink your approach.
|
|
|
|
* Client components
|
|
|
|
** DObjectManager
|
|
Manages object proxies; converts value change requests into events,
|
|
forwards them via the iomgr; dispatches events on incoming queue; reaps
|
|
proxies when last subscriber goes away
|
|
|
|
** UI (AWT/Swing)
|
|
Standard AWT/Swing UI
|
|
|
|
** UI (Controller)?
|
|
Provides a paradigm of controllers and commands; code can post commands
|
|
back to the controller queue for later execution; UI elements structured
|
|
to automatically generate commands; will probably opt not to use this in
|
|
favor of Swing's built-in paradigms
|
|
|
|
** I/O Manager
|
|
*** Reader
|
|
Reads incoming data from the socket; decodes messages; posts events to
|
|
domgr queue; notifies object subscription penders (this should be done
|
|
asychronously)
|
|
|
|
*** Writer
|
|
Encodes object subscription and event forwarding requests; writes them to
|
|
the outgoing socket
|
|
|
|
** Client object
|
|
Informs exo-client about connection state changes; provides interface to
|
|
connection + authentication (logon) and disconnection (logoff); provides
|
|
access to omgr and client dobj
|
|
|
|
* Server components
|
|
|
|
** Connection Manager
|
|
Listens on accepting socket; creates and manages connection objects;
|
|
informs connection observer of state changes; handles all network traffic
|
|
on own thread;
|
|
|
|
** Auth Manager
|
|
Processes auth requests on own thread; uses pluggable Authenticator to
|
|
perform actual authentication;
|
|
|
|
** Client Manager
|
|
Registers with connection manager; manages authentication; maps
|
|
connections to existing client objects or creates new client objects for
|
|
newly connecting clients;
|