-.SH "SPECIFICATIONS"
-.
-.PP
-\fBovsdb\-server\fR implements the Open vSwitch Database (OVSDB)
-protocol specified in RFC 7047, with the following clarifications:
-.
-.IP "3.1. JSON Usage"
-RFC 4627 says that names within a JSON object should be unique.
-The Open vSwitch JSON parser discards all but the last value
-for a name that is specified more than once.
-.
-.IP
-The definition of <error> allows for implementation extensions.
-Currently \fBovsdb\-server\fR uses the following additional "error"
-strings which might change in later releases):
-.
-.RS
-.IP "\fBsyntax error\fR or \fBunknown column\fR"
-The request could not be parsed as an OVSDB request. An additional
-"syntax" member, whose value is a string that contains JSON, may
-narrow down the particular syntax that could not be parsed.
-.IP "\fBinternal error\fR"
-The request triggered a bug in \fBovsdb\-server\fR.
-.IP "\fBovsdb error\fR"
-A map or set contains a duplicate key.
-.RE
-.
-.IP "3.2. Schema Format"
-RFC 7047 requires the "version" field in <database-schema>. Current
-versions of \fBovsdb\-server\fR allow it to be omitted (future
-versions are likely to require it).
-.IP
-RFC 7047 allows columns that contain weak references to be immutable.
-This raises the issue of the behavior of the weak reference when the
-rows that it references are deleted. Since version 2.6,
-\fBovsdb\-server\fR forces columns that contain weak references to be
-mutable.
-.
-.IP "4. Wire Protocol"
-The original OVSDB specifications included the following reason,
-omitted from RFC 7047, to operate JSON-RPC directly over a stream
-instead of over HTTP:
-.
-.RS
-.IP \(bu
-JSON-RPC is a peer-to-peer protocol, but HTTP is a client-server
-protocol, which is a poor match. Thus, JSON-RPC over HTTP requires
-the client to periodically poll the server to receive server requests.
-.IP \(bu
-HTTP is more complicated than stream connections and doesn't provide
-any corresponding advantage.
-.IP \(bu
-The JSON-RPC specification for HTTP transport is incomplete.
-.RE
-.
-.IP "4.1.5. Monitor"
-For backward compatibility, \fBovsdb\-server\fR currently permits a
-single <monitor-request> to be used instead of an array; it is treated
-as a single-element array. Future versions of \fBovsdb\-server\fR
-might remove this compatibility feature.
-.IP
-Because the <json-value> parameter is used to match subsequent update
-notifications (see below) to the request, it must be unique among all
-active monitors. \fBovsdb\-server\fR rejects attempt to create two
-monitors with the same identifier.
-.
-.IP "4.1.12. Monitor_cond"
-A new monitor method added in Open vSwitch version 2.6. The monitor_cond
-request enables a client to replicate subsets of tables within an OVSDB
-database by requesting notifications of changes to rows matching one of
-the conditions specified in "where" by receiving the specified contents
-of these rows when table updates occur. Monitor_cond also allows a more
-efficient update notifications by receiving table-updates2 notifications
-(described below).
-.
-.IP
-The monitor method described in Section 4.1.5 also applies to monitor_cond,
-with the following exceptions:
-.
-.RS
-.IP \(bu
-RPC request method becomes "monitor_cond".
-.IP \(bu
-Reply result follows <table-updates2>, described in Section 4.1.14.
-.IP \(bu
-Subsequent changes are sent to the client using the "update2" monitor
-notification, described in Section 4.1.14
-.IP \(bu
-Update notifications are being sent only for rows matching [<condition>*].
-.RE
-.
-.IP
-The request object has the following members:
-.
-.PP
-.RS
-.nf
-"method": "monitor_cond"
-"params": [<db-name>, <json-value>, <monitor-cond-requests>]
-"id": <nonnull-json-value>
-.fi
-.RE
-.
-.IP
-The <json-value> parameter is used to match subsequent update notifications
-(see below) to this request. The <monitor-cond-requests> object maps the name
-of the table to an array of <monitor-cond-request>.
-.
-.IP
-Each <monitor-cond-request> is an object with the following members:
-.
-.PP
-.RS
-.nf
-"columns": [<column>*] optional
-"where": [<condition>*] optional
-"select": <monitor-select> optional
-.fi
-.RE
-.
-.IP
-The "columns", if present, define the columns within the table to be monitored
-that match conditions. If not present all columns are being monitored.
-.
-.IP
-The "where" if present is a JSON array of <condition> and boolean values. If not
-present or condition is an empty array, implicit True will be considered and
-updates on all rows will be sent.
-.
-.IP
-<monitor-select> is an object with the following members:
-.
-.PP
-.RS
-.nf
-"initial": <boolean> optional
-"insert": <boolean> optional
-"delete": <boolean> optional
-"modify": <boolean> optional
-.fi
-.RE
-.
-.IP
-The contents of this object specify how the columns or table are to be
-monitored as explained in more detail below.
-.
-.IP
-The response object has the following members:
-.
-.PP
-.RS
-.nf
-"result": <table-updates2>
-"error": null
-"id": same "id" as request
-.fi
-.RE
-.
-.IP
-The <table-updates2> object is described in detail in Section 4.1.14. It
-contains the contents of the tables for which "initial" rows are selected.
-If no tables initial contents are requested, then "result" is an empty object.
-.
-.IP
-Subsequently, when changes to a specified table that match one of the conditions
-in monitor-cond-request are committed, the changes are automatically sent to the
-client using the "update2" monitor notification (see Section 4.1.14). This
-monitoring persists until the JSON-RPC session terminates or until the client
-sends a "monitor_cancel" JSON-RPC request.
-.
-.IP
-Each <monitor-cond-request> specifies one or more conditions and the manner in
-which the rows that match the conditions are to be monitored. The circumstances in
-which an "update" notification is sent for a row within the table are determined by
-<monitor-select>:
-.
-.RS
-.IP \(bu
-If "initial" is omitted or true, every row in the original table that matches one of
-the conditions is sent as part of the response to the "monitor_cond" request.
-.IP \(bu
-If "insert" is omitted or true, "update" notifications are sent for rows newly
-inserted into the table that match conditions or for rows modified in the table
-so that their old version does not match the condition and new version does.
-.IP \(bu
-If "delete" is omitted or true, "update" notifications are sent for rows deleted
-from the table that match conditions or for rows modified in the table so that
-their old version does match the conditions and new version does not.
-.IP \(bu
-If "modify" is omitted or true, "update" notifications are sent whenever a row in
-the table that matches conditions in both old and new version is modified.
-.RE
-.
-.IP
-Both monitor and monitor_cond sessions can exist concurrently. However,
-monitor and monitor_cond shares the same <json-value> parameter space; it
-must be unique among all monitor and monitor_cond sessions.
-.
-.IP "4.1.13. Monitor_cond_change"
-The "monitor_cond_change" request enables a client to change an existing
-"monitor_cond" replication of the database by specifying a new condition
-and columns for each replicated table. Currently changing the columns set
-is not supported.
-.
-.IP
-The request object has the following members:
-.
-.IP
-.RS
-.nf
-"method": "monitor_cond_change"
-"params": [<json-value>, <json-value>, <monitor-cond-update-requests>]
-"id": <nonnull-json-value>
-.fi
-.RE
-.
-.IP
-The <json-value> parameter should have a value of an existing conditional
-monitoring session from this client. The second <json-value> in params array
-is the requested value for this session. This value is valid only after
-"monitor_cond_change" is committed. A user can use these values to distinguish
-between update messages before conditions update and after. The
-<monitor-cond-update-requests> object maps the name of the table to an array of
-<monitor-cond-update-request>.
-.
-.IP
-Each <monitor-cond-update-request> is an object with the following members:
-.
-.IP
-.RS
-.nf
-"columns": [<column>*] optional
-"where": [<condition>*] optional
-.fi
-.RE
-.
-.IP
-The "columns" specify a new array of columns to be monitored
-(Currently unsupported).
-.
-.IP
-The "where" specify a new array of conditions to be applied to this monitoring
-session.
-.
-.IP
-The response object has the following members:
-.
-.IP
-.RS
-.nf
-"result": null
-"error": null
-"id": same "id" as request
-.fi
-.RE
-.IP
-Subsequent <table-updates2> notifications are described in detail in Section
-4.1.14 in the RFC. If insert contents are requested by original monitor_cond
-request, <table-updates2> will contain rows that match the new condition and
-do not match the old condition.
-If deleted contents are requested by origin monitor request, <table-updates2>
-will contain any matched rows by old condition and not matched by the new
-condition.
-.
-.IP
-Changes according to the new conditions are automatically sent to the client
-using the "update2" monitor notification. An update, if any, as a result of a
-condition change, will be sent to the client before the reply to the
-"monitor_cond_change" request.
-.
-.IP "4.1.14. Update2 notification"
-The "update2" notification is sent by the server to the client to report
-changes in tables that are being monitored following a "monitor_cond" request
-as described above. The notification has the following members:
-.
-.RS
-.nf
-"method": "update2"
-"params": [<json-value>, <table-updates2>]
-"id": null
-.fi
-.RE
-.
-.IP
-The <json-value> in "params" is the same as the value passed as the
-<json-value> in "params" for the corresponding "monitor" request.
-<table-updates2> is an object that maps from a table name to a <table-update2>.
-A <table-update2> is an object that maps from row's UUID to a <row-update2>
-object. A <row-update2> is an object with one of the following members:
-.
-.RS
-.IP "\(dqinitial\(dq: <row>"
-present for "initial" updates
-.IP "\(dqinsert\(dq: <row>"
-present for "insert" updates
-.IP "\(dqdelete\(dq: <row>"
-present for "delete" updates
-.IP "\(dqmodify\(dq: <row>"
-present for "modify" updates
-.RE
-.
-.IP
-The format of <row> is described in Section 5.1.
-.
-.IP
-<row> is always a null object for a "delete" update. In "initial" and
-"insert" updates, <row> omits columns whose values equal the default
-value of the column type.
-.
-.IP
-For a "modify" update, <row> contains only the columns that are modified.
-<row> stores the difference between the old and new value for those columns,
-as described below.
-.
-.IP
-For columns with single value, the difference is the value of the new
-column.
-.
-.IP
-The difference between two sets are all elements that only belong
-to one of the sets.
-.
-.IP
-The difference between two maps are all key-value pairs whose keys
-appears in only one of the maps, plus the key-value pairs whose keys
-appear in both maps but with different values. For the latter
-elements, <row> includes the value from the new column.
-.
-.IP
-Initial views of rows are not presented in update2 notifications,
-but in the response object to the monitor_cond request. The formatting
-of the <table-updates2> object, however, is the same in either case.
-.
-.IP "5.1. Notation"
-For <condition>, RFC 7047 only allows the use of \fB!=\fR, \fB==\fR,
-\fBincludes\fR, and \fBexcludes\fR operators with set types. Open
-vSwitch 2.4 and later extend <condition> to allow the use of \fB<\fR,
-\fB<=\fR, \fB>=\fR, and \fB>\fR operators with columns with type ``set
-of 0 or 1 integer'' and ``set of 0 or 1 real''. These conditions
-evaluate to false when the column is empty, and otherwise as described
-in RFC 7047 for integer and real types.
-.
-.IP
-<condition> is specified in Section 5.1 in the RFC with the following change:
-A condition can be either a 3-element JSON array as described in the RFC or a
-boolean value. In case of an empty array an implicit true boolean value will be
-considered.
-.
projects / mirror_ovs.git / blobdiff