Plugin Use Cases

Plugin description

A plug-in receives messages as part of a stream processes the messages
(in an application-specific way), and sends one or more new messages
on the same stream.

A plug-in has one parent and one or more children

Plug-in can be multithreaded (stci library is thread-safe)

Connections to the plug-in

  • One connection with parent (parent is closer to the front-end)
  • One connection with each child.
  • Zero or more connections with other plug-ins

Communication operations provided by scti api

  • A plug-in can request to receive a message from
    • a particular child ( stci_recv_child(in: child_no, out: buf) )
    • any child ( stci_recv_anychild(out: src, out: buf) )
    • all children ( stci_recv_allchild(out: buf[]) )
    • the parent ( stci_recv_parent(out: buf) )
    • a particular plug-in ( stci_recv_plugin(in: plugin_id, out: buf) )
    • any plug-in ( stci_recv_anyplugin(out: src, out: buf) )
    • any connection ( stci_recv(out: src, out: buf) )
  • A plug-in can send a message to
    • a particular child ( stci_send_child(in: child_no, in: buf) )
    • all children, same buffer i.e., broadcast ( stci_send_allchild(in: buf) )
    • all children, different buffer i.e., scatter ( stci_send_eachchild(in: buf) )
    • the parent ( stci_send_parent(in: buf) )
    • a particular plug-in ( stci_send_plugin(in: plugin_id, in: buf) )
  • Both blocking and non-blocking communication operations are provided
  • The communication operations, at least the ones to/from the child and parent, should take a parameter specifying the stream.

Use Cases

Broadcast passthrough

This plug-in receives messages from its parent and forwards them to each child.


do forever
      stci_recv_parent(buf)    // blocking recv from parent
      stci_send_allchild(buf)  // send to all children

Gather passthrough

This plugin receives messages from any child and forwards them to the parent.


do forever
      stci_recv_anychild(src, buf) // blocking receive from any child
      stci_send_parent(buf)        // send buffer to parent

Staging dynamic objects

This plugin gets requests for files to be staged from each child and forwards the request to the parent. The file is then received from the parent and forwarded to each requesting child. The requests are collective, but each agent need not request the same file, or any file at all.

The example below is synchronous: The plugin will wait for a request from every child before forwarding the request to the parent.


// a request message consists of a set of paths for the files
    do forever
      // wait for a request from each child and forward combined list
      // to parent
      stci_recv_allchild(src, request[])
      file_set = union(request[0], request[1], ...)
      // distribute each incoming file to every child that requested it
      for i = 1 to |file_set|
        for j = 0 to num_children-1
          if filename in request[j]
            stci_isend_child(j, filename) //nonblocking send
            stci_isend_child(j, file)     //nonblocking send

This example illustrates the need for a communication operation to forward data from the parent to one or more children. In the above example, the entire file is received by the plugin before it is sent to the children. A "forward to" operation would allow the infrastructure to pipeline the message data. Using this code we could do something like this:

// distribute each incoming file to every child that requested it
      for i = 1 to |file_set|
        for j = 0 to num_children-1
          if filename in request[j]
            stci_send_child(j, filename)
            child_set += j

Interactive Tool (Parallel Debugger) Plugins

The parallel debugger will be designed to distribute functional responsibilities into the plugin level nodes in order to meet the following design objectives:

  • Improved scalability
  • Increased interactive response
  • Reduced network bandwidth requirements
  • Reduced debug agent footprint
  • Leverage existing standalone debugger components

In general, these functional responsibilities come under the umbrella of reduction and aggregation although there is also the concept of store (cache) and forward on demand.

Define a first level plugin to be the plugin that communicates directly to agents. The plugin should be able to determine that the downstream object is an agent. If this is not possible then the debugger tool will have to determine this when the communication is established by sending a tool message upstream. Using the later technique, the tool would be able to establish the number of hops between the agent and the front-end. Should this function be intrinsic to the STCI?

The parallel debugger will use these first level plugins as a low-level proxy for the front-end. This plugin level debugger tool component will be capable of:

  • Aggregating group responses.
  • Providing symbolic information to the agents.
  • Caching debug agent data and state information
  • Serving as an end point (tool-based proxy) for request/response interactions associated with the existing standalone debugger.

At the other end of the stream topology, the plugin connected to the front-end, is another opportunity for a tool-based proxy.

  • Translation(mapping) between tool front-end request/responses and agent request/responses.
  • Special operations during front-end detachment.
  • Session level authentication and authorization.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License