लहसुन फार्म प्रोटोकॉल

अवलोकन

यह गैर्लिक फार्म वायर प्रोटोकॉल के लिए विनिर्देश है, जो JRaft पर आधारित है, TCP पर कार्यान्वयन के लिए इसका “exts” कोड, और इसका “dmprinter” नमूना अनुप्रयोग JRAFT ।

हमें कोई भी कार्यान्वयन जिसके साथ दस्तावेजीकृत वायर प्रोटोकॉल हो, खोजने में असमर्थ थे। हालांकि, JRaft कार्यान्वयन इतना सरल है कि हम कोड का निरीक्षण कर सकते थे और फिर इसके प्रोटोकॉल को दस्तावेज़ीकृत कर सकते थे। यह प्रस्ताव उस प्रयास का परिणाम है।

यह राउटर्स के समन्वय के लिए बैकएंड होगा जो मेटा लीज़सेट में प्रविष्टियाँ प्रकाशित करते हैं। प्रस्ताव 123 देखें।

लक्ष्य

• छोटा कोड आकार
• मौजूदा कार्यान्वयन पर आधारित
• कोई सीरियलाइज़्ड जावा ऑब्जेक्ट या कोई भी जावा-विशिष्ट सुविधाएँ या एन्कोडिंग नहीं
• कोई भी बूटस्ट्रैपिंग प्रोटोकॉल के दायरे से बाहर है। कम से कम एक अन्य सर्वर माना जाता है हार्डकोडेड है, या इस प्रोटोकॉल के बाहर बैंड में कॉन्फ़िगर किया गया है।
• आउट-ऑफ-बैंड और इन-आई2पी दोनों उपयोग के मामलों का समर्थन करें।

डिज़ाइन

राफ्ट प्रोटोकॉल एक ठोस प्रोटोकॉल नहीं है; यह केवल एक स्टेट मशीन को परिभाषित करता है। इसलिए हम JRaft के ठोस प्रोटोकॉल को दस्तावेज़ीकृत करते हैं और अपने प्रोटोकॉल को उस पर आधारित बनाते हैं। JRaft प्रोटोकॉल में कोई भी परिवर्तन नहीं हैं सिवाय एक प्रमाणीकरण हैंडशेक के अतिरिक्त।

राफ्ट एक लीडर का चुनाव करता है जिसका काम एक लॉग प्रकाशित करना है। लॉग में राफ्ट कॉन्फ़िगरेशन डेटा और एप्लिकेशन डेटा शामिल है। एप्लिकेशन डेटा में प्रत्येक सर्वर के राउटर की स्थिति और मेटा LS2 क्लस्टर के लिए डेस्टिनेशन शामिल है। सर्वर एक सामान्य एल्गोरिथ्म का उपयोग करते हैं जो मेटा LS2 के प्रकाशक और सामग्री का निर्धारण करता है। मेटा LS2 का प्रकाशक आवश्यक रूप से राफ्ट लीडर नहीं है।

विनिर्देश

वायर प्रोटोकॉल SSL सॉकेट या गैर-SSL I2P सॉकेट पर है। I2P सॉकेट HTTP प्रॉक्सी के माध्यम से प्रॉक्सी किए जाते हैं। क्लियरनेट गैर-SSL सॉकेट के लिए कोई समर्थन नहीं है।

हैंडशेक और प्रमाणीकरण

JRaft द्वारा परिभाषित नहीं।

लक्ष्य:

• उपयोगकर्ता/पासवर्ड प्रमाणीकरण विधि
• संस्करण पहचानकर्ता
• क्लस्टर पहचानकर्ता
• विस्तार योग्य
• I2P सॉकेट के लिए उपयोग किए जाने पर प्रॉक्सी करने में आसानी
• गैर्लिक फार्म सर्वर के रूप में सर्वर को अनावश्यक रूप से उजागर न करें
• सरल प्रोटोकॉल ताकि पूरे वेब सर्वर कार्यान्वयन की आवश्यकता न हो
• सामान्य मानकों के साथ संगत, ताकि कार्यान्वयन यदि वांछित हो तो मानक लाइब्रेरी का उपयोग कर सकें

हम एक वेबसॉकेट-जैसे हैंडशेक और HTTP डाइजेस्ट प्रमाणीकरण RFC 2617 का उपयोग करेंगे। RFC 2617 बेसिक प्रमाणीकरण समर्थित नहीं है। HTTP प्रॉक्सी के माध्यम से प्रॉक्सी करते समय, RFC 2616 में निर्दिष्ट अनुसार प्रॉक्सी के साथ संचार करें।

प्रमाणपत्र

क्या उपयोगकर्ता नाम और पासवर्ड क्लस्टर-वार हैं, या प्रति-सर्वर, यह कार्यान्वयन पर निर्भर है।

HTTP अनुरोध 1

प्रारंभकर्ता निम्नलिखित भेजेगा।

HTTP द्वारा आवश्यक CRLF के साथ सभी पंक्तियाँ समाप्त होती हैं।

GET /GarlicFarm/CLUSTER/VERSION/websocket HTTP/1.1
  Host: (ip):(port)
  Cache-Control: no-cache
  Connection: close
  (any other headers ignored)
  (blank line)

  CLUSTER is the name of the cluster (default "farm")
  VERSION is the Garlic Farm version (currently "1")

HTTP प्रतिक्रिया 1

यदि पथ सही नहीं है, तो प्राप्तकर्ता एक मानक “HTTP/1.1 404 Not Found” प्रतिक्रिया भेजेगा, जैसा कि RFC 2616 में है।

यदि पथ सही है, तो प्राप्तकर्ता एक मानक “HTTP/1.1 401 Unauthorized” प्रतिक्रिया भेजेगा, जिसमें WWW-Authenticate HTTP डाइजेस्ट प्रमाणीकरण हेडर शामिल है, जैसा कि RFC 2617 में है।

दोनों पक्ष फिर सॉकेट को बंद कर देंगे।

HTTP अनुरोध 2

प्रारंभकर्ता निम्नलिखित भेजेगा, जैसा कि RFC 2617 में है।

HTTP द्वारा आवश्यक CRLF के साथ सभी पंक्तियाँ समाप्त होती हैं।

GET /GarlicFarm/CLUSTER/VERSION/websocket HTTP/1.1
  Host: (ip):(port)
  Cache-Control: no-cache
  Connection: keep-alive, Upgrade
  Upgrade: websocket
  (Sec-Websocket-* headers if proxied)
  Authorization: (HTTP digest authorization header as in RFC 2617)
  (any other headers ignored)
  (blank line)

  CLUSTER is the name of the cluster (default "farm")
  VERSION is the Garlic Farm version (currently "1")

HTTP प्रतिक्रिया 2

यदि प्रमाणीकरण सही नहीं है, तो प्राप्तकर्ता एक और मानक “HTTP/1.1 401 Unauthorized” प्रतिक्रिया भेजेगा, जैसा कि RFC 2617 में है।

यदि प्रमाणीकरण सही है, तो प्राप्तकर्ता निम्नलिखित प्रतिक्रिया भेजेगा, जैसा कि वेबसॉकेट प्रोटोकॉल में है।

HTTP द्वारा आवश्यक CRLF के साथ सभी पंक्तियाँ समाप्त होती हैं।

HTTP/1.1 101 Switching Protocols
  Connection: Upgrade
  Upgrade: websocket
  (Sec-Websocket-* headers)
  (any other headers ignored)
  (blank line)

इसे प्राप्त करने के बाद, सॉकेट खुला रहता है। नीचे परिभाषित राफ्ट प्रोटोकॉल शुरू होता है, उसी सॉकेट पर।

कैशिंग

प्रमाणपत्रों को कम से कम एक घंटे के लिए कैश किया जाना चाहिए, ताकि बाद के कनेक्शन सीधे ऊपर दिए गए “HTTP अनुरोध 2” पर जा सकें।

संदेश प्रकार

दो प्रकार के संदेश हैं, अनुरोध और प्रतिक्रिया। अनुरोधों में लॉग प्रविष्टियाँ शामिल हो सकती हैं, और चर-आकार के हैं; प्रतिक्रियाओं में लॉग प्रविष्टियाँ नहीं होती हैं, और निश्चित आकार की होती हैं।

संदेश प्रकार 1-4 राफ्ट द्वारा परिभाषित मानक RPC संदेश हैं। यह मुख्य राफ्ट प्रोटोकॉल है।

संदेश प्रकार 5-15 JRaft द्वारा परिभाषित विस्तारित RPC संदेश हैं, जो क्लाइंट्स, गतिशील सर्वर परिवर्तनों का समर्थन करने के लिए, और कुशल लॉग सिंक्रनाइज़ेशन के लिए।

संदेश प्रकार 16-17 लॉग कॉम्पैक्शन RPC संदेश हैं जो राफ्ट खंड 7 में परिभाषित हैं।

स्थापना

HTTP हैंडशेक के बाद, स्थापना अनुक्रम निम्नलिखित है:

नया सर्वर एलिस              कोई भी अनुयायी बॉब

  ClientRequest   ------->
          <---------   AppendEntriesResponse

  यदि बॉब कहता है कि वह लीडर है, तो नीचे के अनुसार जारी रखें।
  अन्यथा, एलिस को बॉब से डिस्कनेक्ट करना चाहिए और लीडर से कनेक्ट करना चाहिए।


  नया सर्वर एलिस              लीडर चार्ली

  ClientRequest   ------->
          <---------   AppendEntriesResponse
  AddServerRequest   ------->
          <---------   AddServerResponse
          <---------   JoinClusterRequest
  JoinClusterResponse  ------->
          <---------   SyncLogRequest
                       OR InstallSnapshotRequest
  SyncLogResponse  ------->
  OR InstallSnapshotResponse

डिस्कनेक्ट अनुक्रम:

अनुयायी एलिस              लीडर चार्ली

  RemoveServerRequest   ------->
          <---------   RemoveServerResponse
          <---------   LeaveClusterRequest
  LeaveClusterResponse  ------->

चुनाव अनुक्रम:

उम्मीदवार एलिस               अनुयायी बॉब

  RequestVoteRequest   ------->
          <---------   RequestVoteResponse

  यदि एलिस चुनाव जीतता है:

  लीडर एलिस                अनुयायी बॉब

  AppendEntriesRequest   ------->
  (heartbeat)
          <---------   AppendEntriesResponse

परिभाषाएँ

• स्रोत: संदेश के उत्पत्ति स्थल को पहचानता है
• गंतव्य: संदेश के प्राप्तकर्ता को पहचानता है
• शब्द: राफ्ट देखें। 0 से आरंभ, एकघाती रूप से बढ़ता है
• सूचकांक: राफ्ट देखें। 0 से आरंभ, एकघाती रूप से बढ़ता है

अनुरोध

अनुरोधों में एक हेडर और शून्य या अधिक लॉग प्रविष्टियाँ शामिल होती हैं। अनुरोधों में एक निश्चित आकार का हेडर और चर आकार की वैकल्पिक लॉग प्रविष्टियाँ होती हैं।

अनुरोध हेडर

अनुरोध हेडर 45 बाइट्स का है, निम्नलिखित अनुसार। सभी मान अहस्ताक्षरित बड़े-एंडियन हैं।

संदेश प्रकार:      1 बाइट
  स्रोत:            ID, 4 बाइट पूर्णांक
  गंतव्य:           ID, 4 बाइट पूर्णांक
  शब्द:              वर्तमान शब्द (टिप्पणियाँ देखें), 8 बाइट पूर्णांक
  अंतिम लॉग शब्द:     8 बाइट पूर्णांक
  अंतिम लॉग सूचकांक:    8 बाइट पूर्णांक
  प्रतिबद्ध सूचकांक:      8 बाइट पूर्णांक
  लॉग प्रविष्टियों का आकार:  बाइट में कुल आकार, 4 बाइट पूर्णांक
  लॉग प्रविष्टियाँ:       नीचे देखें, निर्दिष्ट के अनुसार कुल लंबाई

टिप्पणियाँ

RequestVoteRequest में, शब्द उम्मीदवार का शब्द है। अन्यथा, यह लीडर का वर्तमान शब्द है।

AppendEntriesRequest में, जब लॉग प्रविष्टियों का आकार शून्य होता है, तो यह संदेश एक हार्टबीट (keepalive) संदेश है।

लॉग प्रविष्टियाँ

लॉग में शून्य या अधिक लॉग प्रविष्टियाँ होती हैं। प्रत्येक लॉग प्रविष्टि निम्नलिखित अनुसार है। सभी मान अहस्ताक्षरित बड़े-एंडियन हैं।

शब्द:           8 बाइट पूर्णांक
  मान प्रकार:     1 बाइट
  प्रविष्टि आकार:     बाइट में, 4 बाइट पूर्णांक
  प्रविष्टि:          निर्दिष्ट लंबाई के अनुसार

लॉग सामग्री

सभी मान अहस्ताक्षरित बड़े-एंडियन हैं।

एप्लिकेशन

एप्लिकेशन सामग्री UTF-8 एन्कोडेड JSON में है। नीचे एप्लिकेशन लेयर खंड देखें।

कॉन्फ़िगरेशन

इसका उपयोग लीडर द्वारा एक नया क्लस्टर कॉन्फ़िगरेशन सीरियलाइज़ करने और साथियों को प्रतिकृति बनाने के लिए किया जाता है। इसमें शून्य या अधिक क्लस्टरसर्वर कॉन्फ़िगरेशन शामिल हैं।

लॉग सूचकांक:  8 बाइट पूर्णांक
  अंतिम लॉग सूचकांक:  8 बाइट पूर्णांक
  प्रत्येक सर्वर के लिए क्लस्टरसर्वर डेटा:
    ID:                4 बाइट पूर्णांक
    एंडपॉइंट डेटा लंबाई: बाइट में, 4 बाइट पूर्णांक
    एंडपॉइंट डेटा:     "tcp://localhost:9001" के रूप में ASCII स्ट्रिंग, निर्दिष्ट लंबाई के अनुसार

क्लस्टरसर्वर

क्लस्टर में एक सर्वर के लिए कॉन्फ़िगरेशन जानकारी। इसे केवल AddServerRequest या RemoveServerRequest संदेश में शामिल किया जाता है।

AddServerRequest संदेश में उपयोग करते समय:

ID:                4 बाइट पूर्णांक
  एंडपॉइंट डेटा लंबाई: बाइट में, 4 बाइट पूर्णांक
  एंडपॉइंट डेटा:     "tcp://localhost:9001" के रूप में ASCII स्ट्रिंग, निर्दिष्ट लंबाई के अनुसार

RemoveServerRequest संदेश में उपयोग करते समय:

ID:                4 बाइट पूर्णांक

लॉगपैक

इसे केवल SyncLogRequest संदेश में शामिल किया जाता है।

ट्रांसमिशन से पहले निम्नलिखित को ज़िप किया जाता है:

सूचकांक डेटा लंबाई: बाइट में, 4 बाइट पूर्णांक
  लॉग डेटा लंबाई:   बाइट में, 4 बाइट पूर्णांक
  सूचकांक डेटा:     प्रत्येक सूचकांक के लिए 8 बाइट, निर्दिष्ट लंबाई के अनुसार
  लॉग डेटा:       निर्दिष्ट लंबाई के अनुसार

SnapshotSyncRequest

इसे केवल InstallSnapshotRequest संदेश में शामिल किया जाता है।

अंतिम लॉग सूचकांक:  8 बाइट पूर्णांक
  अंतिम लॉग शब्द:   8 बाइट पूर्णांक
  कॉन्फ़िग डेटा लंबाई: बाइट में, 4 बाइट पूर्णांक
  कॉन्फ़िग डेटा:     निर्दिष्ट लंबाई के अनुसार
  ऑफ़सेट:          डेटाबेस में डेटा का ऑफ़सेट, बाइट में, 8 बाइट पूर्णांक
  डेटा लंबाई:        बाइट में, 4 बाइट पूर्णांक
  डेटा:            निर्दिष्ट लंबाई के अनुसार
  पूर्ण है:         1 यदि पूर्ण है, 0 यदि नहीं (1 बाइट)

प्रतिक्रियाएँ

सभी प्रतिक्रियाएँ 26 बाइट्स की हैं, निम्नलिखित अनुसार। सभी मान अहस्ताक्षरित बड़े-एंडियन हैं।

संदेश प्रकार:   1 बाइट
  स्रोत:         ID, 4 बाइट पूर्णांक
  गंतव्य:    आमतौर पर वास्तविक गंतव्य ID (टिप्पणियाँ देखें), 4 बाइट पूर्णांक
  शब्द:           वर्तमान शब्द, 8 बाइट पूर्णांक
  अगला सूचकांक:     लीडर के अंतिम लॉग सूचकांक + 1 से आरंभ, 8 बाइट पूर्णांक
  स्वीकृत है:    1 यदि स्वीकृत, 0 यदि नहीं (टिप्पणियाँ देखें), 1 बाइट

टिप्पणियाँ

गंतव्य ID आमतौर पर इस संदेश के लिए वास्तविक गंतव्य होता है। हालांकि, AppendEntriesResponse, AddServerResponse, और RemoveServerResponse के लिए, यह वर्तमान लीडर की ID है।

RequestVoteResponse में, स्वीकृत है उम्मीदवार (अनुरोधकर्ता) के लिए 1 है, और कोई वोट नहीं देने के लिए 0 है।

एप्लिकेशन लेयर

प्रत्येक सर्वर नियमित रूप से एक ClientRequest में लॉग पर एप्लिकेशन डेटा पोस्ट करता है। एप्लिकेशन डेटा में प्रत्येक सर्वर के राउटर की स्थिति और मेटा LS2 क्लस्टर के लिए डेस्टिनेशन शामिल है। सर्वर मेटा LS2 के प्रकाशक और सामग्री का निर्धारण करने के लिए एक सामान्य एल्गोरिथ्म का उपयोग करते हैं। लॉग में “सबसे अच्छी” हाल की स्थिति वाला सर्वर मेटा LS2 प्रकाशक है। मेटा LS2 का प्रकाशक आवश्यक रूप से राफ्ट लीडर नहीं है।

एप्लिकेशन डेटा सामग्री

एप्लिकेशन सामग्री UTF-8 एन्कोडेड JSON में है, सरलता और विस्तार योग्यता के लिए। पूर्ण विनिर्देश अभी तय नहीं है। लक्ष्य मेटा LS2 प्रकाशित करने के लिए “सबसे अच्छे” राउटर का निर्धारण करने के लिए एल्गोरिथ्म लिखने के लिए पर्याप्त डेटा प्रदान करना है, और प्रकाशक के पास मेटा LS2 में डेस्टिनेशन को वजन देने के लिए पर्याप्त जानकारी हो। डेटा में राउटर और डेस्टिनेशन दोनों के आंकड़े शामिल होंगे।

डेटा में अन्य सर्वरों के स्वास्थ्य पर दूरस्थ सेंसिंग डेटा और मेटा एलएस प्राप्त करने की क्षमता वैकल्पिक रूप से शामिल हो सकती है। इन डेटा को पहले रिलीज में समर्थित नहीं किया जाएगा।

डेटा में एक प्रशासक क्लाइंट द्वारा पोस्ट की गई कॉन्फ़िगरेशन जानकारी वैकल्पिक रूप से शामिल हो सकती है। इन डेटा को पहले रिलीज में समर्थित नहीं किया जाएगा।

यदि “नाम: मान” सूचीबद्ध है, तो यह JSON मानचित्र कुंजी और मान निर्दिष्ट करता है। अन्यथा, विनिर्देश अभी तय नहीं है।

क्लस्टर डेटा (शीर्ष स्तर):

• cluster: क्लस्टर का नाम
• date: इस डेटा की तारीख (लंबा, युग के बाद से मिलीसेकंड में)
• id: राफ्ट आईडी (पूर्णांक)

कॉन्फ़िगरेशन डेटा (config):

• कोई भी कॉन्फ़िगरेशन पैरामीटर

मेटाएलएस प्रकाशन स्थिति (meta):

• destination: the metals destination, base64
• lastPublishedLS: यदि उपस्थित है, तो अंतिम प्रकाशित metals का base64 एन्कोडिंग
• lastPublishedTime: मिलीसेकंड में, या कभी नहीं तो 0
• publishConfig: प्रकाशक कॉन्फ़िग स्थिति चालू/बंद/स्वचालित
• publishing: metals प्रकाशक स्थिति बूलियन सत्य/असत्य

राउटर डेटा (router):

• lastPublishedRI: यदि उपस्थित है, तो अंतिम प्रकाशित राउटर जानकारी का base64 एन्कोडिंग
• uptime: मिलीसेकंड में अपटाइम
• जॉब लैग
• अन्वेषणात्मक टनल
• भाग लेने वाले टनल
• कॉन्फ़िगर की गई बैंडविड्थ
• वर्तमान बैंडविड्थ

डेस्टिनेशन (destinations): सूची

डेस्टिनेशन डेटा:

• destination: the destination, base64
• uptime: मिलीसेकंड में अपटाइम
• कॉन्फ़िगर की गई टनल
• वर्तमान टनल
• कॉन्फ़िगर की गई बैंडविड्थ
• वर्तमान बैंडविड्थ
• कॉन्फ़िगर की गई कनेक्शन
• वर्तमान कनेक्शन
• ब्लैकलिस्ट डेटा

दूरस्थ राउटर सेंसिंग डेटा:

• अंतिम RI संस्करण देखा गया
• एलएस फ़ेच समय
• कनेक्शन परीक्षण डेटा
• सबसे निकटतम फ्लडफिल्स प्रोफ़ाइल डेटा कल, आज और कल के लिए समय अवधि

दूरस्थ डेस्टिनेशन सेंसिंग डेटा:

• अंतिम एलएस संस्करण देखा गया
• एलएस फ़ेच समय
• कनेक्शन परीक्षण डेटा
• सबसे निकटतम फ्लडफिल्स प्रोफ़ाइल डेटा कल, आज और कल के लिए समय अवधि

मेटा एलएस सेंसिंग डेटा:

• अंतिम संस्करण देखा गया
• फ़ेच समय
• सबसे निकटतम फ्लडफिल्स प्रोफ़ाइल डेटा कल, आज और कल के लिए समय अवधि

प्रशासन इंटरफ़ेस

अभी तय नहीं है, संभवतः एक अलग प्रस्ताव। पहले रिलीज के लिए आवश्यक नहीं है।

एक प्रशासक इंटरफ़ेस की आवश्यकताएँ:

• एकाधिक मास्टर डेस्टिनेशन का समर्थन करें, अर्थात एकाधिक आभासी क्लस्टर (फार्म)
• साझा क्लस्टर स्थिति का व्यापक दृश्य प्रदान करें - सदस्यों द्वारा प्रकाशित सभी आंकड़े, वर्तमान लीडर कौन है, आदि।
• क्लस्टर से एक प्रतिभागी या लीडर को बलपूर्वक हटाने की क्षमता
• मेटाएलएस को बलपूर्वक प्रकाशित करने की क्षमता (यदि वर्तमान नोड प्रकाशक है)
• मेटाएलएस से हैश को बाहर रखने की क्षमता (यदि वर्तमान नोड प्रकाशक है)
• बल्क तैनाती के लिए कॉन्फ़िगरेशन आयात/निर्यात कार्यक्षमता

राउटर इंटरफ़ेस

अभी तय नहीं है, संभवतः एक अलग प्रस्ताव। i2pcontrol पहले रिलीज के लिए आवश्यक नहीं है और विस्तृत परिवर्तन एक अलग प्रस्ताव में शामिल किए जाएंगे।

गैर्लिक फार्म से राउटर API के लिए आवश्यकताएँ (in-JVM java या i2pcontrol)

• getLocalRouterStatus()
• getLocalLeafHash(Hash masterHash)
• getLocalLeafStatus(Hash leaf)
• getRemoteMeasuredStatus(Hash masterOrLeaf) // संभवतः MVP में नहीं
• publishMetaLS(Hash masterHash, List contents) // या हस्ताक्षरित MetaLeaseSet? हस्ताक्षर कौन करता है?
• stopPublishingMetaLS(Hash masterHash)
• प्रमाणीकरण अभी तय नहीं है?

औचित्य

एटोमिक्स बहुत बड़ा है और हमें आई2पी पर प्रोटोकॉल को मार्ग करने के लिए अनुकूलन की अनुमति नहीं देगा। इसके अलावा, इसका वायर फॉर्मेट अदस्तावेजीकृत है, और जावा सीरियलाइज़ेशन पर निर्भर करता है।

टिप्पणियाँ

मुद्दे

• क्लाइंट के पास अज्ञात लीडर के बारे में जानने और उससे कनेक्ट करने का कोई तरीका नहीं है। एक अनुयायी के लिए AppendEntriesResponse में एक लॉग प्रविष्टि के रूप में कॉन्फ़िगरेशन भेजने के लिए यह एक मामूली परिवर्तन होगा।

माइग्रेशन

कोई पिछड़ी संगतता समस्याएँ नहीं हैं।

संदर्भ

• JRAFT
• JSON
• RAFT
• RFC-2616
• RFC-2617
• WEBSOCKET