To: 06f522 class:
RJLRef: $PH/06f522/SetGame06f/SetGame04fReport_ra.txt

This started as a checklist for Nitin; then I discovered RAlmonte's
report on SetGame04f and added a review of that. Almonte produced
a .doc [?] file with artwork that replaces my hand-drawn slides,
formalizes the network message handling aspects and proposes
an architecture for this part of DSG or DistributedSetGame.

We scheduled a Design Revievw for next week,
and moved the Exam2 to Dec. 5 (in 2 wks).
Final project review and demo will be in OS309 
during exam week Tues Dec. 19.

We reviewed .ppt slides in $PH/DBDE, $PH/04s522/{lcp04s,SetGame04s}

We reviewed code (auto-generated, inherited or redone by ajlopez) 
for SetGame04s and its state models and handed out overhead transparencies 
that I hand-drew in 200x together with the Java Report paper 
on the Game of Set that inspired the SetGame project 

In particular we reviewed LCP04s/olc code for the LCP interpreter
(esp. dispatchEvent.c), the lcpSetup and lcpMain phases (setup phase calls
makeHead.c which processes one StateModel at a time and creates the jump 
table in FuncTbl[] for each state action name. Run phase  depends on
the linker to initialize these FuncTbl ptr entries referenced as (*actRtnName).

CAVEAT: don't rely on my names as identifiers here. 
Look at the schema then the code for the correct spelling.


The Hominid StateModels are for app classes called HD and HL. 
Their STDiagram definitions are in H?setup.c 
and their State Actions are defined in H?actions.c.

In SetGame04s, the Server/Controller ActiveClasses 
have application subclasses SG and SF respectively.)

In XXsetup.c, a call to olc function StateModelCreateCompletely 
creates the State Model database from strings declaring each
ST, TR and ET as transition-label. 
It also adds the FuncTbl index to the ST-row for each state action name.
This index goes into an I4 type field (still called actRtnPtr although
64-bit ptrs outgrew 32-bit ints and are illegal as persistent data).


Update: Use SetGame04f: after class tonight I discovered RAlmonte's update
to the SetGame04s project. Please read his report at:
 
http://www.cs.uml.edu/~lechner/05f523/04fdsg_raReportR05f.doc

He has extensive diagrams that replace my hand-drawn ones.
Please check it out and reuse as you see fit - it may be the best 
starting point for your updated SetGame06f project documentation.
I append below a footnote TBAdded to his Section on Use Case Diagrams 
on page 9.

His Section 4 has an elaborate class model for the networking aspects.
Have fun magnifying it by zooming in.
Section 5 has state diagrams for the in and out message handlers,
which might be a basis for future LCP-based control of comm aspects.

In Section 6 Implementation, he simplifies the above model for DSG:
"...in my simple implementation there are neither outgoing threads nor queues, 
instead the application calls utilities to send the messages from <message.h>.  
The incoming queue is implemented as a circular buffer with fixed size...."

His Section 7 Future Plans, describes what must be done next (in 06f522, I hope).

[Note: RALMonte focused on communications and did not have time to 
finish this project, so you still have work to do besides the graphics.]

=====================================================

PS: 04fdsg_raReportR05f.doc has footnote comments by me (hence, rev. R05f).
I will add the new footnote #4 below to the end of ralmonte's 
DSG Use Case Diagram on page 9 of 

PPS: RAlmonte has a link to Prof Moloney's tutorial distributed Systems.ppt.
I saved a copy of that in $PH/COOL-LCP/OS515_wm_Distributed_systems.ppt
for those who have not yet taken OS515.

http://www.cs.uml.edu/~lechner/05f523/04fdsg_raReportR05f.doc.
---------------------------------
[RJL061121: I don't see a need for the synchronization of Request msgs,
as long as the Server [has threads that] can listen in parallel to all the players. 
Then any thread detecting a complete  a msg. waiting in a from-Client buffer 
can unpack the waiting msg content (which is an EI of type EI.ETid).  
The next step is to enqueue this EI on the main Server's EI queue table.  
This I believe accomplishes serialization. 
These threads are on the Server's machine and use shared memory. 
In effect, the msg. contains an EI, and multiple Client threads 
can be trying to enqueue their EI's simultaneously. That's OK as long as 
they don't use the same pkey.  Either we can pre-allocate a disjoint EIid 
range to each client or we can delegate the EIid-setting job to the Server's 
EI-receiving thread.  The Server thread EI-constructors (hand-coded) 
must share a pr_add lock and wait their turn for this lock to be cleared 
by another client. (<test-and- wait-for-lock> or <test-and-set lock, call 
pr_add(EI...) and clear lock>).  Note that the pr_add code is NOT  re-entrant.   
(In the STDs of Secton 5,  I assume parallel threads buffer one incoming msgs each, 
and the lock occurs on a critical section that encompasses pr-add, 
but not the entire unpacking and EI-copy-construction, which is quite similar 
to reading a CQ, encoding its fvalues and adding it to
the CandidatekeyQuery or CQ table).]