एक से अधिक अग्रणी नोड वाले वातावरण में स्वचालित संघर्ष समाधान (इस आलेख में, एक प्रमुख नोड एक नोड को संदर्भित करता है जो डेटा परिवर्तन अनुरोधों को स्वीकार करता है) अनुसंधान का एक बहुत ही दिलचस्प क्षेत्र है। एप्लिकेशन के आधार पर कई अलग-अलग दृष्टिकोण और एल्गोरिदम हैं, और यह आलेख Google डॉक्स और एथेरपैड जैसे सहयोगी संपादन अनुप्रयोगों में संघर्षों को हल करने के लिए ऑपरेशनल ट्रांसफॉर्मेशन (ओटी) तकनीक पर चर्चा करेगा।

1. परिचय

तकनीकी दृष्टिकोण से सहयोग कठिन है, क्योंकि कई लोग लगभग एक ही समय बिंदुओं पर पाठ के एक ही खंड में विभिन्न परिवर्तन कर सकते हैं। चूंकि इंटरनेट के माध्यम से डेटा वितरण तात्कालिक नहीं है (ऑप्टिकल फाइबर में डेटा ट्रांसफर गति की सीमाएं हैं), प्रत्येक ग्राहक एक त्वरित प्रतिक्रिया का अनुकरण करने के लिए संपादित दस्तावेज़ के स्थानीय संस्करण (प्रतिकृति) के साथ काम करता है, जो अन्य प्रतिभागियों के संस्करणों से भिन्न हो सकता है। और मुख्य पकड़ स्थानीय संस्करणों के बीच या दूसरे शब्दों में, यह सुनिश्चित करने के लिए है कि यह कैसे सुनिश्चित किया जाए कि सभी स्थानीय संस्करण एक दस्तावेज़ के जल्द या बाद में एक ही, सही संस्करण में परिवर्तित हों (हमें सभी क्लाइंट की आवश्यकता नहीं हो सकती है एक साथ समय के कुछ क्षणों में एक ही संस्करण था, क्योंकि संपादन प्रक्रिया अंतहीन हो सकती है)।

Google डॉक्स का पुराना संस्करण

प्रारंभ में, Google डॉक्स ने कई अन्य सहयोगी दस्तावेज़ संपादन अनुप्रयोगों की तरह, दस्तावेज़ के विभिन्न संस्करणों की सामग्री की एक सरल तुलना का उपयोग किया। मान लीजिए कि हमारे पास दो ग्राहक हैं - पेट्या और वास्या, और दस्तावेज़ की वर्तमान स्थिति उनके बीच समन्वयित है। Google के Google सर्वर के पुराने संस्करण में, पेट्या से अपडेट प्राप्त करने पर, यह अपने संस्करण और अपने बीच के अंतर (अंतर) की गणना करता है और दो संस्करणों को सर्वोत्तम संभव तरीके से एक में विलय करने का प्रयास करता है। फिर सर्वर प्राप्त संस्करण को वास्या को भेजता है। यदि वास्या में कोई भी परिवर्तन सर्वर पर नहीं भेजा गया है, तो प्रक्रिया दोहराती है - आपको सर्वर से स्थानीय वासिना के साथ संस्करण को मर्ज करने और इसे सर्वर पर वापस भेजने की आवश्यकता है।

बहुत बार, यह दृष्टिकोण बहुत अच्छी तरह से काम नहीं करता है। उदाहरण के लिए, मान लीजिए कि पेट्या, वास्या और सर्वर पाठ " द क्विक ब्राउन फोक्स " के साथ एक सिंक्रनाइज़ दस्तावेज़ से शुरू होते हैं ।

पेट्या ने भूरे रंग के लोमड़ी शब्द को बोल्ड पर प्रकाश डाला, जबकि वास्या ने लोमड़ी शब्द को कुत्ते के साथ बदल दिया। बता दें कि पेटिना पहले सर्वर में बदलाव करती है और वह वास्या का अपडेटेड वर्जन भेजती है। यह स्पष्ट है कि अंतिम परिणाम त्वरित भूरे रंग का कुत्ता होना चाहिए, लेकिन मर्ज एल्गोरिदम के लिए यह समझने के लिए पर्याप्त जानकारी नहीं है, विकल्प त्वरित भूरे लोमड़ी कुत्ते , त्वरित भूरे कुत्ते कुत्ते , त्वरित भूरे कुत्ते लोमड़ी बिल्कुल सही हैं। (उदाहरण के लिए, ऐसे मामलों में गिट में, आपको एक मर्ज संघर्ष मिलेगा और आपको अपने हाथों से शासन करना होगा)। यह इस दृष्टिकोण की मुख्य समस्या है - यदि आप केवल दस्तावेज़ की सामग्री पर भरोसा करते हैं तो आप विलय के परिणामों के बारे में सुनिश्चित नहीं कर पाएंगे।

आप स्थिति को सुधारने और पाठ के अनुभागों को संपादित करने के लिए अन्य प्रतिभागियों की क्षमता को अवरुद्ध करने का प्रयास कर सकते हैं जो किसी ने पहले से ही नियम बनाए हैं। लेकिन यह वह नहीं है जो हम चाहते हैं - यह दृष्टिकोण बस उपयोगकर्ता अनुभव को खराब करके एक तकनीकी समस्या को हल करने से बचने की कोशिश करता है, और ऐसी स्थिति भी हो सकती है जहां दो प्रतिभागियों ने एक ही समय में एक ही वाक्य को संपादित करना शुरू कर दिया - और फिर उनमें से एक या तो परिवर्तन खो देगा। या उसे उपरोक्त संघर्ष की स्थिति में परिवर्तनों को मैन्युअल रूप से संयोजित करना होगा।

Google डॉक्स का नया संस्करण

Google डॉक्स के नए संस्करण में, एक पूरी तरह से अलग दृष्टिकोण का उपयोग किया गया था: दस्तावेजों को परिवर्तनों के अनुक्रम के रूप में संग्रहीत किया जाता है और सामग्री की तुलना करने के बजाय, हम क्रम में बदलावों को रोल करते हैं (बाद में आदेश संबंध के रूप में संदर्भित )। यह जानते हुए कि उपयोगकर्ता ने दस्तावेज़ को कैसे संशोधित किया और इसके इरादों को ध्यान में रखते हुए , हम सभी संस्करणों के संयोजन के बाद अंतिम संस्करण को सही ढंग से निर्धारित कर सकते हैं।

ठीक है, अब हमें यह समझने की आवश्यकता है कि परिवर्तनों को कब लागू किया जाए - हमें एक सहयोग प्रोटोकॉल की आवश्यकता है ।

Google डॉक्स में, सभी दस्तावेज़ संपादन तीन अलग-अलग कार्यों के लिए उबालते हैं:

पाठ प्रविष्टि
पाठ हटाएं
पाठ के लिए शैलियों को लागू करना

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

एक छोटी टिप्पणी: ओटी समर्थन वाला पहला (सार्वजनिक) Google उत्पाद, जाहिरा तौर पर, Google Wave था। उन्होंने कई व्यापक अभियानों का समर्थन किया।

उदाहरण

बता दें कि पेट्या और वास्या की शुरुआत "एचएबीआर 2017" से हुई थी।
पेटीएम 2017 से 2018 में बदलता है, यह वास्तव में 2 ऑपरेशन बनाता है:

उसी समय, वास्या ने पाठ को "हेलो एचबीआर 2017" में बदल दिया:

वास्या को डिलीट करने के लिए पेटिन का ऑपरेशन मिला, अगर वह इसे लागू करता है, तो गलत टेक्स्ट प्राप्त होगा (संख्या 7 को हटा दिया जाना चाहिए:

इससे बचने के लिए, वास्या को अपने वर्तमान स्थानीय बदलावों के अनुसार पेटिन के ऑपरेशन को बदलना होगा (दूसरे शब्दों में, ऑपरेशन संदर्भ-संवेदनशील हैं):

\ {हटाएँ \ \ @ 8 \} \ rightarrow \ {हटाएँ \ \ @ 15 \}

$\ {हटाएँ \ \ @ 8 \} \ rightarrow \ {हटाएँ \ \ @ 15 \}$

थोड़ा और औपचारिक रूप से बोलते हुए, इस उदाहरण पर विचार करें:

तब:

$O1 '(O2 (X)) = O2' (O1 (X))$

देखा! वर्णित एल्गोरिदम को ऑपरेशनल ट्रांसफॉर्मेशन कहा जाता है।

2. परिचालनात्मक परिवर्तन

संगति मॉडल

स्थिरता सुनिश्चित करने के लिए, कई संगतता मॉडल विकसित किए गए हैं, उनमें से एक पर विचार करें - CCI।

CCI मॉडल तीन गुण प्रदान करता है:

अभिसरण: सभी कार्यों के पूरा होने के बाद एक सामान्य दस्तावेज की सभी प्रतिकृतियां समान होनी चाहिए:

इस उदाहरण में, दोनों उपयोगकर्ता समान प्रतिकृतियों के साथ शुरू करते हैं। फिर वे दस्तावेज़ और प्रतिकृतियां बदलते हैं - इस तरह न्यूनतम प्रतिक्रिया समय प्राप्त होता है। अन्य ग्राहकों को स्थानीय परिवर्तन भेजने के बाद, अभिसरण संपत्ति के लिए आवश्यक है कि सभी ग्राहकों के लिए दस्तावेज़ की अंतिम स्थिति समान हो।
इरादा संरक्षण: एक ऑपरेशन का इरादा सभी प्रतिकृतियों पर संग्रहीत किया जाना चाहिए, भले ही यह एक ही समय में कई ऑपरेशन करने के लिए अतिव्यापी हो। एक ऑपरेशन के इरादे को कॉपी पर उसके निष्पादन के प्रभाव के रूप में परिभाषित किया गया है जहां इसे बनाया गया था।

एक उदाहरण पर विचार करें जहां यह संपत्ति विफल रहती है:

दोनों क्लाइंट एक ही प्रतिकृतियों से शुरू होते हैं, फिर दोनों बदलाव करते हैं। पेट्या के लिए, उसके ऑपरेशन का इरादा पहले सूचकांक पर '12' डालना है, और वास्या के लिए, सूचक 2 और 3 के साथ वर्ण हटाएं। पेट्या वासिनो के साथ सिंक्रनाइज़ेशन के बाद, इरादे और वास्या पेटिनो के इरादे का उल्लंघन किया जाता है। यह भी ध्यान दें कि प्रतिकृतियों ने विचलन किया है, लेकिन यह प्रश्न में संपत्ति के लिए एक आवश्यकता नहीं है। एक छोटे से अभ्यास के रूप में पाठक की पहचान करने के लिए सही अंतिम संस्करण प्रस्तावित है।
कारण परिरक्षण: संचालन एक कारण क्रम में किया जाना चाहिए ( पहले हुए संबंध के आधार पर)।

एक उदाहरण पर विचार करें जहां यह संपत्ति विफल रहती है:

जैसा कि आप देख सकते हैं, पेट्या ने वास्या और एजेंट स्मिथ को अपने दस्तावेज़ बदलने के लिए भेजा, वास्या ने इसे पहले प्राप्त किया और अंतिम चरित्र को हटा दिया। नेटवर्क लैग के कारण, स्मिथ को वासीन के लिए पहला ऑपरेशन मिलता है, जो एक ऐसे चरित्र को हटा देता है जो अभी तक मौजूद नहीं है।

ओटी यह सुनिश्चित नहीं कर सकता है कि कार्य-कारण संरक्षण संपत्ति पूरी हो गई है; इसलिए, इन उद्देश्यों के लिए एक वेक्टर घड़ी जैसे एल्गोरिदम का उपयोग किया जाता है।

ओटी डिजाइन

ओटी प्रणाली की डिजाइन रणनीति में से एक तीन भागों में विभाजन है:

ट्रांसफॉर्मेशन कंट्रोल एल्गोरिदम: निर्धारित करें कि ऑपरेशन (टारगेट) ट्रांसफॉर्म करने के लिए तैयार है, ट्रांसफॉर्मेशन को किस ऑपरेशन (संदर्भ) से और किस क्रम में अंजाम दिया जाए।
परिवर्तन के कार्य: संदर्भ संचालन के प्रभाव को ध्यान में रखते हुए, लक्ष्य संचालन को बदल देता है।
परिवर्तन की आवश्यकताएँ और गुण (गुण और स्थितियाँ): इन घटकों के बीच एक संबंध प्रदान करते हैं और शुद्धता के लिए जाँच करते हैं।

रूपांतरण कार्य

रूपांतरण कार्यों को दो प्रकारों में विभाजित किया जा सकता है:

समावेशन / अग्रेषण परिवर्तन: किसी ऑपरेशन को बदलना $O_a$ सर्जरी से पहले $O_b$ ताकि का प्रभाव $O_b$ (जैसे दो आवेषण)
बहिष्करण / पिछड़ा परिवर्तन: एक ऑपरेशन का परिवर्तन $O_a$ सर्जरी से पहले $O_b$ ताकि का प्रभाव $O_b$ बाहर रखा गया (जैसे विलोपन के बाद सम्मिलित करें)

प्रतीकात्मक सम्मिलित / हटाने के संचालन के लिए एक उदाहरण (i - सम्मिलित करें, डी - हटाएं):

Tii(Ins[p1, c1], Ins[p2, c2]) { if (p1 < p2) || ((p1 == p2) && (order() == -1)) // order() –   return Ins[p1, c1]; // Tii(Ins[3, 'a'], Ins[4, 'b']) = Ins[3, 'a'] else return Ins[p1 + 1, c1]; // Tii(Ins[3, 'a'], Ins[1, 'b']) = Ins[4, 'a'] } Tid(Ins[p1, c1], Del[p2]) { if (p1 <= p2) return Ins[p1, c1]; // Tid(Ins[3, 'a'], Del[4]) = Ins[3, 'a'] else return Ins[p1 – 1, c1]; // Tid(Ins[3, 'a'], Del[1]) = Ins[2, 'a'] } Tdi(Del[p1], Ins[p2, c1]) { //   ,    } Tdd(Del[p1], Del[p2]) { if (p1 < p2) return Del[p1]; // Tdd(Del[3], Del[4]) = Del[3] else if (p1 > p2) return Del[p1 – 1]; // Tdd(Del[3], Del[1]) = Del[2] else return Id; // Id –   }

3. Google डॉक्स में इंटरेक्शन प्रोटोकॉल

आइए देखें कि Google डॉक्स में इंटरैक्शन प्रोटोकॉल और अधिक विस्तार से कैसे काम करता है। मान लीजिए कि हमारे पास एक सर्वर, पेट्या और वासा है, और उनके पास एक खाली दस्तावेज़ का एक सिंक्रनाइज़ संस्करण है।

प्रत्येक ग्राहक को निम्नलिखित जानकारी याद है:

सर्वर से प्राप्त अंतिम परिवर्तन का संस्करण (आईडी, संशोधन)।
स्थानीय रूप से किए गए सभी परिवर्तन लेकिन सर्वर पर नहीं भेजे गए (भेजना लंबित)
स्थानीय रूप से किए गए सभी परिवर्तन, सर्वर को भेजे गए, लेकिन सर्वर से पुष्टि के बिना।
दस्तावेज़ की वर्तमान स्थिति जिसे उपयोगकर्ता देखता है।

सर्वर, बदले में, याद रखता है:

प्राप्त सभी की सूची लेकिन संसाधित परिवर्तन (लंबित प्रसंस्करण) नहीं।
सभी संसाधित परिवर्तनों (संशोधन लॉग) का पूरा इतिहास।
अंतिम संसाधित परिवर्तन के समय दस्तावेज़ की स्थिति।

इसलिए, पेट्या दस्तावेज़ की शुरुआत में "हैलो" शब्द से शुरू होता है:

क्लाइंट ने पहले इस बदलाव को प्रतीक्षा सूची में जोड़ा, और फिर इसे सर्वर पर भेजा और परिवर्तनों को भेजे गए सूची में स्थानांतरित कर दिया।

पेट्या टाइप करना जारी रखती है और पहले से ही "हैबर" शब्द जोड़ चुकी है। उसी समय, वासा ने टाइप किया "!" अपने खाली स्थान में (उसने अभी तक पेटिना के परिवर्तन नहीं प्राप्त किए हैं) दस्तावेज़।

Petino

\ {इंसर्ट \ _ "हबर", \ @ 5 \}

$\ {इंसर्ट \ _ "हबर", \ @ 5 \}$ लंबित सूची में जोड़ा गया है, लेकिन अभी तक नहीं भेजा गया है, क्योंकि हम एक समय में एक से अधिक परिवर्तन नहीं भेज रहे हैं , और पिछले एक की पुष्टि अभी तक नहीं की गई है । हम यह भी नोट करते हैं कि सर्वर ने अपने संशोधन लॉग में पेटिट के परिवर्तनों को बचाया। फिर सर्वर उन्हें वास्या के पास भेजता है और पेट्या को पुष्टि भेजता है (कि पेटिना के पहले बदलाव सफलतापूर्वक संसाधित हो गए थे)

वास्या के ग्राहक को सर्वर से पेटिना के परिवर्तन प्राप्त होते हैं और सर्वर पर लंबित भेजने के संबंध में ओटी लागू करता है

\ {इंसर्ट \ "!, \ @ 0 \}

$\ {इंसर्ट \ "!, \ @ 0 \}$ । परिणाम 0 से 5 तक सम्मिलन सूचकांक में एक बदलाव है। हम यह भी नोट करते हैं कि दोनों ग्राहकों ने सर्वर के साथ अंतिम सिंक्रनाइज़ किए गए संशोधन की संख्या को 1 में अपडेट किया। अंत में, पेटिन क्लाइंट सर्वर से लंबित पुष्टि की सूची से संबंधित परिवर्तन को हटा देता है।

फिर पेट्या और वासा सर्वर में अपने बदलाव भेजते हैं।

सर्वर, पेटीना के पहले (दर्ज आदेश के बारे में) वसीनिख के बदलावों को प्राप्त करता है, इसलिए वह पहले उन्हें संसाधित करता है, और पेट्या को पुष्टि भेजता है। वह उन्हें वस्या के पास भी भेजता है, और उनके ग्राहक उन्हें उन परिवर्तनों के बारे में बताते हैं जिनकी पुष्टि अभी तक नहीं हुई है

\ {इंसर्ट \ _! ', \ @ 5 \}

$\ {इंसर्ट \ _! ', \ @ 5 \}$ ।

फिर महत्वपूर्ण बिंदु आता है। सर्वर वासियों के परिवर्तनों को संसाधित करना शुरू कर देता है, जो कि, वास्या के अनुसार, संशोधन संख्या 2 है। लेकिन सर्वर ने पहले से ही 2 नंबर पर बदलाव किए हैं, इसलिए यह उन सभी परिवर्तनों पर रूपांतरण लागू करता है जो वासना के ग्राहक को अभी तक पता नहीं है (इस मामले में) -

\ {इंसर्ट \ _ "हबर", \ @ 5 \}

$\ {इंसर्ट \ _ "हबर", \ @ 5 \}$ ), और 3 नंबर पर परिणाम बचाता है।

जैसा कि हम देख सकते हैं, पेटिन के पाठ को समायोजित करने के लिए वासिन के परिवर्तन में सूचकांक को 5 से बढ़ा दिया गया था।

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

4. ईथरपद

आइए एक और समान एप्लिकेशन को देखें जहां ओटी का उपयोग किया जाता है - सह-संपादन etherpad.org के साथ ऑनलाइन संपादक का ओपन सोर्स प्रोजेक्ट

एथरपैड में, रूपांतरण कार्य थोड़े अलग होते हैं - परिवर्तन के सेट के रूप में सर्वर को परिवर्तन भेजे जाते हैं (परिवर्तन) , परिभाषित

$(\ ell_1 \ rightarrow \ ell_2) [c_1, c_2, c_3, ...],$

जहाँ

$\ ell_1$ : संपादन से पहले दस्तावेज़ की लंबाई।
$\ ell_2$ : संपादन के बाद दस्तावेज़ की लंबाई।
c1,c2,c3,... - संपादन के बाद दस्तावेज़ का विवरण। अगर ci एक संख्या (या संख्याओं की एक सीमा) है, तो ये मूल दस्तावेज़ के पात्रों के सूचक हैं जो संपादन (बनाए रखने) के बाद बने रहेंगे, और यदि ci - एक चरित्र (या स्ट्रिंग), तो यह प्रविष्टि है।

एक उदाहरण:
1. $ इनलाइन $ `` '' + \ _ (0 \ सही मूल्य 6) [`` हैलो '' = = `` हैलो '' इनलाइन $
2. $ इनलाइन $ `` बेवर ”+ (4 \ rightarrow 4) [` `हा”, \ 2-3] = `` हैबर $ इनलाइन $

जैसा कि आप पहले से ही समझते हैं, अंतिम दस्तावेज़ एक खाली दस्तावेज़ के क्रम में ऐसे परिवर्तनों के अनुक्रम के रूप में बनता है।

ध्यान दें कि हम अन्य प्रतिभागियों से परिवर्तन लागू नहीं कर सकते हैं (यह, सिद्धांत रूप में, Google डॉक्स में संभव है), क्योंकि दस्तावेजों की कुल लंबाई भिन्न हो सकती है।
उदाहरण के लिए, यदि स्रोत दस्तावेज़ लंबाई n का था, और हमारे दो परिवर्तन हैं:

$A = (n \ rightarrow n_a) [\ cdots] \\ B = (n \ rightarrow n_b) [\ cdots],$

$ए (बी)$ असंभव है, क्योंकि

$ए$ दस्तावेज़ की लंबाई की आवश्यकता है

$एन$ और उसके बाद

$ब$ वह लंबाई का होगा

$n_b$ ।
इस स्थिति को हल करने के लिए, एथरपैड एक मर्ज तंत्र का उपयोग करता है: यह एक फ़ंक्शन है जिसे द्वारा चिह्नित किया जाता है

$m (A, B)$ दस्तावेज़ की उसी स्थिति पर इनपुट में दो परिवर्तन स्वीकार करता है (बाद में इसे संदर्भित करता है

$X$ ) और एक नया परिवर्तन करता है।

आवश्यक है कि

$m (A, B) = m (B, A)$

ध्यान दें कि परिवर्तनों वाले ग्राहक के लिए

$ए$ जिसने परिवर्तन प्राप्त किया

$ब$ इसका कोई मतलब नहीं है

$m (A, B)$ जैसा

$m (A, B)$ पर लागू होता है

$X$ , और

$ए$ वर्तमान स्थिति

$ए (एक्स)$ । वास्तव में, हमें गणना करने की आवश्यकता है

$ए ’$ और

$ब ’$ ऐसा है

$B '(A (X)) = A' (B (X)) = m (A, B) (X)$

समारोह की गणना

$ए ’$ और

$ब ’$ को फॉलो कहा जाता है और इसे निम्नानुसार परिभाषित किया जाता है:

$f (A, B) (A) = f (B, A) (B) = m (A, B) = m (B, A)$
निर्माण एल्गोरिथ्म

$च (ए, बी)$ निम्नलिखित:

ए में डालने से सूचकांक बनते हैं $च (ए, बी)$
B में इन्सर्ट इन्सर्ट इन हो जाता है $च (ए, बी)$
A और B में मिलान सूचकांकों को ले जाता है $च (ए, बी)$

एक उदाहरण:

$ $ $ $ $ X = (0 \ सही मूल्य 8) [`` बेसबॉल ”] \\ ए = (8 \ सही गौरैया 5) [0 - 1,` `सी”, 7] \ / \ \!! = == `` तुलसी ”\\ बी = (8 \ rightarrow 5) [0,` `ई”, 6, `` उल्लू ”\ _ \ _! \ _! = ==` `नीचे” $ $ प्रदर्शन $ $!

हम गणना करते हैं:

$A '= f (B, A) = (5 \ rightarrow 6) [0, 1, `` si', 3, 4] \\ B '= f (A, B) = (5 \ rightarrow 6) [ 0, "ई", 2, 3, `` ओव '] \\ एम (ए, बी) = एम (बी, ए) = ए (बी') = बी (ए ') = (8 \ राइटरो 6) [ 0, `` esiow ”] \\$

गणना

$m (A, B) (X)$ एक अभ्यास के रूप में की पेशकश की।

इंटरैक्शन प्रोटोकॉल अनिवार्य रूप से Google डॉक्स के समान है, जब तक कि गणना थोड़ी अधिक जटिल न हो।

5. ओटी की आलोचना

प्रोग्रामिंग के लिहाज से OT को लागू करना बहुत ही मुश्किल काम है। विकीपीडिया से उद्धृत करते हुए: शेयर.जेएस लाइब्रेरी के डेवलपर और पूर्व Google Wave इंजीनियर जोसेफ जेंटल ने कहा, "दुर्भाग्य से, Pins को लागू करना। अलग-अलग ट्रेडऑफ के साथ एक लाख एल्गोरिदम हैं, जो ज्यादातर अकादमिक पेपर में फंसे हैं। एल्गोरिदम वास्तव में कठिन हैं और सही ढंग से लागू होने में समय लगता है। [...] वेव को लिखने में 2 साल लग गए और अगर हमने आज इसे फिर से लिखा, तो दूसरी बार लिखने में लगभग उतना ही समय लगेगा। "

(दुर्भाग्य से, ओटी लिखना बहुत मुश्किल है। उनके पेशेवरों और विपक्षों के साथ एक लाख एल्गोरिदम हैं, लेकिन उनमें से ज्यादातर केवल अकादमिक अध्ययन हैं। एल्गोरिदम वास्तव में बहुत जटिल हैं और उनके सही कार्यान्वयन के लिए बहुत समय की आवश्यकता है। [...] हमने 2 साल बिताए। राइटिंग वेव, और अगर हमें इसे आज फिर से लिखना होता, तो हमें उतना ही समय लगता।)
आपको दस्तावेज़ में हर परिवर्तन को सहेजना होगा

परिचालन परिवर्तनों का उपयोग करते हुए स्वचालित संघर्ष संकल्प