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