DRAFT

Contributors

Ben Allan, Rob Armstrong, Colin Potter

Change history

• 0.0.0 baa 5/2/2000 initial
• 0.0.1 baa 5/3/2000 htmlify
• 0.0.2 baa 5/30/2000 finished appendices A,B

Map of what is and what might be for remote UI/HPC framework communication in CCAFFEINE


Introduction

CCAFFEINE (Common Component Architecture Fast Framework Example In Need of Everything) is the first Sandia testbed implementation of a component software framework supporting the standards proposals published by the Common Component Architecture Forum. Our two purposes in writing are to solicit technical suggestions and criticism (dope slaps?) for the proposed version 1 wire protocol currently in design for CCAFFEINE and to document the allegedly scalable command and control structure and the version 0 wire protocol presently used in CCAFFEINE.


First, we very briefly review the current command and control strategy used in CCAFFEINE. It would be overstating the case to claim that the accumulated code which handles these tasks was designed beyond the most basic structural levels. Second section, we list the objectives we believe need to be considered when replacing the remote control layer. Finally, we present an initial design of the replacement for review by the larger community.


Command, control, and communications anatomy of CCAFFEINE

We document the current wire protocol and message transport scheme used in CCAFFEINE for the runtime management of HPC software components to motivate a new design and to capture many relevant use-cases. We are not writing a reference manual to support future users of an existing product. We hope the documentation of several failings in the initial implementation may save time for later implementers and designers.


UI Servers and SPMD Clients

(Put some pictures here that explain our sockets, muxers, and CmdLineBuildViews and the process of starting up CCAFFEINE).

Existing (G)UI features (5/2000)

As seen in UI Servers and SPMD Clients the CCAFFEINE GUI drives the framework by sending it strings through a socket connection. Thus each GUI feature is implemented as some combination of framework line-oriented commands and (minimal) GUI-cached data. We will document the command-line syntax and semantics in Appendix A.


The current CCAFFEINE GUI has buttons, features, and bindings (actions) as summarized in the following list. We name these items in a dot notation to indicate a conceptual hierarchy that organizes the information and functions delivered by the GUI. This does not correspond to a specific hierarchy of widgets in the implementation or to a specific display layout.


CCAFFEINE version 0 GUI

GUI.title	Publicity string naming the system and the demo being shown.
file.new	forget the existing components and start a new screen
file.quit	exit the GUI and cause linux kernel failure if using mpich/c++ frame. Just quit if pure java.
help.about_this_demo	display about file from disk (html)
open_and_execute .bld file.	replay history file
save .bld file as	save history file
pallette.fill from framework list	load list of component classes into GUI
pallette.pick	nominate class for next instantiation in arena
remove	delete picked arena instance
remove all	delete all arena instances and clear history.
run	fire all go ports in arena. probably a really bad idea.
arena.component.pick	highlight in blue/nominate component instance for next arena action
arena.component.drop	normal finish of pallet.pick process. create an instance and draw icon at GUI drop location.
arena.component.move	reposition instance icon in the arena GUI
arena.component.port.pick_source	highlight uses port to connect next.
arena.component.port.pick_target_and_connect	select providing port and attempt connection.
arena.component.port.pick_go	select and execute go port.
arena.component.port.pick_config	select port and initiate configuration parameters dialog
paramDialog.ok	dismiss parameter port dialog and feed configs back to framework.
paramDialog.cancel	dismiss parameter port dialog
arena.component.port.hover	display port type
paramDialog.*	See Appendix B, Generic Configuration Port.

Shortcomings

• The present GUI and underlying sockets cannot go away and come back later in a long running job.
• There is no generic mechanism for special rendering of framework service-linked ports such as Go, ParameterDialog, Stop, ConnectionEvent, DisconnectionEvent, ParameterChangeEvent, HumanLineOutput, UIMessageOutput, HumanLineInput, HumanErrorOutput, MPIService, ConfirmationDialog, etc, etc, etc.
• There is no GUI mechanism for adding components from a repository.
• The gui (and underlying framework) do not account for the possibility that components may live on a subset of the remote processors.
• The gui, the underlying framework, and the CCA standard on which these are based do not anticipate a port existing on only the lead processor in the set of processors where the component is instantiated.

WHAT OUGHT probably TO BE

Scope, objectives and constraints

Desired product scope

We seek a wire protocol (event strings over sockets) for managing a heavy, remote, "mostly single threaded" parallel framework from java/tk/python/other shell languages. The protocol should be such that a GUI can optimize some aspects of its rendering while becoming consistent with the remote framework state if the user waits an appropriate amount of time. In particular, it should not be such that the GUI offers services before they are really there or that it continues to offer services after they are definitely *not* there. Given lags in network transport and long pauses while computations progress, it is not efficient to fully synchronize a largely passive (frame the parallel job then get out of the way) remote GUI rendering with its phalanx of controlled processes. This scope may be rather distinct from the loosely coupled system represented by the Indiana framework.

Expected results

The framework and protocols we describe here are aimed at supporting framework developers, component developers, and component testers using the software on a workstation emulating a multiprocessor or a small set of processors in a larger SPMD machine. Most tightly coupled, massively parallel platforms we are aware of provide such an interactive environment for development purposes, while production runs are large, batch-queued, and non-interactive. Interaction with production runs is often through examination of periodically dumped checkpoint files or editing of a periodically reread parameter file.

The minimum result we require from CCAFFEINE is that the actions of an interactive session can be recorded as a script which can be reread as the control file for a non-interactive production run where only a lightweight C++ framework backend is present. The other result we expect to obtain is that we can generate a C++ main() which is equivalent to the script, but requires no string interpreters and only an extremely lightweight framework backend without the CCAFFEINE control sockets outlined in UI Servers and SPMD Clients.

Other objectives

• Make the remote UI/GUI as passive as possible. I.e. whereever possible, the UI is simply a listener to (and renderer of) the output events.
• Let the UI/GUI come and go while the framework runs.
• Use a protocol identical for both Java and C++ frameworks to facilitate testing.
• Use a protocol implementation as nearly identical for both Java and C++ frameworks as possible to reduce development cost.

General behaviors needed at a low level

• Let the GUI can preempt (cancel) instructions (queued in framework) it already received from the user by sending framework a later cancel/stop. This means the GUI must not hang waiting for an answer to an instruction that never arrived.
• Let the framework silently refuse to queue new instructions from the GUI. This means the GUI must not hang waiting for an answer to an instruction that never arrived.
• Let the GUI immediately do every command it receives from the framework.
• Disallow the GUI from on its own flushing the queue of events it receives from the framework or refuse to queue new commands. GUI can only remove itself from the listeners on the framework by the appropriate detach protocol. This shouldn't be an issue since the GUI shouldn't be running a queue of any sort on the framework events in the first place.

Specific behaviors and events (make browser wide for proper viewing)

GUI.title	string from GUI author.
framework title	goes in the container titles issued by the framework; not a separate facility.
file.new	GUI sends a request for a new named container newContainer <name> GUI returns to passivity framework sends back event sequence newContainer <name> containerTitle <name> <title> pallet begin <name> newClass <class-name> <name> [repeat newClass until list done] pallet end <name> arena begin <name> newComponent <class-name> <instance-name> <name> [repeat newComponent until list done] arena end <name> GUI renders named pallet and arena into its collection of pages on receipt of the arena/pallet end <name>. The pallet may be empty. (The GUI has a separate facility to support the framework api that adds classes to a (possibly empty) pallet. The arena may be empty. It may not if the framework chooses to preinstantiate some components always! Notes: The GUI cannot be certain the framework is done with a new container and should be capable of accurate partial rendering of the container. Similarly, the GUI cannot be certain of receiving either pallet end <name> or arena end <name>. The intent of the "end" events is to give the GUI a backstop event for those times where the GUI wants to skip the rendering phase of adding to its list of managed classes/instances until "all" have been received or a specified timeout since last newClass event has occured. This allows optimization (minimization) of GUI redraws; e.g. wait until all the classes are in (or a timeout) and then resize pallet to hold the widest label.
GUI.about	anything the GUI author implements
framework.about	GUI sends a request for about info containerAbout <name> GUI returns to passivity. framework sends back event sequence containerAbout <name> <html> ... </html> if the named container exists (and produces its "about" string). Notes: Between <html> and </html> there may be line breaks. </html> may be assumed to occur on a line by itself for sloppy prototype implementations if needed.
file.attach	GUI attaches to a running framework and sends introspection request: fwkDump GUI returns to passivity. framework sends back event sequence which will be fwkDump begin <fwkName> [0 or more newContainer sequences as described for file.new] [0 or more newComponent sequences as described for file new] fwkDump end <fwkName> framework flushes from its queue any events that an overeager user tried to schedule while the GUI was catching up with output from the framework.
container.close	send a single request to the framework to close and destroy the named container. containerClose <name> GUI returns to passivity. framework sends back (if lucky) containerClose <name> GUI may de-render the container at any time after containerClose is sent. Notes: It may be desirable for the GUI to queue to itself the teardown event to be done in X seconds. The containerClose event from the framework should cause immediate de-rendering of the container on the GUI side. A teardown event on a non-existent container must not be an error. Tearing down a container must cause cancel and teardown of any open dialogs associated with it. containerClose <name> may also generate messages as in "remove picked arena instance" below.
file.detach	GUI unregisters as a framework listener and tears down all the renderings of containers.
file.quit	GUI sends exit command to the framework. GUI does file.detach above. GUI exits. framework will shutdown on its own at next convenient point which may be after a long computation finishes.
file.quit_now_damnit	GUI sends stop command to the framework. GUI does file.detach above. GUI displays instructions to user about how to kill the framework job if it doesn't die nicely on its own. GUI exits. framework will shutdown immediately (or at next checkpoint in computation). If this is not soon enough, user can follow instructions about killing processes.
cca.about_this_demo:	see framework.about above.
open_and_execute .bld file save .bld file: save .bld file as:	These need further thought, as we have the following small conundrum- .bld is really a history file. presently it is a history of the GUI issued commands. But if the GUI comes and goes, then the history of a container in the framework must be kept in the framework not in the GUI. So then we need a command for the GUI to query the container for the history string.
pallette.fill from framework list	subsumed by container above, though implemented separately.
pallette.pick	nominate class for next arena drop or other query GUI-only. no implication on framework.
remove picked arena instance	GUI send remove request. remove <container-name> <comp-name> GUI return to quiescent state. framework will see about tearing down connections and removing component. It may send back to the GUI zero or more disconnect <container-name> <comp> <port> <comp> <port> delete <container-name> <comp-name> commands which cause the GUI to de-render the connection or component. Notes: if a component is de-rendered, any open dialogs for it should also be de-rendered and actions equivalent to cancel taken. The delete and disconnect commands must deal gracefully (silently) with names the GUI no longer recognizes/already de-rendered.
remove all arena instances and clear history	implement as close.container <name>;file.new <name>.
run	(fire all go ports in arena. probably a really bad idea now): just delete this feature.
arena.component.pick	(highlight in blue/nominate for next arena action) GUI-only. no implication on framework.
arena.component.drop	Normal finish of pallet.pick-arena.create. GUI send create request to framework. pulldown containerName className compName framework may follow up with events newComponent <class-name> <instance-name> <name>
arena.component.describe	GUI send request for port and other component properties. display component <containerName> <compName> framework may follow up with events that add ports, properties, hints, etc to a component (as currently done)
arena.component.move	reposition in the GUI. GUI-only. no implication on framework.
arena.component.port.pick_source	highlight uses port to connect. GUI-only. no implication on framework.
arena.component.port.pick_target_and_connect	select providing port. GUI send request for connection. connect <containerName> <component> <port> <component> <port> framework may respond (or not) with connection/port making/breaking events. connect <containerName> <component> <port> <component> <port> disconnect <containerName> <component> <port> <component> <port> addPort/removePort/etc as currently but with <containerName> added.
arena.component.port.pick_go	highlight and execute go port. GUI send request for execution. go <containerName> <component> <port> framework not expected to do anything in return.
arena.component.port.pick_config	highlight and execute config port. GUI send request for config info configure <containerName> <component> <port> GUI return to passive state. framework may or not subsequently issue events as now for parameter dialog, but adding in container name to arguments needed.
paramDialog.ok	Dismiss dialog and feed configs back to framework. GUI send parameter set requests to framework. GUI return to passive state.
paramDialog.cancel	dismiss dialog. GUI-only. no implication on framework. teardown dialog window.

Lots more to be added. See TODO-list and then get inspired to extend here.
E.g.
RepositoryService, SemaphoreService,AboutService, HelpService, GeneralDialogService, control of Nestable containers, Port property hints (rendering),
component property hints (rendering), framework properties (rendering). GlobalResourceStringService ala Argonne
integrated with parameter dialog wire protocol. 

Appendix A: Version 0 command Line and wire protocol

Appendix B: Generic Configuration Parameter Dialog

We provide a basic, UI-independent parameter input request protocol that lets the component developer assume primitive input sanity. One GUI rendering of the input request protocol, the paramDialog, is described in the second table below. The first table below gives the protocol itself, the line-oriented commands sent from the framework to the GUI. The UI optional response to these commands is to send back configure commands for one or more of the fields of the parameter dialog according to the description in Appendix A.

The protocol could be easily replaced with a single dialog display command using an XML description of the parameter input request. The series of commands is sent in an order that will allow any reasonable object-oriented UI implementation to build temporary data structures needed to negotiate with the user.

The first shortcoming of the protocol is that it may need to have inserted a lead argument to all commands which lets the UI discriminate among multiple containers. I.e. everywhere in the protocol that arguments instance port appear we may need to extend to containerInstance instance port . The second shortcoming of the protocol is that it requires the UI implementation to associate each paramField received with the most recently received paramTab in the given dialog. It would be preferable to include a tabName in the arguments associated with individual fields.