Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
The theme callback updates instance and device colors.
Topology Model
The UI maintains an internal model of the topology by storing data representing ONOS instances, nodes (devices and hosts) and links. The model starts empty, but is augmented as events (such as addInstance, addDevice, addLink, etc.) come in from the server. As these events come in, the model is updated, and the visual representation is modified to reflect the current model.
Client-Server Communication
The Topology View uses a websocket to establish communication with the server. This provides a dedicated TCP connection along which both the client and the server can emit messages to the other side. The server emits messages ("events") telling the client of status and/or changes to the topology; the client emits messages ("events") to the server, requesting actions to be performed on behalf of the user, or requesting additional data.
Event messages are structured as JSON objects, with the following general format:
| Code Block | ||
|---|---|---|
| ||
{
"event": "eventType",
"sid": ... ,
"payload": {
...
}
}
|
The event field is a string uniquely identifying the event type.
The sid field is an optional sequence identifier (monotonically increasing integers) which, if provided by the client, should be echoed back in the server's response. Note that server initiated events generally don't include a sid.
The payload field is an arbitrary JSON object whose structure is implied by the event type. Many payloads include an id field at the top level, which holds the unique ID of the item being described by the event.
Event Descriptions
The following table enumerates the events, providing a high-level description of the payload. For explicit details of the payloads, see the source-code 
| Source | Event Type | Description of Payload | Comments |
|---|---|---|---|
| UI | requestSummary | No payload | Client requesting the server to send topology summary data |
| Server | showSummary | High level summary properties: total number of devices, links, hosts, ... | The summary data is displayed in a "fly-in" pane in the top right of the view. |
| Server | addInstance | Instance ID, IP address, online status, ... | An ONOS instance to be added to the model. |
| Server | addDevice | Device ID, type, online status, mastership, labels, properties, ... | A device (switch, roadm, ...) to be added to the model. |
| Server | addHost | Host ID, type, connection point, labels, properties, ... | A host (endstation, bgpSpeaker, router, ...) to be added to the model. |
| Server | addLink | Link ID, type, source ID/port, destination ID/port, ... | A link (direct, optical, tunnel, ...) to be added to the model. |
| Server | updateInstance | (same as addInstance) | An ONOS instance with updated state. |
| Server | updateDevice | (same as addDevice) | A device with updated state. |
| Server | updateHost | (same as addHost) | A host with updated state. |
| Server | updateLink | (same as addLink) | A link with updated state. |
| Server | removeInstance | (same as addInstance)**(1) | An ONOS instance to be removed from the model. |
| Server | removeDevice | (same as addDevice)**(1) | A device to be removed from the model. |
| Server | removeHost | (same as addHost)**(1) | A host to be removed from the model. |
| Server | removeLink | (same as addLink)**(1) | A link to be removed from the model. |
**(1) Technically, only the ID field is required, but this simplifies the code on the server side.
A Note about Links
The topology model on the server side represents links as unidirectional, with a source and destination. In the UI, each link model object abstracts away the directionality.
<<more details to follow>>
Server-Side Architecture
<details of web-socket handling, TopologyResource and related classes, etc.>
...