मास्को एक्सचेंज के व्यापार और समाशोधन प्रणाली की वास्तुकला का विकास। भाग 1

सभी को नमस्कार! मेरा नाम सर्गेई कोस्तानबाव है, एक्सचेंज में मैं ट्रेडिंग सिस्टम का मूल विकास कर रहा हूं।

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

हम सभी वर्गों की परिसंपत्तियों का व्यापार करने और विनिमय सेवाओं की एक पूरी श्रृंखला प्रदान करने के लिए दुनिया के कुछ एक्सचेंजों में से एक हैं। उदाहरण के लिए, पिछले साल हम बॉन्ड ट्रेडिंग के मामले में दुनिया में दूसरे स्थान पर थे, सभी स्टॉक एक्सचेंजों में 25 वें, सार्वजनिक एक्सचेंजों के बीच पूंजीकरण द्वारा 13 वें स्थान पर।



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

थोड़ा सा इतिहास

1994 में, मॉस्को इंटरबैंक करेंसी एक्सचेंज (MICEX) पर ऑस्ट्रेलियाई एएसटीएस प्रणाली शुरू की गई थी, और इस क्षण से आप इलेक्ट्रॉनिक ट्रेडिंग के रूसी इतिहास को गिन सकते हैं। 1998 में इंटरनेट ट्रेडिंग की शुरुआत के लिए एक्सचेंज के आर्किटेक्चर का आधुनिकीकरण किया गया था। तब से, सभी प्रणालियों और उप-प्रणालियों में नए समाधान और स्थापत्य परिवर्तनों को पेश करने की गति केवल गति प्राप्त कर रही है।

उन वर्षों में, एक्सचेंज सिस्टम ने हाई-एंड हार्डवेयर पर काम किया - अत्यधिक विश्वसनीय एचपी सुपरडोम 9000 सर्वर ( पीए-आरआईएससी आर्किटेक्चर पर बनाया गया), जिसने बिल्कुल सब कुछ डुप्लिकेट किया: I / O सबसिस्टम, नेटवर्क, रैम (वास्तव में, RAM से एक RAID सरणी थी ), प्रोसेसर (गर्म स्वैपिंग समर्थित)। मशीन को बंद किए बिना सर्वर के किसी भी घटक को बदलना संभव था। हमने इन उपकरणों पर भरोसा किया, उन्हें वास्तव में परेशानी से मुक्त माना। ऑपरेटिंग सिस्टम यूनिक्स-जैसे एचपी यूएक्स था।

लेकिन 2010 के बाद से, हाई-फ़्रीक्वेंसी ट्रेडिंग (HFT), या फ़्री-फ़्रीक्वेंसी ट्रेडिंग, सीधे शब्दों में कहें तो, रोबोट का आदान-प्रदान हुआ है। केवल 2.5 वर्षों में, हमारे सर्वर पर लोड 140 गुना बढ़ गया है।



पुरानी वास्तुकला और उपकरणों के साथ इस तरह के भार का सामना करना असंभव था। किसी तरह अनुकूलन करना आवश्यक था।

शुरुआत

विनिमय प्रणाली के अनुरोधों को दो प्रकारों में विभाजित किया जा सकता है:

• लेन-देन। यदि आप डॉलर, स्टॉक या कुछ और खरीदना चाहते हैं, तो ट्रेडिंग सिस्टम को लेनदेन भेजें और सफलता के बारे में प्रतिक्रिया प्राप्त करें।
• सूचना अनुरोध। यदि आप वर्तमान मूल्य जानना चाहते हैं, तो ऑर्डर बुक या इंडेक्स देखें, तो सूचना अनुरोध भेजें।

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

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

ट्रेडिंग सिस्टम का मुख्य एक मुश्किल इन-मेमोरी डेटाबेस है जिसमें सभी लेन-देन विनिमय लेनदेन हैं। आधार को C में लिखा गया था, बाहरी निर्भरता में केवल libc पुस्तकालय था और पूरी तरह से कोई गतिशील मेमोरी आवंटन नहीं था। प्रसंस्करण समय को कम करने के लिए, सिस्टम सरणियों के एक स्थिर सेट के साथ और डेटा के स्थैतिक स्थानांतरण के साथ शुरू होता है: सबसे पहले, वर्तमान दिन के लिए सभी डेटा को मेमोरी में लोड किया जाता है, और फिर कोई डिस्क एक्सेस नहीं किया जाता है, सभी काम केवल मेमोरी में किया जाता है। जब सिस्टम शुरू होता है, तो सभी संदर्भ डेटा पहले से ही सॉर्ट किए जाते हैं, इसलिए खोज बहुत कुशलता से काम करती है और रनटाइम में बहुत कम समय लेती है। सभी तालिकाओं को गतिशील डेटा संरचनाओं के लिए घुसपैठ सूचियों और पेड़ों के साथ बनाया गया है ताकि उन्हें रनटाइम में मेमोरी आवंटन की आवश्यकता न हो।

आइए संक्षेप में हमारे व्यापार और समाशोधन प्रणाली के विकास के इतिहास पर जाएं।
ट्रेडिंग और क्लियरिंग सिस्टम की वास्तुकला का पहला संस्करण तथाकथित यूनिक्स इंटरैक्शन पर बनाया गया था: साझा मेमोरी, सेमाफोर और क्वीन्स का उपयोग किया गया था, और प्रत्येक प्रक्रिया में एक धागा शामिल था। 1990 के दशक की शुरुआत में यह दृष्टिकोण व्यापक था।

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

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

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

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

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

SystemV IPC में कतार, मेमोरी और सेमाफोर ऑब्जेक्ट की स्थिति देखने के लिए उपयोगिताओं शामिल हैं। हमने यह समझने के लिए सक्रिय रूप से इसका उपयोग किया कि एक विशेष क्षण में सिस्टम में क्या हो रहा है, जहां पैकेट जमा हो रहे हैं, जो अवरुद्ध है, आदि।

पहला आधुनिकीकरण

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

उच्च आवृत्ति व्यापार का प्रभाव

आर्किटेक्चर का उपरोक्त संस्करण 2010 तक चला। इस बीच, हम एचपी सुपरडोम सर्वर के प्रदर्शन से संतुष्ट नहीं थे। इसके अलावा, पीए-आरआईएससी वास्तुकला वास्तव में मर गया, विक्रेता ने कोई महत्वपूर्ण अपडेट नहीं दिया। परिणामस्वरूप, हमने HP UX / PA RISC से Linux / x86 पर स्विच करना शुरू किया। संक्रमण का उपयोग एक्सेस सर्वर के अनुकूलन के साथ शुरू हुआ।

हमें फिर से वास्तुकला को क्यों बदलना पड़ा? तथ्य यह है कि उच्च आवृत्ति ट्रेडिंग ने सिस्टम कोर के लोड प्रोफाइल को महत्वपूर्ण रूप से बदल दिया है।

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



50 एमएस के अंतराल पर, औसत गति प्रति सेकंड 16 हजार लेनदेन है। यदि आप विंडो को 20 एमएस तक कम करते हैं, तो हमें प्रति सेकंड 90 हजार लेनदेन की औसत गति मिलती है, और चरम पर 200 हजार लेनदेन होंगे। दूसरे शब्दों में, लोड अस्थिर है, तेज फटने के साथ। और अनुरोध कतार को हमेशा जल्दी से संसाधित किया जाना चाहिए।

लेकिन एक कतार क्यों है? इसलिए, हमारे उदाहरण में, कई उपयोगकर्ताओं ने मूल्य परिवर्तन पर ध्यान दिया और संबंधित लेनदेन भेजें। वे गेटवे पर आते हैं, वह उन्हें सीरियल करता है, एक निश्चित क्रम सेट करता है और उन्हें नेटवर्क पर भेजता है। राउटर पैकेट मिलाते हैं और उन्हें आगे बढ़ाते हैं। जिसका पैकेज पहले आया था, वह लेनदेन "जीता"। नतीजतन, एक्सचेंज ग्राहकों ने नोटिस करना शुरू कर दिया कि यदि एक ही लेनदेन कई गेटवे से भेजा गया था, तो इसके त्वरित प्रसंस्करण की संभावना बढ़ जाती है। जल्द ही, एक्सचेंज रोबोट ने अनुरोधों के साथ गेटवे पर बमबारी शुरू कर दी, और लेनदेन का एक हिमस्खलन पैदा हुआ।

विकास का एक नया दौर

व्यापक परीक्षण और अनुसंधान के बाद, हमने ऑपरेटिंग सिस्टम के वास्तविक समय कर्नेल पर स्विच किया। ऐसा करने के लिए, उन्होंने RedHat Enterprise MRG Linux को चुना, जहाँ MRG का वास्तविक समय ग्रिड संदेश देने के लिए है। वास्तविक समय के पैच का लाभ यह है कि वे सबसे तेज़ संभव निष्पादन के लिए सिस्टम का अनुकूलन करते हैं: सभी प्रक्रियाओं को एक फीफो कतार में व्यवस्थित किया जाता है, आप गुठली को अलग कर सकते हैं, कोई बूंद नहीं, सभी लेनदेन को सख्त अनुक्रम में संसाधित किया जाता है।


लाल - एक नियमित कर्नेल में एक कतार के साथ काम करते हैं, हरे - एक वास्तविक समय कर्नेल में काम करते हैं।

लेकिन नियमित सर्वर पर कम विलंबता प्राप्त करना इतना सरल नहीं है:

• SMI मोड, जो x86 आर्किटेक्चर में महत्वपूर्ण परिधीयों के साथ काम करने के दिल में है, बहुत हस्तक्षेप करता है। विभिन्न हार्डवेयर घटनाओं को संसाधित करना और घटकों और उपकरणों को तथाकथित पारदर्शी एसएमआई मोड में फर्मवेयर द्वारा निष्पादित किया जाता है, जिसमें ऑपरेटिंग सिस्टम यह नहीं देखता है कि फर्मवेयर बिल्कुल क्या कर रहा है। एक नियम के रूप में, सभी प्रमुख विक्रेता फर्मवेयर सर्वर के लिए विशेष एक्सटेंशन प्रदान करते हैं, जो एसएमआई प्रसंस्करण की मात्रा को कम करने की अनुमति देता है।
• प्रोसेसर आवृत्ति का कोई गतिशील नियंत्रण नहीं होना चाहिए, इससे अतिरिक्त डाउनटाइम होता है।
• जब फ़ाइल सिस्टम लॉग रीसेट हो जाता है, तो कर्नेल में कुछ प्रक्रियाएँ होती हैं जो अप्रत्याशित देरी का कारण बनती हैं।
• आपको CPU Affinity, Interrupt affinity, NUMA जैसी चीजों पर ध्यान देने की आवश्यकता है।

मुझे कहना होगा कि वास्तविक समय के लिए लिनक्स हार्डवेयर और कर्नेल को कॉन्फ़िगर करने का विषय एक अलग लेख के योग्य है। अच्छा परिणाम हासिल करने से पहले हमने प्रयोगों और अनुसंधान पर बहुत समय बिताया।

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

X86 पर स्विच करने के बाद, उत्पादकता लगभग तीन गुना बढ़ गई, औसत लेनदेन प्रसंस्करण समय घटकर 60 μs हो गया।

आइए अब इस बात पर करीब से नज़र डालते हैं कि सिस्टम आर्किटेक्चर में क्या महत्वपूर्ण बदलाव किए गए हैं।

हॉट स्टैंडबाय महाकाव्य

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

इसके अलावा, अन्य आवश्यकताएं थीं:

• किसी भी मामले में आपको संसाधित लेनदेन नहीं खोना चाहिए।
• सिस्टम हमारे बुनियादी ढांचे के लिए बिल्कुल पारदर्शी होना चाहिए।
• ग्राहकों को कनेक्शन विराम नहीं देखना चाहिए।
• आरक्षण को एक महत्वपूर्ण देरी का परिचय नहीं देना चाहिए, क्योंकि यह विनिमय के लिए एक महत्वपूर्ण कारक है।

हॉट स्टैंडबाय सिस्टम बनाते समय, हमने ऐसे परिदृश्यों को दोहरी विफलताओं के रूप में नहीं माना (उदाहरण के लिए, एक सर्वर पर नेटवर्क ने काम करना बंद कर दिया और मुख्य सर्वर लटका दिया); सॉफ़्टवेयर में त्रुटियों की संभावना पर विचार नहीं किया, क्योंकि परीक्षण के दौरान उनका पता लगाया गया है; और लोहे की खराबी पर विचार नहीं किया।

परिणामस्वरूप, हम निम्नलिखित योजना में आए:

• मुख्य सर्वर ने सीधे गेटवे सर्वर के साथ बातचीत की।
• मुख्य सर्वर पर प्राप्त सभी लेनदेन तुरंत एक अलग चैनल के माध्यम से बैकअप सर्वर पर दोहराया गया। रेफरी (गवर्नर) ने किसी भी समस्या के होने पर स्विच का समन्वय किया।
  
  
• मुख्य सर्वर ने प्रत्येक लेनदेन को संसाधित किया और बैकअप सर्वर से पुष्टि की प्रतीक्षा की। देरी को कम करने के लिए, हमने बैकअप सर्वर पर लेनदेन पूरा होने की प्रतीक्षा करने से इनकार कर दिया। चूंकि नेटवर्क पर लेन-देन की अवधि लेनदेन की अवधि के बराबर थी, इसलिए कोई अतिरिक्त विलंब नहीं जोड़ा गया था।
• हम केवल पिछले लेनदेन के लिए मुख्य और बैकअप सर्वर की प्रसंस्करण स्थिति को सत्यापित कर सकते हैं, और वर्तमान लेनदेन की प्रसंस्करण स्थिति अज्ञात थी। चूंकि सिंगल-थ्रेडेड प्रक्रियाएं अभी भी यहां उपयोग की जाती थीं, बैकअप से प्रतिक्रिया की प्रतीक्षा में पूरे प्रसंस्करण प्रवाह धीमा हो जाएगा, और इसलिए हमने एक उचित समझौता किया: हमने पिछले लेनदेन के परिणाम की जांच की।

योजना निम्नानुसार काम की।

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

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

जारी रखा जाए।