cnnmmd

Extension: Engine (prc)

The engines used by the servers are called dynamically (dynamic libraries) according to the script name pattern (owner + engine type):

◯

Specification: Between engine and server

- Class Name - (Stt|Tts|Ttt|Sen)Prc
- method - system # setting - infere # inference

◯

Specification: Between server and client

- endpoint - /sys # config - /gen # inference

◯

Call: Specifying the engine from the server script

- --engine <author>/<engine>

Configuration: Endpoints

The relay server has the following four fixed endpoints/four types of polling endpoints:

/ini # Initial/set @ Store (receives raw data and passes data key)
/get # Get (receives data key and delivers raw data)
/prc # Processing (executing registered dynamic code)
/spsNNN # Store: Receive raw data (notify completion of reception)
/sppNNN # Store: Hand over the data key (when ready)
/gpsNNN # Get: Receive data key (notify reception completion)
/gppNNN # Get: Deliver raw data (when ready)

We provide the following convenience methods to access these endpoints:

MidClt.reqset # Send data MidClt.reqget # Receive data MidClt.reqprc # Execute processing (registered dynamic code)

Extension: Relay Handler (dyn)

The relay handler defines classes and methods for each module and registers them in a specified dictionary format. The relay server extracts the dictionary and dynamically executes the class methods (dynamic library + dynamic code generation): [※1]

◯

Definition: Class ~ Dictionary

class <class>:
  @staticmethod
  def <method>(<argument>, ...):
LibMid.dicprc["<...>"] = { # Process name (optional)
  "frm": "<module>.<class>.<method>",
Processing entity (module + class + method)
  "arg": [...], # Argument group: Priority (1): Get data from label "cnf": [...], # Argument group: Priority (2): Get only label "syn": (True|False) # False for asynchronous response}

*1

The definition of the dynamic code's arguments ("arg"/"cnf") rearranges the dictionary keys (as arguments) entered in the request dictionary to the relay server in the order they are entered as method arguments -- the names of these keys are arbitrary, but if you use a single dictionary key for the data key ("keydat") for the first argument of the method, it has the advantage that you can write the flow without having to worry about argument names (especially when there is only one return value -- however, it can be difficult to determine where the problem is in the event of a problem, so this is a trade-off with the disadvantage).

◯

Definition: Global variable

The following global variables are available in the class:

LibMid.values = {} # LibMid.values[KEYDAT] = ... # Clear contents every turn LibMid.memory = {} # LibMid.memory[KEYDAT] = ... # Do not clear contents every turn

◯

input

The relay handlers you define are specified by the following dictionary keys:

> "keyprc"

◯

output

The execution result of the relay handler is all raw data. The data key(s) are returned.

Data keys are stored in a dictionary, and can usually be derived from a single dictionary key, but if the result is a tuple, it can be derived from multiple dictionary keys:

> "keydat" # When it is a single value (a string is also a single value)
> "key000", "key001", ... # For tuples

◯

Usage: Simple methods ~ endpoints

When raw data is stored on the relay server, the data keys are returned in dictionary format. To retrieve specific raw data, send the data keys in dictionary format:

# Store raw data on the relay server MidClt.reqset({<data>, <address_relay_server>})
# Get raw data from the relay server MidClt.reqget({"keydat": <key_data>},
<address_relay_server>)

To execute a registered relay handler, provide the name of the handler:

# Execute the specified process (registered dynamic code) on the relay server MidClt.reqprc({"keyprc": "<key_plugin>", ...},
<address_relay_server>)