TTNetworkManager

A process to manage the abstract network interface for the ensemble. This follows the familiar pattern in other processes, in which the main body of the process awaits inputs through a singular queue, and all incoming items contain self-identification information so this process knows how to treat the data. This includes forwarding data meant for other processes when said data arrives on the network interface.

All TT*Process classes follows the same design pattern. They implement a singular input queue from which they read new Messages, which self-identify their function. After processes are created, they exchange interfacing information, primarily in the form of callback functions. After configuring interfaces, the processes start. Each of these processes spends its idle time waiting for new inputs within a ‘run loop’, responding to messages as they arrive; the responses will modify internal process state and produce new messages for other processes implemented on the Ensemble, which ‘owns’ the processes.

class ticktalkpython.NetworkManager.TTNetworkManager(input_queue, ensemble_name=None)

A process to manage the network and token forwarding on behalf of SQs.

This process maintains the network interface, including sending and receiving; the network interface itself handles the exact details, which may be simulated or physical (e.g., UDP layer).

This process maintains a mapping for each SQ so that when an output token is ready, it can duplicate said token and send it to each output destination. This will include handling control layer outputs like deadline tokens

Parameters:

input_queue (queue.Queue or multiprocessing.Queue, depending on simulated or physical runtime (physical meaning actually distinct processes at the OS level)) – A queue into which all messages arrive, both Message and TTNetworkMessage types
ensemble_name (string) – The name of the ensemble this process resides on
sim (simpy.Environment) – The simulation environment, if present

create_and_send_message(dest_ensemble_name, payload, ensure=False)

Create a TTNetworkMessage to be sent to a destination ensemble. Option to guarantee delivery

Parameters:

dest_ensemble_name (string) – The (unique) name of the ensemble to send to. This ensemble must be registered in the TTNetwork routing table, else a KeyError will be thrown
payload (Any) – The payload for the message. This is simply the value/object to send. This does not need to be serialized prior to creating the message
ensure (bool) – An indicator for whether this message should require guaranteed devlivery or not. Defaults to false.

Returns:

The message that is ready to be sent over the network interface

Return type:

TTNetworkMessage (or a subclass thereof)

create_network_interface(network_interface_type, sim=None, ip=None, port=None)

Create and start the network interface for this ensemble

Parameters:

interface_type (TTNetworkInterfaceType) – The type of TTNetworkInterface to be created. Depending on the value, the set of arguments will be used in different ways
sim (simpy.Environment) – If using a simulated form of network, this is the simulation environment. Defaults to None
ip (string) – If using a physical network interface that invokes the IP layer, include that as a string here in IPv4 format. Defaults to None
port (int) – The port to use for the network interface. Must be between 1024 and 65535 and must not be used by another other process on the machine. Defaults to None

get_next_input(): Pull the next input off the input queue.

handle_IPC_message(msg: Message)

This will handle IPC (Inter Process Communication) messages arriving to this process via the singular input queue. This will include messages at the data, control, and management planes, which will have designators to specify how they should be handled (using process-specific enumeration)

The network process will handle messages related to mapping, routing and outgoing tokens

handle_IPC_message_from_network(ipc_msg: Message)

Slightly different than handle_IPC_message because these ones from the network may not be only for the NetworkManager. The Message contains a process recipient, so use that to forward the message appropriately.

Parameters:: message (Message) – A Message that arrived within a TTNetworkMessage
Returns:: None

handle_network_message(message: TTNetworkMessage)

Respond to an incoming message directly from the May contain multiple messages, but they should be contained as Messages so the recipient process and functionalities are known

Parameters:: message (TTNetworkMessage or a child class thereof) – The received message from the network

input_msg(message)

Callback used to provide messages to this process’s input queue.

If this is a simulated environment, we interrupt the process, which is otherwise waiting indefinitely for data to arrive on the queue.

Parameters:: message (TTNetworkMessage | Message) – The message intended for this process

receive_from_network(message)

Receive a message through the TTNetworkInterface; intended to be used as a callback function.

Parameters:: message (TTNetworkMessage) – The message intended for this same ensemble

receive_from_self(message)

Receive a message intended for this process (that would otherwise go through the network)

Parameters:: message (TTNetworkMessage) – The message intended for this same ensemble

run_phy(ip, rx_port=8225, tx_port=8425)

The main run loop for a runtime environment using physical processes, which can take advantage of multi-core processors.

The network is not created until this point, so we require input arguments unlike the other runtime processes

Parameters:

ip (string) – This ensemble’s IP address
rx_port (int) – The port to receive inputs on. Defaults to the RX_PORT for the UDP interface (TICK in 9-key -> 8425)
tx_port – The port to send outputs on. Defaults to the TX_Port for the UDP interface (TALK in 9-key -> 8225)

run_sim(sim)

The main run loop for a runtime environment using simulated processes, which runs on a single core and can implement many ensembles. This function be initially run like any other simpy process to allow proper ‘yield’ interpretation (it is technically a generator, thus the run_sim, run_phy distinction)

The network is not created until this point, so we require input arguments unlike the other runtime processes

Parameters:: sim (simpy.Environment) – The simulation environment

setup_proc_intfc(input_token_func, input_execute_func, input_runtime_manager_func=None, sim_process=None)

Configure the interface to this process, meaning the callback functions for sending outputs to the other processes. This process needs a callback for each other runtime process, as it may receive inputs for any other process through the

Parameters:

input_token_func (function) – A callback function for providing Message inputs to the TTInputTokenProcess
input_execute_func (function) – A callback function for providing Message inputs to the TTExecuteProcess
input_runtime_manager_func (function) – A callback function for providing Message inputs to the TTRuntimeManagerProcess. This should only be provided if the ensemble is a runtime manager. Defaults to None
sim_process (simpy.Process | None) – A reference to the simulated process that this class runs inside of. Mainly used for interrupting the simulated variant on input messages. dDefaults to None