Erlang 21 - 13. Distribution Protocol

13 वितरण प्रोटोकॉल




erlang

13 वितरण प्रोटोकॉल

यह वर्णन पूर्ण से दूर है। प्रोटोकॉल अपडेट होने पर इसे अपडेट किया जाएगा। हालाँकि, प्रोटोकॉल, दोनों Erlang नोड्स से Erlang Port Mapper Daemon (EPMD) और Erlang नोड्स के बीच कई वर्षों से स्थिर हैं।

वितरण प्रोटोकॉल को चार भागों में विभाजित किया जा सकता है:

  • निम्न-स्तरीय सॉकेट कनेक्शन (1)

  • हैंडशेक, इंटरचेंज नोड नाम और प्रमाणित (2)

  • प्रमाणीकरण ( net_kernel(3) द्वारा किया गया) (3)

  • कनेक्टेड (4)

एक नोड कनेक्शन अनुरोध आरंभ करने के लिए EPMD (दूसरे होस्ट पर) के माध्यम से दूसरे नोड का पोर्ट नंबर प्राप्त करता है।

प्रत्येक मेजबान के लिए, जहां एक वितरित एर्लांग नोड चल रहा है, एक ईपीएमडी भी चलना है। ईपीएमडी को स्पष्ट रूप से या स्वचालित रूप से एर्लांग नोड स्टार्टअप के परिणामस्वरूप शुरू किया जा सकता है।

डिफ़ॉल्ट रूप से EPMD पोर्ट 4369 पर सुनता है।

(3) और (4) ऊपर एक ही स्तर पर प्रदर्शन किया जाता है, लेकिन अगर कोई अमान्य कुकी (1 सेकंड के बाद) का उपयोग करता है तो net_kernel दूसरे नोड को डिस्कनेक्ट करता है।

सभी मल्टीबाइट फ़ील्ड में पूर्णांक बड़े-एंडियन क्रम में हैं।

चेतावनी

एर्लांग वितरण प्रोटोकॉल स्वयं सुरक्षित नहीं है और ऐसा करने का लक्ष्य नहीं है। सुरक्षित वितरण प्राप्त करने के लिए वितरित नोड्स को टीलों पर वितरण का उपयोग करने के लिए कॉन्फ़िगर किया जाना चाहिए। सुरक्षित वितरित नोड को सेटअप करने के तरीके के विवरण के Using SSL for Erlang Distribution उपयोगकर्ता की मार्गदर्शिका के लिए Using SSL for Erlang Distribution देखें।

13.1 ईपीएमडी प्रोटोकॉल

ईपीएमडी द्वारा दिए गए अनुरोधों को निम्नलिखित आंकड़ों में संक्षेपित किया गया है।

चित्र 13.1: ईपीएमडी अनुरोधों का सारांश

प्रत्येक अनुरोध *_REQ एक 2 बाइट लंबाई क्षेत्र से पहले है। इस प्रकार, समग्र अनुरोध प्रारूप इस प्रकार है:

2 n
Length Request

तालिका 13.1: प्रारूप का अनुरोध करें

ईपीएमडी में एक नोड पंजीकृत करें

जब एक वितरित नोड शुरू किया जाता है तो यह ईपीएमडी में खुद को पंजीकृत करता है। नीचे वर्णित ALIVE2_REQ संदेश नोड से EPMD को भेजा गया है। EPMD की प्रतिक्रिया ALIVE2_RESP

1 2 1 1 2 2 2 Nlen 2 Elen
120 PortNo NodeType Protocol HighestVersion LowestVersion Nlen NodeName Elen Extra

तालिका 13.2: ALIVE2_REQ (120)

PortNo

पोर्ट संख्या जिस पर नोड कनेक्शन अनुरोधों को स्वीकार करता है।

NodeType

77 = सामान्य एरलांग नोड, 72 = छिपा नोड (सी-नोड), ...

Protocol

0 = टीसीपी / आईपीवी 4, ...

HighestVersion

उच्चतम वितरण संस्करण जो इस नोड को संभाल सकता है। Erlang / OTP R6B में मूल्य और बाद में 5 है।

LowestVersion

सबसे कम वितरण संस्करण जिसे यह नोड संभाल सकता है। Erlang / OTP R6B में मूल्य और बाद में 5 है।

Nlen

क्षेत्र NodeName की लंबाई (बाइट्स में)।

NodeName

नोड नाम UTF-8 Nlen बाइट्स के एन्कोडेड स्ट्रिंग के Nlen

Elen

क्षेत्र की लंबाई Extra

Extra

Elen बाइट्स का अतिरिक्त क्षेत्र।

EPMD में बनाया गया कनेक्शन तब तक रखा जाना चाहिए जब तक नोड एक वितरित नोड है। जब कनेक्शन बंद हो जाता है, तो नोड स्वचालित रूप से EPMD से अपंजीकृत होता है।

प्रतिक्रिया संदेश ALIVE2_RESP इस प्रकार है:

1 1 2
121 Result Creation

तालिका 13.3: ALIVE2_RESP (121)

परिणाम = 0 -> ठीक है, परिणाम> 0 -> त्रुटि।

EPMD से एक नोड अनरजिस्टर्ड करें

नोड नोड पंजीकृत होने पर ईपीएमडी के लिए टीसीपी कनेक्शन को बंद करके ईपीएमडी से खुद को हटा देता है।

दूसरे नोड का वितरण पोर्ट प्राप्त करें

जब एक नोड दूसरे नोड से कनेक्ट करना चाहता है तो यह होस्ट पर EPMD के लिए PORT_PLEASE2_REQ अनुरोध के साथ शुरू होता है जहां नोड वितरण पोर्ट को प्राप्त करने के लिए रहता है जिसे नोड सुनता है।

1 एन
122 NodeName

तालिका 13.4: PORT_PLEASE2_REQ (122)

जहां एन = Length - 1।

1 1
119 Result

तालिका 13.5: PORT2_RESP (119) प्रतिक्रिया इंगित करने में त्रुटि, परिणाम> 0

या

1 1 2 1 1 2 2 2 Nlen 2 Elen
119 Result PortNo NodeType Protocol HighestVersion LowestVersion Nlen NodeName Elen > Extra

तालिका 13.6: PORT2_RESP, परिणाम = 0

यदि Result > 0, पैकेट में केवल [119, Result] होते हैं।

ईपीएमडी ने सॉकेट बंद कर दिया जब उसने सूचना भेजी।

ईपीएमडी से सभी पंजीकृत नाम प्राप्त करें

यह अनुरोध Erlang फ़ंक्शन net_adm:names/1,2 माध्यम से उपयोग किया जाता है। एक TCP कनेक्शन EPMD के लिए खोला जाता है और यह अनुरोध भेजा जाता है।

1
110

तालिका 13.7: NAMES_REQ (110)

NAMES_REQ की प्रतिक्रिया इस प्रकार है:

4
EPMDPortNo NodeInfo*

तालिका 13.8: NAMES_RESP

NodeInfo प्रत्येक सक्रिय नोड के लिए लिखा गया एक स्ट्रिंग है। जब सभी NodeInfo को लिखा गया है तो कनेक्शन EPMD द्वारा बंद कर दिया गया है।

NodeInfo है, जैसा कि NodeInfo में व्यक्त किया गया है:

io:format("name ~ts at port ~p~n", [NodeName, Port]).

EPMD से सभी डेटा को डंप करें

यह अनुरोध वास्तव में उपयोग नहीं किया गया है, इसे डिबग सुविधा के रूप में माना जाना है।

1
100

तालिका 13.9: DUMP_REQ

DUMP_REQ की प्रतिक्रिया इस प्रकार है:

4
EPMDPortNo NodeInfo*

तालिका 13.10: DUMP_RESP

NodeInfo EPMD में रखे गए प्रत्येक नोड के लिए लिखा गया एक स्ट्रिंग है। जब सभी NodeInfo को लिखा गया है तो कनेक्शन EPMD द्वारा बंद कर दिया गया है।

NodeInfo है, जैसा कि NodeInfo में व्यक्त किया गया है:

io:format("active name     ~ts at port ~p, fd = ~p~n",
          [NodeName, Port, Fd]).

या

io:format("old/unused name ~ts at port ~p, fd = ~p ~n",
          [NodeName, Port, Fd]).

ईपीएमडी को मार डालो

यह अनुरोध चल रहे EPMD को मारता है। इसका उपयोग लगभग कभी नहीं किया जाता है।

1
107

तालिका 13.11: KILL_REQ

KILL_REQ की प्रतिक्रिया इस प्रकार है:

2
OKString

तालिका 13.12: KILL_RESP

जहां OKString "ओके" है।

STOP_REQ (प्रयुक्त नहीं)

1 n
115 NodeName

तालिका 13.13: STOP_REQ

जहां n = Length - 1।

ईपीएमडी से संबंध टूट जाने पर एर्लैंग का वर्तमान कार्यान्वयन परवाह नहीं करता है।

STOP_REQ की प्रतिक्रिया इस प्रकार है:

7
OKString

तालिका 13.14: STOP_RESP

जहां OKString " OKString " है।

एक नकारात्मक प्रतिक्रिया निम्नानुसार हो सकती है:

7
NOKString

तालिका 13.15: STOP_NOTOK_RESP

जहाँ NOKString "NOEXIST" है।

13.2 वितरण हैंडशेक

यह खंड एर्लांग / ओटीपी आर 6 में शुरू किए गए वितरण हैंडशेक प्रोटोकॉल का वर्णन करता है। यह विवरण पहले $ERL_TOP/lib/kernel/internal_doc/distribution_handshake.txt में स्थित था और कमोबेश कॉपी किया गया है और यहाँ "स्वरूपित" किया गया है। यह 1999 के बाद से लगभग अपरिवर्तित है, लेकिन हैंडशेक तब से बहुत अधिक नहीं बदला है।

सामान्य

टीसीपी / आईपी वितरण एक हैंडशेक का उपयोग करता है जो कनेक्शन-आधारित प्रोटोकॉल की अपेक्षा करता है, अर्थात, हैंडशेक प्रक्रिया के बाद प्रोटोकॉल में कोई प्रमाणीकरण शामिल नहीं है।

यह पूरी तरह से सुरक्षित नहीं है, क्योंकि यह टेकओवर हमलों के खिलाफ कमजोर है, लेकिन यह निष्पक्ष सुरक्षा और प्रदर्शन के बीच एक व्यापार है।

कुकीज को कभी भी क्लीयरटेक्स्ट में नहीं भेजा जाता है और हैंडशेक प्रक्रिया क्लाइंट ( A ) कहलाती है, यह साबित करने के लिए कि वह पर्याप्त डाइजेस्ट उत्पन्न कर सकती है। पाचन एमडी 5 संदेश डाइजेस्ट एल्गोरिथ्म के साथ उत्पन्न होता है और चुनौतियों को यादृच्छिक संख्या होने की उम्मीद है।

परिभाषाएं

एक चुनौती बड़े-एंडियन क्रम में 32-बिट पूर्णांक है। फ़ंक्शन के नीचे gen_challenge() एक यादृच्छिक 32-बिट पूर्णांक को एक चुनौती के रूप में उपयोग करता है।

एक पाचन एक (16 बाइट्स) है एमडी 5 हैश की चुनौती (पाठ के रूप में) कुकी के साथ संक्षिप्त (पाठ के रूप में)। नीचे, फ़ंक्शन gen_digest(Challenge, Cookie) एक पाचन उत्पन्न करता है जैसा कि ऊपर वर्णित है।

एक out_cookie एक निश्चित नोड के लिए आउटगोइंग संचार में उपयोग की जाने वाली कुकी है, ताकि A का out_cookie B लिए A और इसके विपरीत के साथ B के in_cookie अनुरूप हो। B लिए A का out_cookie और B लिए A का in_cookie समान नहीं होना चाहिए। फ़ंक्शन के नीचे out_cookie(Node) वर्तमान नोड के out_cookie को Node लिए out_cookie है।

एक in_cookie हमारे साथ संचार करते समय किसी अन्य नोड द्वारा उपयोग की जाने वाली कुकी है, ताकि B लिए A का in_cookie A के लिए B in_cookie से मेल खाता हो। फ़ंक्शन के नीचे in_cookie(Node) नोड के लिए वर्तमान नोड का in_cookie है।

कुकीज़ टेक्स्ट स्ट्रिंग्स हैं जिन्हें पासवर्ड के रूप में देखा जा सकता है।

हैंडशेक में प्रत्येक संदेश 16-बिट बड़े-एंडियन पूर्णांक से शुरू होता है, जिसमें संदेश की लंबाई (दो प्रारंभिक बाइट्स की गिनती नहीं) होती है। gen_tcp(3) में यह gen_tcp(3) में विकल्प {packet, 2} से gen_tcp(3) । ध्यान दें कि हैंडशेक के बाद, वितरण 4 बाइट पैकेट हेडर पर स्विच करता है।

हैंडशेक डिटेल में

दो नोड्स की कल्पना करें, A जो हैंडशेक शुरू करता है और B जो कनेक्शन स्वीकार करता है।

1) कनेक्ट / स्वीकार करते हैं

टीसीपी / आईपी के माध्यम से B कनेक्ट होता है और B कनेक्शन स्वीकार करता है।

2) send_name / receive_name

A , B को एक प्रारंभिक पहचान भेजता है, जो संदेश प्राप्त करता है। यह संदेश निम्नानुसार है (प्रत्येक "वर्ग" एक बाइट है और पैकेट हैडर हटा दिया गया है):

+---+--------+--------+-----+-----+-----+-----+-----+-----+-...-+-----+
|'n'|Version0|Version1|Flag0|Flag1|Flag2|Flag3|Name0|Name1| ... |NameN|
+---+--------+--------+-----+-----+-----+-----+-----+-----+-... +-----+

'n' संदेश टैग है। 'वर्जन 0' और 'वर्जन 1' A द्वारा चयनित वितरण संस्करण है, जो ईपीएमडी की जानकारी पर आधारित है। (16-बिट बिग-एंडियन) 'फ्लैग0' ... 'फ्लैग 3' क्षमता के झंडे हैं, क्षमताओं को $ERL_TOP/lib/kernel/include/dist.hrl । (32-बिट बिग-एंडियन) 'Name0' ... 'NameN' A का पूरा नोड नाम है, बाइट्स के एक स्ट्रिंग के रूप में (पैकेट की लंबाई दर्शाता है कि यह कितनी देर है)।

3) recv_status / send_status

B A को एक स्थिति संदेश भेजता है, जो इंगित करता है कि क्या कनेक्शन की अनुमति है। निम्नलिखित स्थिति कोड परिभाषित किए गए हैं:

ok

हाथ मिलाना जारी रहेगा।

ok_simultaneous

हैंडशेक जारी रहेगा, लेकिन A को सूचित किया जाता है कि B में एक और चल रहा कनेक्शन प्रयास है जो बंद हो जाएगा (साथ ही कनेक्ट जहां A का नाम शाब्दिक रूप से B नाम से अधिक है)।

nok

हैंडशेक जारी नहीं रहेगा, क्योंकि B पहले से ही एक हैंडशेक चल रहा है, जिसे उसने खुद शुरू किया है (साथ ही कनेक्ट जहां B का नाम A 'एस से अधिक है)।

not_allowed

कनेक्शन को कुछ (अनिर्दिष्ट) सुरक्षा कारणों से अस्वीकृत कर दिया गया है।

alive

नोड के लिए एक कनेक्शन पहले से ही सक्रिय है, जिसका अर्थ है कि नोड A भ्रमित है या कि इस नाम के साथ पिछले नोड का टीसीपी कनेक्शन टूटना अभी तक नोड B तक नहीं पहुंचा है। नीचे चरण 3B देखें।

स्थिति संदेश का प्रारूप इस प्रकार है:

+---+-------+-------+-...-+-------+
|'s'|Status0|Status1| ... |StatusN|
+---+-------+-------+-...-+-------+

's' संदेश टैग है। 'Status0' ... 'StatusN' एक स्ट्रिंग के रूप में स्थिति है (समाप्त नहीं)।

3B) send_status / recv_status

यदि स्थिति alive थी, तो नोड A और स्थिति संदेश के साथ A उत्तर देता है जिसमें कोई भी true , जिसका अर्थ है कि कनेक्शन जारी रखना है (इस नोड से पुराना कनेक्शन टूट गया है), या false , जिसका अर्थ है कि कनेक्शन बंद होना है (कनेक्शन प्रयास एक गलती थी।

4) recv_challenge / send_challenge

यदि स्थिति ok या ok_simultaneous , हैंडशेक B साथ जारी रहता है तो A अन्य संदेश, चुनौती। इस चुनौती में एक ही प्रकार की जानकारी होती है जैसे "नाम" संदेश शुरू में A से B तक भेजा जाता है, साथ ही 32-बिट चुनौती:

+---+--------+--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-...-+-----+
|'n'|Version0|Version1|Flag0|Flag1|Flag2|Flag3|Chal0|Chal1|Chal2|Chal3|Name0|Name1| ... |NameN|
+---+--------+--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-... +-----+

'Chal0' ... 'Chal3' एक 32-बिट बड़े-एंडियन पूर्णांक के रूप में चुनौती है और अन्य फ़ील्ड B का संस्करण, ध्वज और पूर्ण नोड नाम हैं।

5) send_challenge_reply / recv_challenge_reply

अब A ने एक पाचन और अपनी चुनौती उत्पन्न की है। इन्हें B पैकेज में एक साथ भेजा जाता है:

+---+-----+-----+-----+-----+-----+-----+-----+-----+-...-+------+
|'r'|Chal0|Chal1|Chal2|Chal3|Dige0|Dige1|Dige2|Dige3| ... |Dige15|
+---+-----+-----+-----+-----+-----+-----+-----+-----+-...-+------+

'r' टैग है। 'Chal0' ... 'Chal3' B को संभालने के लिए A की चुनौती है। 'Dige0' ... 'Dige15' एक ऐसा डाइजेस्ट है जिसे A ने पिछले चरण में भेजे गए चैलेंज B से बनाया है।

6) recv_challenge_ack / send_challenge_ack

B जाँचता है कि A से प्राप्त पाचन सही है और A से प्राप्त चुनौती से एक पाचन उत्पन्न करता है। फिर पाचन A भेजा जाता है। संदेश इस प्रकार है:

+---+-----+-----+-----+-----+-...-+------+
|'a'|Dige0|Dige1|Dige2|Dige3| ... |Dige15|
+---+-----+-----+-----+-----+-...-+------+

'ए' टैग है। 'Dige0' ... 'Dige15' A की चुनौती के लिए B द्वारा पचाया गया पाचन है।

7) जाँच करें

A , B से पाचन की जाँच करता है और कनेक्शन समाप्त हो जाता है।

अर्धवृत्त दृश्य

A (initiator)                                      B (acceptor)

TCP connect ------------------------------------>
                                                   TCP accept

send_name -------------------------------------->
                                                   recv_name

  <---------------------------------------------- send_status
recv_status
(if status was 'alive'
 send_status - - - - - - - - - - - - - - - - - ->
                                                   recv_status)
                                                   ChB = gen_challenge()
                          (ChB)
  <---------------------------------------------- send_challenge
recv_challenge
ChA = gen_challenge(),
OCA = out_cookie(B),
DiA = gen_digest(ChB, OCA)
                          (ChA, DiA)
send_challenge_reply --------------------------->
                                                   recv_challenge_reply
                                                   ICB = in_cookie(A),
                                                   check:
                                                   DiA == gen_digest (ChB, ICB)?
                                                   - if OK:
                                                    OCB = out_cookie(A),
                                                    DiB = gen_digest (ChA, OCB)
                          (DiB)
  <----------------------------------------------- send_challenge_ack
recv_challenge_ack                                  DONE
ICA = in_cookie(B),                                - else:
check:                                              CLOSE
DiB == gen_digest(ChA, ICA)?
- if OK:
 DONE
- else:
 CLOSE

वितरण झंडे

निम्नलिखित क्षमता झंडे परिभाषित किए गए हैं:

-define(DFLAG_PUBLISHED,16#1).

नोड को प्रकाशित किया जाना है और वैश्विक नामस्थान का हिस्सा है।

-define(DFLAG_ATOM_CACHE,16#2).

नोड एक परमाणु कैश (अप्रचलित) को लागू करता है।

-define(DFLAG_EXTENDED_REFERENCES,16#4).

नोड का विस्तार (3 × 32 बिट्स) संदर्भों को लागू करता है। आज इसकी आवश्यकता है। यदि मौजूद नहीं है, तो कनेक्शन से इनकार कर दिया जाता है।

-define(DFLAG_DIST_MONITOR,16#8).

नोड कार्यान्वयन ने प्रक्रिया की निगरानी वितरित की।

-define(DFLAG_FUN_TAGS,16#10).

नोड वितरण प्रोटोकॉल में फ़न (लैम्ब्डा) के लिए अलग टैग का उपयोग करता है।

-define(DFLAG_DIST_MONITOR_NAME,16#20).

नोड अनुलिपि को प्रक्रिया निगरानी नाम दिया गया।

-define(DFLAG_HIDDEN_ATOM_CACHE,16#40).

(छिपा हुआ) नोड एटम कैश (अप्रचलित) को लागू करता है।

-define(DFLAG_NEW_FUN_TAGS,16#80).

नोड नए मजेदार टैग को समझते हैं।

-define(DFLAG_EXTENDED_PIDS_PORTS,16#100).

नोड विस्तारित pids और पोर्ट को संभाल सकता है। आज इसकी आवश्यकता है। यदि मौजूद नहीं है, तो कनेक्शन से इनकार कर दिया जाता है।

-define(DFLAG_EXPORT_PTR_TAG,16#200).
-define(DFLAG_BIT_BINARIES,16#400).
-define(DFLAG_NEW_FLOATS,16#800).

नोड नए फ्लोट प्रारूप को समझता है।

-define(DFLAG_UNICODE_IO,16#1000).
-define(DFLAG_DIST_HDR_ATOM_CACHE,16#2000).

नोड वितरण हैडर में एटम कैश को लागू करता है।

-define(DFLAG_SMALL_ATOM_TAGS, 16#4000).

नोड SMALL_ATOM_EXT टैग को समझते हैं।

-define(DFLAG_UTF8_ATOMS, 16#10000).

नोड समझे UTF-8 एन्कोडेड परमाणु।

-define(DFLAG_MAP_TAG, 16#20000).

नोड मैप का टैग समझता है।

-define(DFLAG_BIG_CREATION, 16#40000).

नोड बड़े नोड निर्माण को समझते हैं।

-define(DFLAG_SEND_SENDER, 16#80000).

SEND_SENDER control message उपयोग करें SEND_SENDER control message बजाय SEND_SENDER control message का उपयोग करें और SEND_SENDER_TT नियंत्रण संदेश के बजाय।

वहाँ भी कार्य dist_util:strict_order_flags/0 सभी झंडे ( dist_util:strict_order_flags/0 या: एड एक साथ) सुविधाओं के अनुरूप है जो वितरण चैनलों पर डेटा के सख्त आदेश की आवश्यकता होती है।

कनेक्टेड नोड्स के बीच 13.3 प्रोटोकॉल

ईआरटीएस 5.7.2 से रनटाइम सिस्टम हैंडशेक चरण में एक वितरण ध्वज को पारित करता है जो पारित किए गए सभी संदेशों पर एक distribution header के उपयोग को सक्षम करता है। नोड्स के बीच दिए गए संदेश इस मामले में निम्न प्रारूप हैं:

4 n मीटर
Length DistributionHeader ControlMessage Message

तालिका 13.16: संदेशों का प्रारूप नोड्स (ERTS 5.7.2 से) के बीच पारित किया गया

Length

D + n + m के बराबर।

ControlMessage

एर्लांग के बाहरी प्रारूप का उपयोग करके एक टपल पारित किया गया।

Message

'का उपयोग कर एक और नोड के लिए भेजा गया संदेश!' (बाहरी प्रारूप में)। ध्यान दें कि Message केवल एक ControlMessage भेजें ('!') एन्कोडिंग के साथ संयोजन में पारित किया गया है।

ध्यान दें कि the version number is omitted from the terms that follow a distribution header

5.7.2 से पहले ईआरटीएस संस्करण वाले नोड्स वितरण फ्लैग को पारित नहीं करते हैं जो वितरण हेडर को सक्षम करता है। नोड्स के बीच दिए गए संदेश इस मामले में निम्न प्रारूप हैं:

4 1 n मीटर
Length Type ControlMessage Message

तालिका 13.17: संदेशों का प्रारूप नोड्स (ERTS 5.7.2 से पहले) के बीच पारित किया गया

Length

1 + एन + एम के बराबर।

Type

112 बराबर (पास से गुजरना)।

ControlMessage

एर्लांग के बाहरी प्रारूप का उपयोग करके एक टपल पारित किया गया।

Message

'का उपयोग कर एक और नोड के लिए भेजा गया संदेश!' (बाहरी प्रारूप में)। ध्यान दें कि Message केवल एक ControlMessage भेजें ('!') एन्कोडिंग के साथ संयोजन में पारित किया गया है।

ControlMessage एक टपल है, जहां पहला तत्व इंगित करता है कि किस ऑपरेशन ने इसे वितरित किया है:

LINK

{1, FromPid, ToPid}

SEND

{2, Unused, ToPid}

Message द्वारा अनुसरण किया गया।

Unused को पिछड़ी संगतता के लिए रखा जाता है।

EXIT

{3, FromPid, ToPid, Reason}

UNLINK

{4, FromPid, ToPid}

NODE_LINK

{5}

REG_SEND

{6, FromPid, Unused, ToName}

Message द्वारा अनुसरण किया गया।

Unused को पिछड़ी संगतता के लिए रखा जाता है।

GROUP_LEADER

{7, FromPid, ToPid}

EXIT2

{8, FromPid, ToPid, Reason}

13.4 distrvsn के लिए नए Ctrlmessages = 1 (Erlang / OTP R4)

SEND_TT

{12, Unused, ToPid, TraceToken}

Message द्वारा अनुसरण किया गया।

Unused को पिछड़ी संगतता के लिए रखा जाता है।

EXIT_TT

{13, FromPid, ToPid, TraceToken, Reason}

REG_SEND_TT

{16, FromPid, Unused, ToName, TraceToken}

Message द्वारा अनुसरण किया गया।

Unused को पिछड़ी संगतता के लिए रखा जाता है।

EXIT2_TT

{18, FromPid, ToPid, TraceToken, Reason}

13.5 distrvsn = 2 के लिए नए Ctrlmessages

distrvsn 2 का उपयोग कभी नहीं किया गया था।

13.6 distrvsn के लिए नए Ctrlmessages = 3 (Erlang / OTP R5C)

कोई नहीं, लेकिन संस्करण संख्या वैसे भी बढ़ गई थी।

13.7 distrvsn के लिए नए Ctrlmessages = 4 (Erlang / OTP R6)

ये केवल एरलैंग नोड्स द्वारा पहचाने जाते हैं, छिपे हुए नोड्स द्वारा नहीं।

MONITOR_P

{19, FromPid, ToProc, Ref} , जहाँ से FromPid = निगरानी प्रक्रिया और ToProc = निगरानी प्रक्रिया pid या नाम (परमाणु)

DEMONITOR_P

{20, FromPid, ToProc, Ref} , जहाँ से FromPid = निगरानी प्रक्रिया और ToProc = निगरानी प्रक्रिया pid या नाम (परमाणु)

हम केवल उस स्थिति से, FromPid हम इसे ट्रेस करना चाहते हैं, शामिल हैं।

MONITOR_P_EXIT

{21, FromProc, ToPid, Ref, Reason} , जहाँ से FromProc = निगरानी प्रक्रिया pid या नाम (परमाणु), ToPid = निगरानी प्रक्रिया, और निगरानी प्रक्रिया के लिए Reason = निकास कारण

13.8 Erlang / OTP 21 के लिए नए Ctrlmessages

SEND_SENDER

{22, FromPid, ToPid}

Message द्वारा अनुसरण किया गया।

यह नियंत्रण संदेश SEND नियंत्रण संदेश को प्रतिस्थापित करता है और जब वितरण ध्वज DFLAG_SEND_SENDER को कनेक्शन सेटअप हैंडशेक में बातचीत के लिए भेजा जाएगा।

ध्यान दें

कनेक्शन सेट होने से पहले एन्कोड किए गए संदेश अभी भी SEND नियंत्रण संदेश का उपयोग कर सकते हैं। हालाँकि, एक बार SEND_SENDER या SEND_SENDER_TT नियंत्रण संदेश भेज दिया गया है, कनेक्शन पर उसी दिशा में कोई और SEND नियंत्रण संदेश नहीं भेजे जाएंगे।

SEND_SENDER_TT

{23, FromPid, ToPid, TraceToken}

Message द्वारा अनुसरण किया गया।

यह नियंत्रण संदेश SEND_TT नियंत्रण संदेश को प्रतिस्थापित करता है और जब वितरण ध्वज DFLAG_SEND_SENDER को कनेक्शन सेटअप हैंडशेक में बातचीत के लिए भेजा जाएगा।

ध्यान दें

कनेक्शन सेट होने से पहले एन्कोड किए गए संदेश अभी भी SEND_TT नियंत्रण संदेश का उपयोग कर सकते हैं। हालाँकि, SEND_SENDER या SEND_SENDER_TT नियंत्रण संदेश भेजे जाने के बाद, कनेक्शन पर समान दिशा में SEND_SENDER_TT नियंत्रण संदेश नहीं भेजे जाएंगे।