भर्खरै, टेलिग्राम कत्तिको राम्रो छ, डुरोभ भाइहरू नेटवर्क प्रणालीहरू निर्माणमा कत्तिको प्रतिभाशाली र अनुभवी छन्, इत्यादि पोस्टहरू हब्रेमा धेरै पटक देखा पर्न थालेका छन्। एकै समयमा, धेरै थोरै व्यक्तिहरूले वास्तवमै प्राविधिक उपकरणमा आफूलाई डुबेका छन् - धेरैमा, तिनीहरूले एकदम सरल (र MTProto भन्दा धेरै फरक) JSON-आधारित Bot API प्रयोग गर्छन्, र सामान्यतया स्वीकार्छन्। विश्वास मा सबै प्रशंसा र PR जुन मेसेन्जरको वरिपरि घुम्छ। लगभग डेढ वर्ष पहिले, एशेलोन एनजीओ भासिलीमा मेरो सहकर्मी (दुर्भाग्यवश, मस्यौदासँगै हब्रेमा उनको खाता मेटाइएको थियो) पर्लमा स्क्र्याचबाट आफ्नै टेलिग्राम क्लाइन्ट लेख्न थाले, र पछि यी लाइनहरूको लेखक सामेल भए। किन पर्ल, केहि तुरुन्तै सोध्नेछ? किनभने त्यस्ता परियोजनाहरू अन्य भाषाहरूमा पहिले नै अवस्थित छन्। वास्तवमा, यो कुरा होइन, त्यहाँ कुनै अन्य भाषा हुन सक्छ जहाँ त्यहाँ छैन। तयार पुस्तकालय, र तदनुसार लेखक सबै बाटो जानुपर्छ सुरुबाट। यसबाहेक, क्रिप्टोग्राफी विश्वासको कुरा हो, तर प्रमाणित गर्नुहोस्। सुरक्षाको उद्देश्यले उत्पादनको साथ, तपाइँ केवल निर्माताबाट तयार-बनाइएको पुस्तकालयमा भर पर्न सक्नुहुन्न र यसलाई अन्धाधुन्ध विश्वास गर्न सक्नुहुन्न (यद्यपि, यो दोस्रो भागको लागि विषय हो)। यस समयमा, पुस्तकालयले "औसत" स्तरमा राम्रोसँग काम गर्दछ (तपाईंलाई कुनै पनि API अनुरोधहरू गर्न अनुमति दिन्छ)।

यद्यपि, पोष्टहरूको यो श्रृंखलामा धेरै क्रिप्टोग्राफी वा गणित हुनेछैन। तर त्यहाँ धेरै अन्य प्राविधिक विवरणहरू र वास्तुशिल्प बैसाखीहरू हुनेछन् (यसका लागि पनि उपयोगी छ जसले स्क्र्याचबाट लेख्दैनन्, तर पुस्तकालयलाई कुनै पनि भाषामा प्रयोग गर्नेछ)। त्यसोभए, मुख्य लक्ष्य ग्राहकलाई स्क्र्याचबाट लागू गर्ने प्रयास गर्नु थियो आधिकारिक दस्तावेज अनुसार। त्यो हो, मानौं कि आधिकारिक ग्राहकहरूको स्रोत कोड बन्द छ (फेरि, दोस्रो भागमा हामी यो सत्य हो भन्ने तथ्यको विषयलाई थप विस्तारमा कभर गर्नेछौं। यो हुन्छ त्यसोभए), तर, पुरानो दिनहरूमा जस्तै, उदाहरणका लागि, त्यहाँ RFC जस्तै मानक छ - के यो स्रोत कोडमा "नहेरेकन" एक्लै निर्दिष्टीकरण अनुसार ग्राहक लेख्न सम्भव छ, यो आधिकारिक होस् (टेलीग्राम डेस्कटप, मोबाइल) वा अनौपचारिक टेलिथन?

सामग्री तालिका:

कागजात ... यो अवस्थित छ, हैन? के यो साँचो हो?..
एक युवा लेखकको रूपमा कहाँ सुरु गर्ने?
बाइनरी क्रमिकरण: TL (प्रकार भाषा) र यसको योजना, र तहहरू, र धेरै अन्य डरलाग्दो शब्दहरू
MT प्रोटो
API?
फेरि जारी राखौंला!

कागजात ... यो अवस्थित छ, हैन? के यो साँचो हो?..

यस लेखको लागि नोटका टुक्राहरू गत गर्मीमा सङ्कलन गर्न थाले। यो सबै समय आधिकारिक वेबसाइटमा https://core.telegram.org कागजात लेयर 23 को रूपमा थियो, अर्थात्। 2014 मा कतै अड्कियो (याद गर्नुहोस्, त्यहाँ च्यानलहरू पनि थिएनन्?)। निस्सन्देह, सिद्धान्तमा, यसले हामीलाई 2014 मा त्यस समयमा कार्यक्षमताको साथ ग्राहकलाई कार्यान्वयन गर्न अनुमति दिनुपर्छ। तर यस अवस्थामा पनि, कागजात, पहिलो, अपूर्ण, र दोस्रो, ठाउँहरूमा यो आफैंमा विरोधाभास थियो। एक महिना अघि, सेप्टेम्बर 2019 मा, यो थियो गल्ती यो पत्ता लाग्यो कि साइटमा कागजातको ठूलो अपडेट थियो, हालैको लेयर 105 को लागि, नोटको साथ कि अब सबै कुरा फेरि पढ्न आवश्यक छ। वास्तवमा, धेरै लेखहरू परिमार्जन गरियो, तर धेरै अपरिवर्तित रहे। तसर्थ, कागजातको बारेमा तलको आलोचना पढ्दा, तपाईंले ध्यानमा राख्नु पर्छ कि यी मध्ये केहि चीजहरू अब सान्दर्भिक छैनन्, तर केहि अझै पनि पर्याप्त छन्। आखिर, आधुनिक संसारमा 5 वर्ष लामो समय मात्र होइन, तर धेरै एकदम धेरै। ती समयदेखि (विशेष गरी यदि तपाईंले खारेज गरिएका र पुनर्जीवित जियोच्याट साइटहरूलाई त्यसबेलादेखि ध्यानमा राख्नुभएन भने), योजनामा API विधिहरूको संख्या सय बाट बढेर दुई सय पचास भन्दा बढि भएको छ!

एक युवा लेखकको रूपमा कहाँ सुरु गर्ने?

तपाईले स्क्र्याचबाट लेख्नुहुन्छ वा प्रयोग गर्नुहुन्छ भन्ने कुराले फरक पार्दैन, उदाहरणका लागि, तयार पुस्तकालयहरू जस्तै पाइथनको लागि टेलिथन वा PHP को लागि मेडलाइन, कुनै पनि अवस्थामा, तपाईंलाई पहिले चाहिन्छ आफ्नो आवेदन दर्ता गर्नुहोस् - प्यारामिटरहरू प्राप्त गर्नुहोस् api_id и api_hash (जसले VKontakte API सँग काम गरेका छन् तुरुन्तै बुझ्छन्) जसद्वारा सर्भरले अनुप्रयोग पहिचान गर्नेछ। यो हुनेछ कानुनी कारणहरूका लागि यो गर्नुहोस्, तर हामी पुस्तकालयका लेखकहरूले यसलाई दोस्रो भागमा किन प्रकाशित गर्न सक्दैनन् भन्ने बारे थप कुरा गर्नेछौं। तपाईं परीक्षण मानहरूसँग सन्तुष्ट हुन सक्नुहुन्छ, यद्यपि तिनीहरू धेरै सीमित छन् - तथ्य यो हो कि अब तपाईं दर्ता गर्न सक्नुहुन्छ एउटा मात्र अनुप्रयोग, त्यसैले यसमा हेडलम हतार नगर्नुहोस्।

अब, प्राविधिक दृष्टिकोणबाट, हामीले यस तथ्यमा चासो राख्नुपर्छ कि दर्ता पछि हामीले टेलीग्रामबाट कागजातहरू, प्रोटोकल, इत्यादि अपडेटहरू बारे सूचनाहरू प्राप्त गर्नुपर्छ। त्यो हो, कसैले मान्न सक्छ कि डक्सको साथ साइट केवल त्यागिएको थियो र ग्राहकहरू बनाउन थालेकाहरूसँग विशेष रूपमा काम गर्न जारी राख्यो, किनभने यो सजिलो छ। तर अहँ, त्यस्तो केही देखिएको छैन, जानकारी आएको छैन ।

र यदि तपाइँ स्क्र्याचबाट लेख्नुहुन्छ भने, प्राप्त प्यारामिटरहरू प्रयोग गरेर वास्तवमा अझै लामो बाटो छ। यद्यपि https://core.telegram.org/ र तिनीहरूको बारेमा कुरा सुरु गर्न सुरु गर्नुहोस्, वास्तवमा, तपाईंले पहिले कार्यान्वयन गर्नुपर्नेछ MTProto प्रोटोकल - तर यदि तपाईले विश्वास गर्नुभयो भने OSI मोडेल अनुसार लेआउट प्रोटोकलको सामान्य विवरणको लागि पृष्ठको अन्त्यमा, त्यसपछि यो पूर्ण रूपमा व्यर्थ छ।

वास्तवमा, MTProto अघि र पछि दुवै, एकै पटक धेरै स्तरहरूमा (OS कर्नेलमा काम गर्ने विदेशी नेटवर्करहरूले लेयर उल्लङ्घन भन्छन्), एउटा ठूलो, पीडादायी र भयानक विषय आउनेछ...

बाइनरी क्रमिकरण: TL (प्रकार भाषा) र यसको योजना, र तहहरू, र धेरै अन्य डरलाग्दो शब्दहरू

यो विषय, वास्तवमा, टेलिग्रामको समस्याहरूको कुञ्जी हो। र त्यहाँ धेरै डरलाग्दो शब्दहरू हुनेछन् यदि तपाईंले यसलाई खोल्ने प्रयास गर्नुभयो भने।

त्यसैले, यहाँ रेखाचित्र छ। यदि यो शब्द तपाईको दिमागमा आयो भने भन्नुहोस्, JSON स्कीमा, तपाईले सहि सोच्नु भयो। लक्ष्य एउटै हो: प्रसारित डाटाको सम्भावित सेट वर्णन गर्न केही भाषा। यहाँ समानता समाप्त हुन्छ। यदि पृष्ठबाट MTProto प्रोटोकल, वा आधिकारिक ग्राहकको स्रोत रूखबाट, हामी केहि स्कीमा खोल्ने प्रयास गर्नेछौं, हामी केहि देख्नेछौं:

int ? = Int;
long ? = Long;
double ? = Double;
string ? = String;

vector#1cb5c415 {t:Type} # [ t ] = Vector t;

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

rpc_answer_unknown#5e2ad36e = RpcDropAnswer;
rpc_answer_dropped_running#cd78e586 = RpcDropAnswer;
rpc_answer_dropped#a43ad8b7 msg_id:long seq_no:int bytes:int = RpcDropAnswer;

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

---functions---

set_client_DH_params#f5045f1f nonce:int128 server_nonce:int128 encrypted_data:bytes = Set_client_DH_params_answer;

ping#7abe77ec ping_id:long = Pong;
ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

invokeAfterMsg#cb9f372d msg_id:long query:!X = X;
invokeAfterMsgs#3dc4b4f0 msg_ids:Vector<long> query:!X = X;

account.updateProfile#78515775 flags:# first_name:flags.0?string last_name:flags.1?string about:flags.2?string = User;
account.sendChangePhoneCode#8e57deb flags:# allow_flashcall:flags.0?true phone_number:string current_number:flags.0?Bool = auth.SentCode;

पहिलो पटक यो देख्ने व्यक्तिले सहज रूपमा लेखिएको अंश मात्र चिन्न सक्षम हुनेछ - ठीक छ, यी स्पष्ट रूपमा संरचनाहरू हुन् (यद्यपि नाम कहाँ छ, बायाँ वा दायाँ?), त्यहाँ क्षेत्रहरू छन्, जस पछि एक प्रकार कोलोन पछि पछ्याउँछ ... सम्भवतः। यहाँ कोण कोष्ठक मा C++ जस्तै टेम्प्लेटहरू छन् (वास्तवमा, वास्तवमा होइन)। र अन्य सबै प्रतीकहरूको अर्थ के हो, प्रश्न चिन्ह, विस्मयादिबोधक चिन्हहरू, प्रतिशतहरू, ह्यास चिन्हहरू (र स्पष्ट रूपमा तिनीहरूले फरक ठाउँहरूमा फरक चीजहरूको अर्थ राख्छन्), कहिले उपस्थित र कहिलेकाहीँ होइन, हेक्साडेसिमल संख्याहरू - र सबैभन्दा महत्त्वपूर्ण कुरा, यसबाट कसरी प्राप्त गर्ने। सहि (जसलाई सर्भरले अस्वीकार गर्दैन) बाइट स्ट्रिम? तपाईंले कागजात पढ्नु पर्छ (हो, त्यहाँ नजिकैको JSON संस्करणमा स्कीमाको लिङ्कहरू छन् - तर यसले यसलाई स्पष्ट बनाउँदैन).

पृष्ठ खोल्नुहोस् बाइनरी डाटा क्रमिकरण र च्याउ र छुट्टै गणितको जादुई संसारमा डुब्नुहोस्, 4th वर्ष मा matan जस्तै केहि। वर्णमाला, प्रकार, मान, कम्बिनेटर, कार्यात्मक कम्बिनेटर, सामान्य रूप, कम्पोजिट प्रकार, बहुरूपी प्रकार ... र यो केवल पहिलो पृष्ठ हो! अर्को तपाईलाई पर्खिरहेको छ TL भाषा, जसमा, यद्यपि यसले पहिले नै मामूली अनुरोध र प्रतिक्रियाको उदाहरण समावेश गर्दछ, यसले थप सामान्य केसहरूमा कुनै जवाफ प्रदान गर्दैन, जसको मतलब यो हो कि तपाईंले अर्को आठ एम्बेडेडमा रूसीबाट अंग्रेजीमा अनुवाद गरिएको गणितको रिटेलिंग मार्फत वेड गर्नुपर्नेछ। पृष्ठहरू!

कार्यात्मक भाषाहरू र स्वचालित प्रकारको अनुमानसँग परिचित पाठकहरूले निस्सन्देह, यस भाषामा वर्णन भाषा देख्नेछन्, उदाहरणबाट पनि, धेरै परिचित रूपमा, र भन्न सक्छन् कि यो वास्तवमा सिद्धान्तमा खराब छैन। यसमा रहेका आपत्तिहरु यस्ता छन् :

हो, लक्ष्य राम्रो सुनिन्छ, तर अफसोस, उनी हासिल गरेको छैन
रूसी विश्वविद्यालयहरूमा शिक्षा आईटी विशेषताहरूमा पनि भिन्न हुन्छ - सबैले समान पाठ्यक्रम लिएका छैनन्
अन्तमा, हामी देख्नेछौं, व्यवहारमा यो छ आवश्यक छैन, वर्णन गरिएको TL को मात्र सीमित उपसेट प्रयोग गरिएको छ

जस्तो भनियो लियोनेर्ड च्यानलमा #perl FreeNode IRC नेटवर्कमा, जसले टेलिग्रामबाट म्याट्रिक्समा गेट लागू गर्ने प्रयास गर्यो (उद्धरणको अनुवाद मेमोरीबाट गलत छ):

यस्तो लाग्छ कि कसैलाई पहिलो पटक थ्योरी टाइप गर्न पेश गरिएको थियो, उत्साहित भयो, र यसको वरिपरि खेल्ने प्रयास गर्न थाल्यो, वास्तवमा यो अभ्यासमा आवश्यक छ कि छैन वास्ता गर्दैन।

आफैलाई हेर्नुहोस्, यदि बेयर-टाइपहरू (int, long, etc.) को लागि प्राथमिक चीजको रूपमा प्रश्न उठाउँदैन - अन्ततः तिनीहरू म्यानुअल रूपमा लागू गरिनुपर्छ - उदाहरणका लागि, तिनीहरूबाट व्युत्पन्न गर्ने प्रयास गरौं। भेक्टर। त्यो हो, वास्तवमा, एर्रे, यदि तपाईंले नतिजा वस्तुहरूलाई तिनीहरूको उचित नामले कल गर्नुहुन्छ।

तर पहिले

आधिकारिक कागजातहरू नपढ्नेहरूका लागि TL सिन्ट्याक्सको सबसेटको छोटो विवरण

constructor = Type;
myVec ids:Vector<long> = Type;

fixed#abcdef34 id:int = Type2;

fixedVec set:Vector<Type2> = FixedVec;

constructorOne#crc32 field1:int = PolymorType;
constructorTwo#2crc32 field_a:long field_b:Type3 field_c:int = PolymorType;
constructorThree#deadcrc bit_flags_of_what_really_present:# optional_field4:bit_flags_of_what_really_present.1?Type = PolymorType;

an_id#12abcd34 id:int = Type3;
a_null#6789cdef = Type3;

परिभाषा सधैं सुरु हुन्छ कन्स्ट्रक्टर, त्यसपछि वैकल्पिक रूपमा (अभ्यासमा - सधैं) प्रतीक मार्फत # हुनुपर्छ सीआरसी ३32 यस प्रकारको सामान्यीकृत वर्णन स्ट्रिङबाट। अर्को फिल्डहरूको विवरण आउँछ; यदि तिनीहरू अवस्थित छन् भने, प्रकार खाली हुन सक्छ। यो सबै बराबर चिन्हको साथ समाप्त हुन्छ, यो कन्स्ट्रक्टरको प्रकारको नाम - त्यो हो, वास्तवमा, उपप्रकार - सम्बन्धित छ। बराबर चिन्हको दायाँपट्टिको मान्छे हो बहुरूपी - त्यो हो, धेरै विशिष्ट प्रकारहरू यसको अनुरूप हुन सक्छ।

यदि परिभाषा रेखा पछि हुन्छ ---functions---, त्यसपछि वाक्यविन्यास उस्तै रहनेछ, तर अर्थ फरक हुनेछ: कन्स्ट्रक्टर RPC प्रकार्यको नाम हुनेछ, क्षेत्रहरू प्यारामिटरहरू हुनेछन् (राम्रो, त्यो हो, यो ठ्याक्कै एउटै संरचना रहनेछ, जस्तै तल वर्णन गरिएको छ। , यो बस तोकिएको अर्थ हुनेछ), र "पोलिमोर्फिक प्रकार " - फिर्ता परिणाम को प्रकार। साँचो, यो अझै पनि बहुरूपी रहनेछ - केवल खण्डमा परिभाषित ---types---, तर यो कन्स्ट्रक्टर "मानिनेछैन"। तिनीहरूका तर्कहरूद्वारा भनिएका प्रकार्यहरू ओभरलोड गर्दै, अर्थात्। कुनै कारणले, एउटै नामका तर फरक हस्ताक्षरहरू भएका धेरै कार्यहरू, जस्तै C++ मा, TL मा उपलब्ध गराइँदैन।

किन "कन्स्ट्रक्टर" र "पोलिमोर्फिक" यदि यो OOP होइन? ठीक छ, वास्तवमा, यो OOP सर्तहरूमा कसैको लागि यो सोच्न सजिलो हुनेछ - एक अमूर्त वर्गको रूपमा बहुरूपी प्रकार, र निर्माणकर्ताहरू यसको प्रत्यक्ष वंशज वर्गहरू हुन्, र final धेरै भाषाहरूको शब्दावलीमा। वास्तवमा, निस्सन्देह, यहाँ मात्र समानता OO प्रोग्रामिङ भाषाहरूमा वास्तविक ओभरलोड कन्स्ट्रक्टर विधिहरूसँग। यहाँ केवल डेटा संरचनाहरू भएकोले, त्यहाँ कुनै विधिहरू छैनन् (यद्यपि कार्यहरू र विधिहरूको विवरणले तिनीहरू अवस्थित छन् भन्ने कुरामा भ्रम सिर्जना गर्न सक्षम छ, तर त्यो फरक कुरा हो) - तपाईं कन्स्ट्रक्टरलाई मानको रूपमा सोच्न सक्नुहुन्छ। जुन निर्माण भइरहेको छ बाइट स्ट्रिम पढ्दा टाइप गर्नुहोस्।

यो कसरी हुन्छ? deserializer, जसले सधैं 4 बाइटहरू पढ्छ, मान देख्छ 0xcrc32 - र त्यसपछि के हुनेछ बुझ्छ field1 प्रकार संग int, अर्थात् ठ्याक्कै ४ बाइट्स पढ्छ, यसमा प्रकारको साथ ओभरलाइङ फिल्ड PolymorType पढ्नुहोस्। देख्छ 0x2crc32 र बुझ्छ कि त्यहाँ दुई क्षेत्रहरू छन्, पहिले long, जसको मतलब हामी 8 बाइटहरू पढ्छौं। र त्यसपछि फेरि एक जटिल प्रकार, जो उही तरिका deserialized छ। उदाहरणका लागि, Type3 क्रमशः दुई कन्स्ट्रक्टरको रूपमा सर्किटमा घोषणा गर्न सकिन्छ, त्यसपछि तिनीहरू या त भेट्नुपर्छ 0x12abcd34, जस पछि तपाईंले 4 थप बाइटहरू पढ्न आवश्यक छ int, वा 0x6789cdef, त्यसपछि त्यहाँ केहि हुनेछैन। अरू केहि - तपाइँ एक अपवाद फेंक गर्न आवश्यक छ। जे भए पनि, यस पछि हामी 4 बाइटहरू पढ्न फर्कन्छौं int क्षेत्रहरु field_c в constructorTwo र हामी हाम्रो पढाइ समाप्त गर्छौं PolymorType.

अन्तमा, यदि तपाईं समात्नु भयो 0xdeadcrc लागि constructorThreeत्यसपछि सबै कुरा थप जटिल हुन्छ। हाम्रो पहिलो क्षेत्र हो bit_flags_of_what_really_present प्रकार संग # - वास्तवमा, यो प्रकारको लागि मात्र एक उपनाम हो nat, अर्थ "प्राकृतिक संख्या"। त्यो हो, वास्तवमा, अहस्ताक्षरित int, वैसे, एक मात्र केस हो जब अहस्ताक्षरित संख्याहरू वास्तविक सर्किटहरूमा देखा पर्दछ। त्यसोभए, अर्को प्रश्न चिन्ह सहितको निर्माण हो, यसको अर्थ यो क्षेत्र - यो तारमा मात्र उपस्थित हुनेछ यदि सम्बन्धित बिटलाई सन्दर्भ गरिएको क्षेत्रमा सेट गरिएको छ (लगभग एक टर्नरी अपरेटर जस्तै)। त्यसोभए, मानौं कि यो बिट सेट गरिएको थियो, जसको मतलब यो हो कि हामीले जस्तै फिल्ड पढ्न आवश्यक छ Type, जसमा हाम्रो उदाहरणमा २ कन्स्ट्रक्टरहरू छन्। एउटा खाली छ (पहिचानकर्ता मात्र समावेश छ), अर्कोमा फिल्ड छ ids प्रकार संग ids:Vector<long>.

तपाइँ सोच्न सक्नुहुन्छ कि दुबै टेम्प्लेट र जेनेरिकहरू पेशेवर वा Java मा छन्। तर होइन। लगभग। यो एकल वास्तविक सर्किटहरूमा कोण कोष्ठकहरू प्रयोग गर्ने मामला, र यो भेक्टरको लागि मात्र प्रयोग गरिन्छ। बाइट स्ट्रिममा, यी भेक्टर प्रकारका लागि 4 CRC32 बाइटहरू हुनेछन्, सधैं उस्तै, त्यसपछि 4 बाइटहरू - array तत्वहरूको संख्या, र त्यसपछि यी तत्वहरू आफैं।

यस तथ्यमा थप्नुहोस् कि क्रमबद्धता सधैं 4 बाइटको शब्दहरूमा हुन्छ, सबै प्रकारहरू यसको गुणन हुन् - निर्मित प्रकारहरू पनि वर्णन गरिएको छ। bytes и string लम्बाइको म्यानुअल सीरियलाइजेसनको साथ र 4 द्वारा यो पङ्क्तिबद्धता - राम्रो, यो सामान्य र अपेक्षाकृत प्रभावकारी जस्तो देखिन्छ? यद्यपि TL लाई प्रभावकारी बाइनरी सिरियलाइजेसन भएको दाबी गरिएको छ, तिनीहरूसँग नरकमा, केहि पनि विस्तारको साथ, बुलियन मानहरू र एकल-क्यारेक्टर स्ट्रिङहरू 4 बाइटहरूमा, के JSON अझै धेरै मोटो हुनेछ? हेर्नुहोस्, अनावश्यक फिल्डहरू पनि बिट फ्ल्यागहरूसँग छोड्न सकिन्छ, सबै कुरा एकदम राम्रो छ, र भविष्यको लागि विस्तारयोग्य पनि छ, त्यसोभए किन पछि कन्स्ट्रक्टरमा नयाँ वैकल्पिक क्षेत्रहरू थप्नु हुँदैन?..

तर होइन, यदि तपाईंले मेरो संक्षिप्त विवरण होइन, तर पूर्ण कागजात पढ्नुभयो भने, र कार्यान्वयनको बारेमा सोच्नुहोस्। सर्वप्रथम, कन्स्ट्रक्टरको CRC32 योजनाको पाठ विवरणको सामान्यीकृत रेखा अनुसार गणना गरिन्छ (अतिरिक्त ह्वाइटस्पेस हटाउनुहोस्, इत्यादि) - त्यसैले यदि नयाँ फिल्ड थपियो भने, प्रकार विवरण रेखा परिवर्तन हुनेछ, र त्यसैले यसको CRC32 र , फलस्वरूप, क्रमबद्धता। र पुरानो ग्राहकले के गर्छ यदि उसले नयाँ झण्डा सेटको साथ फिल्ड प्राप्त गर्यो, र उसलाई थाहा छैन कि तिनीहरूसँग के गर्ने?..

दोस्रो, याद गरौं सीआरसी ३32, जुन यहाँ अनिवार्य रूपमा प्रयोग गरिएको छ ह्यास प्रकार्यहरू कुन प्रकार (de) क्रमबद्ध गरिँदैछ भनेर विशिष्ट रूपमा निर्धारण गर्न। यहाँ हामी टक्करहरूको समस्याको सामना गरिरहेका छौं - र होइन, सम्भाव्यता 232 मा एक होइन, तर धेरै ठूलो छ। CRC32 संचार च्यानलमा त्रुटिहरू पत्ता लगाउन (र सच्याउन) डिजाइन गरिएको हो, र तदनुसार अरूको हानिमा यी गुणहरूलाई सुधार गर्न कसले सम्झ्यो? उदाहरणका लागि, यसले बाइटहरू पुन: व्यवस्थित गर्ने बारे वास्ता गर्दैन: यदि तपाईंले दुई लाइनहरूबाट CRC32 गणना गर्नुहुन्छ भने, दोस्रोमा तपाईंले अर्को 4 बाइटहरूसँग पहिलो 4 बाइटहरू स्वैप गर्नुहुन्छ - यो उस्तै हुनेछ। जब हाम्रो इनपुट ल्याटिन वर्णमाला (र थोरै विराम चिह्न) बाट पाठ स्ट्रिङ हो, र यी नामहरू विशेष गरी अनियमित छैनन्, यस्तो पुन: व्यवस्थित हुने सम्भावना धेरै बढ्छ।

खैर, त्यहाँ के थियो कसले जाँच गर्यो? वास्तवमा CRC32? प्रारम्भिक स्रोत कोडहरू मध्ये एक (वाल्टम्यान भन्दा पहिले पनि) मा ह्यास प्रकार्य थियो जसले प्रत्येक क्यारेक्टरलाई नम्बर 239 ले गुणन गर्‍यो, यी मानिसहरूलाई धेरै प्रिय, हा हा!

अन्तमा, ठीक छ, हामीले बुझ्यौं कि क्षेत्र प्रकारको साथ निर्माणकर्ताहरू Vector<int> и Vector<PolymorType> फरक CRC32 हुनेछ। अनलाइन प्रदर्शनको बारेमा के हो? र सैद्धान्तिक दृष्टिकोणबाट, के यो प्रकारको अंश बन्छ? मानौं हामी दस हजार नम्बरहरूको एरे पास गर्छौं, राम्रोसँग Vector<int> सबै कुरा स्पष्ट छ, लम्बाइ र अर्को 40000 बाइट। के हुन्छ भने यो Vector<Type2>, जसमा एउटा मात्र क्षेत्र हुन्छ int र यो प्रकारमा एक्लै छ - के हामीले 10000xabcdef0 34 पटक र त्यसपछि 4 बाइटहरू दोहोर्याउनु पर्छ? int, वा भाषाले कन्स्ट्रक्टरबाट हाम्रो लागि यसलाई स्वतन्त्र गर्न सक्षम छ fixedVec र 80000 बाइटको सट्टा, फेरि 40000 मात्र स्थानान्तरण?

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

तर…

भेक्टर, जुन कहिल्यै जारी गरिएको थिएन

यदि तपाइँ कम्बिनेटरहरू र यस्तै अन्य विवरणहरूको पृष्ठहरू मार्फत घुम्ने प्रयास गर्नुहुन्छ भने, तपाइँ देख्नुहुनेछ कि भेक्टर (र पनि एक म्याट्रिक्स) औपचारिक रूपमा धेरै पानाहरूको टुपलहरू मार्फत आउटपुट हुन प्रयास गरिरहेको छ। तर अन्तमा तिनीहरू बिर्सन्छन्, अन्तिम चरण छोडिएको छ, र भेक्टरको परिभाषा सरल रूपमा दिइएको छ, जुन अझै एक प्रकारमा बाँधिएको छैन। के भयो? भाषाहरूमा प्रोग्रामिंग, विशेष गरी कार्यात्मकहरू, संरचनालाई पुनरावर्ती रूपमा वर्णन गर्न यो एकदम सामान्य छ - यसको अल्छी मूल्याङ्कनको साथ कम्पाइलरले सबै कुरा बुझ्नेछ र आफैं गर्नेछ। भाषामा डाटा क्रमिकरण के चाहिन्छ दक्षता हो: यो केवल वर्णन गर्न पर्याप्त छ सूची, अर्थात् दुई तत्वहरूको संरचना - पहिलो डेटा तत्व हो, दोस्रो एउटै संरचना हो वा पुच्छरको लागि खाली ठाउँ हो (प्याक (cons) Lisp मा)। तर यो स्पष्ट रूपमा आवश्यक हुनेछ प्रत्येक तत्वले यसको प्रकार वर्णन गर्न थप 4 बाइटहरू खर्च गर्दछ (TL मा CRC32)। एरे पनि सजिलै वर्णन गर्न सकिन्छ निश्चित आकार, तर अग्रिम अज्ञात लम्बाइको एर्रेको अवस्थामा, हामी तोड्छौं।

तसर्थ, TL ले भेक्टर आउटपुट गर्न अनुमति दिँदैन, यसलाई छेउमा थप्नुपर्थ्यो। अन्ततः दस्तावेज भन्छ:

क्रमिकरणले सधैं समान कन्स्ट्रक्टर "भेक्टर" (const 0x1cb5c415 = crc32("भेक्टर t:Type # [ t ] = भेक्टर t") प्रयोग गर्दछ जुन t प्रकारको चरको विशिष्ट मानमा निर्भर हुँदैन।

वैकल्पिक प्यारामिटर t को मान सीरियलाइजेशनमा संलग्न हुँदैन किनभने यो परिणाम प्रकारबाट लिइएको हो (जहिले पनि डिसेरियलाइजेसन अघि थाहा हुन्छ)।

नजिकबाट हेर्नुहोस्: vector {t:Type} # [ t ] = Vector t - तर कतै पनि छैन यो परिभाषा आफैंले पहिलो नम्बर भेक्टरको लम्बाइ बराबर हुनुपर्छ भनेर भन्दैन! र यो कतैबाट आउँदैन। यो एक दिइएको छ जुन दिमागमा राख्नु पर्छ र आफ्नो हातले लागू गर्न आवश्यक छ। अन्यत्र, कागजातले पनि इमानदारीपूर्वक उल्लेख गरेको छ कि प्रकार वास्तविक छैन:

भेक्टर टी पोलिमोर्फिक स्यूडोटाइप एउटा "प्रकार" हो जसको मान कुनै पनि प्रकारको t, या त बक्स गरिएको वा बेयरको मानहरूको अनुक्रम हो।

... तर त्यसमा ध्यान दिँदैन। जब तपाई, गणितको स्ट्रेचिङबाट थकित हुनुभयो (सायद तपाईलाई विश्वविद्यालयको पाठ्यक्रमबाट पनि थाहा छ), हार मान्ने निर्णय गर्नुहुन्छ र वास्तवमा व्यवहारमा यसलाई कसरी काम गर्ने भनेर हेर्नुहुन्छ, तपाईको दिमागमा छाप छोड्छ कि यो गम्भीर छ। कोरमा गणित, यो स्पष्ट रूपमा कूल मानिसहरू (दुई गणितज्ञहरू - ACM विजेता) द्वारा आविष्कार गरिएको थियो, र कसैलाई मात्र होइन। लक्ष्य - देखाउने - हासिल भएको छ।

खैर, संख्या को बारे मा। हामी तपाईंलाई त्यो सम्झना गरौं # यो एक समानार्थी शब्द हो nat, प्राकृतिक संख्या:

त्यहाँ प्रकार अभिव्यक्तिहरू छन् (टाइप-एक्सप्र) र संख्यात्मक अभिव्यक्ति (nat-expr)। यद्यपि, तिनीहरू समान रूपमा परिभाषित छन्।
type-expr ::= expr
nat-expr ::= expr
तर व्याकरणमा तिनीहरूलाई उस्तै तरिकाले वर्णन गरिएको छ, अर्थात्। यो भिन्नतालाई पुन: सम्झिनुपर्छ र हातले कार्यान्वयनमा राख्नुपर्छ।

खैर, हो, टेम्प्लेट प्रकार (vector<int>, vector<User>) एक साझा पहिचानकर्ता छ (#1cb5c415), अर्थात् यदि तपाईंलाई थाहा छ कि कल घोषणा गरिएको छ

users.getUsers#d91a548 id:Vector<InputUser> = Vector<User>;

त्यसोभए तपाईं अब केवल एक भेक्टरको लागि पर्खिरहनु भएको छैन, तर प्रयोगकर्ताहरूको भेक्टर। अझ स्पष्ट रूपमा, हुनु पर्छ पर्खनुहोस् - वास्तविक कोडमा, प्रत्येक तत्व, यदि एक खाली प्रकारको होइन भने, एक कन्स्ट्रक्टर हुनेछ, र कार्यान्वयनमा राम्रो तरिकाले यो जाँच गर्न आवश्यक हुनेछ - तर हामीलाई यो भेक्टरको प्रत्येक तत्वमा ठ्याक्कै पठाइएको थियो। त्यो प्रकार? के हुन्छ यदि यो कुनै प्रकारको PHP थियो, जसमा एरेले विभिन्न तत्वहरूमा विभिन्न प्रकारहरू समावेश गर्न सक्छ?

यस बिन्दुमा तपाईले सोच्न थाल्नुभयो - के यस्तो TL आवश्यक छ? हुनसक्छ कार्टको लागि मानव सिरियलाइजर प्रयोग गर्न सम्भव छ, उही प्रोटोबफ जुन पहिले नै अवस्थित थियो? त्यो सिद्धान्त थियो, व्यवहार हेरौं।

कोडमा अवस्थित TL कार्यान्वयनहरू

TL VKontakte को गहिराई मा Durov को शेयर को बिक्री संग प्रसिद्ध घटनाहरु अघि पनि जन्म भएको थियो र (पक्कै पनि), टेलिग्राम को विकास सुरु हुनु अघि नै। र खुला स्रोतमा पहिलो कार्यान्वयनको स्रोत कोड तपाईं धेरै हास्यास्पद बैसाखी पाउन सक्नुहुन्छ। र भाषा आफैं त्यहाँ टेलिग्राममा अहिले भन्दा बढी पूर्ण रूपमा लागू गरिएको थियो। उदाहरणका लागि, ह्यासहरू योजनामा प्रयोग गरिँदैन (अर्थमा निर्मित स्यूडोटाइप (एक भेक्टर जस्तै) विचलित व्यवहारको साथ)। वा

Templates are not used now. Instead, the same universal constructors (for example, vector {t:Type} [t] = Vector t) are used w

तर हामी विचार गरौं, पूर्णताको खातिर, ट्रेस गर्न, त्यसैले बोल्ने, विचारको विशाल विकास।

#define ZHUKOV_BYTES_HACK

#ifdef ZHUKOV_BYTES_HACK

/* dirty hack for Zhukov request */

वा यो सुन्दर:

    static const char *reserved_words_polymorhic[] = {

      "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", NULL

      };

यो टुक्रा टेम्प्लेटहरूको बारेमा हो:

intHash {alpha:Type} vector<coupleInt<alpha>> = IntHash<alpha>;

यो int - Type जोडीहरूको भेक्टरको रूपमा ह्याशम्याप टेम्प्लेट प्रकारको परिभाषा हो। C++ मा यो यस्तो देखिन्छ:

    template <T> class IntHash {
      vector<pair<int,T>> _map;
    }

त्यसैले, alpha - कीवर्ड! तर केवल C++ मा तपाइँ T लेख्न सक्नुहुन्छ, तर तपाइँले अल्फा, बीटा लेख्नु पर्छ ... तर 8 मापदण्डहरू भन्दा बढी छैन, जहाँ कल्पना समाप्त हुन्छ। यस्तो देखिन्छ कि एक पटक सेन्ट पिटर्सबर्गमा केहि संवादहरू यस प्रकारका थिए:

-- Надо сделать в TL шаблоны
-- Бл... Ну пусть параметры зовут альфа, бета,... Какие там ещё буквы есть... О, тэта!
-- Грамматика? Ну потом напишем

-- Смотрите, какой я синтаксис придумал для шаблонов и вектора!
-- Ты долбанулся, как мы это парсить будем?
-- Да не ссыте, он там один в схеме, захаркодить -- и ок

तर यो TL को "सामान्य रूपमा" को पहिलो प्रकाशित कार्यान्वयनको बारेमा थियो। टेलीग्राम क्लाइन्टहरू आफैंमा कार्यान्वयनहरू विचार गर्न अगाडि बढौं।

Vasily को शब्द:

Vasily, [09.10.18 17:07] सबै भन्दा, गधा तातो छ किनभने तिनीहरूले abstractions को एक गुच्छा सिर्जना गरे, र त्यसपछि तिनीहरूमा बोल्ट हथौड़ा, र बैसाखी संग कोड जनरेटर छोप्यो।
नतिजाको रूपमा, पहिले डक pilot.jpg बाट
त्यसपछि कोड dzhekichan.webp बाट

अवश्य पनि, एल्गोरिदम र गणितसँग परिचित व्यक्तिहरूबाट, हामी आशा गर्न सक्छौं कि उनीहरूले Aho, Ullmann पढेका छन्, र उपकरणहरूसँग परिचित छन् जुन उद्योगमा दशकौंदेखि उनीहरूको DSL कम्पाइलरहरू लेख्नको लागि वास्तविक मानक बनेको छ, हैन?

द्वारा टेलिग्राम-क्लि Vitaly Valtman हो, जसरी TLO ढाँचा यसको (cli) सीमाना बाहिर भएको घटनाबाट बुझ्न सकिन्छ, टोलीको सदस्य - अब TL पार्सिङको लागि पुस्तकालय आवंटित गरिएको छ। छुट्टै, उनको कस्तो छाप छ TL पार्सर? ..

16.12 04:18 भासिली: मलाई लाग्छ कि कसैले लेक्स+याकमा महारत हासिल गरेको छैन
16.12 04:18 Vasily: म यसलाई अन्यथा व्याख्या गर्न सक्दिन
16.12 04:18 Vasily: ठीक छ, वा तिनीहरूलाई VK मा लाइनहरूको संख्याको लागि भुक्तान गरिएको थियो
16.12 04:19 Vasily: 3k+ रेखाहरू आदि।<censored> पार्सरको सट्टा

शायद एक अपवाद? कसरी हेरौं गर्छ यो आधिकारिक ग्राहक हो - टेलिग्राम डेस्कटप:

    nametype = re.match(r'([a-zA-Z.0-9_]+)(#[0-9a-f]+)?([^=]*)=s*([a-zA-Z.<>0-9_]+);', line);
    if (not nametype):
      if (not re.match(r'vector#1cb5c415 {t:Type} # [ t ] = Vector t;', line)):
         print('Bad line found: ' + line);

पाइथनमा 1100+ रेखाहरू, केही नियमित अभिव्यक्तिहरू + विशेष केसहरू जस्तै एक भेक्टर, जुन निस्सन्देह, यो योजनामा TL वाक्यविन्यास अनुसार हुनुपर्छ भनेर घोषणा गरिएको छ, तर तिनीहरूले यसलाई पार्स गर्न यो वाक्य रचनामा भर परेका छन् ... प्रश्न उठ्छ, किन यो सबै चमत्कार थियो?иयो अधिक स्तरित छ यदि कसैले पनि कागजात अनुसार यसलाई पार्स गर्न जाँदैछ?!

वैसे... हामीले CRC32 जाँच गर्ने बारे कुरा गरेका थियौं? त्यसोभए, टेलिग्राम डेस्कटप कोड जेनेरेटरमा ती प्रकारहरूको लागि अपवादहरूको सूची छ जसमा गणना गरिएको CRC32 मिलेन रेखाचित्रमा देखाइएको एक संग!

Vasily, [18.12/22 49:XNUMX] र यहाँ म यस्तो TL आवश्यक छ कि भनेर सोच्नेछु
यदि म वैकल्पिक कार्यान्वयनहरूसँग गडबड गर्न चाहन्छु भने, म लाइन ब्रेकहरू सम्मिलित गर्न सुरु गर्नेछु, आधा पार्सरहरू बहु-लाइन परिभाषाहरूमा तोडिनेछन्।
tdesktop, तथापि, पनि

एक-लाइनरको बारेमा बिन्दु सम्झनुहोस्, हामी यसलाई केहि पछि फर्काउनेछौं।

ठीक छ, टेलिग्राम-क्ली अनौपचारिक छ, टेलिग्राम डेस्कटप आधिकारिक छ, तर अरूको बारेमा के हुन्छ? कसलाई थाहा छ?... एन्ड्रोइड क्लाइन्ट कोडमा कुनै स्किमा पार्सर थिएन (जसले खुला स्रोतको बारेमा प्रश्नहरू खडा गर्छ, तर यो दोस्रो भागको लागि हो), तर त्यहाँ कोडका अन्य धेरै हास्यास्पद टुक्राहरू थिए, तर तिनीहरूमा थप तलको उपखण्ड।

क्रमबद्धताले व्यवहारमा अरू के प्रश्नहरू खडा गर्छ? उदाहरणका लागि, तिनीहरूले धेरै चीजहरू गरे, निस्सन्देह, बिट क्षेत्रहरू र सशर्त क्षेत्रहरूसँग:

भासिली: flags.0? true
यसको अर्थ क्षेत्र अवस्थित छ र झण्डा सेट गरिएको छ भने बराबर सत्य हुन्छ

भासिली: flags.1? int
यसको मतलब फिल्ड अवस्थित छ र डिसेरियलाइज गर्न आवश्यक छ

Vasily: गधा, तपाई के गर्दै हुनुहुन्छ भनेर चिन्ता नगर्नुहोस्!
Vasily: कागजातमा कतै उल्लेख छ कि सत्य एक खाली शून्य-लम्बाइ प्रकार हो, तर तिनीहरूको कागजातबाट केहि पनि भेला गर्न असम्भव छ।
Vasily: खुला स्रोत कार्यान्वयनहरूमा यो मामला होइन, तर त्यहाँ बैसाखी र समर्थनहरूको गुच्छा छ।

टेलिथनको बारेमा के हो? MTProto को विषयमा अगाडि हेर्दै, एक उदाहरण - कागजातमा त्यस्ता टुक्राहरू छन्, तर चिन्ह % यसलाई केवल "दिईएको बेयर-प्रकारको अनुरूप" भनेर वर्णन गरिएको छ, अर्थात्। तलका उदाहरणहरूमा त्यहाँ कुनै त्रुटि वा कागजात नभएको केही छ:

Vasily, [22.06.18 18:38] एक ठाउँमा:
msg_container#73f1f8dc messages:vector message = MessageContainer;
एक फरक मा:
msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;
र यी दुई ठूला भिन्नताहरू हुन्, वास्तविक जीवनमा कुनै नग्न भेक्टर आउँछ

मैले बेयर भेक्टर परिभाषा देखेको छैन र एउटा भेटेको छैन

विश्लेषण टेलिथनमा हातले लेखिएको छ

उनको रेखाचित्रमा परिभाषा बाहिर टिप्पणी गरिएको छ msg_container

फेरि, प्रश्न % को बारे मा रहन्छ। यो वर्णन गरिएको छैन।

Vadim Goncharov, [22.06.18 19:22] र tdesktop मा?

Vasily, [22.06.18 19:23] तर नियमित इन्जिनहरूमा तिनीहरूको TL पार्सरले यो पनि खाँदैनन्।

// parsed manually

TL एक सुन्दर सार हो, कसैले यसलाई पूर्ण रूपमा लागू गर्दैन

र % तिनीहरूको योजनाको संस्करणमा छैन

तर यहाँ कागजात आफैंमा विरोधाभास छ, त्यसैले idk

यो व्याकरणमा फेला पर्यो, तिनीहरूले केवल शब्दार्थ वर्णन गर्न बिर्सन सक्थे

तपाईंले TL मा कागजात हेर्नुभयो, तपाईंले आधा लिटर बिना यो पत्ता लगाउन सक्नुहुन्न

"ठीक छ, भनौं," अर्को पाठकले भन्नेछ, "तपाईले कुनै कुराको आलोचना गर्नुहुन्छ, त्यसैले मलाई यो कसरी गर्ने भनेर देखाउनुहोस्।"

Vasily जवाफ दिन्छ: "पार्सरको लागि, मलाई चीजहरू मनपर्छ

    args: /* empty */ { $$ = NULL; }
        | args arg { $$ = g_list_append( $1, $2 ); }
        ;

    arg: LC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | LC_ID ':' condition '?' type-term { $$ = tl_arg_new_cond( $1, $5, $3 ); free($3); }
            | UC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | type-term { $$ = tl_arg_new( "", $1 ); }
            | '[' LC_ID ']' { $$ = tl_arg_new_mult( "", tl_type_new( $2, TYPE_MOD_NONE ) ); }
            ;

कुनै न कुनै रूपमा यो भन्दा राम्रो मनपर्छ

struct tree *parse_args4 (void) {
  PARSE_INIT (type_args4);
  struct parse so = save_parse ();
  PARSE_TRY (parse_optional_arg_def);
  if (S) {
    tree_add_child (T, S);
  } else {
    load_parse (so);
  }
  if (LEX_CHAR ('!')) {
    PARSE_ADD (type_exclam);
    EXPECT ("!");
  }
  PARSE_TRY_PES (parse_type_term);
  PARSE_OK;
}

वा

        # Regex to match the whole line
        match = re.match(r'''
            ^                  # We want to match from the beginning to the end
            ([w.]+)           # The .tl object can contain alpha_name or namespace.alpha_name
            (?:
                #             # After the name, comes the ID of the object
                ([0-9a-f]+)    # The constructor ID is in hexadecimal form
            )?                 # If no constructor ID was given, CRC32 the 'tl' to determine it

            (?:s              # After that, we want to match its arguments (name:type)
                {?             # For handling the start of the '{X:Type}' case
                w+            # The argument name will always be an alpha-only name
                :              # Then comes the separator between name:type
                [wd<>#.?!]+  # The type is slightly more complex, since it's alphanumeric and it can
                               # also have Vector<type>, flags:# and flags.0?default, plus :!X as type
                }?             # For handling the end of the '{X:Type}' case
            )*                 # Match 0 or more arguments
            s                 # Leave a space between the arguments and the equal
            =
            s                 # Leave another space between the equal and the result
            ([wd<>#.?]+)     # The result can again be as complex as any argument type
            ;$                 # Finally, the line should always end with ;
            ''', tl, re.IGNORECASE | re.VERBOSE)

यो सम्पूर्ण लेक्सर हो:

    ---functions---         return FUNCTIONS;
    ---types---             return TYPES;
    [a-z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return LC_ID;
    [A-Z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return UC_ID;
    [0-9]+                  yylval.number = atoi(yytext); return NUM;
    #[0-9a-fA-F]{1,8}       yylval.number = strtol(yytext+1, NULL, 16); return ID_HASH;

    n                      /* skip new line */
    [ t]+                  /* skip spaces */
    //.*$                 /* skip comments */
    /*.**/              /* skip comments */
    .                       return (int)yytext[0];

ती। सजिलो भनेको यसलाई हल्का रूपमा राख्नु हो।"

सामान्यतया, नतिजाको रूपमा, TL को वास्तवमा प्रयोग गरिएको उपसेटको लागि पार्सर र कोड जनरेटर व्याकरणको लगभग 100 रेखाहरू र जेनरेटरको ~ 300 लाइनहरूमा फिट हुन्छ (सबै गणना गर्दै printको उत्पन्न कोड), प्रत्येक कक्षामा आत्मनिरीक्षणको लागि जानकारी बन्स टाइप सहित। प्रत्येक पोलिमोर्फिक प्रकार खाली एब्स्ट्र्याक्ट बेस क्लासमा परिणत हुन्छ, र कन्स्ट्रक्टरहरू यसबाट इनहेरिट हुन्छन् र क्रमबद्ध र डिसेरियलाइजेसनका लागि विधिहरू हुन्छन्।

टाइप भाषामा प्रकारहरूको अभाव

कडा टाइपिङ एक राम्रो कुरा हो, हैन? होइन, यो होलिभर होइन (यद्यपि म गतिशील भाषाहरू रुचाउँछु), तर TL को ढाँचा भित्रको पोस्टुलेट। यसको आधारमा, भाषाले हाम्रो लागि सबै प्रकारका जाँचहरू प्रदान गर्नुपर्छ। ठीक छ, ठीक छ, सायद उहाँ आफैं होइन, तर कार्यान्वयन, तर उहाँले कम्तिमा तिनीहरूलाई वर्णन गर्नुपर्छ। र हामी कस्तो प्रकारको अवसरहरू चाहन्छौं?

सबै भन्दा पहिले, बाधाहरू। यहाँ हामी फाइलहरू अपलोड गर्नका लागि कागजातमा देख्छौं:

फाइलको बाइनरी सामग्री त्यसपछि भागहरूमा विभाजित हुन्छ। सबै भागहरू समान आकारको हुनुपर्छ ( part_size ) र निम्न सर्तहरू पूरा गर्नुपर्छ:

part_size % 1024 = 0 (1KB द्वारा विभाजित)

524288 % part_size = 0 (512KB part_size द्वारा समान रूपमा विभाजित हुनुपर्छ)

अन्तिम भागले यी सर्तहरू पूरा गर्न आवश्यक छैन, यदि यसको आकार part_size भन्दा कम छ।

प्रत्येक भाग एक अनुक्रम संख्या हुनुपर्छ, file_part, 0 देखि 2,999 सम्मको मानको साथ।

फाइल विभाजन गरिसकेपछि तपाईंले यसलाई सर्भरमा बचत गर्नको लागि एक विधि छनौट गर्न आवश्यक छ। प्रयोग गर्नुहोस् upload.saveBigFilePart फाइलको पूर्ण साइज १० एमबी भन्दा बढी भएको अवस्थामा र upload.saveFilePart साना फाइलहरूको लागि।
[...] निम्न डेटा इनपुट त्रुटिहरू मध्ये एक फिर्ता हुन सक्छ:

FILE_PARTS_INVALID — भागहरूको अमान्य संख्या। मूल्य बीचमा छैन 1..3000

के यो रेखाचित्रमा छ? के यो TL को प्रयोग गरेर अभिव्यक्त गर्न सकिन्छ? छैन। तर मलाई माफ गर्नुहोस्, हजुरबुबाको टर्बो पास्कलले निर्दिष्ट प्रकारहरू वर्णन गर्न सक्षम थिए दायराहरू। र उसलाई अर्को कुरा थाह थियो, अब अझ राम्ररी चिनिन्छ enum - मानहरूको निश्चित (सानो) संख्याको गणना समावेश भएको प्रकार। C - संख्यात्मक जस्ता भाषाहरूमा, ध्यान दिनुहोस् कि अहिलेसम्म हामीले प्रकारहरूको बारेमा मात्र कुरा गरेका छौं संख्या। तर त्यहाँ पनि arrays, strings... उदाहरणका लागि, यो स्ट्रिङले फोन नम्बर मात्र समावेश गर्न सक्छ भनेर वर्णन गर्न राम्रो हुनेछ, हैन?

यी मध्ये कुनै पनि TL मा छैन। तर त्यहाँ छ, उदाहरण को लागी, JSON स्कीमा मा। र यदि अरू कसैले 512 KB को विभाज्यताको बारेमा तर्क गर्न सक्छ, कि यो अझै पनि कोडमा जाँच गर्न आवश्यक छ, त्यसपछि निश्चित गर्नुहोस् कि ग्राहकले मात्र सकिनँ दायरा बाहिर नम्बर पठाउनुहोस् 1..3000 (र सम्बन्धित त्रुटि उत्पन्न हुन सकेन) यो सम्भव हुन्थ्यो, हैन? ..

वैसे, त्रुटिहरू र फिर्ता मानहरूको बारेमा। TL सँग काम गर्नेहरूले पनि आफ्नो आँखा धमिलो पार्छन् - यो हामीलाई तुरुन्तै थाहा भएन प्रत्येक एक TL मा एक प्रकार्यले वास्तवमा वर्णित रिटर्न प्रकार मात्र होइन, तर त्रुटि पनि फर्काउन सक्छ। तर यो TL को प्रयोग गरेर कुनै पनि हिसाबले अनुमान गर्न सकिँदैन। निस्सन्देह, यो पहिले नै स्पष्ट छ र व्यवहारमा कुनै पनि कुराको आवश्यकता छैन (यद्यपि, वास्तवमा, RPC विभिन्न तरिकामा गर्न सकिन्छ, हामी यो पछि फिर्ता आउनेछौं) - तर अमूर्त प्रकारहरूको गणितको अवधारणाको शुद्धताको बारेमा के हुन्छ? स्वर्गीय संसारबाट?.. मैले टग उठाएँ - त्यसैले यसलाई मिलाउनुहोस्।

र अन्तमा, पठनीयताको बारेमा के हो? खैर, त्यहाँ, सामान्यतया, म चाहन्छु विवरण यो स्कीमामा सही छ (JSON स्कीमामा, फेरि, यो हो), तर यदि तपाइँ पहिले नै यसको साथ तनावग्रस्त हुनुहुन्छ भने, त्यसोभए व्यावहारिक पक्षको बारेमा के हुन्छ - कम्तिमा तुच्छ रूपमा अपडेटको समयमा भिन्नताहरू हेर्दै? मा आफैलाई हेर्नुहोस् वास्तविक उदाहरणहरू:

-channelFull#76af5481 flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;
+channelFull#1c87a71a flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true can_view_stats:flags.12?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int online_count:flags.13?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;

वा

-message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;
+message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true from_scheduled:flags.18?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;

यो सबैमा निर्भर गर्दछ, तर GitHub, उदाहरणका लागि, त्यस्ता लामो लाइनहरू भित्र परिवर्तनहरू हाइलाइट गर्न अस्वीकार गर्दछ। खेल "१० भिन्नताहरू फेला पार्नुहोस्", र मस्तिष्कले तुरुन्तै के देख्छ कि दुबै उदाहरणहरूमा शुरुवात र अन्त्यहरू समान छन्, तपाईंले थकित भएर बीचमा कतै पढ्नु आवश्यक छ... मेरो विचारमा, यो सिद्धान्तमा मात्र होइन, तर विशुद्ध दृष्टिले फोहोर र फोहोर.

वैसे, सिद्धान्त को शुद्धता को बारे मा। हामीलाई बिट फिल्डहरू किन चाहिन्छ? उनीहरुलाई लाग्दैन गन्ध प्रकार सिद्धान्त को दृष्टिकोण देखि खराब? व्याख्या रेखाचित्रको अघिल्लो संस्करणहरूमा देख्न सकिन्छ। सुरुमा, हो, यो कस्तो थियो, हरेक हाच्छिउँको लागि नयाँ प्रकार सिर्जना गरिएको थियो। यी पूर्वाधारहरू अझै पनि यस फारममा अवस्थित छन्, उदाहरणका लागि:

storage.fileUnknown#aa963b05 = storage.FileType;
storage.filePartial#40bc6f52 = storage.FileType;
storage.fileJpeg#7efe0e = storage.FileType;
storage.fileGif#cae1aadf = storage.FileType;
storage.filePng#a4f63c0 = storage.FileType;
storage.filePdf#ae1e508d = storage.FileType;
storage.fileMp3#528a0677 = storage.FileType;
storage.fileMov#4b09ebbc = storage.FileType;
storage.fileMp4#b3cea0e4 = storage.FileType;
storage.fileWebp#1081464c = storage.FileType;

तर अब कल्पना गर्नुहोस्, यदि तपाइँसँग तपाइँको संरचनामा 5 वैकल्पिक क्षेत्रहरू छन् भने, तपाइँलाई सबै सम्भावित विकल्पहरूको लागि 32 प्रकारहरू आवश्यक पर्दछ। संयोजन विस्फोट। यसरी, TL सिद्धान्तको क्रिस्टल शुद्धता एक पटक फेरि क्रमबद्धताको कठोर वास्तविकताको कास्ट-फलामको गधाको बिरूद्ध चकनाचुर भयो।

थप रूपमा, केही ठाउँहरूमा यी केटाहरू आफैंले आफ्नै टाइपोलोजी उल्लङ्घन गर्छन्। उदाहरणका लागि, MTProto (अर्को अध्याय) मा प्रतिक्रिया Gzip द्वारा संकुचित गर्न सकिन्छ, सबै कुरा ठीक छ - बाहेक तह र सर्किट उल्लङ्घन गरिएको छ। एक पटक फेरि, यो RpcResult आफैले काटिएको थिएन, तर यसको सामग्रीहरू। खैर, यो किन?.. मैले एक बैसाखीमा काट्नु पर्यो ताकि कम्प्रेसनले जहाँसुकै काम गरोस्।

वा अर्को उदाहरण, हामीले एक पटक त्रुटि पत्ता लगायौं - यो पठाइएको थियो InputPeerUser को सट्टा InputUser। वा उल्टो। तर यसले काम गर्यो! त्यो हो, सर्भरले प्रकारको वास्ता गर्दैन। यो कसरी हुन सक्छ? जवाफ टेलिग्राम-क्लीबाट कोड टुक्राहरूद्वारा हामीलाई दिन सकिन्छ:

  if (tgl_get_peer_type (E->id) != TGL_PEER_CHANNEL || (C && (C->flags & TGLCHF_MEGAGROUP))) {
    out_int (CODE_messages_get_history);
    out_peer_id (TLS, E->id);
  } else {    
    out_int (CODE_channels_get_important_history);

    out_int (CODE_input_channel);
    out_int (tgl_get_peer_id (E->id));
    out_long (E->id.access_hash);
  }
  out_int (E->max_id);
  out_int (E->offset);
  out_int (E->limit);
  out_int (0);
  out_int (0);

अर्को शब्दमा, यो जहाँ सीरियलाइजेशन गरिन्छ म्यानुअल रूपमा, उत्पन्न कोड छैन! सायद सर्भर समान रूपमा लागू गरिएको छ?.. सिद्धान्तमा, यो एक पटक गरेमा काम गर्नेछ, तर यसलाई पछि अद्यावधिक गर्दा कसरी समर्थन गर्न सकिन्छ? यही कारणले योजनाको आविष्कार भएको हो ? र यहाँ हामी अर्को प्रश्नमा जान्छौं।

संस्करण। तहहरू

किन योजनाबद्ध संस्करणहरूलाई तहहरू भनिन्छ, प्रकाशित स्केमेटिक्सको इतिहासको आधारमा मात्र अनुमान गर्न सकिन्छ। स्पष्ट रूपमा, सुरुमा लेखकहरूले सोचेका थिए कि आधारभूत चीजहरू अपरिवर्तित योजना प्रयोग गरेर गर्न सकिन्छ, र आवश्यक भएमा मात्र, विशेष अनुरोधहरूको लागि, तिनीहरू फरक संस्करण प्रयोग गरी गरिँदैछ भनेर संकेत गर्दछ। सिद्धान्तमा, एक राम्रो विचार पनि - र नयाँ हुनेछ, जस्तै यो थियो, "मिश्रित", पुरानो माथि तहमा। तर यो कसरी गरियो हेरौं। साँचो, मैले यसलाई सुरुदेखि नै हेर्न सकेन - यो हास्यास्पद छ, तर आधार तहको रेखाचित्र मात्र अवस्थित छैन। तहहरू 2 बाट सुरु भयो। कागजातले हामीलाई विशेष TL सुविधाको बारेमा बताउँछ:

यदि एक ग्राहक लेयर 2 लाई समर्थन गर्दछ भने, त्यसपछि निम्न कन्स्ट्रक्टर प्रयोग गर्नुपर्छ:
invokeWithLayer2#289dd1f6 {X:Type} query:!X = X;
अभ्यासमा, यसको मतलब प्रत्येक एपीआई कल अघि, मानको साथ एक int 0x289dd1f6 विधि नम्बर अघि थप्नु पर्छ।

सामान्य सुनिन्छ। तर त्यसपछि के भयो? त्यसपछि देखा पर्यो

invokeWithLayer3#b7475268 query:!X = X;

त्यसोभए अर्को के छ? तपाईले अनुमान गर्न सक्नुहुन्छ,

invokeWithLayer4#dea0d430 query:!X = X;

हास्यास्पद? होइन, हाँस्न धेरै चाँडो छ, यो तथ्यको बारेमा सोच्नुहोस् प्रत्येक अर्को तहको अनुरोधलाई यस्तो विशेष प्रकारमा र्‍याप गर्न आवश्यक छ - यदि तिनीहरू सबै तपाईंको लागि फरक छन् भने, तपाईं तिनीहरूलाई कसरी छुट्याउन सक्नुहुन्छ? र अगाडि मात्र 4 बाइटहरू थप्नु एक राम्रो कुशल विधि हो। तर,

invokeWithLayer5#417a57ae query:!X = X;

तर यो स्पष्ट छ कि केहि समय पछि यो एक प्रकारको बचनालिया हुनेछ। र समाधान आयो:

अपडेट: लेयर ९ बाट सुरु गर्दै, सहायक विधिहरू invokeWithLayerN संग मात्र प्रयोग गर्न सकिन्छ initConnection

हुर्रे! 9 संस्करणहरू पछि, हामी अन्ततः 80 को दशकमा इन्टरनेट प्रोटोकलहरूमा के गरिएको थियो - जडानको सुरुमा एक पटक संस्करणमा सहमति जनाउँदै आएका छौं!

त्यसोभए अब के छ? ..

invokeWithLayer10#39620c41 query:!X = X;
...
invokeWithLayer18#1c900537 query:!X = X;

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

ठ्याक्कै?..

Vasily, [16.07.18 14:01] शुक्रबार पनि मैले सोचे:
टेलिसर्भरले अनुरोध बिना घटनाहरू पठाउँछ। अनुरोधहरू InvokeWithLayer मा बेरिएको हुनुपर्छ। सर्भरले अपडेटहरू र्‍याप गर्दैन; प्रतिक्रियाहरू र अद्यावधिकहरू र्‍याप गर्ने कुनै संरचना छैन।

ती। क्लाइन्टले लेयर निर्दिष्ट गर्न सक्दैन जसमा उसले अपडेटहरू चाहन्छ

Vadim Goncharov, [16.07.18 14:02] InvokeWithLayer सिद्धान्तमा एक बैसाखी होइन?

Vasily, [16.07.18 14:02] यो एक मात्र तरिका हो

Vadim Goncharov, [16.07.18 14:02] जसको अर्थ सत्रको सुरुमा तहमा सहमत हुनु हो।

वैसे, यो ग्राहक डाउनग्रेड प्रदान गरिएको छैन कि अनुसरण गर्दछ

अपडेटहरू, अर्थात् प्रकार Updates योजनामा, यो सर्भरले ग्राहकलाई API अनुरोधको जवाफमा होइन, तर घटना हुँदा स्वतन्त्र रूपमा पठाउँछ। यो एक जटिल विषय हो जुन अर्को पोष्टमा छलफल गरिनेछ, तर अहिलेको लागि यो जान्न महत्त्वपूर्ण छ कि सर्भरले क्लाइन्ट अफलाइन हुँदा पनि अद्यावधिकहरू बचत गर्दछ।

यसरी, यदि तपाइँ लपेट्न अस्वीकार गर्नुहुन्छ प्रत्येक प्याकेज यसको संस्करण संकेत गर्न, यसले तार्किक रूपमा निम्न सम्भावित समस्याहरू निम्त्याउँछ:

सर्भरले क्लाइन्टले कुन संस्करणलाई समर्थन गर्छ भनेर जानकारी दिनु अघि नै ग्राहकलाई अद्यावधिकहरू पठाउँछ
ग्राहक अपग्रेड गरेपछि मैले के गर्नुपर्छ?
को ग्यारेन्टीलेयर नम्बरको बारेमा सर्भरको राय प्रक्रियाको क्रममा परिवर्तन हुनेछैन?

के तपाईंलाई लाग्छ कि यो विशुद्ध सैद्धान्तिक अनुमान हो, र व्यवहारमा यो हुन सक्दैन, किनकि सर्भर सही रूपमा लेखिएको छ (कम्तीमा, यो राम्रोसँग परीक्षण गरिएको छ)? हा! जतिसुकै भए पनि !

ठ्याक्कै यही हो जुन हामीले अगस्टमा दौड्यौं। अगस्ट १४ मा, टेलिग्राम सर्भरमा केही अपडेट भैरहेको सन्देशहरू थिए... र त्यसपछि लगहरूमा:

2019-08-15 09:28:35.880640 MSK warn  main: ANON:87: unknown object type: 0x80d182d1 at TL/Object.pm line 213.
2019-08-15 09:28:35.751899 MSK warn  main: ANON:87: unknown object type: 0xb5223b0f at TL/Object.pm line 213.

र त्यसपछि स्ट्याक ट्रेसहरूको धेरै मेगाबाइटहरू (राम्रो, एकै समयमा लगिङ निश्चित गरिएको थियो)। आखिर, यदि तपाइँको TL मा केहि पहिचान गरिएको छैन भने, यो हस्ताक्षर द्वारा बाइनरी हो, रेखा तल सबै जान्छ, डिकोडिङ असम्भव हुनेछ। यस्तो अवस्थामा के गर्नुपर्छ ?

ठीक छ, कसैको दिमागमा आउने पहिलो कुरा विच्छेदन र फेरि प्रयास गर्नु हो। सहयोग गरेनन् । हामीले CRC32 गुगल गर्छौं - यी योजना 73 बाट वस्तुहरू हुन्, यद्यपि हामीले 82 मा काम गर्यौं। हामी लगहरूमा ध्यानपूर्वक हेर्छौं - त्यहाँ दुई फरक योजनाहरूबाट पहिचानकर्ताहरू छन्!

सायद समस्या हाम्रो अनौपचारिक ग्राहक मा विशुद्ध छ? होइन, हामी Telegram Desktop 1.2.17 (Linux वितरणको संख्यामा आपूर्ति गरिएको संस्करण) सुरु गर्छौं, यसले अपवाद लगमा लेख्छ: MTP अनपेक्षित प्रकार id #b5223b0f MTPMessageMedia मा पढियो...

गुगलले देखायो कि एक समान समस्या पहिले नै अनौपचारिक क्लाइन्टहरू मध्ये एकमा भएको थियो, तर त्यसपछि संस्करण नम्बरहरू र, तदनुसार, अनुमानहरू फरक थिए ...

त्यसोभए हामीले के गर्नुपर्छ? भासिली र म छुट्टिए: उसले सर्किटलाई 91 मा अपडेट गर्ने प्रयास गरे, मैले केही दिन पर्खने र 73 मा प्रयास गर्ने निर्णय गरे। दुबै विधिहरूले काम गरे, तर तिनीहरू अनुभवजन्य भएकाले, तपाईंलाई कति संस्करणहरू माथि वा तल चाहिन्छ भन्ने कुनै बुझाइ छैन। हाम फाल्न, वा तपाईले कति समय पर्खनु पर्छ।

पछि मैले स्थिति पुन: उत्पादन गर्न सक्षम भएँ: हामीले क्लाइन्ट सुरु गर्छौं, यसलाई बन्द गर्छौं, सर्किटलाई अर्को तहमा पुन: कम्पाइल गर्छौं, पुन: सुरु गर्छौं, फेरि समस्या समात्छौं, अघिल्लोमा फर्कन्छौं - उफ्, सर्किट स्विचिङको कुनै मात्रा छैन र ग्राहक पुन: सुरु हुन्छ। केही मिनेट मद्दत गर्नेछ। तपाईंले विभिन्न तहहरूबाट डाटा संरचनाहरूको मिश्रण प्राप्त गर्नुहुनेछ।

व्याख्या? तपाईले विभिन्न अप्रत्यक्ष लक्षणहरूबाट अनुमान लगाउन सक्नुहुन्छ, सर्भरले विभिन्न मेसिनहरूमा विभिन्न प्रकारका धेरै प्रक्रियाहरू समावेश गर्दछ। सम्भवतः, "बफरिङ" को लागी जिम्मेवार सर्भरले लाममा राख्यो जुन यसका वरिष्ठहरूले दिएका थिए, र उनीहरूले यो योजनामा दिए जुन पुस्ताको समयमा थियो। र यो लाम "सडेर" सम्म, यसको बारेमा केहि गर्न सकिँदैन।

सायद... तर यो एक भयानक बैसाखी हो?!.. होइन, पागल विचारहरूको बारेमा सोच्नु अघि, आधिकारिक ग्राहकहरूको कोड हेरौं। एन्ड्रोइड संस्करणमा हामीले कुनै पनि TL पार्सर फेला पारेनौं, तर हामीले (de) क्रमिकरणको साथ एक भारी फाइल (GitHub ले यसलाई छोउन अस्वीकार गर्छ) फेला पार्छौं। यहाँ कोड स्निपेटहरू छन्:

public static class TL_message_layer68 extends TL_message {
    public static int constructor = 0xc09be45f;
//...
//еще пачка подобных
//...
    public static class TL_message_layer47 extends TL_message {
        public static int constructor = 0xc992e15c;
        public static Message TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
            Message result = null;
            switch (constructor) {
                case 0x1d86f70e:
                    result = new TL_messageService_old2();
                    break;
                case 0xa7ab1991:
                    result = new TL_message_old3();
                    break;
                case 0xc3060325:
                    result = new TL_message_old4();
                    break;
                case 0x555555fa:
                    result = new TL_message_secret();
                    break;
                case 0x555555f9:
                    result = new TL_message_secret_layer72();
                    break;
                case 0x90dddc11:
                    result = new TL_message_layer72();
                    break;
                case 0xc09be45f:
                    result = new TL_message_layer68();
                    break;
                case 0xc992e15c:
                    result = new TL_message_layer47();
                    break;
                case 0x5ba66c13:
                    result = new TL_message_old7();
                    break;
                case 0xc06b9607:
                    result = new TL_messageService_layer48();
                    break;
                case 0x83e5de54:
                    result = new TL_messageEmpty();
                    break;
                case 0x2bebfa86:
                    result = new TL_message_old6();
                    break;
                case 0x44f9b43d:
                    result = new TL_message_layer104();
                    break;
                case 0x1c9b1027:
                    result = new TL_message_layer104_2();
                    break;
                case 0xa367e716:
                    result = new TL_messageForwarded_old2(); //custom
                    break;
                case 0x5f46804:
                    result = new TL_messageForwarded_old(); //custom
                    break;
                case 0x567699b3:
                    result = new TL_message_old2(); //custom
                    break;
                case 0x9f8d60bb:
                    result = new TL_messageService_old(); //custom
                    break;
                case 0x22eb6aba:
                    result = new TL_message_old(); //custom
                    break;
                case 0x555555F8:
                    result = new TL_message_secret_old(); //custom
                    break;
                case 0x9789dac4:
                    result = new TL_message_layer104_3();
                    break;

वा

    boolean fixCaption = !TextUtils.isEmpty(message) &&
    (media instanceof TLRPC.TL_messageMediaPhoto_old ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer68 ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer74 ||
     media instanceof TLRPC.TL_messageMediaDocument_old ||
     media instanceof TLRPC.TL_messageMediaDocument_layer68 ||
     media instanceof TLRPC.TL_messageMediaDocument_layer74)
    && message.startsWith("-1");

हम्म... जंगली देखिन्छ। तर, सायद, यो उत्पन्न कोड हो, त्यसपछि ठीक छ? .. तर यसले निश्चित रूपमा सबै संस्करणहरूलाई समर्थन गर्दछ! साँचो, यो स्पष्ट छैन किन सबै कुरा सँगै मिसाइएको छ, गोप्य कुराकानी, र सबै प्रकारका _old7 कतै मेशिन जेनेरेसन जस्तो लाग्दैन... यद्यपि, सबै भन्दा धेरै म उडाएँ

TL_message_layer104
TL_message_layer104_2
TL_message_layer104_3

साथीहरू, तपाईं एक तह भित्र के छ भनेर पनि निर्णय गर्न सक्नुहुन्न?! खैर, ठीक छ, भनौं "दुई" त्रुटिको साथ जारी भयो, ठीक छ, यो हुन्छ, तर तीन?.. तुरुन्तै, फेरि उही रेक? यो कस्तो पोर्नोग्राफी हो, माफ गर्नुहोस्?...

टेलिग्राम डेस्कटपको स्रोत कोडमा, वैसे, यस्तै कुरा हुन्छ - यदि त्यसो हो भने, योजनामा पङ्क्तिमा धेरै कमिटहरूले यसको लेयर नम्बर परिवर्तन गर्दैन, तर केहि ठीक गर्नुहोस्। योजनाको लागि डाटाको आधिकारिक स्रोत नभएको अवस्थामा, आधिकारिक ग्राहकको स्रोत कोड बाहेक कहाँबाट प्राप्त गर्न सकिन्छ? र यदि तपाइँ यसलाई त्यहाँबाट लिनुहुन्छ भने, तपाइँ निश्चित हुन सक्नुहुन्न कि योजना पूर्ण रूपमा सही छ जबसम्म तपाइँ सबै विधिहरू परीक्षण गर्नुहुन्न।

यो पनि कसरी परीक्षण गर्न सकिन्छ? मलाई आशा छ कि एकाइ, कार्यात्मक र अन्य परीक्षणका प्रशंसकहरूले टिप्पणीहरूमा साझेदारी गर्नेछन्।

ठीक छ, कोडको अर्को टुक्रा हेरौं:

public static class TL_folders_deleteFolder extends TLObject {
    public static int constructor = 0x1c295881;

    public int folder_id;

    public TLObject deserializeResponse(AbstractSerializedData stream, int constructor, boolean exception) {
        return Updates.TLdeserialize(stream, constructor, exception);
    }

    public void serializeToStream(AbstractSerializedData stream) {
        stream.writeInt32(constructor);
        stream.writeInt32(folder_id);
    }
}

//manually created

//RichText start
public static abstract class RichText extends TLObject {
    public String url;
    public long webpage_id;
    public String email;
    public ArrayList<RichText> texts = new ArrayList<>();
    public RichText parentRichText;

    public static RichText TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
        RichText result = null;
        switch (constructor) {
            case 0x1ccb966a:
                result = new TL_textPhone();
                break;
            case 0xc7fb5e01:
                result = new TL_textSuperscript();
                break;

यो टिप्पणी "म्यानुअल रूपमा सिर्जना गरिएको" ले सुझाव दिन्छ कि यो फाइलको केवल भाग म्यानुअल रूपमा लेखिएको थियो (के तपाइँ सम्पूर्ण मर्मत दुःस्वप्न कल्पना गर्न सक्नुहुन्छ?), र बाँकी मेसिनद्वारा उत्पन्न गरिएको थियो। यद्यपि, त्यसपछि अर्को प्रश्न उठ्छ - स्रोतहरू उपलब्ध छन् पूर्ण रूपमा होइन (लिनक्स कर्नेलमा एक ला GPL ब्लबहरू), तर यो पहिले नै दोस्रो भागको लागि विषय हो।

तर पर्याप्त। प्रोटोकलमा जाऔं जसको शीर्षमा यो सबै क्रमिकरण चल्छ।

MT प्रोटो

त्यसोभए, खोलौं सामान्य विवरण и प्रोटोकलको विस्तृत विवरण र हामीले ठेस लाग्ने पहिलो कुरा भनेको शब्दावली हो। र सबै चीजको प्रशस्तता संग। सामान्यतया, यो टेलिग्रामको स्वामित्वको विशेषता जस्तो देखिन्छ - चीजहरूलाई फरक ठाउँमा फरक तरिकाले कल गर्ने, वा एक शब्दको साथ फरक चीजहरू, वा यसको विपरीत (उदाहरणका लागि, उच्च-स्तर API मा, यदि तपाईंले स्टिकर प्याक देख्नुभयो भने, यो होइन। तपाईले के सोच्नुभयो)।

उदाहरण को लागी, "सन्देश" र "सत्र" को अर्थ यहाँ सामान्य टेलिग्राम क्लाइन्ट इन्टरफेस भन्दा फरक छ। ठीक छ, सन्देशसँग सबै कुरा स्पष्ट छ, यसलाई OOP सर्तहरूमा व्याख्या गर्न सकिन्छ, वा केवल "प्याकेट" शब्द भनिन्छ - यो कम, यातायात स्तर हो, त्यहाँ इन्टरफेसमा जस्तै सन्देशहरू छैनन्, त्यहाँ धेरै सेवा सन्देशहरू छन्। । तर सत्र ... तर पहिलो चीजहरू पहिले।

यातायात तह

पहिलो कुरा यातायात हो। तिनीहरूले हामीलाई 5 विकल्पहरूको बारेमा बताउनेछन्:

टीसीपी
वेबसाइट
HTTPS मा वेबसकेट
HTTP
HTTPS

Vasily, [15.06.18 15:04] त्यहाँ UDP यातायात पनि छ, तर यो दस्तावेज गरिएको छैन

र TCP तीन संस्करणहरूमा

पहिलो TCP मा UDP जस्तै छ, प्रत्येक प्याकेट अनुक्रम संख्या र crc समावेश गर्दछ
कार्टमा कागजातहरू पढ्न किन यति पीडादायी छ?

खैर, यो अहिले छ TCP पहिले नै 4 संस्करणहरूमा:

संक्षिप्त
मध्यवर्ती
प्याड गरिएको मध्यवर्ती
पूर्ण

ठीक छ, MTProxy को लागि प्याडेड मध्यवर्ती, यो पछि प्रसिद्ध घटनाहरूको कारण थपिएको थियो। तर किन दुई थप संस्करणहरू (कुलमा तीन) जब तपाईं एकको साथ प्राप्त गर्न सक्नुहुन्छ? सबै चार मुख्य MTProto को लम्बाइ र पेलोड कसरी सेट गर्ने मा मात्र फरक छ, जसलाई थप छलफल गरिनेछ:

संक्षिप्तमा यो 1 वा 4 बाइट हो, तर 0xef होइन, त्यसपछि शरीर
मध्यवर्ती मा यो लम्बाइको 4 बाइट र एक फिल्ड हो, र ग्राहकले पहिलो पटक पठाउनु पर्छ 0xeeeeeeee यो मध्यवर्ती हो भनेर संकेत गर्न
पूर्ण रूपमा सबैभन्दा लत, नेटवर्करको दृष्टिकोणबाट: लम्बाइ, अनुक्रम संख्या, र मुख्य रूपमा MTProto, शरीर, CRC32 होइन। हो, यो सबै TCP मा छ। जसले हामीलाई क्रमिक बाइट स्ट्रिमको रूपमा भरपर्दो यातायात प्रदान गर्दछ; कुनै अनुक्रम आवश्यक पर्दैन, विशेष गरी चेकसमहरू। ठीक छ, अब कसैले मलाई आपत्ति गर्नेछ कि TCP मा 16-बिट चेकसम छ, त्यसैले डाटा भ्रष्टाचार हुन्छ। उत्कृष्ट, तर हामीसँग 16 बाइट्स भन्दा लामो ह्यास भएको क्रिप्टोग्राफिक प्रोटोकल छ, यी सबै त्रुटिहरू - र अझ बढी - उच्च स्तरमा SHA बेमेल द्वारा समातिनेछन्। यसको शीर्षमा CRC32 मा कुनै बिन्दु छैन।

संक्षिप्त तुलना गरौं, जसमा लम्बाइको एक बाइट सम्भव छ, मध्यवर्तीसँग, जसले "यदि 4-बाइट डेटा पङ्क्तिबद्धता आवश्यक छ" लाई जायज ठहराउँछ, जुन एकदमै बकवास हो। के, यो विश्वास गरिन्छ कि टेलिग्राम प्रोग्रामरहरू यति अयोग्य छन् कि तिनीहरूले सकेटबाट पङ्क्तिबद्ध बफरमा डाटा पढ्न सक्दैनन्? तपाईंले अझै पनि यो गर्नै पर्छ, किनभने पढाइले तपाईंलाई कुनै पनि संख्यामा बाइटहरू फर्काउन सक्छ (र त्यहाँ प्रोक्सी सर्भरहरू पनि छन्, उदाहरणका लागि...)। वा अर्कोतर्फ, किन ब्लक संक्षिप्त गर्नुहोस् यदि हामीसँग अझै पनि 16 बाइटहरूको माथि भारी प्याडिङ हुनेछ - 3 बाइटहरू बचत गर्नुहोस् कहिलेकाहीं ?

निकोलाई डुरोभले कुनै वास्तविक व्यावहारिक आवश्यकता बिना नेटवर्क प्रोटोकलहरू सहित पाङ्ग्राहरू पुन: आविष्कार गर्न मन पराउँछन् भन्ने धारणा पाउँछ।

अन्य यातायात विकल्पहरू, सहित। वेब र MTProxy, हामी अब विचार गर्दैनौं, हुनसक्छ अर्को पोस्टमा, यदि त्यहाँ अनुरोध छ। यही MTProxy को बारेमा, हामी अब मात्र सम्झन्छौं कि 2018 मा यसको रिलीजको केही समय पछि, प्रदायकहरूले चाँडै यसलाई ब्लक गर्न सिकेका थिए, जसको उद्देश्य बाइपास अवरुद्धद्वारा प्याकेज आकार! र यो तथ्य पनि कि सी मा लेखिएको MTProxy सर्भर (फेरि Waltman द्वारा) लाई लिनक्स स्पेसिफिकेशनमा धेरै जोडिएको थियो, यद्यपि यो आवश्यक थिएन (फिल कुलिनले पुष्टि गर्नेछ), र त्यो समान सर्भर या त Go वा Node.js मा हुनेछ। एक सय भन्दा कम लाइन मा फिट।

तर हामी यी व्यक्तिहरूको प्राविधिक साक्षरताको बारेमा खण्डको अन्त्यमा, अन्य मुद्दाहरूलाई विचार गरेपछि निष्कर्ष निकाल्नेछौं। अहिलेको लागि, OSI तह 5, सत्रमा जाऔं - जसमा उनीहरूले MTProto सत्र राखेका थिए।

कुञ्जीहरू, सन्देशहरू, सत्रहरू, Diffie-Hellman

तिनीहरूले यसलाई त्यहाँ पूर्ण रूपमा सही रूपमा राखेनन्... एक सत्र सक्रिय सत्रहरू अन्तर्गत इन्टरफेसमा देखिने एउटै सत्र होइन। तर क्रम मा।

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

त्यहाँ दुई संस्था भनिन्छ सत्र - "वर्तमान सत्रहरू" अन्तर्गत आधिकारिक ग्राहकहरूको UI मा एक, जहाँ प्रत्येक सत्र सम्पूर्ण यन्त्र / OS सँग मेल खान्छ।
दोस्रो - MTProto सत्र, जसमा सन्देशको अनुक्रम संख्या (निम्न-स्तरको अर्थमा) छ, र कुन विभिन्न TCP जडानहरू बीचमा रहन सक्छ। धेरै MTProto सत्रहरू एकै समयमा स्थापना गर्न सकिन्छ, उदाहरणका लागि, फाइल डाउनलोड गति बढाउन।

यी दुई बिचमा सत्र त्यहाँ एक अवधारणा छ प्राधिकरण। पतित अवस्थामा, हामी यो भन्न सक्छौं UI सत्र जस्तै छ प्राधिकरण, तर अफसोस, सबै कुरा जटिल छ। हेरौं:

नयाँ यन्त्रमा प्रयोगकर्ताले पहिले उत्पन्न गर्छ auth_key र यसलाई खातामा बाँध्छ, उदाहरणका लागि SMS मार्फत - त्यसैले प्राधिकरण

यो पहिलो भित्र भयो MTProto सत्र, जसमा छ session_id आफै भित्र।

यस चरणमा, संयोजन प्राधिकरण и session_id बोलाउन सकिन्छ उदाहरण - यो शब्द केही ग्राहकहरूको कागजात र कोडमा देखिन्छ

त्यसपछि, ग्राहक खोल्न सक्छ धेरै MTProto सत्रहरू एउटै अन्तर्गत auth_key - एउटै डीसीमा।

त्यसपछि, एक दिन ग्राहकले फाइल अनुरोध गर्न आवश्यक हुनेछ अर्को डीसी - र यो DC को लागी एक नयाँ उत्पन्न हुनेछ auth_key !

प्रणालीलाई सूचित गर्न कि यो दर्ता गर्ने नयाँ प्रयोगकर्ता होइन, तर उस्तै हो प्राधिकरण (UI सत्र), ग्राहकले API कलहरू प्रयोग गर्दछ auth.exportAuthorization घर DC मा auth.importAuthorization नयाँ DC मा।

सबै उस्तै छ, धेरै खुला हुन सक्छ MTProto सत्रहरू (प्रत्येकको आफ्नै session_id) यस नयाँ DC लाई, अन्तर्गत आफ्नो auth_key.

अन्तमा, ग्राहकले सही फर्वार्ड गोपनीयता चाहन सक्छ। हरेक auth_key थियो स्थायी कुञ्जी - प्रति DC - र ग्राहकले कल गर्न सक्छ auth.bindTempAuthKey प्रयोगको लागि अस्थायी auth_key - र फेरि, केवल एक temp_auth_key प्रति DC, सबैको लागि साझा MTProto सत्रहरू यस DC लाई।

ध्यान दिनुहोस्, त्यो नमक (र भविष्यको नुन) पनि एक हो auth_key ती। सबैको बीच साझा MTProto सत्रहरू एउटै DC लाई।

"भिन्न TCP जडानहरू बीच" भनेको के हो? त्यसैले यो मतलब छ केहि जस्तै वेबसाइटमा प्राधिकरण कुकी - यो दिइएको सर्भरमा धेरै TCP जडानहरू रहन्छ (बाँच्दछ), तर एक दिन यो खराब हुन्छ। HTTP को विपरीत मात्र, MTProto सन्देशहरू एक सत्र भित्र क्रमिक रूपमा नम्बर र पुष्टि हुन्छन्; यदि तिनीहरू सुरुङमा प्रवेश गरे, जडान टुटेको थियो - नयाँ जडान स्थापना गरेपछि, सर्भरले यस सत्रमा अघिल्लोमा डेलिभर नगरेको सबै कुरा पठाउनेछ। TCP जडान।

यद्यपि, माथिको जानकारी धेरै महिनाको अनुसन्धान पछि संक्षेप गरिएको छ। यस बीचमा, के हामी हाम्रो ग्राहकलाई स्क्र्याचबाट लागू गर्दैछौं? - सुरुमा फर्कौं।

त्यसैले उत्पन्न गरौं auth_key मा टेलिग्रामबाट Diffie-Hellman संस्करणहरू। दस्तावेज बुझ्न प्रयास गरौं ...

Vasily, [19.06.18 20:05] data_with_hash := SHA1(डेटा) + डाटा + (कुनै पनि अनियमित बाइट्स); लम्बाइ बराबर 255 बाइट;
encrypted_data := RSA(data_with_hash, server_public_key); 255-बाइट लामो नम्बर (ठूलो एन्डियन) आवश्यक मोड्युलसमा आवश्यक शक्तिमा उठाइएको छ, र परिणामलाई 256-बाइट नम्बरको रूपमा भण्डार गरिएको छ।

तिनीहरूसँग केही डोप DH छ

स्वस्थ व्यक्तिको DH जस्तो देखिदैन
dx मा कुनै दुई सार्वजनिक कुञ्जीहरू छैनन्

ठीक छ, अन्तमा यो क्रमबद्ध भयो, तर अवशेष बाँकी रह्यो - कामको प्रमाण ग्राहकले गरेको छ कि उसले संख्या कारक गर्न सक्षम थियो। DoS आक्रमणहरू विरुद्ध सुरक्षाको प्रकार। र RSA कुञ्जी एक पटक मात्र एक दिशामा प्रयोग गरिन्छ, अनिवार्य रूपमा गुप्तिकरणको लागि new_nonce। तर यो साधारण देखिने अपरेशन सफल हुँदा, तपाईंले के सामना गर्नुपर्नेछ?

Vasily, [20.06.18/00/26 XNUMX:XNUMX] मैले अहिलेसम्म एपिड अनुरोध प्राप्त गरेको छैन

मैले यो अनुरोध DH लाई पठाएँ

र, यातायात डकमा यसले त्रुटि कोडको 4 बाइट्ससँग प्रतिक्रिया दिन सक्छ भनी भन्छ। यति नै

खैर, उहाँले मलाई भन्नुभयो -404, त्यसोभए के हो?

त्यसैले मैले उसलाई भनें: "यस प्रकारको फिंगरप्रिन्टको साथ सर्भर कुञ्जीसँग इन्क्रिप्ट गरिएको तपाईंको बुलशिट समात्नुहोस्, मलाई DH चाहिएको छ," र यसले मूर्ख 404 सँग जवाफ दियो।

तपाइँ यो सर्भर प्रतिक्रिया के सोच्नुहुन्छ? के गर्ने? सोध्ने कोही छैन (तर दोस्रो भागमा थप)।

यहाँ सबै चासो डकमा गरिन्छ

मसँग अरू केही गर्न छैन, मैले संख्याहरू अगाडि र पछाडि रूपान्तरण गर्ने सपना देखेको छु

दुई 32 बिट नम्बरहरू। मैले सबैलाई जस्तै प्याक गरें

तर होइन, यी दुई लाई पहिले BE को रूपमा लाइनमा थप्न आवश्यक छ

Vadim Goncharov, [20.06.18 15:49] र यो 404 को कारण?

Vasily, [20.06.18 15:49] हो!

Vadim Goncharov, [20.06.18 15:50] त्यसैले मैले बुझिन कि उसले "फेला पार्न सकेन"

भासिली, [२०.०६.१८ १५:५०] लगभग

मैले प्राइम कारक% मा यस्तो विघटन फेला पार्न सकिन)

हामीले त्रुटि रिपोर्टिङ पनि व्यवस्थित गरेका छैनौं

Vasily, [20.06.18 20:18] ओह, त्यहाँ MD5 पनि छ। पहिले नै तीन फरक ह्यासहरू

कुञ्जी फिंगरप्रिन्ट निम्नानुसार गणना गरिएको छ:
digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)
SHA1 र sha2

त्यसैले राखौं auth_key हामीले Diffie-Hellman प्रयोग गरेर आकारमा 2048 बिट प्राप्त गर्यौं। अब के? अर्को हामीले पत्ता लगायौं कि यो कुञ्जीको तल्लो 1024 बिटहरू कुनै पनि हिसाबले प्रयोग गरिएको छैन... तर अहिलेको लागि यस बारे सोचौं। यस चरणमा, हामीसँग सर्भरसँग साझा गोप्य छ। TLS सत्रको एनालग स्थापना गरिएको छ, जुन धेरै महँगो प्रक्रिया हो। तर सर्भरले अझै पनि हामी को हौं भनेर केहि थाहा छैन! अझै छैन, वास्तवमा। प्राधिकरण। ती। यदि तपाईंले "लगइन-पासवर्ड" को सन्दर्भमा सोच्नुभयो भने, तपाईंले एक पटक ICQ मा गर्नुभएको थियो, वा कम्तिमा "लगइन-कुञ्जी", SSH मा जस्तै (उदाहरणका लागि, केही gitlab/github मा)। हामीले एउटा गुमनाम प्राप्त गर्यौं। के हुन्छ यदि सर्भरले हामीलाई "यी फोन नम्बरहरू अर्को DC द्वारा सर्भिस गरिएको छ" बताउँछ? वा "तपाईंको फोन नम्बर प्रतिबन्धित छ"? हामीले गर्न सक्ने सबै भन्दा राम्रो कुञ्जीलाई आशामा राख्नु हो कि यो उपयोगी हुनेछ र त्यतिन्जेल कुहिने छैन।

वैसे, हामीले यसलाई आरक्षणको साथ "प्राप्त" गर्यौं। उदाहरणका लागि, के हामी सर्भरमा विश्वास गर्छौं? के यो नक्कली छ भने? क्रिप्टोग्राफिक जाँचहरू आवश्यक हुनेछ:

Vasily, [21.06.18 17:53] तिनीहरूले मोबाइल क्लाइन्टहरूलाई 2kbit नम्बर primality% जाँच गर्न प्रस्ताव गर्छन्)

तर यो बिल्कुल स्पष्ट छैन, nafeijoa

Vasily, [21.06.18 18:02] कागजात सरल नभएको खण्डमा के गर्ने भनेर बताउदैन

भनिएन । आउनुहोस् हेरौं आधिकारिक एन्ड्रोइड ग्राहकले यस अवस्थामा के गर्छ? ए त्यो के हो (र हो, सम्पूर्ण फाइल चाखलाग्दो छ) - तिनीहरूले भने, म यसलाई यहाँ छोड्नेछु:

278     static const char *goodPrime = "c71caeb9c6b1c9048e6c522f70f13f73980d40238e3e21c14934d037563d930f48198a0aa7c14058229493d22530f4dbfa336f6e0ac925139543aed44cce7c3720fd51f69458705ac68cd4fe6b6b13abdc9746512969328454f18faf8c595f642477fe96bb2a941d5bcd1d4ac8cc49880708fa9b378e3c4f3a9060bee67cf9a4a4a695811051907e162753b56b0f6b410dba74d8a84b2a14b3144e0ef1284754fd17ed950d5965b4b9dd46582db1178d169c6bc465b0d6ff9ca3928fef5b9ae4e418fc15e83ebea0f87fa9ff5eed70050ded2849f47bf959d956850ce929851f0d8115f635b105ee2e4e15d04b2454bf6f4fadf034b10403119cd8e3b92fcc5b";
279   if (!strcasecmp(prime, goodPrime)) {

होइन, पक्कै पनि यो त्यहाँ छ केहि त्यहाँ संख्याको प्राथमिकताको लागि परीक्षणहरू छन्, तर व्यक्तिगत रूपमा मसँग गणितको पर्याप्त ज्ञान छैन।

ठीक छ, हामीले मास्टर कुञ्जी पायौं। लग इन गर्न, i.e. अनुरोधहरू पठाउनुहोस्, तपाईंले AES प्रयोग गरेर थप इन्क्रिप्सन गर्न आवश्यक छ।

सन्देश कुञ्जीलाई सन्देशको मुख्य भागको SHA128 को 256 मध्य बिट्सको रूपमा परिभाषित गरिएको छ (सत्र, सन्देश ID, आदि सहित), प्याडिङ बाइटहरू सहित, प्राधिकरण कुञ्जीबाट लिइएको 32 बाइटहरूद्वारा पूर्व-पेन्ड गरिएको।

Vasily, [22.06.18 14:08] औसत, कुतिया, बिट

प्राप्त भयो auth_key। सबै। तिनीहरू परे ... यो कागजातबाट स्पष्ट छैन। खुला स्रोत कोड अध्ययन गर्न स्वतन्त्र महसुस गर्नुहोस्।

नोट गर्नुहोस् कि MTProto 2.0 लाई 12 देखि 1024 बाइट्स प्याडिङ चाहिन्छ, अझै पनि परिणाम सन्देशको लम्बाइ 16 बाइट्सले विभाजन गर्न सकिने शर्तको अधीनमा छ।

त्यसोभए तपाईले कति प्याडिङ थप्नुपर्छ?

र हो, त्यहाँ त्रुटि को मामला मा 404 पनि छ

यदि कसैले ध्यानपूर्वक कागजातको रेखाचित्र र पाठ अध्ययन गरे भने, उनीहरूले त्यहाँ कुनै MAC छैन भनेर याद गरे। र त्यो AES एक निश्चित IGE मोडमा प्रयोग गरिन्छ जुन कतै प्रयोग गरिएको छैन। तिनीहरू अवश्य पनि, तिनीहरूको FAQ मा यस बारे लेख्छन्... यहाँ, जस्तै, सन्देश कुञ्जी आफैं पनि डिक्रिप्टेड डाटाको SHA ह्यास हो, अखण्डता जाँच गर्न प्रयोग गरिन्छ - र बेमेलको अवस्थामा, कुनै कारणले कागजातहरू चुपचाप तिनीहरूलाई बेवास्ता गर्न सिफारिस गर्दछ (तर सुरक्षाको बारेमा के हो, यदि तिनीहरूले हामीलाई तोड्छन्?)

म क्रिप्टोग्राफर होइन, सायद सैद्धान्तिक दृष्टिकोणबाट यस अवस्थामा यस मोडमा केहि गलत छैन। तर म उदाहरणको रूपमा टेलिग्राम डेस्कटप प्रयोग गरेर व्यावहारिक समस्यालाई स्पष्ट रूपमा नाम दिन सक्छु। यसले स्थानीय क्यास (यी सबै D877F783D5D3EF8C) लाई MTProto मा सन्देशहरू जस्तै (यस अवस्थामा संस्करण 1.0 मा मात्र) इन्क्रिप्ट गर्दछ, अर्थात्। पहिले सन्देश कुञ्जी, त्यसपछि डाटा आफैं (र कतै मुख्य ठूलो auth_key 256 बाइट्स, बिना msg_key बेकार)। त्यसोभए, समस्या ठूला फाइलहरूमा उल्लेखनीय हुन्छ। अर्थात्, तपाईंले डाटाको दुई प्रतिलिपिहरू राख्न आवश्यक छ - एन्क्रिप्टेड र डिक्रिप्टेड। र यदि त्यहाँ मेगाबाइटहरू छन्, वा स्ट्रिमिङ भिडियोहरू, उदाहरणका लागि?... MAC सँग सिफरटेक्स्ट पछि क्लासिक स्किमहरूले तपाईंलाई यसलाई स्ट्रिम पढ्न अनुमति दिन्छ, तुरुन्तै प्रसारण गर्दै। तर MTProto को साथ तपाईले गर्नुपर्नेछ सुरुमा सम्पूर्ण सन्देशलाई गुप्तिकरण वा डिक्रिप्ट गर्नुहोस्, त्यसपछि मात्र यसलाई नेटवर्क वा डिस्कमा स्थानान्तरण गर्नुहोस्। तसर्थ, क्यास मा टेलिग्राम डेस्कटप को नवीनतम संस्करण मा user_data अर्को ढाँचा पनि प्रयोग गरिन्छ - CTR मोडमा AES संग।

Vasily, [21.06.18 01:27] ओह, मैले IGE भनेको के हो भनेर थाहा पाए: IGE मूलतः Kerberos को लागि "प्रमाणीकरण गर्ने ईन्क्रिप्शन मोड" मा पहिलो प्रयास थियो। यो एक असफल प्रयास थियो (यसले अखण्डता सुरक्षा प्रदान गर्दैन), र हटाउनु थियो। त्यो काम गर्ने प्रमाणिकरण ईन्क्रिप्शन मोडको लागि २० वर्षको खोजको सुरुवात थियो, जुन हालै OCB र GCM जस्ता मोडहरूमा परिणत भयो।

र अब कार्ट पक्षबाट तर्कहरू:

निकोलाई दुरोभको नेतृत्वमा रहेको टेलिग्राम पछाडिको टोलीमा छ एसीएम च्याम्पियनहरू छन्, जसमध्ये आधा गणितमा पीएच.डी. MTProto को हालको संस्करण रोल आउट गर्न लगभग दुई वर्ष लाग्यो।

त्यो हास्यास्पद छ। तल्लो तहमा दुई वर्ष

वा तपाइँ केवल tls लिन सक्नुहुन्छ

ठीक छ, मानौं हामीले इन्क्रिप्शन र अन्य सूक्ष्मताहरू गरेका छौं। के यो TL मा क्रमबद्ध अनुरोधहरू पठाउन र प्रतिक्रियाहरू deserialize गर्न सम्भव छ? त्यसोभए तपाईले के र कसरी पठाउनु पर्छ? यहाँ, विधि भनौं initConnection, सायद यो हो?

Vasily, [25.06.18 18:46] जडान प्रारम्भ गर्दछ र प्रयोगकर्ताको उपकरण र अनुप्रयोगमा जानकारी बचत गर्दछ।

यसले app_id, device_model, system_version, app_version र lang_code स्वीकार गर्छ।

र केहि प्रश्न

सधैं जस्तै दस्तावेज। खुला स्रोत अध्ययन गर्न स्वतन्त्र महसुस गर्नुहोस्

यदि invokeWithLayer सँग सबै कुरा लगभग स्पष्ट थियो भने, त्यसपछि यहाँ के गलत छ? यो बाहिर जान्छ, मानौं हामीसँग छ - ग्राहकसँग पहिले नै सर्भरलाई सोध्नको लागि केहि थियो - त्यहाँ एउटा अनुरोध छ जुन हामीले पठाउन चाहन्थ्यौं:

Vasily, [25.06.18 19:13] कोड द्वारा न्याय, पहिलो कल यो बकवास मा बेरिएको छ, र बकवास आफै invokewithlayer मा बेरिएको छ।

किन initConnection छुट्टै कल हुन सकेन, तर र्यापर हुनुपर्छ? हो, यो बाहिर निस्कियो, यो प्रत्येक सत्रको सुरुमा प्रत्येक पटक गर्नुपर्छ, र एक पटक होइन, मुख्य कुञ्जीको रूपमा। तर! यो एक अनाधिकृत प्रयोगकर्ता द्वारा कल गर्न सकिँदैन! अब हामी यो लागू हुने चरणमा पुगेका छौं यो चाहिँ कागजात पृष्ठ - र यसले हामीलाई बताउँछ कि ...

API विधिहरूको सानो अंश मात्र अनधिकृत प्रयोगकर्ताहरूको लागि उपलब्ध छ:

auth.sendCode
auth.resendCode
account.getPassword
auth.checkPassword
auth.checkPhone
auth.signUp
auth.signIn
auth.importAuthorization
help.getConfig
help.getNearestDc
help.getAppUpdate
help.getCdnConfig
langpack.getLangPack
langpack.getStrings
langpack.getDifference
langpack.getLanguages
langpack.getLanguage

तिनीहरूमध्ये सबैभन्दा पहिले, auth.sendCode, र त्यहाँ त्यो प्यारो पहिलो अनुरोध छ जसमा हामी api_id र api_hash पठाउँछौं, र त्यसपछि हामीले कोड सहितको SMS प्राप्त गर्छौं। र यदि हामी गलत DC मा छौं (यस देशमा टेलिफोन नम्बरहरू अर्कोद्वारा सेवा गरिन्छ, उदाहरणका लागि), तब हामीले इच्छित DC को नम्बरको साथ त्रुटि प्राप्त गर्नेछौं। DC नम्बर द्वारा कुन IP ठेगानामा जडान गर्न आवश्यक छ भनेर पत्ता लगाउन, हामीलाई मद्दत गर्नुहोस् help.getConfig। एक समयमा त्यहाँ केवल 5 प्रविष्टिहरू थिए, तर 2018 को प्रसिद्ध घटनाहरू पछि, संख्या उल्लेखनीय रूपमा बढेको छ।

अब याद गरौं कि हामी अज्ञात रूपमा सर्भरमा यस चरणमा पुग्यौं। IP ठेगाना मात्र प्राप्त गर्न धेरै महँगो छैन? MTProto को एन्क्रिप्ट नगरिएको भागमा यो र अन्य कार्यहरू किन नगर्ने? म आपत्ति सुन्छु: "हामी कसरी पक्का गर्न सक्छौं कि यो RKN होइन जसले झूटा ठेगानाहरूको साथ जवाफ दिनेछ?" यसका लागि हामी सम्झन्छौं, सामान्यतया, आधिकारिक ग्राहकहरू RSA कुञ्जीहरू सम्मिलित छन्, अर्थात् तपाईं मात्र सक्नुहुन्छ चिन्ह यो सूचना। वास्तवमा, यो पहिले नै क्लाइन्टहरूले अन्य च्यानलहरू मार्फत प्राप्त गर्ने ब्लकिङलाई बाइपास गर्ने जानकारीको लागि गरिँदै छ (तार्किक रूपमा, यो MTProto मा गर्न सकिँदैन; तपाईंलाई कहाँ जडान गर्ने भनेर पनि जान्न आवश्यक छ)।

ठिक छ। ग्राहक प्राधिकरणको यस चरणमा, हामी अझै अधिकृत छैनौं र हाम्रो आवेदन दर्ता गरेका छैनौं। हामी अहिलेको लागि हेर्न चाहन्छौं कि सर्भरले अनाधिकृत प्रयोगकर्तालाई उपलब्ध विधिहरूमा के प्रतिक्रिया दिन्छ। र यहाँ…

भासिली, [२०.०६.१८ १५:५०] https://core.telegram.org/method/help.getConfig
config#7dae33e0 [...] = Config;
help.getConfig#c4f9186b = Config;
https://core.telegram.org/api/datacenter
config#232d5905 [...] = Config;
help.getConfig#c4f9186b = Config;
योजनामा, पहिलो दोस्रो आउँछ

tdesktop स्कीमामा तेस्रो मान हो

हो, तब देखि, अवश्य पनि, कागजात अद्यावधिक गरिएको छ। यद्यपि यो चाँडै फेरि अप्रासंगिक हुन सक्छ। एक नौसिखिया विकासकर्तालाई कसरी थाहा हुनुपर्छ? हुनसक्छ यदि तपाईंले आफ्नो आवेदन दर्ता गर्नुभयो भने, तिनीहरूले तपाईंलाई सूचित गर्नेछन्? Vasily यो गरे, तर अफसोस, तिनीहरूले उहाँलाई केहि पठाएनन् (फेरि, हामी दोस्रो भागमा यस बारे कुरा गर्नेछौं)।

...तपाईले याद गर्नुभयो कि हामी पहिले नै कुनै न कुनै रूपमा API मा सरेका छौं, अर्थात्। अर्को स्तरमा, र MTProto विषयमा केहि छुटेको छ? कुनै आश्चर्य छैन:

Vasily, [28.06.18 02:04] Mm, तिनीहरू e2e मा केही एल्गोरिदमहरू मार्फत गफ गर्दैछन्।

Mtproto दुबै डोमेनहरूको लागि एन्क्रिप्शन एल्गोरिदम र कुञ्जीहरू परिभाषित गर्दछ, साथसाथै र्यापर संरचनाको एक बिट

तर तिनीहरू निरन्तर स्ट्याकको विभिन्न स्तरहरू मिलाउँछन्, त्यसैले यो सधैं स्पष्ट हुँदैन कि mtproto कहाँ समाप्त भयो र अर्को स्तर सुरु भयो।

तिनीहरू कसरी मिश्रण गर्छन्? ठीक छ, यहाँ PFS को लागी उही अस्थायी कुञ्जी छ, उदाहरण को लागी (वैसे, टेलिग्राम डेस्कटपले यो गर्न सक्दैन)। यो एपीआई अनुरोध द्वारा कार्यान्वयन गरिएको छ auth.bindTempAuthKey, अर्थात् शीर्ष स्तरबाट। तर एकै समयमा यसले तल्लो स्तरमा एन्क्रिप्शनमा हस्तक्षेप गर्दछ - यसको पछि, उदाहरणका लागि, तपाइँ यसलाई फेरि गर्न आवश्यक छ। initConnection आदि, यो होइन बस सामान्य अनुरोध। के पनि विशेष छ कि तपाईंसँग प्रति DC मात्र एउटा अस्थायी कुञ्जी हुन सक्छ, यद्यपि फिल्ड auth_key_id प्रत्येक सन्देशमा तपाइँलाई कम्तिमा प्रत्येक सन्देश कुञ्जी परिवर्तन गर्न अनुमति दिन्छ, र सर्भरसँग कुनै पनि समयमा अस्थायी कुञ्जी "बिर्सने" अधिकार छ - कागजातले यस अवस्थामा के गर्ने भनेर बताउँदैन ... ठीक छ, किन हुन सक्छ। तपाईंसँग धेरै कुञ्जीहरू छैनन्, जस्तै भविष्यको नुनको सेटको साथ, र?..

MTProto विषयवस्तुको बारेमा ध्यान दिन लायक केहि अन्य चीजहरू छन्।

सन्देश सन्देशहरू, msg_id, msg_seqno, पुष्टिकरणहरू, गलत दिशामा पिंगहरू र अन्य idiosyncrasies

तपाईंले तिनीहरूको बारेमा किन जान्न आवश्यक छ? किनभने तिनीहरू उच्च स्तरमा "लीक" हुन्छन्, र एपीआईसँग काम गर्दा तपाईलाई तिनीहरूको बारेमा सचेत हुन आवश्यक छ। मानौं हामी msg_key मा रुचि राख्दैनौं; तल्लो तहले हाम्रो लागि सबै कुरा डिक्रिप्ट गरेको छ। तर डिक्रिप्टेड डाटा भित्र हामीसँग निम्न क्षेत्रहरू छन् (डेटाको लम्बाइ पनि, त्यसैले हामीलाई थाहा छ प्याडिङ कहाँ छ, तर त्यो महत्त्वपूर्ण छैन):

नमक - int64
सत्र_आईडी - int64
सन्देश_आईडी - int64
seq_no - int32

हामी तपाईंलाई सम्झना गरौं कि सम्पूर्ण DC को लागी एक मात्र नुन छ। उनको बारेमा किन थाहा छ? अनुरोध छ भनेर मात्र होइन get_future_salts, जसले तपाइँलाई बताउँछ कि कुन अन्तराल मान्य हुनेछ, तर यो पनि कि यदि तपाइँको नुन "सडेको" छ भने, सन्देश (अनुरोध) मात्र हराउनेछ। सर्भरले, अवश्य पनि, जारी गरेर नयाँ नुन रिपोर्ट गर्नेछ new_session_created - तर पुरानोको साथ तपाईंले यसलाई कुनै न कुनै रूपमा पुन: पठाउनुपर्नेछ, उदाहरणका लागि। र यो मुद्दाले अनुप्रयोग वास्तुकलालाई असर गर्छ।

सर्भरलाई सत्रहरू पूरै छोड्न र धेरै कारणहरूको लागि यस तरिकामा प्रतिक्रिया दिन अनुमति दिइएको छ। वास्तवमा, ग्राहक पक्षबाट MTProto सत्र के हो? यी दुई नम्बर हुन् session_id и seq_no यस सत्र भित्र सन्देशहरू। ठीक छ, र अन्तर्निहित TCP जडान, अवश्य पनि। मानौं हाम्रो ग्राहकलाई अझै धेरै कुराहरू कसरी गर्ने भनेर थाहा छैन, उसले विच्छेद गर्यो, पुन: जडान भयो। यदि यो छिटो भयो भने - नयाँ TCP जडानमा पुरानो सत्र जारी रह्यो, बढाउनुहोस् seq_no थप। यदि यसले लामो समय लिन्छ भने, सर्भरले यसलाई मेटाउन सक्छ, किनभने यसको छेउमा यो पनि एक लाम हो, जस्तो कि हामीले पत्ता लगायौं।

यो के हुनुपर्छ seq_no? ओह, यो एक कठिन प्रश्न हो। इमानदारीपूर्वक बुझ्ने प्रयास गर्नुहोस् के मतलब थियो:

सामग्री-सम्बन्धित सन्देश

स्पष्ट स्वीकृति चाहिने सन्देश। यसमा सबै प्रयोगकर्ता र धेरै सेवा सन्देशहरू समावेश छन्, वस्तुतः सबै कन्टेनरहरू र स्वीकृतिहरू बाहेक।

सन्देश अनुक्रम संख्या (msg_seqno)

यो सन्देश अघि प्रेषकद्वारा सिर्जना गरिएको "सामग्री-सम्बन्धित" सन्देशहरूको दोब्बर संख्या बराबरको 32-बिट नम्बर (जसलाई स्वीकृति चाहिन्छ, र विशेष गरी ती कन्टेनरहरू छैनन्) र हालको सन्देश हो भने एकद्वारा बढाइएको। सामग्री सम्बन्धित सन्देश। कन्टेनर सधैं यसको सम्पूर्ण सामग्री पछि उत्पन्न हुन्छ; त्यसकारण, यसको अनुक्रम संख्या यसमा समावेश सन्देशहरूको अनुक्रम संख्या भन्दा ठूलो वा बराबर छ।

यो कस्तो प्रकारको सर्कस हो जसमा 1 को वृद्धि हुन्छ, र त्यसपछि अर्को 2 द्वारा?... मलाई शंका छ कि सुरुमा तिनीहरूले "ACK को लागि कम्तिमा महत्त्वपूर्ण बिट, बाँकी संख्या हो", तर नतिजा एकदम समान छैन - विशेष गरी, यो बाहिर आउँछ, पठाउन सकिन्छ धेरै समान भएको पुष्टिहरू seq_no! कसरी? ठीक छ, उदाहरणका लागि, सर्भरले हामीलाई केहि पठाउँछ, पठाउँछ, र हामी आफै मौन रहन्छौं, केवल सेवा सन्देशहरूको साथ प्रतिक्रिया दिँदै यसको सन्देशहरूको प्राप्ति पुष्टि गर्दछ। यस अवस्थामा, हाम्रो बहिर्गमन पुष्टिकरणहरू एउटै बहिर्गमन नम्बर हुनेछ। यदि तपाइँ TCP सँग परिचित हुनुहुन्छ र सोच्नुभएको छ कि यो कुनै प्रकारले जंगली सुनिन्छ, तर यो धेरै जंगली देखिदैन, किनभने TCP मा seq_no परिवर्तन हुँदैन, तर पुष्टिकरण जान्छ seq_no अर्को तिर, म तिमीलाई निराश पार्न हतार गर्नेछु। MTProto मा पुष्टिकरणहरू प्रदान गरिन्छ होइन मा seq_no, TCP मा जस्तै, तर द्वारा msg_id !

यो के हो msg_id, यी क्षेत्रहरू मध्ये सबैभन्दा महत्त्वपूर्ण? एउटा अद्वितीय सन्देश पहिचानकर्ता, नामले सुझाव दिन्छ। यसलाई 64-बिट नम्बरको रूपमा परिभाषित गरिएको छ, जसको सबैभन्दा तल्लो बिट्समा फेरि "सर्भर-नो-सर्भर" जादू छ, र बाँकी एक युनिक्स टाइमस्ट्याम्प हो, आंशिक भाग सहित, 32 बिटहरू बायाँतिर सारियो। ती। टाइमस्ट्याम्प प्रति से (र धेरै फरक भएका सन्देशहरू सर्भरद्वारा अस्वीकार गरिनेछ)। यसबाट यो बाहिर निस्कन्छ कि सामान्यतया यो एक पहिचानकर्ता हो जुन ग्राहकको लागि विश्वव्यापी हो। त्यो दिएर - याद गरौं session_id - हामी ग्यारेन्टी छौं: कुनै पनि परिस्थितिमा एक सत्रको लागि सन्देश अर्को सत्रमा पठाउन सकिँदैन। त्यो हो, यो पहिले नै छ कि बाहिर जान्छ तीन स्तर - सत्र, सत्र नम्बर, सन्देश आईडी। किन यस्तो जटिलता, यो रहस्य धेरै ठूलो छ।

र त्यसैले, msg_id को लागि आवश्यक...

RPC: अनुरोधहरू, प्रतिक्रियाहरू, त्रुटिहरू। पुष्टिहरू।

तपाईंले याद गर्नुभएको हुनसक्छ, त्यहाँ कुनै विशेष "RPC अनुरोध गर्नुहोस्" प्रकार वा कार्य रेखाचित्रमा कहीं पनि छैन, यद्यपि त्यहाँ जवाफहरू छन्। आखिर, हामीसँग सामग्री-सम्बन्धित सन्देशहरू छन्! त्यो हो, कुनै सन्देश अनुरोध हुन सक्छ! वा नहुने । जे भएपनि, प्रत्येक त्यहाँ छ msg_id। तर त्यहाँ जवाफहरू छन्:

rpc_result#f35c6d01 req_msg_id:long result:Object = RpcResult;

यो कुन सन्देशको प्रतिक्रिया हो भनेर संकेत गरिएको छ। त्यसकारण, API को शीर्ष स्तरमा, तपाईंले आफ्नो अनुरोधको संख्या के थियो भनेर सम्झनु पर्छ - मलाई लाग्छ कि काम एसिन्क्रोनस छ भनेर व्याख्या गर्न आवश्यक छैन, र त्यहाँ एकै समयमा धेरै अनुरोधहरू प्रगतिमा हुन सक्छ, जसको जवाफ कुनै पनि क्रममा फर्काउन सकिन्छ? सिद्धान्तमा, यसबाट र कुनै कामदार नभएका त्रुटि सन्देशहरूबाट, यसको पछाडिको वास्तुकला पत्ता लगाउन सकिन्छ: तपाइँसँग TCP जडान कायम गर्ने सर्भर फ्रन्ट-एन्ड ब्यालेन्सर हो, यसले ब्याकएन्डहरूमा अनुरोधहरू फर्वार्ड गर्दछ र तिनीहरूलाई मार्फत फिर्ता सङ्कलन गर्दछ। message_id। यस्तो देखिन्छ कि यहाँ सबै कुरा स्पष्ट, तार्किक र राम्रो छ।

हो?.. र यदि तपाइँ यसको बारेमा सोच्नुहुन्छ? आखिर, RPC प्रतिक्रियाको पनि एक क्षेत्र छ msg_id! के हामीले सर्भरमा चिच्याउन आवश्यक छ "तपाईं मेरो जवाफको जवाफ दिनुहुन्न!"? र हो, त्यहाँ पुष्टिकरणहरूको बारेमा के थियो? पृष्ठको बारेमा सन्देशहरूको बारेमा सन्देशहरू हामीलाई के हो बताउँछ

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

र यो प्रत्येक पक्ष द्वारा गर्नुपर्छ। तर सधैं होइन! यदि तपाईंले RpcResult प्राप्त गर्नुभयो भने, यो आफैले पुष्टिकरणको रूपमा कार्य गर्दछ। त्यो हो, सर्भरले MsgsAck मार्फत तपाईंको अनुरोधलाई जवाफ दिन सक्छ - जस्तै, "मैले यो प्राप्त गरेको छु।" RpcResult तुरुन्तै प्रतिक्रिया दिन सक्छ। यो दुबै हुन सक्छ।

र हो, तपाईले अझै जवाफ दिनु पर्छ! पुष्टि। अन्यथा, सर्भरले यसलाई डेलिभर गर्न नसकिने ठान्नेछ र तपाईंलाई फेरि पठाउनेछ। पुन जडान पछि पनि। तर यहाँ, निस्सन्देह, टाइमआउटको मुद्दा उठ्छ। तिनीहरूलाई केही पछि हेरौं।

यस बीचमा, सम्भावित क्वेरी कार्यान्वयन त्रुटिहरू हेरौं।

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

ओह, कसैले चिच्याउनेछ, यहाँ एक अधिक मानवीय ढाँचा छ - त्यहाँ एक रेखा छ! आफ्नो समय लिनुहोस्। यहाँ त्रुटिहरूको सूची, तर पक्कै पनि पूर्ण छैन। यसबाट हामीले सिक्यौं कि कोड हो केहि जस्तै HTTP त्रुटिहरू (ठीक छ, निस्सन्देह, प्रतिक्रियाहरूको अर्थशास्त्रलाई सम्मान गरिएको छैन, केही ठाउँहरूमा तिनीहरू कोडहरू बीच अनियमित रूपमा वितरित हुन्छन्), र रेखा जस्तो देखिन्छ। CAPITAL_LETTERS_AND_NUMBERS। उदाहरण को लागी, PHONE_NUMBER_OCCUPIED वा FILE_PART_Х_MISSING। ठीक छ, त्यो हो, तपाईलाई अझै पनि यो लाइन चाहिन्छ पार्स। उदाहरण को लागी FLOOD_WAIT_3600 यसको मतलब तपाईले एक घण्टा पर्खनु पर्छ, र PHONE_MIGRATE_5, यो उपसर्ग भएको टेलिफोन नम्बर 5th DC मा दर्ता हुनुपर्छ। हामीसँग एक प्रकारको भाषा छ, हैन? हामीलाई स्ट्रिङबाट तर्क चाहिँदैन, नियमितहरूले गर्नेछन्, ठीक छ।

फेरि, यो सेवा सन्देश पृष्ठमा छैन, तर, यो परियोजना संग पहिले नै सामान्य छ, जानकारी पाउन सकिन्छ। अर्को कागजात पृष्ठमा। वा आशंका व्यक्त गर्ने। पहिले, हेर्नुहोस्, टाइपिङ/लेयर उल्लङ्घन - RpcError मा नेस्ट गर्न सकिन्छ RpcResult। बाहिर किन छैन? हामीले के कुरालाई ध्यानमा राखेका छैनौं?.. तदनुसार, यसको ग्यारेन्टी कहाँ छ RpcError मा सम्मिलित नहुन सक्छ RpcResult, तर सीधै वा अर्को प्रकारमा नेस्टेड हुनुहोस्?... र यदि यो गर्न सक्दैन भने, यो किन शीर्ष स्तरमा छैन, अर्थात्। यो हराइरहेको छ req_msg_id ? ..

तर सेवा सन्देशहरूको बारेमा जारी राखौं। ग्राहकले सोच्न सक्छ कि सर्भरले लामो समयको लागि सोचिरहेको छ र यो अद्भुत अनुरोध गर्नुहोस्:

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

यस प्रश्नको तीन सम्भावित उत्तरहरू छन्, पुन: पुष्टिकरण संयन्त्रसँग प्रतिच्छेद गर्दै; तिनीहरू के हुनुपर्छ भनेर बुझ्ने प्रयास गर्दै (र कुन प्रकारहरूको सामान्य सूची जसलाई पुष्टिकरण आवश्यक पर्दैन) पाठकलाई गृहकार्यको रूपमा छोडिएको छ (नोट: मा जानकारी टेलिग्राम डेस्कटप स्रोत कोड पूरा भएको छैन)।

लागूपदार्थ लत: सन्देश स्थिति

सामान्यतया, TL, MTProto र Telegram मा धेरै ठाउँहरू सामान्यतया जिद्दीको भावना छोड्छन्, तर विनम्रता, चालचलन र अन्यबाट बाहिर। नरम कौशल हामीले यसको बारेमा विनम्रतापूर्वक मौन रह्यौं, र संवादहरूमा अश्लीलता सेन्सर गर्यौं। यद्यपि, यो ठाउँОधेरै जसो पृष्ठ बारेमा छ सन्देशहरूको बारेमा सन्देशहरू यो मेरो लागि पनि अचम्मको छ, जसले लामो समयदेखि नेटवर्क प्रोटोकलसँग काम गर्दै आएको छ र साइकलहरू फरक-फरक कुटिलता देखेको छ।

यो निर्दोष रूपमा, पुष्टिकरण संग सुरु हुन्छ। त्यसपछि तिनीहरूले हामीलाई बताउँछन्

bad_msg_notification#a7eff811 bad_msg_id:long bad_msg_seqno:int error_code:int = BadMsgNotification;
bad_server_salt#edab447b bad_msg_id:long bad_msg_seqno:int error_code:int new_server_salt:long = BadMsgNotification;

ठीक छ, MTProto सँग काम गर्न सुरु गर्ने सबैले तिनीहरूसँग व्यवहार गर्नुपर्नेछ; "सही - पुन: कम्पाइल गरिएको - सुरु" चक्रमा, सम्पादनको क्रममा खराब हुन सफल भएको नम्बर त्रुटि वा नुन प्राप्त गर्नु सामान्य कुरा हो। यद्यपि, यहाँ दुईवटा बिन्दुहरू छन्:

यसको अर्थ मूल सन्देश हराएको छ। हामीले केही लामहरू सिर्जना गर्न आवश्यक छ, हामी पछि हेर्नेछौं।
यी अजीब त्रुटि संख्याहरू के हुन्? 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 64... अन्य नम्बरहरू कहाँ छन्, टमी?

कागजात भन्छ:

इरादा यो हो कि error_code मानहरू समूहबद्ध छन् (error_code >> 4): उदाहरणका लागि, कोडहरू 0x40 — 0x4f कन्टेनर विघटनमा त्रुटिहरूसँग मेल खान्छ।

तर, पहिलो, अर्को दिशामा परिवर्तन, र दोस्रो, यसले फरक पार्दैन, अन्य कोडहरू कहाँ छन्? लेखकको टाउकोमा?.. यद्यपि, यी साना कुराहरू हुन्।

सन्देश स्थिति र सन्देश प्रतिलिपिहरूको बारेमा सन्देशहरूमा लत सुरु हुन्छ:

सन्देश स्थिति जानकारीको लागि अनुरोध
यदि कुनै पक्षले केही समयको लागि आफ्नो बहिर्गमन सन्देशहरूको स्थितिमा जानकारी प्राप्त गरेको छैन भने, यसले स्पष्ट रूपमा अर्को पक्षबाट अनुरोध गर्न सक्छ:
msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;
सन्देशहरूको स्थिति बारे जानकारीमूलक सन्देश
msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;
यहाँ, info आगमन msg_ids सूचीबाट प्रत्येक सन्देशको लागि सन्देश स्थितिको ठीक एक बाइट समावेश गर्ने स्ट्रिङ हो:
- 1 = सन्देश बारे केहि थाहा छैन (msg_id धेरै कम छ, अर्को पक्षले बिर्सेको हुन सक्छ)
- 2 = सन्देश प्राप्त भएन (msg_id भण्डार गरिएको पहिचानकर्ताहरूको दायरा भित्र पर्दछ; यद्यपि, अर्को पक्षले निश्चित रूपमा त्यस्तो सन्देश प्राप्त गरेको छैन)
- 3 = सन्देश प्राप्त भएन (msg_id धेरै उच्च; यद्यपि, अर्को पक्षले पक्कै पनि प्राप्त गरेको छैन)
- 4 = सन्देश प्राप्त भयो (ध्यान दिनुहोस् कि यो प्रतिक्रिया पनि एकै समयमा रसिद स्वीकृति हो)
- +8 = सन्देश पहिले नै स्वीकार गरिएको छ
- +16 = सन्देशलाई स्वीकृति आवश्यक छैन
- +32 = सन्देशमा समावेश RPC क्वेरी प्रशोधन भइरहेको वा प्रक्रिया पहिले नै पूरा भएको छ
- +64 = पहिले नै उत्पन्न सन्देशमा सामग्री-सम्बन्धित प्रतिक्रिया
- +128 = अर्को पक्षलाई तथ्य थाहा छ कि सन्देश पहिले नै प्राप्त भएको छ
  यो प्रतिक्रियालाई स्वीकृति आवश्यक पर्दैन। यो सान्दर्भिक msgs_state_req को एक स्वीकृति हो, भित्र र आफै।
  ध्यान दिनुहोस् कि यदि यो अचानक बाहिर जान्छ कि अर्को पक्षसँग सन्देश छैन जुन यो पठाइएको जस्तो देखिन्छ, सन्देश मात्र पुन: पठाउन सकिन्छ। अर्को पक्षले एकै समयमा सन्देशको दुई प्रतिलिपिहरू प्राप्त गर्नुपर्दछ भने पनि, नक्कललाई बेवास्ता गरिनेछ। (यदि धेरै समय बितिसकेको छ, र मूल msg_id अब मान्य छैन भने, सन्देश msg_copy मा बेर्नु पर्छ)।
सन्देशहरूको स्थितिको स्वैच्छिक सञ्चार
कुनै पनि पक्षले स्वेच्छिक रूपमा अर्को पक्षलाई अर्को पक्षले पठाएको सन्देशहरूको स्थितिको जानकारी दिन सक्छ।
msgs_all_info#8cc0d131 msg_ids:Vector long info:string = MsgsAllInfo
एक सन्देशको स्थितिको विस्तारित स्वैच्छिक संचार
...
msg_detailed_info#276d3ec6 msg_id:long answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
msg_new_detailed_info#809db6df answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
सन्देशहरू पुन: पठाउनको लागि स्पष्ट अनुरोध
msg_resend_req#7d861a08 msg_ids:Vector long = MsgResendReq;
रिमोट पार्टीले अनुरोध गरिएका सन्देशहरू पुन: पठाएर तुरुन्तै प्रतिक्रिया दिन्छ […]
जवाफहरू पुन: पठाउनको लागि स्पष्ट अनुरोध
msg_resend_ans_req#8610baeb msg_ids:Vector long = MsgResendReq;
रिमोट पार्टीले तुरुन्तै पुन: पठाएर प्रतिक्रिया दिन्छ उत्तर अनुरोध गरिएका सन्देशहरूमा […]
सन्देश प्रतिलिपिहरू
केहि परिस्थितिहरूमा, msg_id को साथ पुरानो सन्देश जुन अब मान्य छैन पुन: पठाउन आवश्यक छ। त्यसपछि, यो प्रतिलिपि कन्टेनरमा बेरिएको छ:
msg_copy#e06046b2 orig_message:Message = MessageCopy;
एकचोटि प्राप्त भएपछि, सन्देश प्रशोधन गरिन्छ मानौं र्यापर त्यहाँ थिएन। यद्यपि, यदि यो निश्चित रूपमा थाहा छ कि सन्देश orig_message.msg_id प्राप्त भएको थियो, तब नयाँ सन्देश प्रशोधन हुँदैन (जबकि एकै समयमा, यो र orig_message.msg_id स्वीकार गरिन्छ)। orig_message.msg_id को मान कन्टेनरको msg_id भन्दा कम हुनुपर्छ।

के कुरामा पनि चुप लागेर बसौं msgs_state_info फेरि अधूरा TL को कान बाहिर टाँसिएको छ (हामीलाई बाइट्स को एक भेक्टर चाहिन्छ, र तल्लो दुई बिट मा एक enum थियो, र माथि दुई बिट मा झण्डा थियो)। कुरो फरक छ । यो सबै व्यवहारमा किन भैरहेको छ कसैले बुझेको छ ? एक वास्तविक ग्राहक मा आवश्यक?... कठिनाई संग, तर एक व्यक्ति डिबगिङ मा संलग्न छ भने केहि लाभ कल्पना गर्न सक्नुहुन्छ, र एक अन्तरक्रियात्मक मोड मा - के र कसरी सर्भर सोध्नुहोस्। तर यहाँ अनुरोधहरू वर्णन गरिएको छ गोल यात्रा.

यसले पछ्याउँछ कि प्रत्येक पक्षले गुप्तिकरण र सन्देशहरू मात्र पठाउन हुँदैन, तर तिनीहरूको बारेमा जानकारी, तिनीहरूको प्रतिक्रियाहरूको बारेमा, अज्ञात समयको लागि भण्डारण गर्नुपर्छ। कागजातले यी सुविधाहरूको समय वा व्यावहारिक लागूताको वर्णन गर्दैन। कुनै बाटो छैन। सबैभन्दा अचम्मको कुरा के छ कि तिनीहरू वास्तवमा आधिकारिक ग्राहकहरूको कोडमा प्रयोग गरिन्छ! स्पष्ट रूपमा उनीहरूलाई केहि भनिएको थियो जुन सार्वजनिक कागजातमा समावेश गरिएको थिएन। कोडबाट बुझ्नुहोस् किन, अब TL को मामलामा जत्तिकै सरल छैन - यो (अपेक्षाकृत) तार्किक रूपमा पृथक भाग होइन, तर एप्लिकेसन आर्किटेक्चरमा बाँधिएको टुक्रा हो, अर्थात्। एप्लिकेसन कोड बुझ्नको लागि धेरै समय चाहिन्छ।

पिंग र समय। लामहरू।

सबै कुराबाट, यदि हामीले सर्भर आर्किटेक्चर (ब्याकएन्डहरूमा अनुरोधहरूको वितरण) को बारे मा अनुमानहरू सम्झन्छौं भने, एक बरु दुखद कुरा पछ्याउँछ - TCP मा सबै डेलिभरी ग्यारेन्टीहरूको बावजुद (या त डाटा डेलिभर गरिएको छ, वा तपाईंलाई अन्तरको बारेमा सूचित गरिनेछ, तर। समस्या आउनु अघि डाटा डेलिभर गरिनेछ), त्यो MTProto मा पुष्टिकरणहरू - कुनै ग्यारेन्टी छैन। सर्भरले सजिलैसँग तपाईंको सन्देश हराउन वा बाहिर फाल्न सक्छ, र यसको बारेमा केहि गर्न सकिँदैन, केवल विभिन्न प्रकारका बैसाखीहरू प्रयोग गर्नुहोस्।

र सबै भन्दा पहिले - सन्देश लामहरू। ठीक छ, एउटा कुराको साथ सबै कुरा सुरुदेखि नै स्पष्ट थियो - एक अपुष्ट सन्देश भण्डारण र रिसेन्ट हुनुपर्छ। अनि कति समय पछि ? र जोस्टरले उसलाई चिन्छ। हुनसक्छ ती लत सेवा सन्देशहरूले कुनै न कुनै रूपमा यो समस्यालाई बैसाखीको साथ समाधान गर्दछ, भन्नुहोस्, टेलिग्राम डेस्कटपमा तिनीहरूसँग मिल्दोजुल्दो 4 लामहरू छन् (हुनसक्छ, पहिले नै उल्लेख गरिएझैं, यसका लागि तपाईंले यसको कोड र वास्तुकलालाई अझ गम्भीरताका साथ खोज्नु आवश्यक छ; उही रूपमा। समय, हामीलाई थाहा छ कि यसलाई नमूनाको रूपमा लिन सकिँदैन; MTProto योजनाबाट निश्चित संख्यामा यसमा प्रयोग गरिएको छैन)।

यो किन भइरहेको छ? सम्भवतः, सर्भर प्रोग्रामरहरूले क्लस्टर भित्र विश्वसनीयता सुनिश्चित गर्न असमर्थ भए, वा अगाडि ब्यालेन्सरमा बफरिङ पनि गरे, र यो समस्या ग्राहकलाई हस्तान्तरण गरे। निराशाको कारण, Vasily TCP बाट एल्गोरिदमहरू प्रयोग गरेर केवल दुई लामहरू सहित वैकल्पिक विकल्प लागू गर्ने प्रयास गर्यो - सर्भरमा RTT मापन गर्दै र अपुष्ट अनुरोधहरूको संख्यामा आधारित "सञ्झ्याल" (सन्देशहरूमा) को आकार समायोजन गर्दै। त्यो हो, सर्भरको लोड मूल्याङ्कन गर्नको लागि यस्तो नराम्रो अनुमानित हो कि हाम्रा कति अनुरोधहरू यसले एकै समयमा चपाउन सक्छ र हराउन सक्दैन।

खैर, त्यो हो, तपाईंले बुझ्नुभयो, हैन? यदि तपाईंले TCP मा चलिरहेको प्रोटोकलको शीर्षमा TCP पुन: लागू गर्नु पर्छ भने, यसले धेरै खराब डिजाइन गरिएको प्रोटोकललाई संकेत गर्दछ।

ओह हो, तपाईलाई किन एक भन्दा बढि लाम चाहिन्छ, र यसले जे भए पनि उच्च-स्तर API सँग काम गर्ने व्यक्तिको लागि के अर्थ राख्छ? हेर्नुहोस्, तपाइँ अनुरोध गर्नुहुन्छ, यसलाई क्रमबद्ध गर्नुहुन्छ, तर प्रायः तपाइँ यसलाई तुरुन्तै पठाउन सक्नुहुन्न। किन? किनभने जवाफ हुनेछ msg_id, जुन अस्थायी होаम एक लेबल हुँ, जसको असाइनमेन्ट सकेसम्म ढिलो सम्म स्थगित हुन्छ - यदि सर्भरले हामी र उहाँको बीचको समयको बेमेलको कारणले यसलाई अस्वीकार गर्दछ (अवश्य पनि, हामीले वर्तमानबाट हाम्रो समय परिवर्तन गर्ने क्रच बनाउन सक्छौं। सर्भरको प्रतिक्रियाहरूबाट गणना गरिएको डेल्टा थपेर सर्भरमा - आधिकारिक ग्राहकहरूले यो गर्छन्, तर यो कच्चा र बफरिङको कारण गलत छ)। त्यसकारण, जब तपाइँ पुस्तकालयबाट स्थानीय प्रकार्य कलको साथ अनुरोध गर्नुहुन्छ, सन्देश निम्न चरणहरूमा जान्छ:

यो एक लाम मा छ र गुप्तिकरण पर्खिरहेको छ।
नियुक्त गरियो msg_id र सन्देश अर्को लाममा गयो - सम्भावित फर्वार्डिङ; सकेटमा पठाउनुहोस्।
a) सर्भरले MsgsAck लाई जवाफ दियो - सन्देश डेलिभर गरिएको थियो, हामी यसलाई "अन्य लाम" बाट मेटाउँछौं।
ख) वा उल्टो, उसलाई केहि मन परेन, उसले जवाफ दियो badmsg - "अर्को लाम" बाट पुन: पठाउनुहोस्
ग) केहि थाहा छैन, सन्देश अर्को लामबाट रिसेन्ट गर्न आवश्यक छ - तर यो ठ्याक्कै कहिले थाहा छैन।
सर्भरले अन्ततः जवाफ दियो RpcResult - वास्तविक प्रतिक्रिया (वा त्रुटि) - डेलिभर मात्र होइन, तर प्रक्रिया पनि।

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

र यस बिन्दुमा गैर-प्राविधिक विचारहरू खेलमा आउँछन्। अनुभवबाट, हामीले धेरै बैसाखीहरू देखेका छौं, र यसको अतिरिक्त, हामी अब खराब सल्लाह र वास्तुकलाको थप उदाहरणहरू देख्नेछौं - त्यस्ता परिस्थितिहरूमा, के यो विश्वास गर्न र त्यस्ता निर्णयहरू गर्न लायक छ? प्रश्न बयानबाजी हो (अवश्य पनि होइन)।

हामी के कुरा गर्दैछौं? यदि "सन्देशहरू बारे औषधि सन्देशहरू" को विषयमा तपाईं अझै पनि "तपाईं मूर्ख हुनुहुन्छ, तपाईंले हाम्रो शानदार योजना बुझ्नुभएन!" जस्ता आपत्तिहरूको साथ अनुमान लगाउन सक्नुहुन्छ। (त्यसैले पहिले कागजात लेख्नुहोस्, सामान्य मानिसहरूले जस्तै, तर्क र प्याकेट एक्सचेन्जको उदाहरणहरू सहित, त्यसपछि हामी कुरा गर्नेछौं), त्यसपछि समय/टाइमआउटहरू एक विशुद्ध व्यावहारिक र विशिष्ट प्रश्न हो, यहाँ सबै कुरा लामो समयदेखि ज्ञात छ। कागजातले हामीलाई टाइमआउटको बारेमा के बताउँछ?

सर्भरले सामान्यतया एक RPC प्रतिक्रिया प्रयोग गरेर ग्राहक (सामान्यतया, एक RPC क्वेरी) बाट सन्देशको प्राप्ति स्वीकार गर्दछ। यदि प्रतिक्रिया आउन लामो समय छ भने, सर्भरले पहिले रसिद स्वीकृति पठाउन सक्छ, र केहि हदसम्म पछि, RPC प्रतिक्रिया आफैं।

ग्राहकले सामान्यतया सर्भरबाट सन्देश प्राप्त भएको स्वीकार गर्दछ (सामान्यतया, एक RPC प्रतिक्रिया) अर्को RPC क्वेरीमा एक स्वीकृति थपेर यदि यो धेरै ढिलो प्रसारण गरिएको छैन (यदि यो उत्पन्न भएको छ भने, भन्नुहोस्, रसिद पछि 60-120 सेकेन्ड। सर्भरबाट सन्देश)। यद्यपि, यदि लामो समयको लागि सर्भरमा सन्देशहरू पठाउने कुनै कारण छैन वा यदि सर्भरबाट ठूलो संख्यामा अपरिचित सन्देशहरू छन् (भन्नुहोस्, 16 भन्दा बढी), ग्राहकले स्ट्यान्ड-अलोन स्वीकृति पठाउँदछ।

... म अनुवाद गर्छु: हामी आफैंलाई थाहा छैन कि हामीलाई यसको कति र कसरी आवश्यक छ, त्यसैले मानौं कि यो यस्तै हुन दिनुहोस्।

र पिंगहरूको बारेमा:

पिङ सन्देशहरू (PING/PONG)
ping#7abe77ec ping_id:long = Pong;
प्रतिक्रिया सामान्यतया उही जडानमा फर्काइन्छ:
pong#347773c5 msg_id:long ping_id:long = Pong;
यी सन्देशहरूलाई स्वीकृति आवश्यक पर्दैन। एक पिंग पिंगको प्रतिक्रियामा मात्र प्रसारित हुन्छ जबकि पिंग दुबै पक्षबाट सुरु गर्न सकिन्छ।

स्थगित जडान बन्द + PING
ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;
पिंग जस्तै काम गर्दछ। थप रूपमा, यो प्राप्त भएपछि, सर्भरले टाइमर सुरु गर्दछ जसले हालको जडान disconnect_delay सेकेन्ड पछि बन्द गर्नेछ जबसम्म यसले समान प्रकारको नयाँ सन्देश प्राप्त गर्दैन जुन स्वचालित रूपमा सबै अघिल्लो टाइमरहरू रिसेट हुन्छ। यदि ग्राहकले यी पिङहरू प्रत्येक 60 सेकेन्डमा एक पटक पठाउँछ भने, उदाहरणका लागि, यसले 75 सेकेन्डको बराबर disconnect_delay सेट गर्न सक्छ।

के तिमी पागल हो ?! 60 सेकेन्डमा, ट्रेन स्टेशनमा प्रवेश गर्नेछ, यात्रुहरूलाई छोड्नेछ र उठाउनेछ, र फेरि सुरुङमा सम्पर्क गुमाउनेछ। 120 सेकेन्डमा, जब तपाइँ यसलाई सुन्नुहुन्छ, यो अर्कोमा आइपुग्छ, र जडान प्रायः बिच्छेद हुनेछ। खैर, खुट्टाहरू कहाँबाट आउँदैछन् भन्ने कुरा स्पष्ट छ - "मैले घण्टी बजिरहेको सुनें, तर थाहा छैन यो कहाँ हो", त्यहाँ Nagl को एल्गोरिदम र TCP_NODELAY विकल्प छ, अन्तरक्रियात्मक कार्यको लागि। तर, माफ गर्नुहोस्, यसको पूर्वनिर्धारित मान होल्ड गर्नुहोस् - 200 मिलिसेकेन्ड यदि तपाइँ साँच्चै यस्तै केहि चित्रण गर्न चाहनुहुन्छ र सम्भावित दुई प्याकेटहरूमा बचत गर्न चाहनुहुन्छ भने, त्यसपछि यसलाई 5 सेकेन्डका लागि बन्द गर्नुहोस्, वा "प्रयोगकर्ताले टाइप गर्दै हुनुहुन्छ..." सन्देशको समय समाप्त भएको छ। तर थप छैन।

र अन्तमा, पिंगहरू। त्यो हो, TCP जडानको जीवन्तता जाँच गर्दै। यो हास्यास्पद छ, तर लगभग 10 वर्ष पहिले मैले हाम्रो संकायको छात्रावासको मेसेन्जरको बारेमा एउटा आलोचनात्मक पाठ लेखेको थिएँ - त्यहाँका लेखकहरूले पनि ग्राहकबाट सर्भर पिंग गरे, र उल्टो होइन। तर तेस्रो वर्षका विद्यार्थीहरू एउटा कुरा हुन्, र अन्तर्राष्ट्रिय कार्यालय अर्को हो, हैन?

पहिलो, सानो शैक्षिक कार्यक्रम। TCP जडान, प्याकेट एक्सचेन्जको अभावमा, हप्तासम्म बाँच्न सक्छ। यो राम्रो र नराम्रो दुबै हो, उद्देश्यमा निर्भर गर्दछ। यदि तपाइँसँग सर्भरमा SSH जडान खुला छ भने यो राम्रो छ, तपाइँ कम्प्युटरबाट उठ्नुभयो, राउटर रिबुट गर्नुभयो, तपाइँको ठाउँमा फर्कनुभयो - यो सर्भर मार्फत सत्र च्यातिएको थिएन (तपाईंले केहि टाइप गर्नुभएन, त्यहाँ कुनै प्याकेटहरू थिएनन्) , यो सुविधाजनक छ। यो खराब छ यदि सर्भरमा हजारौं ग्राहकहरू छन्, प्रत्येकले स्रोतहरू लिइरहेका छन् (नमस्ते, पोस्टग्रेस!), र ग्राहकको होस्टले लामो समय पहिले रिबुट गरेको हुन सक्छ - तर हामीलाई यसको बारेमा थाहा छैन।

च्याट/आईएम प्रणालीहरू एक अतिरिक्त कारणका लागि दोस्रो केसमा पर्छन् - अनलाइन स्थितिहरू। यदि प्रयोगकर्ता "खिर्यो" भने, तपाईंले आफ्नो वार्तालापहरूलाई यस बारे सूचित गर्न आवश्यक छ। अन्यथा, तपाईंले जब्बरका सिर्जनाकर्ताहरूले गरेको गल्तीको अन्त्य गर्नुहुनेछ (र २० वर्षको लागि सच्याइयो) - प्रयोगकर्ताले विच्छेद गरेको छ, तर उनीहरूले उहाँलाई सन्देशहरू लेख्न जारी राख्छन्, उहाँ अनलाइन हुनुहुन्छ भन्ने विश्वास गर्दै (जुन पनि यी कुराहरूमा पूर्ण रूपमा हराएका थिए। विच्छेदन पत्ता लगाउन केही मिनेट अघि)। होइन, TCP_KEEPALIVE विकल्प, जसलाई धेरै मानिसहरू जसले TCP टाइमरहरूले अनियमित रूपमा काम गर्ने तरिका (दसौं सेकेन्डहरू जस्तै जंगली मानहरू सेट गरेर) काम गर्छ भनेर बुझ्दैनन्, यहाँ मद्दत गर्दैन - तपाईंले यो सुनिश्चित गर्न आवश्यक छ कि ओएस कर्नेल मात्र होइन। प्रयोगकर्ताको मेसिन जीवित छ, तर सामान्य रूपमा काम गरिरहेको छ, प्रतिक्रिया दिन सक्षम छ, र एप्लिकेसन आफैं (तपाईलाई लाग्छ कि यो फ्रिज हुन सक्दैन? उबुन्टु 20 मा टेलिग्राम डेस्कटप मेरो लागि एक पटक भन्दा बढी फ्रिज भयो)।

त्यसैले पिङ गर्नु पर्छ सर्भर ग्राहक, र यसको विपरित होइन - यदि ग्राहकले यो गर्छ भने, जडान बिग्रिएको छ भने, पिङ डेलिभर हुने छैन, लक्ष्य हासिल हुने छैन।

हामी टेलिग्राममा के देख्छौं? यो ठ्याक्कै उल्टो छ! खैर, त्यो हो। औपचारिक रूपमा, निस्सन्देह, दुवै पक्षले एकअर्कालाई पिंग गर्न सक्छन्। व्यवहारमा, ग्राहकहरूले बैसाखी प्रयोग गर्छन् ping_delay_disconnect, जसले सर्भरमा टाइमर सेट गर्दछ। ठीक छ, मलाई माफ गर्नुहोस्, यो ग्राहकले निर्णय गर्न सक्दैन कि ऊ त्यहाँ पिंग बिना कति समय बस्न चाहन्छ। सर्भर, यसको लोडमा आधारित, राम्रो जान्दछन्। तर, पक्कै पनि, यदि तपाइँ स्रोतहरू मन पराउनुहुन्न भने, तब तपाइँ तपाइँको आफ्नै दुष्ट पिनोचियो हुनुहुनेछ, र एक बैसाखीले गर्नेछ ...

यसलाई कसरी डिजाइन गरिएको हुनुपर्छ?

मलाई विश्वास छ कि माथिका तथ्यहरूले स्पष्ट रूपमा संकेत गर्दछ कि Telegram/VKontakte टोली कम्प्यूटर नेटवर्कको यातायात (र तल्लो) स्तर र सान्दर्भिक मामिलाहरूमा उनीहरूको कम योग्यताको क्षेत्रमा धेरै सक्षम छैन।

यो किन यति जटिल भयो, र कसरी टेलिग्राम आर्किटेक्टहरूले आपत्ति गर्ने प्रयास गर्न सक्छन्? तथ्य यो हो कि तिनीहरूले एक सत्र बनाउन प्रयास गरे जुन TCP जडान विच्छेदहरू बाँचेका छन्, अर्थात्, के अहिले डेलिभर गरिएको छैन, हामी पछि डेलिभर गर्नेछौं। तिनीहरूले सम्भवतः UDP यातायात बनाउन पनि प्रयास गरे, तर तिनीहरूले कठिनाइहरूको सामना गरे र यसलाई त्यागे (त्यसैले कागजात खाली छ - त्यहाँ घमण्ड गर्न केही थिएन)। तर सामान्य रूपमा कसरी नेटवर्कहरू र विशेष रूपमा TCP ले काम गर्दछ, तपाईं यसमा भर पर्न सक्नुहुन्छ, र तपाईंले यसलाई कहाँ गर्न आवश्यक छ (र कसरी), र यसलाई क्रिप्टोग्राफीसँग संयोजन गर्ने प्रयासको कारणले गर्दा "दुई चराहरूसँग। एक ढुङ्गा", यो परिणाम हो।

यो कसरी आवश्यक थियो? भन्ने तथ्यका आधारमा msg_id रिप्ले आक्रमणहरू रोक्नको लागि क्रिप्टोग्राफिक दृष्टिकोणबाट आवश्यक टाइमस्ट्याम्प हो, यसमा एक अद्वितीय पहिचानकर्ता प्रकार्य संलग्न गर्नु गल्ती हो। त्यसकारण, मौलिक रूपमा हालको वास्तुकला परिवर्तन नगरीकन (जब अपडेट स्ट्रिम उत्पन्न हुन्छ, त्यो पोष्टहरूको यस श्रृंखलाको अर्को भागको लागि उच्च-स्तर API विषय हो), एकलाई आवश्यक पर्दछ:

क्लाइन्टमा TCP जडान राखेको सर्भरले जिम्मेवारी लिन्छ - यदि यो सकेटबाट पढेको छ भने, कृपया स्वीकार गर्नुहोस्, प्रक्रिया गर्नुहोस् वा त्रुटि फिर्ता गर्नुहोस्, कुनै हानि छैन। त्यसपछि पुष्टिकरण id को भेक्टर होइन, तर केवल "पछिल्लो प्राप्त seq_no" - केवल एक संख्या, TCP मा जस्तै (दुई संख्या - तपाईंको seq र पुष्टि गरिएको एक)। हामी सँधै सत्र भित्र छौं, होइन र?
रिप्ले आक्रमणहरू रोक्नको लागि टाइमस्ट्याम्प एक अलग क्षेत्र, एक ला नोन्स हुन्छ। यो जाँच गरिएको छ, तर अरू केहि असर गर्दैन। पर्याप्त र uint32 - यदि हाम्रो नुन कम्तिमा हरेक आधा दिनमा परिवर्तन हुन्छ भने, हामी हालको समयको पूर्णांक भागको कम-अर्डर बिटहरूमा 16 बिटहरू आवंटित गर्न सक्छौं, बाँकी - सेकेन्डको आंशिक भागमा (अहिलेको रूपमा)।
हटाइयो msg_id सबैमा - ब्याकएन्डहरूमा अनुरोधहरू छुट्याउनको दृष्टिकोणबाट, त्यहाँ, पहिले, ग्राहक आईडी, र दोस्रो, सत्र आईडी, तिनीहरूलाई जोड्नुहोस्। तदनुसार, अनुरोध पहिचानकर्ताको रूपमा मात्र एक चीज पर्याप्त छ seq_no.

यो पनि सबैभन्दा सफल विकल्प होइन; एक पूर्ण अनियमित एक पहिचानकर्ता को रूप मा काम गर्न सक्छ - यो पहिले नै उच्च-स्तर API मा एक सन्देश पठाउँदा गरिसकिएको छ। आर्किटेक्चरलाई सापेक्षिकबाट निरपेक्षमा पूर्ण रूपमा रिमेक गर्नु राम्रो हुनेछ, तर यो अर्को भागको लागि विषय हो, यो पोस्ट होइन।

API?

ता-दाम! त्यसोभए, पीडा र बैसाखीले भरिएको बाटोमा संघर्ष गरिसकेपछि, हामीले अन्ततः सर्भरमा कुनै पनि अनुरोधहरू पठाउन र तिनीहरूलाई कुनै पनि जवाफ प्राप्त गर्न, साथै सर्भरबाट अद्यावधिकहरू प्राप्त गर्न सक्षम भयौं (अनुरोधको जवाफमा होइन, तर यो आफैंमा। हामीलाई पठाउँदछ, जस्तै PUSH, यदि कोही यो स्पष्ट छ भने)।

ध्यान, अब लेख मा पर्ल मा मात्र उदाहरण हुनेछ! (वाक्यविन्याससँग परिचित नभएकाहरूका लागि, धन्यको पहिलो तर्क वस्तुको डेटा संरचना हो, दोस्रो यसको वर्ग हो):

2019.10.24 12:00:51 $1 = {
'cb' => 'TeleUpd::__ANON__',
'out' => bless( {
'filter' => bless( {}, 'Telegram::ChannelMessagesFilterEmpty' ),
'channel' => bless( {
'access_hash' => '-6698103710539760874',
'channel_id' => '1380524958'
}, 'Telegram::InputPeerChannel' ),
'pts' => '158503',
'flags' => 0,
'limit' => 0
}, 'Telegram::Updates::GetChannelDifference' ),
'req_id' => '6751291954012037292'
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'req_msg_id' => '6751291954012037292',
'result' => bless( {
'pts' => 158508,
'flags' => 3,
'final' => 1,
'new_messages' => [],
'users' => [],
'chats' => [
bless( {
'title' => 'Хулиномика',
'username' => 'hoolinomics',
'flags' => 8288,
'id' => 1380524958,
'access_hash' => '-6698103710539760874',
'broadcast' => 1,
'version' => 0,
'photo' => bless( {
'photo_small' => bless( {
'volume_id' => 246933270,
'file_reference' => '
'secret' => '1854156056801727328',
'local_id' => 228648,
'dc_id' => 2
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'local_id' => 228650,
'file_reference' => '
'secret' => '1275570353387113110',
'volume_id' => 246933270
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1531221081
}, 'Telegram::Channel' )
],
'timeout' => 300,
'other_updates' => [
bless( {
'pts_count' => 0,
'message' => bless( {
'post' => 1,
'id' => 852,
'flags' => 50368,
'views' => 8013,
'entities' => [
bless( {
'length' => 20,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 18,
'offset' => 480,
'url' => 'https://alexeymarkov.livejournal.com/[url_вырезан].html'
}, 'Telegram::MessageEntityTextUrl' )
],
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'text' => '???? 165',
'data' => 'send_reaction_0'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 9'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'message' => 'А вот и новая книга! 
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
напечатаю.',
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571724559,
'edit_date' => 1571907562
}, 'Telegram::Message' ),
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'message' => bless( {
'edit_date' => 1571907589,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571807301,
'message' => 'Почему Вы считаете Facebook плохой компанией? Можете прокомментировать? По-моему, это шикарная компания. Без долгов, с хорошей прибылью, а если решат дивы платить, то и еще могут нехило подорожать.
Для меня ответ совершенно очевиден: потому что Facebook делает ужасный по качеству продукт. Да, у него монопольное положение и да, им пользуется огромное количество людей. Но мир не стоит на месте. Когда-то владельцам Нокии было смешно от первого Айфона. Они думали, что лучше Нокии ничего быть не может и она навсегда останется самым удобным, красивым и твёрдым телефоном - и доля рынка это красноречиво демонстрировала. Теперь им не смешно.
Конечно, рептилоиды сопротивляются напору молодых гениев: так Цукербергом был пожран Whatsapp, потом Instagram. Но всё им не пожрать, Паша Дуров не продаётся!
Так будет и с Фейсбуком. Нельзя всё время делать говно. Кто-то когда-то сделает хороший продукт, куда всё и уйдут.
#соцсети #facebook #акции #рептилоиды',
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 452'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'text' => '???? 21',
'data' => 'send_reaction_1'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'entities' => [
bless( {
'length' => 199,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 8,
'offset' => 919
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 928,
'length' => 9
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 6,
'offset' => 938
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 11,
'offset' => 945
}, 'Telegram::MessageEntityHashtag' )
],
'views' => 6964,
'flags' => 50368,
'id' => 854,
'post' => 1
}, 'Telegram::Message' ),
'pts_count' => 0
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'message' => bless( {
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 213'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 8'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 2940,
'entities' => [
bless( {
'length' => 609,
'offset' => 348
}, 'Telegram::MessageEntityItalic' )
],
'flags' => 50368,
'post' => 1,
'id' => 857,
'edit_date' => 1571907636,
'date' => 1571902479,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'message' => 'Пост про 1С вызвал бурную полемику. Человек 10 (видимо, 1с-программистов) единодушно написали:
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
Я бы добавил, что блестящая у 1С дистрибуция, а маркетинг... ну, такое.'
}, 'Telegram::Message' ),
'pts_count' => 0,
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'pts_count' => 0,
'message' => bless( {
'message' => 'Здравствуйте, расскажите, пожалуйста, чем вредит экономике 1С?
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
#софт #it #экономика',
'edit_date' => 1571907650,
'date' => 1571893707,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'flags' => 50368,
'post' => 1,
'id' => 856,
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 360'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 32'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 4416,
'entities' => [
bless( {
'offset' => 0,
'length' => 64
}, 'Telegram::MessageEntityBold' ),
bless( {
'offset' => 1551,
'length' => 5
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 3,
'offset' => 1557
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 1561,
'length' => 10
}, 'Telegram::MessageEntityHashtag' )
]
}, 'Telegram::Message' )
}, 'Telegram::UpdateEditChannelMessage' )
]
}, 'Telegram::Updates::ChannelDifference' )
}, 'MTProto::RpcResult' )
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'update' => bless( {
'user_id' => 2507460,
'status' => bless( {
'was_online' => 1571907651
}, 'Telegram::UserStatusOffline' )
}, 'Telegram::UpdateUserStatus' ),
'date' => 1571907650
}, 'Telegram::UpdateShort' )
};
2019.10.24 12:05:46 $1 = {
'in' => bless( {
'chats' => [],
'date' => 1571907946,
'seq' => 0,
'updates' => [
bless( {
'max_id' => 141719,
'channel_id' => 1295963795
}, 'Telegram::UpdateReadChannelInbox' )
],
'users' => []
}, 'Telegram::Updates' )
};
2019.10.24 13:01:23 $1 = {
'in' => bless( {
'server_salt' => '4914425622822907323',
'unique_id' => '5297282355827493819',
'first_msg_id' => '6751307555044380692'
}, 'MTProto::NewSessionCreated' )
};
2019.10.24 13:24:21 $1 = {
'in' => bless( {
'chats' => [
bless( {
'username' => 'freebsd_ru',
'version' => 0,
'flags' => 5440,
'title' => 'freebsd_ru',
'min' => 1,
'photo' => bless( {
'photo_small' => bless( {
'local_id' => 328733,
'volume_id' => 235140688,
'dc_id' => 2,
'file_reference' => '
'secret' => '4426006807282303416'
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'file_reference' => '
'volume_id' => 235140688,
'local_id' => 328735,
'secret' => '71251192991540083'
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1461248502,
'id' => 1038300508,
'democracy' => 1,
'megagroup' => 1
}, 'Telegram::Channel' )
],
'users' => [
bless( {
'last_name' => 'Panov',
'flags' => 1048646,
'min' => 1,
'id' => 82234609,
'status' => bless( {}, 'Telegram::UserStatusRecently' ),
'first_name' => 'Dima'
}, 'Telegram::User' )
],
'seq' => 0,
'date' => 1571912647,
'updates' => [
bless( {
'pts' => 137596,
'message' => bless( {
'flags' => 256,
'message' => 'Создать джейл с именем покороче ??',
'to_id' => bless( {
'channel_id' => 1038300508
}, 'Telegram::PeerChannel' ),
'id' => 119634,
'date' => 1571912647,
'from_id' => 82234609
}, 'Telegram::Message' ),
'pts_count' => 1
}, 'Telegram::UpdateNewChannelMessage' )
]
}, 'Telegram::Updates' )
};

हो, उद्देश्यमा बिगार्ने होइन - यदि तपाईंले यसलाई अहिलेसम्म पढ्नुभएको छैन भने, अगाडि बढ्नुहोस् र यो गर्नुहोस्!

ओह, वाइ~~... यो कस्तो देखिन्छ? केहि धेरै परिचित ... हुनसक्छ यो JSON मा एक विशिष्ट वेब API को डेटा संरचना हो, बाहेक कक्षाहरू पनि वस्तुहरूमा संलग्न छन्? ..

त्यसोभए यो यसरी बाहिर जान्छ ... यो सबै के हो, कमरेडहरू? ... यति धेरै प्रयास - र हामी वेब प्रोग्रामरहरू जहाँ आराम गर्न रोक्यौं। भर्खर सुरु गर्दै?.. HTTPS मा JSON मात्र सरल हुनेछैन?! बदलामा के पायौं ? के प्रयास यसको लायक थियो?

TL+MTProto ले हामीलाई के दियो र कस्ता विकल्पहरू सम्भव छन् भनेर मूल्याङ्कन गरौं। ठीक छ, HTTP, जुन अनुरोध-प्रतिक्रिया मोडेलमा केन्द्रित छ, एक खराब फिट हो, तर कम्तिमा TLS को शीर्षमा केहि छ?

कम्प्याक्ट सीरियलाइजेशन। यो डाटा संरचना देखेर, JSON जस्तै, मलाई याद छ कि त्यहाँ यसको बाइनरी संस्करणहरू छन्। MsgPack लाई अपर्याप्त रूपमा एक्स्टेन्सिबलको रूपमा चिन्ह लगाउनुहोस्, तर त्यहाँ छ, उदाहरणका लागि, CBOR - वैसे, मा वर्णन गरिएको मानक RFC 7049। यसले परिभाषित गरेको तथ्यको लागि यो उल्लेखनीय छ ट्यागहरू, विस्तार संयन्त्रको रूपमा, र बीचमा पहिले नै मानकीकृत उपलब्ध:

25 + 256 - लाइन नम्बरको सन्दर्भमा दोहोर्याइएको रेखाहरू प्रतिस्थापन गर्दै, यस्तो सस्तो कम्प्रेसन विधि
26 - वर्ग नाम र कन्स्ट्रक्टर तर्क संग क्रमबद्ध पर्ल वस्तु
27 - प्रकारको नाम र कन्स्ट्रक्टर आर्गुमेन्टको साथ क्रमबद्ध भाषा-स्वतन्त्र वस्तु

ठिक छ, मैले TL र CBOR मा स्ट्रिङ र वस्तु प्याकिङ सक्षम गरी समान डेटा क्रमबद्ध गर्ने प्रयास गरें। नतिजा मेगाबाइटबाट कतै CBOR को पक्षमा भिन्न हुन थाल्यो:

cborlen=1039673 tl_len=1095092

र त्यसैले, निष्कर्ष: त्यहाँ पर्याप्त सरल ढाँचाहरू छन् जुन तुलनात्मक दक्षताको साथ, सिङ्क्रोनाइजेसन विफलता वा अज्ञात पहिचानकर्ताको समस्याको अधीनमा छैनन्।

द्रुत जडान स्थापना। यसको मतलब पुन: जडान पछि शून्य आरटीटी हुन्छ (जब कुञ्जी पहिले नै एक पटक उत्पन्न भइसकेको छ) - पहिलो MTProto सन्देशबाट लागू हुन्छ, तर केही रिजर्भेसनका साथ - उही नुन हिट गर्नुहोस्, सत्र सडेको छैन, आदि। यसको सट्टा TLS ले हामीलाई के प्रस्ताव गर्छ? विषयमा उद्धरण:

TLS मा PFS प्रयोग गर्दा, TLS सत्र टिकट (RFC 5077) कुञ्जीहरू पुन: वार्ता नगरी र सर्भरमा मुख्य जानकारी भण्डारण नगरी गुप्तिकरण गरिएको सत्र पुन: सुरु गर्न। पहिलो जडान खोल्दा र कुञ्जीहरू सिर्जना गर्दा, सर्भरले जडान स्थिति इन्क्रिप्ट गर्दछ र ग्राहकलाई (सत्र टिकटको रूपमा) पठाउँछ। तदनुसार, जब जडान पुन: सुरु हुन्छ, ग्राहकले सत्र कुञ्जी सहित, सर्भरमा फिर्ता सत्र टिकट पठाउँछ। टिकट आफैं एक अस्थायी कुञ्जी (सत्र टिकट कुञ्जी) संग गुप्तिकरण गरिएको छ, जुन सर्भरमा भण्डार गरिएको छ र क्लस्टर समाधानहरूमा SSL प्रशोधन गर्ने सबै फ्रन्टएन्ड सर्भरहरू बीच वितरित हुनुपर्छ। [१०]। तसर्थ, सत्र टिकटको परिचयले PFS लाई उल्लङ्घन गर्न सक्छ यदि अस्थायी सर्भर कुञ्जीहरू सम्झौता गरिएको छ, उदाहरणका लागि, जब तिनीहरू लामो समयसम्म भण्डारण हुन्छन् (OpenSSL, nginx, Apache तिनीहरूलाई कार्यक्रमको सम्पूर्ण अवधिको लागि पूर्वनिर्धारित रूपमा भण्डार गर्नुहोस्; लोकप्रिय साइटहरू प्रयोग गर्छन्। धेरै घण्टाको लागि कुञ्जी, दिन सम्म)।

यहाँ RTT शून्य होइन, तपाईंले कम्तिमा ClientHello र ServerHello साटासाट गर्नुपर्छ, त्यसपछि ग्राहकले Finished सँग डाटा पठाउन सक्छ। तर यहाँ हामीले यो याद गर्नुपर्छ कि हामीसँग वेब छैन, यसको भर्खरै खोलिएको जडानहरूको गुच्छाको साथ, तर एक मेसेन्जर, जसको जडान प्रायः एक र धेरै वा कम लामो समयसम्म रहन्छ, वेब पृष्ठहरूमा अपेक्षाकृत छोटो अनुरोधहरू - सबै कुरा मल्टिप्लेक्स गरिएको छ। आन्तरिक रूपमा। त्यो हो, यो एकदम स्वीकार्य छ यदि हामी वास्तवमै खराब सबवे खण्डमा आएनौं।

अरु केहि बिर्सनुभयो? कमेन्टमा लेख्नुहोस ।

फेरि जारी राखौंला!

पोष्टहरूको यस शृङ्खलाको दोस्रो भागमा हामी प्राविधिक होइन, तर संगठनात्मक मुद्दाहरू - दृष्टिकोण, विचारधारा, इन्टरफेस, प्रयोगकर्ताहरूप्रतिको दृष्टिकोण, आदिलाई विचार गर्नेछौं। यद्यपि, यहाँ प्रस्तुत गरिएको प्राविधिक जानकारीको आधारमा।

तेस्रो भाग प्राविधिक घटक / विकास अनुभव विश्लेषण गर्न जारी रहनेछ। तपाईले सिक्नुहुनेछ, विशेष गरी:

TL प्रकार को विविधता संग pandemonium को निरन्तरता
च्यानलहरू र सुपरसमूहहरूको बारेमा अज्ञात कुराहरू
किन संवादहरू रोस्टर भन्दा खराब छन्
निरपेक्ष बनाम सापेक्ष सन्देश ठेगाना बारे
तस्बिर र छविमा के फरक छ
इमोजीले इटालिक पाठमा कसरी हस्तक्षेप गर्छ

र अन्य बैसाखी! सम्पर्कमा रहनुहोस्!

स्रोत: www.habr.com

टेलिग्रामको प्रोटोकल र संगठनात्मक दृष्टिकोणको आलोचना। भाग १, प्राविधिक: स्क्र्याचबाट ग्राहक लेख्ने अनुभव - TL, MT