Mercurial > hg
comparison mercurial/help/internals/wireprotocol.txt @ 39558:b0e0db1565d1
internals: extract frame-based protocol docs to own document
wireprotocol.txt is quite long and difficult to digest. The
frame-based protocol is effectively a standalone concept (and could
even be used outside of Mercurial). So this commit extracts its
docs to a standalone file.
The first few paragraphs were rewritten as part of the extraction.
Sections headers were adjusted accordingly.
Existing referalls in wireprotocol.txt were updated to refer to the
new doc / concept, which I've started referring to as `hgrpc`.
I'm on the fence as to whether to move the HTTP and SSH transport
details to the new doc as well. For now, I'm leaving them in
wireprotocol.txt.
Differential Revision: https://phab.mercurial-scm.org/D4443
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Mon, 27 Aug 2018 13:30:44 -0700 |
parents | dc61a67c1fc0 |
children | 124507a263e5 |
comparison
equal
deleted
inserted
replaced
39557:623081f2abc2 | 39558:b0e0db1565d1 |
---|---|
218 exchange takes place. This provides a better end-user experience. | 218 exchange takes place. This provides a better end-user experience. |
219 | 219 |
220 Requests to unknown commands or URLS result in an HTTP 404. | 220 Requests to unknown commands or URLS result in an HTTP 404. |
221 TODO formally define response type, how error is communicated, etc. | 221 TODO formally define response type, how error is communicated, etc. |
222 | 222 |
223 HTTP request and response bodies use the *Unified Frame-Based Protocol* | 223 HTTP request and response bodies use the ``hgrpc`` protocol for media |
224 (defined below) for media exchange. The entirety of the HTTP message | 224 exchange.` (See :hg:`help internals.wireprotocolrpc` for details of |
225 body is 0 or more frames as defined by this protocol. | 225 the protocol.) The entirety of the HTTP message body is 0 or more frames |
226 as defined by this protocol. | |
226 | 227 |
227 Clients and servers MUST advertise the ``TBD`` media type via the | 228 Clients and servers MUST advertise the ``TBD`` media type via the |
228 ``Content-Type`` request and response headers. In addition, clients MUST | 229 ``Content-Type`` request and response headers. In addition, clients MUST |
229 advertise this media type value in their ``Accept`` request header in all | 230 advertise this media type value in their ``Accept`` request header in all |
230 requests. | 231 requests. |
234 an HTTP 406. | 235 an HTTP 406. |
235 | 236 |
236 Servers receiving requests with an invalid ``Content-Type`` header SHOULD | 237 Servers receiving requests with an invalid ``Content-Type`` header SHOULD |
237 respond with an HTTP 415. | 238 respond with an HTTP 415. |
238 | 239 |
239 The command to run is specified in the POST payload as defined by the | 240 The command to run is specified in the POST payload as defined by ``hgrpc``. |
240 *Unified Frame-Based Protocol*. This is redundant with data already | 241 This is redundant with data already encoded in the URL. This is by design, |
241 encoded in the URL. This is by design, so server operators can have | 242 so server operators can have better understanding about server activity from |
242 better understanding about server activity from looking merely at | 243 looking merely at HTTP access logs. |
243 HTTP access logs. | |
244 | 244 |
245 In most circumstances, the command specified in the URL MUST match | 245 In most circumstances, the command specified in the URL MUST match |
246 the command specified in the frame-based payload or the server will | 246 the command specified in the frame-based payload or the server will |
247 respond with an error. The exception to this is the special | 247 respond with an error. The exception to this is the special |
248 ``multirequest`` URL. (See below.) In addition, HTTP requests | 248 ``multirequest`` URL. (See below.) In addition, HTTP requests |
252 The ``multirequest`` command endpoints (``ro/multirequest`` and | 252 The ``multirequest`` command endpoints (``ro/multirequest`` and |
253 ``rw/multirequest``) are special in that they allow the execution of | 253 ``rw/multirequest``) are special in that they allow the execution of |
254 *any* command and allow the execution of multiple commands. If the | 254 *any* command and allow the execution of multiple commands. If the |
255 HTTP request issues multiple commands across multiple frames, all | 255 HTTP request issues multiple commands across multiple frames, all |
256 issued commands will be processed by the server. Per the defined | 256 issued commands will be processed by the server. Per the defined |
257 behavior of the *Unified Frame-Based Protocol*, commands may be | 257 behavior of ``hgrpc```, commands may be issued interleaved and responses |
258 issued interleaved and responses may come back in a different order | 258 may come back in a different order than they were issued. Clients MUST |
259 than they were issued. Clients MUST be able to deal with this. | 259 be able to deal with this. |
260 | 260 |
261 SSH Protocol | 261 SSH Protocol |
262 ============ | 262 ============ |
263 | 263 |
264 Handshake | 264 Handshake |
510 s: 240\n | 510 s: 240\n |
511 s: capabilities: known getbundle batch ...\n | 511 s: capabilities: known getbundle batch ...\n |
512 | 512 |
513 Following capabilities advertisement, the peers communicate using version | 513 Following capabilities advertisement, the peers communicate using version |
514 1 of the SSH transport. | 514 1 of the SSH transport. |
515 | |
516 Unified Frame-Based Protocol | |
517 ============================ | |
518 | |
519 **Experimental and under development** | |
520 | |
521 The *Unified Frame-Based Protocol* is a communications protocol between | |
522 Mercurial peers. The protocol aims to be mostly transport agnostic | |
523 (works similarly on HTTP, SSH, etc). | |
524 | |
525 To operate the protocol, a bi-directional, half-duplex pipe supporting | |
526 ordered sends and receives is required. That is, each peer has one pipe | |
527 for sending data and another for receiving. | |
528 | |
529 All data is read and written in atomic units called *frames*. These | |
530 are conceptually similar to TCP packets. Higher-level functionality | |
531 is built on the exchange and processing of frames. | |
532 | |
533 All frames are associated with a *stream*. A *stream* provides a | |
534 unidirectional grouping of frames. Streams facilitate two goals: | |
535 content encoding and parallelism. There is a dedicated section on | |
536 streams below. | |
537 | |
538 The protocol is request-response based: the client issues requests to | |
539 the server, which issues replies to those requests. Server-initiated | |
540 messaging is not currently supported, but this specification carves | |
541 out room to implement it. | |
542 | |
543 All frames are associated with a numbered request. Frames can thus | |
544 be logically grouped by their request ID. | |
545 | |
546 Frames begin with an 8 octet header followed by a variable length | |
547 payload:: | |
548 | |
549 +------------------------------------------------+ | |
550 | Length (24) | | |
551 +--------------------------------+---------------+ | |
552 | Request ID (16) | Stream ID (8) | | |
553 +------------------+-------------+---------------+ | |
554 | Stream Flags (8) | | |
555 +-----------+------+ | |
556 | Type (4) | | |
557 +-----------+ | |
558 | Flags (4) | | |
559 +===========+===================================================| | |
560 | Frame Payload (0...) ... | |
561 +---------------------------------------------------------------+ | |
562 | |
563 The length of the frame payload is expressed as an unsigned 24 bit | |
564 little endian integer. Values larger than 65535 MUST NOT be used unless | |
565 given permission by the server as part of the negotiated capabilities | |
566 during the handshake. The frame header is not part of the advertised | |
567 frame length. The payload length is the over-the-wire length. If there | |
568 is content encoding applied to the payload as part of the frame's stream, | |
569 the length is the output of that content encoding, not the input. | |
570 | |
571 The 16-bit ``Request ID`` field denotes the integer request identifier, | |
572 stored as an unsigned little endian integer. Odd numbered requests are | |
573 client-initiated. Even numbered requests are server-initiated. This | |
574 refers to where the *request* was initiated - not where the *frame* was | |
575 initiated, so servers will send frames with odd ``Request ID`` in | |
576 response to client-initiated requests. Implementations are advised to | |
577 start ordering request identifiers at ``1`` and ``0``, increment by | |
578 ``2``, and wrap around if all available numbers have been exhausted. | |
579 | |
580 The 8-bit ``Stream ID`` field denotes the stream that the frame is | |
581 associated with. Frames belonging to a stream may have content | |
582 encoding applied and the receiver may need to decode the raw frame | |
583 payload to obtain the original data. Odd numbered IDs are | |
584 client-initiated. Even numbered IDs are server-initiated. | |
585 | |
586 The 8-bit ``Stream Flags`` field defines stream processing semantics. | |
587 See the section on streams below. | |
588 | |
589 The 4-bit ``Type`` field denotes the type of frame being sent. | |
590 | |
591 The 4-bit ``Flags`` field defines special, per-type attributes for | |
592 the frame. | |
593 | |
594 The sections below define the frame types and their behavior. | |
595 | |
596 Command Request (``0x01``) | |
597 -------------------------- | |
598 | |
599 This frame contains a request to run a command. | |
600 | |
601 The payload consists of a CBOR map defining the command request. The | |
602 bytestring keys of that map are: | |
603 | |
604 name | |
605 Name of the command that should be executed (bytestring). | |
606 args | |
607 Map of bytestring keys to various value types containing the named | |
608 arguments to this command. | |
609 | |
610 Each command defines its own set of argument names and their expected | |
611 types. | |
612 | |
613 This frame type MUST ONLY be sent from clients to servers: it is illegal | |
614 for a server to send this frame to a client. | |
615 | |
616 The following flag values are defined for this type: | |
617 | |
618 0x01 | |
619 New command request. When set, this frame represents the beginning | |
620 of a new request to run a command. The ``Request ID`` attached to this | |
621 frame MUST NOT be active. | |
622 0x02 | |
623 Command request continuation. When set, this frame is a continuation | |
624 from a previous command request frame for its ``Request ID``. This | |
625 flag is set when the CBOR data for a command request does not fit | |
626 in a single frame. | |
627 0x04 | |
628 Additional frames expected. When set, the command request didn't fit | |
629 into a single frame and additional CBOR data follows in a subsequent | |
630 frame. | |
631 0x08 | |
632 Command data frames expected. When set, command data frames are | |
633 expected to follow the final command request frame for this request. | |
634 | |
635 ``0x01`` MUST be set on the initial command request frame for a | |
636 ``Request ID``. | |
637 | |
638 ``0x01`` or ``0x02`` MUST be set to indicate this frame's role in | |
639 a series of command request frames. | |
640 | |
641 If command data frames are to be sent, ``0x08`` MUST be set on ALL | |
642 command request frames. | |
643 | |
644 Command Data (``0x02``) | |
645 ----------------------- | |
646 | |
647 This frame contains raw data for a command. | |
648 | |
649 Most commands can be executed by specifying arguments. However, | |
650 arguments have an upper bound to their length. For commands that | |
651 accept data that is beyond this length or whose length isn't known | |
652 when the command is initially sent, they will need to stream | |
653 arbitrary data to the server. This frame type facilitates the sending | |
654 of this data. | |
655 | |
656 The payload of this frame type consists of a stream of raw data to be | |
657 consumed by the command handler on the server. The format of the data | |
658 is command specific. | |
659 | |
660 The following flag values are defined for this type: | |
661 | |
662 0x01 | |
663 Command data continuation. When set, the data for this command | |
664 continues into a subsequent frame. | |
665 | |
666 0x02 | |
667 End of data. When set, command data has been fully sent to the | |
668 server. The command has been fully issued and no new data for this | |
669 command will be sent. The next frame will belong to a new command. | |
670 | |
671 Command Response Data (``0x03``) | |
672 -------------------------------- | |
673 | |
674 This frame contains response data to an issued command. | |
675 | |
676 Response data ALWAYS consists of a series of 1 or more CBOR encoded | |
677 values. A CBOR value may be using indefinite length encoding. And the | |
678 bytes constituting the value may span several frames. | |
679 | |
680 The following flag values are defined for this type: | |
681 | |
682 0x01 | |
683 Data continuation. When set, an additional frame containing response data | |
684 will follow. | |
685 0x02 | |
686 End of data. When set, the response data has been fully sent and | |
687 no additional frames for this response will be sent. | |
688 | |
689 The ``0x01`` flag is mutually exclusive with the ``0x02`` flag. | |
690 | |
691 Error Occurred (``0x05``) | |
692 ------------------------- | |
693 | |
694 Some kind of error occurred. | |
695 | |
696 There are 3 general kinds of failures that can occur: | |
697 | |
698 * Command error encountered before any response issued | |
699 * Command error encountered after a response was issued | |
700 * Protocol or stream level error | |
701 | |
702 This frame type is used to capture the latter cases. (The general | |
703 command error case is handled by the leading CBOR map in | |
704 ``Command Response`` frames.) | |
705 | |
706 The payload of this frame contains a CBOR map detailing the error. That | |
707 map has the following bytestring keys: | |
708 | |
709 type | |
710 (bytestring) The overall type of error encountered. Can be one of the | |
711 following values: | |
712 | |
713 protocol | |
714 A protocol-level error occurred. This typically means someone | |
715 is violating the framing protocol semantics and the server is | |
716 refusing to proceed. | |
717 | |
718 server | |
719 A server-level error occurred. This typically indicates some kind of | |
720 logic error on the server, likely the fault of the server. | |
721 | |
722 command | |
723 A command-level error, likely the fault of the client. | |
724 | |
725 message | |
726 (array of maps) A richly formatted message that is intended for | |
727 human consumption. See the ``Human Output Side-Channel`` frame | |
728 section for a description of the format of this data structure. | |
729 | |
730 Human Output Side-Channel (``0x06``) | |
731 ------------------------------------ | |
732 | |
733 This frame contains a message that is intended to be displayed to | |
734 people. Whereas most frames communicate machine readable data, this | |
735 frame communicates textual data that is intended to be shown to | |
736 humans. | |
737 | |
738 The frame consists of a series of *formatting requests*. Each formatting | |
739 request consists of a formatting string, arguments for that formatting | |
740 string, and labels to apply to that formatting string. | |
741 | |
742 A formatting string is a printf()-like string that allows variable | |
743 substitution within the string. Labels allow the rendered text to be | |
744 *decorated*. Assuming use of the canonical Mercurial code base, a | |
745 formatting string can be the input to the ``i18n._`` function. This | |
746 allows messages emitted from the server to be localized. So even if | |
747 the server has different i18n settings, people could see messages in | |
748 their *native* settings. Similarly, the use of labels allows | |
749 decorations like coloring and underlining to be applied using the | |
750 client's configured rendering settings. | |
751 | |
752 Formatting strings are similar to ``printf()`` strings or how | |
753 Python's ``%`` operator works. The only supported formatting sequences | |
754 are ``%s`` and ``%%``. ``%s`` will be replaced by whatever the string | |
755 at that position resolves to. ``%%`` will be replaced by ``%``. All | |
756 other 2-byte sequences beginning with ``%`` represent a literal | |
757 ``%`` followed by that character. However, future versions of the | |
758 wire protocol reserve the right to allow clients to opt in to receiving | |
759 formatting strings with additional formatters, hence why ``%%`` is | |
760 required to represent the literal ``%``. | |
761 | |
762 The frame payload consists of a CBOR array of CBOR maps. Each map | |
763 defines an *atom* of text data to print. Each *atom* has the following | |
764 bytestring keys: | |
765 | |
766 msg | |
767 (bytestring) The formatting string. Content MUST be ASCII. | |
768 args (optional) | |
769 Array of bytestrings defining arguments to the formatting string. | |
770 labels (optional) | |
771 Array of bytestrings defining labels to apply to this atom. | |
772 | |
773 All data to be printed MUST be encoded into a single frame: this frame | |
774 does not support spanning data across multiple frames. | |
775 | |
776 All textual data encoded in these frames is assumed to be line delimited. | |
777 The last atom in the frame SHOULD end with a newline (``\n``). If it | |
778 doesn't, clients MAY add a newline to facilitate immediate printing. | |
779 | |
780 Progress Update (``0x07``) | |
781 -------------------------- | |
782 | |
783 This frame holds the progress of an operation on the peer. Consumption | |
784 of these frames allows clients to display progress bars, estimated | |
785 completion times, etc. | |
786 | |
787 Each frame defines the progress of a single operation on the peer. The | |
788 payload consists of a CBOR map with the following bytestring keys: | |
789 | |
790 topic | |
791 Topic name (string) | |
792 pos | |
793 Current numeric position within the topic (integer) | |
794 total | |
795 Total/end numeric position of this topic (unsigned integer) | |
796 label (optional) | |
797 Unit label (string) | |
798 item (optional) | |
799 Item name (string) | |
800 | |
801 Progress state is created when a frame is received referencing a | |
802 *topic* that isn't currently tracked. Progress tracking for that | |
803 *topic* is finished when a frame is received reporting the current | |
804 position of that topic as ``-1``. | |
805 | |
806 Multiple *topics* may be active at any given time. | |
807 | |
808 Rendering of progress information is not mandated or governed by this | |
809 specification: implementations MAY render progress information however | |
810 they see fit, including not at all. | |
811 | |
812 The string data describing the topic SHOULD be static strings to | |
813 facilitate receivers localizing that string data. The emitter | |
814 MUST normalize all string data to valid UTF-8 and receivers SHOULD | |
815 validate that received data conforms to UTF-8. The topic name | |
816 SHOULD be ASCII. | |
817 | |
818 Stream Encoding Settings (``0x08``) | |
819 ----------------------------------- | |
820 | |
821 This frame type holds information defining the content encoding | |
822 settings for a *stream*. | |
823 | |
824 This frame type is likely consumed by the protocol layer and is not | |
825 passed on to applications. | |
826 | |
827 This frame type MUST ONLY occur on frames having the *Beginning of Stream* | |
828 ``Stream Flag`` set. | |
829 | |
830 The payload of this frame defines what content encoding has (possibly) | |
831 been applied to the payloads of subsequent frames in this stream. | |
832 | |
833 The payload begins with an 8-bit integer defining the length of the | |
834 encoding *profile*, followed by the string name of that profile, which | |
835 must be an ASCII string. All bytes that follow can be used by that | |
836 profile for supplemental settings definitions. See the section below | |
837 on defined encoding profiles. | |
838 | |
839 Stream States and Flags | |
840 ----------------------- | |
841 | |
842 Streams can be in two states: *open* and *closed*. An *open* stream | |
843 is active and frames attached to that stream could arrive at any time. | |
844 A *closed* stream is not active. If a frame attached to a *closed* | |
845 stream arrives, that frame MUST have an appropriate stream flag | |
846 set indicating beginning of stream. All streams are in the *closed* | |
847 state by default. | |
848 | |
849 The ``Stream Flags`` field denotes a set of bit flags for defining | |
850 the relationship of this frame within a stream. The following flags | |
851 are defined: | |
852 | |
853 0x01 | |
854 Beginning of stream. The first frame in the stream MUST set this | |
855 flag. When received, the ``Stream ID`` this frame is attached to | |
856 becomes ``open``. | |
857 | |
858 0x02 | |
859 End of stream. The last frame in a stream MUST set this flag. When | |
860 received, the ``Stream ID`` this frame is attached to becomes | |
861 ``closed``. Any content encoding context associated with this stream | |
862 can be destroyed after processing the payload of this frame. | |
863 | |
864 0x04 | |
865 Apply content encoding. When set, any content encoding settings | |
866 defined by the stream should be applied when attempting to read | |
867 the frame. When not set, the frame payload isn't encoded. | |
868 | |
869 Streams | |
870 ------- | |
871 | |
872 Streams - along with ``Request IDs`` - facilitate grouping of frames. | |
873 But the purpose of each is quite different and the groupings they | |
874 constitute are independent. | |
875 | |
876 A ``Request ID`` is essentially a tag. It tells you which logical | |
877 request a frame is associated with. | |
878 | |
879 A *stream* is a sequence of frames grouped for the express purpose | |
880 of applying a stateful encoding or for denoting sub-groups of frames. | |
881 | |
882 Unlike ``Request ID``s which span the request and response, a stream | |
883 is unidirectional and stream IDs are independent from client to | |
884 server. | |
885 | |
886 There is no strict hierarchical relationship between ``Request IDs`` | |
887 and *streams*. A stream can contain frames having multiple | |
888 ``Request IDs``. Frames belonging to the same ``Request ID`` can | |
889 span multiple streams. | |
890 | |
891 One goal of streams is to facilitate content encoding. A stream can | |
892 define an encoding to be applied to frame payloads. For example, the | |
893 payload transmitted over the wire may contain output from a | |
894 zstandard compression operation and the receiving end may decompress | |
895 that payload to obtain the original data. | |
896 | |
897 The other goal of streams is to facilitate concurrent execution. For | |
898 example, a server could spawn 4 threads to service a request that can | |
899 be easily parallelized. Each of those 4 threads could write into its | |
900 own stream. Those streams could then in turn be delivered to 4 threads | |
901 on the receiving end, with each thread consuming its stream in near | |
902 isolation. The *main* thread on both ends merely does I/O and | |
903 encodes/decodes frame headers: the bulk of the work is done by worker | |
904 threads. | |
905 | |
906 In addition, since content encoding is defined per stream, each | |
907 *worker thread* could perform potentially CPU bound work concurrently | |
908 with other threads. This approach of applying encoding at the | |
909 sub-protocol / stream level eliminates a potential resource constraint | |
910 on the protocol stream as a whole (it is common for the throughput of | |
911 a compression engine to be smaller than the throughput of a network). | |
912 | |
913 Having multiple streams - each with their own encoding settings - also | |
914 facilitates the use of advanced data compression techniques. For | |
915 example, a transmitter could see that it is generating data faster | |
916 and slower than the receiving end is consuming it and adjust its | |
917 compression settings to trade CPU for compression ratio accordingly. | |
918 | |
919 While streams can define a content encoding, not all frames within | |
920 that stream must use that content encoding. This can be useful when | |
921 data is being served from caches and being derived dynamically. A | |
922 cache could pre-compressed data so the server doesn't have to | |
923 recompress it. The ability to pick and choose which frames are | |
924 compressed allows servers to easily send data to the wire without | |
925 involving potentially expensive encoding overhead. | |
926 | |
927 Content Encoding Profiles | |
928 ------------------------- | |
929 | |
930 Streams can have named content encoding *profiles* associated with | |
931 them. A profile defines a shared understanding of content encoding | |
932 settings and behavior. | |
933 | |
934 The following profiles are defined: | |
935 | |
936 TBD | |
937 | |
938 Command Protocol | |
939 ---------------- | |
940 | |
941 A client can request that a remote run a command by sending it | |
942 frames defining that command. This logical stream is composed of | |
943 1 or more ``Command Request`` frames and and 0 or more ``Command Data`` | |
944 frames. | |
945 | |
946 All frames composing a single command request MUST be associated with | |
947 the same ``Request ID``. | |
948 | |
949 Clients MAY send additional command requests without waiting on the | |
950 response to a previous command request. If they do so, they MUST ensure | |
951 that the ``Request ID`` field of outbound frames does not conflict | |
952 with that of an active ``Request ID`` whose response has not yet been | |
953 fully received. | |
954 | |
955 Servers MAY respond to commands in a different order than they were | |
956 sent over the wire. Clients MUST be prepared to deal with this. Servers | |
957 also MAY start executing commands in a different order than they were | |
958 received, or MAY execute multiple commands concurrently. | |
959 | |
960 If there is a dependency between commands or a race condition between | |
961 commands executing (e.g. a read-only command that depends on the results | |
962 of a command that mutates the repository), then clients MUST NOT send | |
963 frames issuing a command until a response to all dependent commands has | |
964 been received. | |
965 TODO think about whether we should express dependencies between commands | |
966 to avoid roundtrip latency. | |
967 | |
968 A command is defined by a command name, 0 or more command arguments, | |
969 and optional command data. | |
970 | |
971 Arguments are the recommended mechanism for transferring fixed sets of | |
972 parameters to a command. Data is appropriate for transferring variable | |
973 data. Thinking in terms of HTTP, arguments would be headers and data | |
974 would be the message body. | |
975 | |
976 It is recommended for servers to delay the dispatch of a command | |
977 until all argument have been received. Servers MAY impose limits on the | |
978 maximum argument size. | |
979 TODO define failure mechanism. | |
980 | |
981 Servers MAY dispatch to commands immediately once argument data | |
982 is available or delay until command data is received in full. | |
983 | |
984 Once a ``Command Request`` frame is sent, a client must be prepared to | |
985 receive any of the following frames associated with that request: | |
986 ``Command Response``, ``Error Response``, ``Human Output Side-Channel``, | |
987 ``Progress Update``. | |
988 | |
989 The *main* response for a command will be in ``Command Response`` frames. | |
990 The payloads of these frames consist of 1 or more CBOR encoded values. | |
991 The first CBOR value on the first ``Command Response`` frame is special | |
992 and denotes the overall status of the command. This CBOR map contains | |
993 the following bytestring keys: | |
994 | |
995 status | |
996 (bytestring) A well-defined message containing the overall status of | |
997 this command request. The following values are defined: | |
998 | |
999 ok | |
1000 The command was received successfully and its response follows. | |
1001 error | |
1002 There was an error processing the command. More details about the | |
1003 error are encoded in the ``error`` key. | |
1004 | |
1005 error (optional) | |
1006 A map containing information about an encountered error. The map has the | |
1007 following keys: | |
1008 | |
1009 message | |
1010 (array of maps) A message describing the error. The message uses the | |
1011 same format as those in the ``Human Output Side-Channel`` frame. | |
1012 | 515 |
1013 Capabilities | 516 Capabilities |
1014 ============ | 517 ============ |
1015 | 518 |
1016 Servers advertise supported wire protocol features. This allows clients to | 519 Servers advertise supported wire protocol features. This allows clients to |