[PATCH] Fix typos in the distribution handshake doc

[Michael Santos]

---
 lib/kernel/internal_doc/distribution_handshake.txt |   38 ++++++++++----------
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/lib/kernel/internal_doc/distribution_handshake.txt b/lib/kernel/internal_doc/distribution_handshake.txt
index f64ebe0..aea290f 100644
--- a/lib/kernel/internal_doc/distribution_handshake.txt
+++ b/lib/kernel/internal_doc/distribution_handshake.txt
@@ -11,7 +11,7 @@ The TCP/IP distribution uses a handshake which expects a
 connection based protocol, i.e. the protocol does not include
 any authentication after the handshake procedure.
 
-This is not entirelly safe, as it is vulnerable against takeover
+This is not entirely safe, as it is vulnerable against takeover
 attacks, but it is a tradeoff between fair safety and performance.
 
 The cookies are never sent in cleartext and the handshake procedure
@@ -23,7 +23,7 @@ random numbers.
 DEFINITIONS
 -----------
 
-A challenge is a 32 bit integer number in big endian. Below the function
+A challenge is a 32 bit integer number in big endian order. Below the function
 gen_challenge() returns a random 32 bit integer used as a challenge.
 
 A digest is a (16 bytes) MD5 hash of [the Challenge (as text) concatenated
@@ -46,19 +46,19 @@ The cookies are text strings that can be viewed as passwords.
 Every message in the handshake starts with a 16 bit big endian integer 
 which contains the length of the message (not counting the two initial bytes).
 In erlang this corresponds to the gen_tcp option {packet, 2}. Note that after 
-the handshake, the distribution switches to 4 byte backet headers.
+the handshake, the distribution switches to 4 byte packet headers.
 
 THE HANDSHAKE IN DETAIL
 -----------------------
  
-Imagine two nodes, node A, which initiates the handshake and node B, whitch
+Imagine two nodes, node A, which initiates the handshake and node B, which
 accepts the connection.
 
 1) connect/accept: A connects to B via TCP/IP and B accepts the connection.
 
 2) send_name/receive_name: A sends an initial identification to B. 
 B receives the message. The message looks
-like this (every "square" beeing one byte and the packet header removed):
+like this (every "square" being one byte and the packet header removed):
 
 +---+--------+--------+-----+-----+-----+-----+-----+-----+-...-+-----+
 |'n'|Version0|Version1|Flag0|Flag1|Flag2|Flag3|Name0|Name1| ... |NameN|
@@ -67,7 +67,7 @@ like this (every "square" beeing one byte and the packet header removed):
 The 'n' is just a message tag,
 Version0 & Version1 is the distribution version selected by node A,
                     based on information from EPMD. (16 bit big endian)
-Flag0 ... Flag3 is capability flags, the capabilities defined in dist.hrl.
+Flag0 ... Flag3 are capability flags, the capabilities defined in dist.hrl.
                 (32 bit big endian)
 Name0 ... NameN is the full nodename of A, as a string of bytes (the
                 packet length denotes how long it is).
@@ -91,9 +91,9 @@ alive: A connection to the node is already active, which either means
 
 This is the format of the status message:
 
-+---+-------+-------+ ... +-------+
++---+-------+-------+-...-+-------+
 |'s'|Status0|Status1| ... |StatusN|
-+---+-------+-------+ ... +-------+
++---+-------+-------+-...-+-------+
 
 's' is the message tag
 Status0 ... StatusN is the status as a string (not terminated)
@@ -111,35 +111,35 @@ initially sent from A to B, with the addition of a 32 bit challenge:
 
 +---+--------+--------+-----+-----+-----+-----+-----+-----+-----+-----+---
 |'n'|Version0|Version1|Flag0|Flag1|Flag2|Flag3|Chal0|Chal1|Chal2|Chal3|
-+---+--------+--------+-----+-----+-----+-----+-----+-----+---- +-----+---
++---+--------+--------+-----+-----+-----+-----+-----+-----+-----+-----+---
    ------+-----+-...-+-----+
     Name0|Name1| ... |NameN|
    ------+-----+-... +-----+
 
-Where Chal0 ... Chal3 is the challenge as a 32 bit biog endian integer
+Where Chal0 ... Chal3 is the challenge as a 32 bit big endian integer
 and the other fields are B's version, flags and full nodename.
 
 5) send_challenge_reply/recv_challenge_reply: Now A has generated
 a digest and it's own challenge. Those are sent together in a package
 to B:
 
-+---+-----+-----+-----+-----+-----+-----+-----+-----+
-|'r'|Chal0|Chal1|Chal2|Chal3|Dige0|Dige1|Dige2|Dige3|
-+---+-----+-----+-----+-----+-----+-----+---- +-----+
++---+-----+-----+-----+-----+-----+-----+-----+-----+-...-+------+
+|'r'|Chal0|Chal1|Chal2|Chal3|Dige0|Dige1|Dige2|Dige3| ... |Dige15|
++---+-----+-----+-----+-----+-----+-----+-----+-----+-...-+------+
 
 Where 'r' is the tag, Chal0 ... Chal3 is A's challenge for B to handle and
-Dige0 ... Dige3 is the digest that A constructed from the challenge B sent
+Dige0 ... Dige15 is the digest that A constructed from the challenge B sent
 in the previous step.
 
 6) recv_challenge_ack/send_challenge_ack: B checks that the digest received
 from A is correct and generates a digest from the challenge received from 
 A. The digest is then sent to A. The message looks like this:
 
-+---+-----+-----+-----+-----+
-|'a'|Dige0|Dige1|Dige2|Dige3|
-+---+-----+-----+---- +-----+
++---+-----+-----+-----+-----+-...-+------+
+|'a'|Dige0|Dige1|Dige2|Dige3| ... |Dige15|
++---+-----+-----+-----+-----+-...-+------+
 
-Where 'a' is the tag and Dige0 ... Dige3 is the digest calculated by B
+Where 'a' is the tag and Dige0 ... Dige15 is the digest calculated by B
 for A's challenge.
 
 7) A checks the digest from B and the connection is up.
@@ -206,7 +206,7 @@ Currently the following capability flags are defined:
 %% The node implements distributed process monitoring.
 -define(DFLAG_DIST_MONITOR,8).
  
-%% The node uses separate tag for fun's (labmdas) in the distribution protocol.
+%% The node uses separate tag for fun's (lambdas) in the distribution protocol.
 -define(DFLAG_FUN_TAGS,16).
  
 An R6 erlang node implements all of the above, while a C or Java node only
-- 
1.7.0.4