-
Notifications
You must be signed in to change notification settings - Fork 1
Message Documentation
This doc contains information of possible request and configure messages to send to the testbed and the possible responses.
Commands in this section can be called on any WiseGroup object and will affect the according nodes in the testbed. An optional callback block can be passed to every of these methods.
If you have an instance of a WiseOMF::Client::WiseGroup (e.g. from the WiseOMF::Client::ReservationManager) named group you can call the method like in the following example:
Example:
group.set_xxx(parameter) { |properties|
# callback block for method with parameters ...
}
group.yyy { |properties|
# callback block for method without parameters ...
}Note: The properties variable in the callback block contains a data structure as described in the following sections. In general all properties have a type field describing the type of the message. This field could be used to decide what to do with the message.
Every instance of WiseOMF::Client::WiseGroup can have a default callback handler for handling messages without a matching callback block. This might be usefull for catching upstream messages as described in "Upstream Messages". Furthermore some OMF specific messages may occur during the experiment. Whenever it is not possible to call a specific callback block in your experiment, the default callback will be called.
Example:
group.default_callback = lambda { |message|
# message is an object containing the information of the entire FRCP message
}Note: Due to the fact that OMF specific messages may have a different format than the testbed specific properties, the callback block will receive the entire message as parameter. Usually this message contains a field properties in which the information described in the following sections may be contained (if the message is from the testbed). The properties field may contain arbitrary data if the message is OMF specific or from another OMF resource than a wisebed_node.
This section contains methods that can be used for modifying the state of nodes in a group. In OMF language these methods are used for creating FRCP configure messages. Speaking in programming language words, you can think of these methods as setter methods.
This method can be used for flashing a binary image onto the nodes.
-
Parameter:
a Base64 encoded binary image
-
Callbacks:
A callback handler for this command might receive responses as well as progress messages.
Progress Messages:
--- type: :progress requestId: <unique-request-id (Integer)> nodeUrns: - "<node urn of node sending the progress message>" progress: <progress in percent>
Response Messages:
--- type: :response requestId: <unique-request-id (Integer)> responses: - nodeUrn: "<node urn of node sending this response>" response: <Base64 encoded response> statusCode: <the status code between 0 and 100 (progress in percent) or negative if error> errorMessage: <optional, if an error occured> - <further responses>
This method can be used to send a message to the nodes.
-
Parameter:
An arbitrary sequence of bytes as Base64 encoded string
-
Callbacks:
A callback handler receives an ACK or an error message as direct response to the call. Furthermore multiple upstream messages may be send as reaction to the downstream message.
Response Messages:
--- type: :response requestId: <unique-request-id (Integer)> responses: - nodeUrn: "<node urn of node sending this response>" statusCode: <the status code> errorMessage: <optional, if an error occured (e.g. node is not connected)> - <further responses>
Upstream Messages:
--- type: :message requestId: <unique-request-id (Integer)> nodeUrns: - "<node urn>" timestamp: <a timestamp> payload: <a Base64 encoded sequence of bytes>
This method can be used to reset the nodes to their default state
-
Callbacks:
Response Messages:
--- type: :response requestId: <unique-request-id (Integer)> responses: - nodeUrn: "<node urn of node sending this response>" statusCode: <the status code> errorMessage: <optional, if an error occured (e.g. node is not connected)> - <further responses>
This section contains methods that can be used for getting the state of nodes in a group. In OMF language these methods are used for creating FRCP request messages. Speaking in programming language words, you can think of these methods as getter methods.
This method can be used to check whether nodes are alive or not.
-
Callbacks:
Response Messages:
--- type: :response requestId: <unique-request-id (Integer)> responses: - nodeUrn: "<node urn of node sending this response>" statusCode: <the status code [0: not alive, 1: alive]> errorMessage: <optional, if an error occured (e.g. node is not connected)> - <further responses>
This method can be used to check whether nodes are connected or not.
-
Callbacks:
Response Messages:
--- type: :response requestId: <unique-request-id (Integer)> responses: - nodeUrn: "<node urn of node sending this response>" statusCode: <the status code [0: not connected, 1: connected]> errorMessage: <optional, if an error occured (e.g. node is not connected)> - <further responses>
In this section we'll describe the format of messages beeing send by the testbed and the nodes in your groups. You'll receive these messages on the group topic of every group containing at least one affected node. Due to the fact that these messages don't have a request id, only the default callback of the affected groups is called.
This message is send if at least one node is attached.
---
type: :nodes_attached
nodeUrns:
- "<node urn>"
timestamp: <timestamp of this event>
reason: "Some nodes in this group were attached."This message is send if at least one node is detached.
---
type: :nodes_detached
nodeUrns:
- "<node urn>"
timestamp: <timestamp of this event>
reason: "Some nodes in this group were detached."This message is send for notifications comming from the nodes.
---
type: :notification
nodeUrns:
- "<node urn>"
timestamp: <timestamp of this event>
message: "<The notification>"