| Author |
Message |
|
| Guest |
 Posted: Thu Jul 22, 2010 12:45 am |
 |
|
|
Guest
|
---
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, .
-%% 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
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Jul 22, 2010 12:45 am |
|
|
|
Guest
|
---
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,.
-%% 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
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
