##// END OF EJS Templates
help: document wire protocol "handshake" protocol...
Gregory Szorc -
r29864:f0d47aca default
parent child Browse files
Show More
@@ -368,3 +368,50 b' indicating which bundle types the server'
368 comma-delimited list. e.g. ``HG10GZ,HG10BZ,HG10UN``. The order of values
368 comma-delimited list. e.g. ``HG10GZ,HG10BZ,HG10UN``. The order of values
369 reflects the priority/preference of that type, where the first value is the
369 reflects the priority/preference of that type, where the first value is the
370 most preferred type.
370 most preferred type.
371
372 Handshake Protocol
373 ==================
374
375 While not explicitly required, it is common for clients to perform a
376 *handshake* when connecting to a server. The handshake accomplishes 2 things:
377
378 * Obtaining capabilities and other server features
379 * Flushing extra server output (e.g. SSH servers may print extra text
380 when connecting that may confuse the wire protocol)
381
382 This isn't a traditional *handshake* as far as network protocols go because
383 there is no persistent state as a result of the handshake: the handshake is
384 simply the issuing of commands and commands are stateless.
385
386 The canonical clients perform a capabilities lookup at connection establishment
387 time. This is because clients must assume a server only supports the features
388 of the original Mercurial server implementation until proven otherwise (from
389 advertised capabilities). Nearly every server running today supports features
390 that weren't present in the original Mercurial server implementation. Rather
391 than wait for a client to perform functionality that needs to consult
392 capabilities, it issues the lookup at connection start to avoid any delay later.
393
394 For HTTP servers, the client sends a ``capabilities`` command request as
395 soon as the connection is established. The server responds with a capabilities
396 string, which the client parses.
397
398 For SSH servers, the client sends the ``hello`` command (no arguments)
399 and a ``between`` command with the ``pairs`` argument having the value
400 ``0000000000000000000000000000000000000000-0000000000000000000000000000000000000000``.
401
402 The ``between`` command has been supported since the original Mercurial
403 server. Requesting the empty range will return a ``\n`` string response,
404 which will be encoded as ``1\n\n`` (value length of ``1`` followed by a newline
405 followed by the value, which happens to be a newline).
406
407 The ``hello`` command was later introduced. Servers supporting it will issue
408 a response to that command before sending the ``1\n\n`` response to the
409 ``between`` command. Servers not supporting ``hello`` will send an empty
410 response (``0\n``).
411
412 In addition to the expected output from the ``hello`` and ``between`` commands,
413 servers may also send other output, such as *message of the day (MOTD)*
414 announcements. Clients assume servers will send this output before the
415 Mercurial server replies to the client-issued commands. So any server output
416 not conforming to the expected command responses is assumed to be not related
417 to Mercurial and can be ignored.
General Comments 0
You need to be logged in to leave comments. Login now