To: 03f522 class

Subject: 2-person game-playing project review.

Thanks to KV Meera for her Trackback review Asgnt4 which is a good contribution to the bde project discussion. It inspired me to add more notes and alternatives for this project topic, and to connect it to the COOL-LCP project (see its URL link on my home page at 97f522 JuicePlant Browser Update Project). -- R Lechner

-----------------------------------------------------------------------

Message 1/303 From Meera kv Oct 28, 03 08:10:37 PM -0800

Subject: Assignment 4: Trackback Use for 2-person games?

Objective of this document is to provide an overview of trackback framework designed for commmunication between blogs, and relate the framework in the context of Genlog, BDElog, and Hominoid project.

Trackback description from technical specification:

TrackBack is a framework for peer-to-peer communication and notifications between web sites. The central idea behind TrackBack is the idea of a TrackBack ping, a request saying, essentially, ``resource A is related/linked to resource B.'' A TrackBack ``resource'' is represented by a TrackBack Ping URL, which is just a standard URI.

Using TrackBack, sites can communicate about related resources. For example, if Weblogger A wishes to notify Weblogger B that he has written something interesting/related/shocking, A sends a TrackBack ping to B. This accomplishes two things:Weblogger B can automatically list all sites that have referenced a particular post on his site, allowing visitors to his site to read all related posts around the web, including Weblogger A's.

The ping provides a firm, explicit link between his entry and yours, as opposed to an implicit link (like a referrer log) that depends upon outside action (someone clicking on the link).

Genlog and BDElog overview:

Genlog provides mechanism for applications to record and replay a log session. It has three methods to implement this mechanism, they are pr_startlog, pr_stoplog, pr_replay. To start recording a log session pr_startlog method needs to be invoked, after starting the log session all the database operations will be logged to the specified .txt file. To stop the log session pr_stop method needs to be invoked. To replay the recorded log file in the same or another application, pr_replay method needs to be used. [see RJL Note 1: load_data in pr_load.]

BDElog provides a controlled Keypress event driven replay mechanism.This mechanism is based on state machine method.There are three states, State 0 is the initialization state, State 1 interprets each command line, State 2 does cleanup. [see RJL Note 2: Two other methods]

Applying Trackback framework to Genlog and BDElog: (Thoughts)

Current Genlog mechanism does not provide communication or notification features like in trackback framework. If the genlog supports Distributed application framework, then trackback mechanism could be used to support distributed database log features, like notify the other database instance when a database started or stopped a log session.

The other possibility could be linking multiple log files, like log session A must be replayed only after log session B. It can be extended further to support linking at the command line level.

[see RJL Note 3: LCP...]

Applying Trackback framework to Hominoid project:

For a game like tick-tack-toe using bde, when a player places his first mark(X/O) on the screen (BDE screen) it should implicitly start the log session and record the players action (marking X/O), then this log session has to be replayed on the screen of the other player and vice-versa. In this use case trackback can be used to communicate actions between the players. [see RJL Note 4: log/replay ....]

RJL NOTES on COOL and Trackback use for 2-Person Games:

RJL Note 1: load_data in pr_load.c has been modified to automatically recognize the need to call pr_replay based on finding an "SR" (Start Replay) command on line 1of the file (bde argv[1] or via File/Open).

RJL Note 2: Two other methods Two other X11 'hooks' were demonstrated by Paul Kingston in 02s522/02f592.: One is a setTimer process that posts an event or a periodic sequence of events to X11's event queue; the callback for this event can also read from the logfile. The Timer approach is useful to execute logfile commands at a periodic rate, either fixed or variable (e.g., by a slider that changes the period). It is probably not useful here.

The other is a WorkProcess that reads and executes one or more logfile lines each time X11's event queue is empty. I recommend a WorkProc to read and execute all database update commands EXCEPT the Wait command. To implement Wait (arg1 = N = delay in msec), the Work Process requests its own setTimer wake up call after N msec; at wakeup time it executes the event and/or forwards it to the X11 event queue.

RJL Note 3: LCP - For log/replay event communications, LCP is probably the appropriate place for Trackback introduction. (GEN is generic for database apps, and should remain independent of multi-threading, except for concurrency control.). LCP already has an OPerator interface that supports reading command file scripts. This OP class can defer support for multi-threading until after more experimentation with a manual discipline like one-at-a-time move selection to achieve mutual exclusion. The more interesting challenge is to use LCP inside of BDE.

RJL Note 4: Log/replay concept.

Should trackback be used to communicate actions between the players? This is a valid concept but not necessarily cost-effective. The players do become active one at a time. This seems to require starting two concurrent bde processes and inter-connecting them for simultaneous logging and replay. Each bde process logs its own changes and has a WorkProc for replay that listens for the other's logging output.

As long as the log output begins with an "SR" command, the rest should be automatic. To speed up the replay process, each player's bde should be able to first load its local copy of the game-board and decorate it with the initial 'game data state'). One way to do this is to supply each one with the pre-packaged 'logfile.txt' database checkpoint. This is not logged but its filename <logfile>+DB1.dat is derived from the change log name <logfile>+.txt. [See function stripDPath at $RL/pr_util/pr_load.c:2902 .]

The logfile's "SR" command causes this checkpoint file to be re-loaded in one player, if the other one selects 'Start Logging'. So both should select 'Start Logging' to send this command to the other player. However, bde needs to be enhanced so even while sending a logfile with local moves, each player can also be replaying the opponent's incoming logfile.

A more significant change is for the two one-way log to replay channels to become Unix socket connections between inter-process communication ports. This can probably be deferred to a later semester by providing a global shared memory instead. This leads to the use of LCP's OPerator class (next topic).

Using COOL-LCP's data model in a control layer over bde:

It is possible to think of logged and replayable commands as 'wrapped' inside event messages (objects of type EI in the Event Instance que which LCP supports). LCP's Event Type or ET class complements its Active Class AC. Each AC has its own State Model SM, and each ET has its own pair of AC's for its sender and receiver. (Each ET could have its own custom argument type list or signature as a remote method call, to constrain EI's to pass values of these types, but this is not in LCP right now.)

EI objects have as data members the actual argument values that become the formal parameter values expected by the method call that the sending AI (AIid1) requests of its receiving AI (AIid2).

In the longer view, this protocol should be extensible to an existing state model for DBDE administration - which oversees the identity of players, records their coming and going, etc. - see the DBDE handout. In this approach, all players send events to an arbiter process who resolves conflicts and updates the master database and re-broadcasts the same stream to every player. So the active player gets a confirmation that the arbiter forwarded the message; such feedback messages can be ignored because the sender has already executed them. They are recognizable because the sending AIid1 is the client's own AIid.

The real (OOAD?) question is whether or not trackback should be used to communicate actions between BDE game-players. Two early ways for web users to interact with servers were post and ????. These achieved limited feedback from users to servers, which the latter could use to run CGI scripts. Then the server could update its .html page copy and download it again to refresh the user view. Trackback may allow a sending client to push a sequence of messages from the active game-player's moves or bde drawing canvas-updates, so the receiving client can use this info any way he/she wants. But the devil is in the details - how flexibly can these messages be interpreted? If they are just URLs that a receiver can link back to, this is not very helpful.

A Simple project: Off-line asynchronous game-playing

Distributed BDE requires synchronous concurrent inter-communication and processing in real-time, because two users have synchronous views of their shared drawing canvas. Trackback could be used effectively with BDE for off-line, asynchronous game-playing. In this case, the users take turns that can be widely separated in time. Note that log/replay is NOT used here - instead the entire diagram is passed back and forth and only one move is added during each one-way pass. When the next player logs in she down-loads the chess-board copy which her opponent has previously updated.

Trackback could nicely inform each player (by email?) when the opponent's latest move is available at a particular URL. Some chess-playing games on the Internet work this way - my son-in-law and grandson were active in these. The sequence of board states (between moves) could be saved at one or both ends as a sequence of diagrams, or in CVS as incremental changes to a bde.dat file. A wrapper script around bde could do cvs check out and enter bde for display, update, and FILE/SAVE-AS a new version or for cvs commit (check-in).

The game-playing wrapper script could also insure that players take turns properly, one move at a time. Bde's schema needs only one change: HGcurr->FSid should become a real fkey to the File-Spec (FS) table. (FS already has author and create-date and mod-date attributes, and the FILE/SAVE menu action needs to be updated to maintain them properly, in which case they are also logged for replay.)