சமீபத்தில், டெலிகிராம் எவ்வளவு சிறந்தது, நெட்வொர்க் அமைப்புகளை உருவாக்குவதில் துரோவ் சகோதரர்கள் எவ்வளவு புத்திசாலித்தனம் மற்றும் அனுபவம் வாய்ந்தவர்கள் போன்ற பதிவுகள் ஹப்ரேயில் அடிக்கடி வெளிவரத் தொடங்கியுள்ளன. அதே நேரத்தில், மிகச் சிலரே உண்மையில் தொழில்நுட்ப சாதனத்தில் தங்களை மூழ்கடித்தனர் - அதிகபட்சம் அவர்கள் மிகவும் எளிமையான (மற்றும் MTProto இலிருந்து மிகவும் வித்தியாசமான) JSON-அடிப்படையிலான Bot API ஐப் பயன்படுத்துகின்றனர், மேலும் பொதுவாக ஏற்றுக்கொள்கிறார்கள். நம்பிக்கை மீது அந்த பாராட்டுக்கள் மற்றும் PR அனைத்தும் தூதுவரைச் சுற்றி வருகின்றன. ஏறக்குறைய ஒன்றரை ஆண்டுகளுக்கு முன்பு, என்பிஓ எச்செலன் வாசிலி (துரதிர்ஷ்டவசமாக, ஹப்ரேயில் உள்ள அவரது கணக்கு வரைவோடு நீக்கப்பட்டது) தனது சொந்த டெலிகிராம் கிளையண்டை பெர்லில் புதிதாக எழுதத் தொடங்கினார், பின்னர் இந்த வரிகளின் ஆசிரியர் இணைந்தார். ஏன் பேர்ல், சிலர் உடனே கேட்பார்கள்? ஏனென்றால், இதுபோன்ற திட்டங்கள் ஏற்கனவே பிற மொழிகளில் உள்ளன, உண்மையில், இது முக்கியமல்ல, வேறு எந்த மொழியும் அங்கு இருக்கலாம் முடிக்கப்பட்ட நூலகம், அதன்படி ஆசிரியர் எல்லா வழிகளிலும் செல்ல வேண்டும் புதிதாக. மேலும், குறியாக்கவியல் அத்தகைய ஒரு விஷயம் - நம்புங்கள், ஆனால் சரிபார்க்கவும். பாதுகாப்பை மையமாகக் கொண்ட தயாரிப்புடன், நீங்கள் விற்பனையாளரின் ஆயத்த நூலகத்தை நம்பி அதை கண்மூடித்தனமாக நம்ப முடியாது (இருப்பினும், இது இரண்டாம் பாகத்தில் அதிகம் பேசப்படும் தலைப்பு). இந்த நேரத்தில், நூலகம் "நடுத்தர" மட்டத்தில் நன்றாக வேலை செய்கிறது (எந்தவொரு API கோரிக்கையையும் செய்ய உங்களை அனுமதிக்கிறது).

இருப்பினும், இந்த தொடர் இடுகைகளில் குறியாக்கவியல் மற்றும் கணிதம் அதிகம் இருக்காது. ஆனால் வேறு பல தொழில்நுட்ப விவரங்கள் மற்றும் கட்டிடக்கலை ஊன்றுகோல்கள் இருக்கும் (புதிதாக எழுதாமல், எந்த மொழியிலும் நூலகத்தைப் பயன்படுத்துபவர்களுக்கும் இது பயனுள்ளதாக இருக்கும்). எனவே, கிளையண்டை புதிதாக செயல்படுத்த முயற்சிப்பதே முக்கிய குறிக்கோளாக இருந்தது அதிகாரப்பூர்வ ஆவணங்களின்படி. அதாவது, அதிகாரப்பூர்வ வாடிக்கையாளர்களின் மூலக் குறியீடு மூடப்பட்டதாக வைத்துக்கொள்வோம் (மீண்டும், இரண்டாவது பகுதியில், இது உண்மையில் என்ன என்ற தலைப்பை இன்னும் விரிவாக வெளிப்படுத்துவோம். அது நடக்கும் எனவே), ஆனால், பழைய நாட்களைப் போலவே, எடுத்துக்காட்டாக, RFC போன்ற ஒரு தரநிலை உள்ளது - விவரக்குறிப்பின் படி ஒரு கிளையண்டை எழுத முடியுமா, மூலத்தில் “எட்டிப்பார்க்காமல்”, அதிகாரப்பூர்வமாக (டெலிகிராம் டெஸ்க்டாப், மொபைல்) கூட , அதிகாரப்பூர்வமற்ற டெலிதான் கூட?

உள்ளடக்க அட்டவணை:

• ஆவணம்... இருக்கிறதா? இது உண்மையா?..
• ஒரு இளம் எழுத்தாளராக எங்கு தொடங்குவது?
• பைனரி வரிசையாக்கம்: TL (வகை மொழி) மற்றும் அதன் திட்டம், மற்றும் அடுக்குகள் மற்றும் பல பயங்கரமான வார்த்தைகள்
  • அதிகாரப்பூர்வ ஆவணங்களைப் படிக்க விரும்பாதவர்களுக்கான TL தொடரியல் துணைக்குழுவின் சுருக்கமான விளக்கம்
  • திசையன், இது கழிக்க முடியாதது
  • குறியீட்டில் இருக்கும் TL செயலாக்கங்கள்
  • வகை மொழியில் வகைகளின் பற்றாக்குறை
  • பதிப்பு. அடுக்குகள்
• எம்டிபிரோட்டோ
  • போக்குவரத்து அடுக்கு
  • விசைகள், செய்திகள், அமர்வுகள், டிஃபி-ஹெல்மேன்
  • செய்தி செய்திகள், msg_id, msg_seqno, ஒப்புகைகள், தவறான திசையில் பிங் மற்றும் பிற தனித்தன்மைகள்
    • RPC: கோரிக்கைகள், பதில்கள், பிழைகள். உறுதிப்படுத்தல்கள்.
    • அடிமையாதல்: செய்தி இடுகை நிலைகள்
    • பிங்ஸ் மற்றும் நேரங்கள். வரிசைகள்.
    • அது எப்படி வடிவமைக்கப்பட்டிருக்க வேண்டும்?
• API?
• தொடரும்!

ஆவணம்... இருக்கிறதா? இது உண்மையா?..

இந்த கட்டுரைக்கான குறிப்புகளின் துண்டுகள் கடந்த கோடையில் சேகரிக்கத் தொடங்கின. இந்த நேரத்தில் அதிகாரப்பூர்வ தளத்தில் https://core.telegram.org ஆவணம் அடுக்கு 23 இல் இருந்தது, அதாவது. 2014 இல் எங்காவது சிக்கிக்கொண்டது (நினைவில் கொள்ளுங்கள், அப்போது இன்னும் சேனல்கள் கூட இல்லை?). நிச்சயமாக, கோட்பாட்டில், இது 2014 இல் அந்த நேரத்தில் ஒரு கிளையண்டை செயல்பாட்டுடன் செயல்படுத்துவதை சாத்தியமாக்கியிருக்க வேண்டும். ஆனால் இந்த நிலையில் கூட, ஆவணங்கள் முதலில், முழுமையடையவில்லை, இரண்டாவதாக, சில இடங்களில் அது முரண்பட்டது. ஒரு மாதத்திற்கு முன்பு, செப்டம்பர் 2019 இல், அது ஒருவேளை முற்றிலும் புதிய லேயர் 105க்கான ஆவணங்களின் பெரிய புதுப்பிப்பை தளத்தில் வைத்திருப்பது கண்டறியப்பட்டது, இப்போது எல்லாவற்றையும் மீண்டும் படிக்க வேண்டும். உண்மையில், பல கட்டுரைகள் திருத்தப்பட்டுள்ளன, ஆனால் பல மாறாமல் உள்ளன. எனவே, ஆவணங்களைப் பற்றி கீழே உள்ள விமர்சனத்தைப் படிக்கும்போது, ​​இந்த விஷயங்களில் சில இனி பொருந்தாது, ஆனால் சில இன்னும் சரியாக உள்ளன என்பதை நீங்கள் நினைவில் கொள்ள வேண்டும். எல்லாவற்றிற்கும் மேலாக, நவீன உலகில் 5 ஆண்டுகள் என்பது நிறைய இல்லை, ஆனால் மிகவும் நிறைய. அப்போதிருந்து (குறிப்பாக நீங்கள் நிராகரிக்கப்பட்ட மற்றும் உயிர்த்தெழுப்பப்பட்ட ஜியோசாட்களை கணக்கில் எடுத்துக் கொள்ளவில்லை என்றால்), திட்டத்தில் உள்ள ஏபிஐ முறைகளின் எண்ணிக்கை நூற்றிலிருந்து இருநூற்று ஐம்பதுக்கும் அதிகமாக வளர்ந்துள்ளது!

ஒரு இளம் எழுத்தாளராக எங்கு தொடங்குவது?

நீங்கள் புதிதாக எழுதினாலும் அல்லது பயன்படுத்தினாலும் பரவாயில்லை, எடுத்துக்காட்டாக, ஆயத்த நூலகங்கள் போன்றவை பைத்தானுக்கு டெலிதான் அல்லது PHP க்கான மேட்லைன், எப்படியிருந்தாலும், உங்களுக்கு முதலில் தேவைப்படும் உங்கள் விண்ணப்பத்தை பதிவு செய்யவும் - அளவுருக்கள் கிடைக்கும் api_id и api_hash (VKontakte API உடன் பணிபுரிந்தவர்கள் உடனடியாக புரிந்துகொள்கிறார்கள்) இதன் மூலம் சேவையகம் பயன்பாட்டை அடையாளம் காணும். இது வேண்டும் சட்ட காரணங்களுக்காக, ஆனால் நூலக ஆசிரியர்கள் அதை ஏன் இரண்டாம் பாகத்தில் வெளியிட முடியாது என்பதைப் பற்றி மேலும் பேசுவோம். சோதனை மதிப்புகளில் நீங்கள் திருப்தி அடைவீர்கள், அவை மிகவும் குறைவாக இருந்தாலும் - உண்மை என்னவென்றால், இப்போது நீங்கள் உங்கள் எண்ணில் பதிவு செய்யலாம் ஒன்று மட்டுமே விண்ணப்பம், எனவே அவசரப்பட வேண்டாம்.

இப்போது, ​​​​ஒரு தொழில்நுட்பக் கண்ணோட்டத்தில், பதிவுசெய்த பிறகு, ஆவணங்கள், நெறிமுறை போன்றவற்றிற்கான புதுப்பிப்புகள் குறித்து டெலிகிராமில் இருந்து அறிவிப்புகளைப் பெற வேண்டும் என்பதில் நாங்கள் ஆர்வமாக இருந்திருக்க வேண்டும். அதாவது, கப்பல்துறைகள் கொண்ட தளம் வெறுமனே "அடித்துவிட்டது" மற்றும் வாடிக்கையாளர்களை உருவாக்கத் தொடங்கியவர்களுடன் தொடர்ந்து வேலை செய்தது என்று ஒருவர் கருதலாம். அது எளிதானது. ஆனால் இல்லை, அப்படி எதுவும் கவனிக்கப்படவில்லை, எந்த தகவலும் வரவில்லை.

நீங்கள் புதிதாக எழுதினால், பெறப்பட்ட அளவுருக்களின் பயன்பாடு உண்மையில் இன்னும் தொலைவில் உள்ளது. இருந்தாலும் https://core.telegram.org/ மற்றும் தொடங்குவதில் முதலில் அவற்றைப் பற்றி பேசுகிறது, உண்மையில், நீங்கள் முதலில் செயல்படுத்த வேண்டும் எம்டிபிரோட்டோ நெறிமுறை - ஆனால் நீங்கள் நம்பினால் OSI மாதிரியின் படி தளவமைப்பு நெறிமுறையின் பொதுவான விளக்கத்தின் பக்கத்தின் முடிவில், பின்னர் முற்றிலும் வீண்.

உண்மையில், MTProto க்கு முன்னும் பின்னும், ஒரே நேரத்தில் பல நிலைகளில் (OS கர்னலில் பணிபுரியும் வெளிநாட்டு நெட்வொர்க்கர்கள் சொல்வது போல், அடுக்கு மீறல்), ஒரு பெரிய, வேதனையான மற்றும் பயங்கரமான தலைப்பு வழியில் வரும் ...

பைனரி வரிசையாக்கம்: TL (வகை மொழி) மற்றும் அதன் திட்டம், மற்றும் அடுக்குகள் மற்றும் பல பயங்கரமான வார்த்தைகள்

இந்த தலைப்பு, உண்மையில், டெலிகிராமின் பிரச்சனைகளுக்கு முக்கியமானது. நீங்கள் அதை ஆராய முயற்சித்தால் பல பயங்கரமான வார்த்தைகள் இருக்கும்.

எனவே, திட்டம். இந்த வார்த்தை உங்களுக்கு நினைவிருந்தால், சொல்லுங்கள், JSON திட்டம்நீங்கள் நினைத்தது சரிதான். இலக்கு ஒன்றே: கடத்தப்பட்ட தரவுகளின் சாத்தியமான தொகுப்பை விவரிக்க சில மொழிகள். உண்மையில், இங்குதான் ஒற்றுமை முடிகிறது. பக்கத்திலிருந்து என்றால் எம்டிபிரோட்டோ நெறிமுறை, அல்லது அதிகாரப்பூர்வ கிளையண்டின் மூல மரத்திலிருந்து, சில திட்டத்தைத் திறக்க முயற்சிப்போம், இதுபோன்ற ஒன்றைக் காண்போம்:

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;

இதை முதன்முறையாகப் பார்க்கும் ஒருவர் எழுதப்பட்டவற்றின் ஒரு பகுதியை மட்டுமே உள்ளுணர்வாக அடையாளம் காண்பார் - சரி, இவை வெளிப்படையாக கட்டமைப்புகள் (பெயர் எங்கிருந்தாலும், இடது அல்லது வலதுபுறம்?), அவற்றில் புலங்கள் உள்ளன, அதன் பிறகு வகை பெருங்குடல் வழியாக செல்கிறது ... அநேகமாக. இங்கே, கோண அடைப்புக்குறிக்குள், சி ++ போன்ற வார்ப்புருக்கள் இருக்கலாம் (உண்மையில், உண்மையில் இல்லை) மற்ற எல்லா சின்னங்களும் எதைக் குறிக்கின்றன, கேள்விக்குறிகள், ஆச்சரியக்குறிகள், சதவீதங்கள், லட்டுகள் (மற்றும் அவை வெவ்வேறு இடங்களில் வெவ்வேறு விஷயங்களைக் குறிக்கின்றன), எங்காவது உள்ளன, ஆனால் எங்காவது இல்லை, ஹெக்ஸாடெசிமல் எண்கள் - மற்றும் மிக முக்கியமாக, இதிலிருந்து எப்படி பெறுவது правильный (சர்வரால் நிராகரிக்கப்படாது) பைட் ஸ்ட்ரீம்? நீங்கள் ஆவணங்களைப் படிக்க வேண்டும் (ஆம், அருகிலுள்ள JSON பதிப்பில் ஸ்கீமாவிற்கான இணைப்புகள் உள்ளன - ஆனால் இது அதை தெளிவாக்கவில்லை).

பக்கத்தைத் திறக்கிறது பைனரி தரவு வரிசைப்படுத்தல் மற்றும் காளான்கள் மற்றும் தனித்துவமான கணிதத்தின் மாயாஜால உலகில் மூழ்கி, 4 ஆம் ஆண்டில் மாடனைப் போன்றது. எழுத்துக்கள், வகை, மதிப்பு, இணைப்பான், செயல்பாட்டு இணைப்பான், சாதாரண வடிவம், கூட்டு வகை, பாலிமார்பிக் வகை... அதுவும் முதல் பக்கம் தான்! அடுத்தது உங்களுக்கு காத்திருக்கிறது TL மொழி, இது ஏற்கனவே ஒரு அற்பமான கோரிக்கை மற்றும் பதிலுக்கான உதாரணத்தைக் கொண்டிருந்தாலும், மிகவும் பொதுவான நிகழ்வுகளுக்கு பதிலை வழங்காது, அதாவது ரஷ்ய மொழியிலிருந்து ஆங்கிலத்தில் மொழிபெயர்க்கப்பட்ட கணிதத்தின் மறுபரிசீலனையை நீங்கள் இன்னும் எட்டு உள்ளமைகளில் படிக்க வேண்டும். பக்கங்கள்!

செயல்பாட்டு மொழிகள் மற்றும் தானியங்கி வகை அனுமானங்களை நன்கு அறிந்த வாசகர்கள், நிச்சயமாக, இந்த மொழி விளக்கங்களில், ஒரு எடுத்துக்காட்டில் இருந்து கூட, மிகவும் பழக்கமானவர்கள், மேலும் இது கொள்கையளவில் மோசமாக இல்லை என்று கூறலாம். இதற்கு எதிர்ப்புகள் வருமாறு:

• , ஆமாம் цель நன்றாக இருக்கிறது, ஆனால் ஐயோ அடையவில்லை
• ரஷ்ய பல்கலைக்கழகங்களில் கல்வி என்பது ஐடி சிறப்புகளில் கூட மாறுபடும் - எல்லோரும் தொடர்புடைய பாடத்திட்டத்தைப் படிப்பதில்லை
• இறுதியாக, நாம் பார்ப்பது போல், அது நடைமுறையில் உள்ளது தேவையில்லை, ஏனெனில் விவரிக்கப்பட்ட TL இன் வரையறுக்கப்பட்ட துணைக்குழு மட்டுமே பயன்படுத்தப்படுகிறது

சொன்னது போல லியோநெர்ட் சேனலில் #perl ஃப்ரீநோட் ஐஆர்சி நெட்வொர்க்கில், டெலிகிராமில் இருந்து மேட்ரிக்ஸுக்கு ஒரு நுழைவாயிலைச் செயல்படுத்த முயற்சிக்கிறது (மேற்கோளின் மொழிபெயர்ப்பு நினைவகத்திலிருந்து துல்லியமாக இல்லை):

முதன்முறையாக தியரியை டைப் செய்ய அறிமுகம் செய்யப்பட்ட ஒருவர், உற்சாகமடைந்து, நடைமுறையில் தேவையா என்று கவலைப்படாமல், அதனுடன் விளையாட முயற்சிப்பது போல் உணர்கிறேன்.

வெற்று வகைகளின் தேவை (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;

எப்போதும் வரையறை தொடங்குகிறது வடிவமைப்பாளர், அதன் பிறகு, விருப்பமாக (நடைமுறையில், எப்போதும்) சின்னத்தின் மூலம் # இருக்க வேண்டும் CRC32 கொடுக்கப்பட்ட வகையின் இயல்பாக்கப்பட்ட விளக்க சரத்திலிருந்து. அடுத்து புலங்களின் விளக்கம் வரும், அவை இருந்தால் - வகை காலியாக இருக்கலாம். இது அனைத்தும் சமமான அடையாளத்துடன் முடிவடைகிறது, கொடுக்கப்பட்ட கட்டமைப்பாளரின் வகையின் பெயர் - அதாவது, உண்மையில், துணை வகை - சொந்தமானது. சம அடையாளத்தின் வலதுபுறத்தில் உள்ள வகை பாலிமார்பிக் - அதாவது, இது பல குறிப்பிட்ட வகைகளுக்கு ஒத்திருக்கும்.

வரிக்குப் பிறகு வரையறை ஏற்பட்டால் ---functions---, பின்னர் தொடரியல் ஒரே மாதிரியாக இருக்கும், ஆனால் பொருள் வேறுபட்டதாக இருக்கும்: கட்டமைப்பாளர் RPC செயல்பாட்டின் பெயராக மாறும், புலங்கள் அளவுருக்களாக மாறும் (சரி, அதாவது, கீழே விவரிக்கப்பட்டுள்ள அதே கட்டமைப்பில் இருக்கும், அது கொடுக்கப்பட்ட பொருளாக இருக்கும்), மேலும் "பாலிமார்பிக் வகை' என்பது திரும்பிய முடிவின் வகையாகும். உண்மை, இது இன்னும் பாலிமார்ஃபிக்காக இருக்கும் - பிரிவில் வரையறுக்கப்பட்டுள்ளது ---types---, மற்றும் இந்த கட்டமைப்பாளர் கருதப்பட மாட்டார். அழைக்கப்படும் செயல்பாடுகளின் ஓவர்லோடுகளை அவற்றின் வாதங்களின் மூலம் தட்டச்சு செய்யவும், அதாவது. சில காரணங்களால், C++ இல் உள்ளதைப் போல, ஒரே பெயரில் ஆனால் வேறு கையொப்பம் கொண்ட பல செயல்பாடுகள் TL இல் வழங்கப்படவில்லை.

OOP இல்லையென்றால் ஏன் "கன்ஸ்ட்ரக்டர்" மற்றும் "பாலிமார்பிக்"? சரி, உண்மையில், OOP - ஒரு சுருக்க வகுப்பாக ஒரு பாலிமார்பிக் வகை, மற்றும் கட்டமைப்பாளர்கள் அதன் நேரடி வழித்தோன்றல் வகுப்புகள், மேலும் இதைப் பற்றி யோசிப்பது எளிதாக இருக்கும். final பல மொழிகளின் சொற்களில். உண்மையில், நிச்சயமாக, இங்கே ஒற்றுமை OO நிரலாக்க மொழிகளில் உண்மையான ஓவர்லோடட் கன்ஸ்ட்ரக்டர் முறைகளுடன். இங்கே தரவு கட்டமைப்புகள் மட்டுமே இருப்பதால், முறைகள் எதுவும் இல்லை (கீழே உள்ள செயல்பாடுகள் மற்றும் முறைகளின் விளக்கம் அவை என்ன என்பதைப் பற்றி தலையில் குழப்பத்தை உருவாக்கும் திறன் கொண்டது, ஆனால் அது வேறு எதையாவது பற்றியது) - நீங்கள் ஒரு கட்டமைப்பாளரைப் பற்றி நினைக்கலாம். அதில் இருந்து மதிப்பு கட்டப்பட்டு வருகிறது பைட்டுகளின் ஸ்ட்ரீமைப் படிக்கும்போது தட்டச்சு செய்யவும்.

இது எப்படி நடக்கிறது? எப்பொழுதும் 4 பைட்டுகளைப் படிக்கும் டீரியலைசர், மதிப்பைப் பார்க்கிறது 0xcrc32 - அடுத்து என்ன நடக்கும் என்பதைப் புரிந்துகொள்கிறார் field1 வகையுடன் int, அதாவது வகையுடன் இந்த மேலோட்டப் புலத்தில் சரியாக 4 பைட்டுகளைப் படிக்கிறது 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"இயற்கை எண்" என்று பொருள். அதாவது, உண்மையில், கையொப்பமிடப்படாத எண்கள் உண்மையான சுற்றுகளில் கையொப்பமிடப்படாத எண்கள் காணப்பட்டால் மட்டுமே. எனவே, அடுத்தது கேள்விக்குறியுடன் கூடிய கட்டுமானமாகும், அதாவது இது புலம் - தொடர்புடைய பிட் குறிப்பிடப்பட்ட புலத்தில் (தோராயமாக ஒரு மும்முனை ஆபரேட்டர் போல) அமைக்கப்பட்டால் மட்டுமே அது கம்பியில் இருக்கும். எனவே, இந்த பிட் இயக்கப்பட்டது என்று வைத்துக்கொள்வோம், நீங்கள் ஒரு புலத்தைப் படிக்க வேண்டும் Type, இது எங்கள் எடுத்துக்காட்டில் 2 கட்டமைப்பாளர்களைக் கொண்டுள்ளது. ஒன்று காலியாக உள்ளது (ஒரு அடையாளங்காட்டியை மட்டுமே கொண்டுள்ளது), மற்றொன்று புலம் கொண்டது ids வகையுடன் ids:Vector<long>.

டெம்ப்ளேட்கள் மற்றும் ஜெனரிக்ஸ் இரண்டும் நல்லது அல்லது ஜாவா என்று நீங்கள் நினைக்கலாம். ஆனால் இல்லை. கிட்டத்தட்ட. இது ஒரே உண்மையான சுற்றுகளில் கோண அடைப்புக்குறிகளின் வழக்கு, மேலும் இது வெக்டருக்கு மட்டுமே பயன்படுத்தப்படுகிறது. ஒரு பைட் ஸ்ட்ரீமில், இது திசையன் வகைக்கு 4 CRC32 பைட்டுகளாக இருக்கும், எப்போதும் ஒரே மாதிரியாக இருக்கும், பின்னர் 4 பைட்டுகள் - வரிசை உறுப்புகளின் எண்ணிக்கை, பின்னர் இந்த உறுப்புகள் தாங்களாகவே இருக்கும்.

வரிசைப்படுத்தல் எப்போதும் 4 பைட்டுகளின் வார்த்தைகளில் நிகழ்கிறது, எல்லா வகைகளும் அதன் மடங்குகளாகும் - உள்ளமைக்கப்பட்ட வகைகளும் விவரிக்கப்பட்டுள்ளன. bytes и string நீளத்தின் கைமுறை வரிசைமுறை மற்றும் இந்த சீரமைப்பு 4 - சரி, இது சாதாரணமாகவும் ஒப்பீட்டளவில் திறமையாகவும் தெரிகிறது? TL ஆனது திறமையான பைனரி சீரியலைசேஷன் என்று கூறப்பட்டாலும், அவற்றுடன் நரகத்திற்கு, எதையும் விரிவுபடுத்தினாலும், பூலியன் மதிப்புகள் மற்றும் 4 பைட்டுகள் வரை ஒற்றை எழுத்து சரங்கள் கூட, JSON இன்னும் தடிமனாக இருக்குமா? பாருங்க, தேவையில்லாத ஃபீல்டுகளை கூட பிட் ஃபிளாக்ஸ் மூலம் தவிர்க்கலாம், எல்லாம் நன்றாக இருக்கிறது, மேலும் எதிர்காலத்திற்கு நீட்டிக்கக் கூடியதாக இருக்கிறது, பிறகு கன்ஸ்ட்ரக்டரில் புதிய விருப்பப் புலங்களைச் சேர்த்தீர்களா?..

ஆனால் இல்லை, நீங்கள் எனது சுருக்கமான விளக்கத்தை அல்ல, ஆனால் முழு ஆவணத்தையும் படித்து, செயல்படுத்துவது பற்றி யோசித்தால். முதலாவதாக, கன்ஸ்ட்ரக்டரின் CRC32 ஆனது இயல்பாக்கப்பட்ட ஸ்கீமா உரை விளக்கச் சரத்தால் கணக்கிடப்படுகிறது (கூடுதல் இடைவெளியை அகற்று, முதலியன) - எனவே ஒரு புதிய புலம் சேர்க்கப்பட்டால், வகை விளக்கச் சரம் மாறும், எனவே அதன் CRC32 மற்றும், அதன் விளைவாக, வரிசைப்படுத்தல். புதிய கொடிகள் அமைக்கப்பட்ட ஒரு புலத்தைப் பெற்றால் பழைய வாடிக்கையாளர் என்ன செய்வார், ஆனால் அவற்றை அடுத்து என்ன செய்வது என்று அவருக்குத் தெரியவில்லை? ..

இரண்டாவதாக, நினைவில் கொள்வோம் CRC32, இது முக்கியமாக இங்கு பயன்படுத்தப்படுகிறது ஹாஷ் செயல்பாடுகள் எந்த வகை (டி)வரிசைப்படுத்தப்படுகிறது என்பதை தனித்துவமாக தீர்மானிக்க. இங்கே நாம் மோதல்களின் சிக்கலை எதிர்கொள்கிறோம் - இல்லை, நிகழ்தகவு 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) லிஸ்ப்பில்). ஆனால் இது வெளிப்படையாக தேவைப்படும் ஒவ்வொருவரும் உறுப்பு அதன் வகையை விவரிக்க கூடுதலாக 4 பைட்டுகளை (TL வழக்கில் CRC32) செலவிடுகிறது. ஒரு வரிசையை விவரிப்பது எளிது நிலையான அளவு, ஆனால் முன்னர் அறியப்படாத நீளத்தின் வரிசையின் விஷயத்தில், நாங்கள் உடைந்து விடுகிறோம்.

ஒரு திசையனை வெளியிடுவதற்கு TL உங்களை அனுமதிக்காததால், அதை பக்கத்தில் சேர்க்க வேண்டும். இறுதியில் ஆவணம் கூறுகிறது:

வரிசைப்படுத்தல் எப்போதும் ஒரே கட்டமைப்பான “திசையன்” (const 0x1cb5c415 = crc32(“திசையன் t:வகை # [ t ] = வெக்டர் t”) ஐப் பயன்படுத்துகிறது, இது t வகையின் மாறியின் குறிப்பிட்ட மதிப்பைச் சார்ந்தது அல்ல.

விருப்பமான அளவுரு t இன் மதிப்பு வரிசைப்படுத்தலில் ஈடுபடவில்லை, ஏனெனில் இது முடிவு வகையிலிருந்து பெறப்பட்டது (எப்போதும் டீரியலைசேஷன் முன் அறியப்படும்).

உன்னிப்பாக பார்த்தல்: vector {t:Type} # [ t ] = Vector t - ஆனால் எங்கும் முதல் எண் திசையன் நீளத்திற்கு சமமாக இருக்க வேண்டும் என்று வரையறையே கூறவில்லை! மேலும் அது எங்கிருந்தும் பின்பற்றப்படுவதில்லை. இது நீங்கள் மனதில் வைத்து உங்கள் கைகளால் செயல்படுத்த வேண்டிய ஒரு கொடுக்கப்பட்டதாகும். மற்ற இடங்களில், ஆவணம் கூட இந்த வகை போலியானது என்று நேர்மையாகக் குறிப்பிடுகிறது:

Vector t பாலிமார்பிக் சூடோடைப் என்பது ஒரு "வகை" ஆகும், அதன் மதிப்பு பெட்டி அல்லது வெற்று வகை t இன் மதிப்புகளின் வரிசையாகும்.

… ஆனால் அதில் கவனம் செலுத்துவதில்லை. நீங்கள், கணிதத்தை (பல்கலைக்கழகப் படிப்பில் இருந்தே உங்களுக்குத் தெரிந்திருக்கலாம்) நீட்டுவதில் சோர்வாக இருக்கும்போது, ​​​​அதை நடைமுறையில் எப்படிச் செய்வது என்று மதிப்பெண் மற்றும் பார்க்க முடிவு செய்தால், உங்கள் தலையில் அபிப்ராயம் இருக்கும்: இங்கே தீவிர கணிதம் அடிப்படையாக உள்ளது. , வெளிப்படையாக கூல் பீப்பிள் (இரண்டு கணிதவியலாளர்கள் -ஏசிஎம் வெற்றியாளர்), மற்றும் யாரும் இல்லை. இலக்கு - களியாட்ட - அடையப்பட்டது.

மூலம், எண் பற்றி. நினைவு கூருங்கள் # அது ஒரு இணைச்சொல் nat, இயற்கை எண்:

வகை வெளிப்பாடுகள் உள்ளன (typeexpr) மற்றும் எண் வெளிப்பாடுகள் (nat-expr) இருப்பினும், அவை ஒரே மாதிரியாக வரையறுக்கப்படுகின்றன.

type-expr ::= expr
nat-expr ::= expr

ஆனால் இலக்கணத்தில் அவை அதே வழியில் விவரிக்கப்பட்டுள்ளன, அதாவது. இந்த வேறுபாட்டை மீண்டும் நினைவில் வைத்துக் கொள்ள வேண்டும் மற்றும் கைமுறையாக செயல்படுத்த வேண்டும்.

சரி, ஆம், டெம்ப்ளேட் வகைகள் (vector<int>, vector<User>) ஒரு பொதுவான அடையாளங்காட்டி உள்ளது (#1cb5c415), அதாவது. அழைப்பு என அறிவிக்கப்படும் என தெரிந்தால்

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

நீங்கள் ஒரு வெக்டருக்கு மட்டும் காத்திருக்கிறீர்கள், ஆனால் பயனர்களின் திசையன். மேலும் துல்லியமாக, வேண்டும் காத்திருங்கள் - உண்மையான குறியீட்டில், ஒவ்வொரு உறுப்பு, வெற்று வகையாக இல்லாவிட்டால், ஒரு கட்டமைப்பாளரைக் கொண்டிருக்கும், மேலும் செயல்பாட்டில் ஒரு நல்ல வழியில் சரிபார்க்க வேண்டியது அவசியம் - மேலும் இந்த திசையனின் ஒவ்வொரு உறுப்புக்கும் சரியாக அனுப்பப்பட்டோம். அந்த வகை? அது சில வகையான PHP ஆக இருந்தால், அதில் வரிசை வெவ்வேறு கூறுகளில் வெவ்வேறு வகைகளைக் கொண்டிருக்கலாம்?

இந்த கட்டத்தில், நீங்கள் ஆச்சரியப்படத் தொடங்குகிறீர்கள் - அத்தகைய TL தேவையா? ஒருவேளை வண்டிக்கு மனித சீரியலைஸரைப் பயன்படுத்த முடியுமா, ஏற்கனவே இருந்த அதே புரோட்டோபஃப்? இது கோட்பாடு, நடைமுறையில் பார்க்கலாம்.

குறியீட்டில் இருக்கும் TL செயலாக்கங்கள்

துரோவின் பங்கு விற்பனையுடன் நன்கு அறியப்பட்ட நிகழ்வுகளுக்கு முன்பே VKontakte இன் குடலில் TL பிறந்தது மற்றும் (நிச்சயமாக), டெலிகிராமின் வளர்ச்சிக்கு முன்பே. மற்றும் திறந்த மூலத்தில் முதல் செயல்படுத்தலின் ஆதாரங்கள் நீங்கள் நிறைய வேடிக்கையான ஊன்றுகோல்களைக் காணலாம். டெலிகிராமில் இப்போது இருப்பதை விட மொழியே முழுமையாக அங்கு செயல்படுத்தப்பட்டது. எடுத்துக்காட்டாக, திட்டத்தில் ஹாஷ்கள் பயன்படுத்தப்படுவதில்லை (அதாவது மாறுபட்ட நடத்தை கொண்ட உள்ளமைக்கப்பட்ட போலி வகை (வெக்டார் போன்றது)). அல்லது

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, [09.10.18/17/07 XNUMX:XNUMX] எல்லாவற்றிற்கும் மேலாக, அவர்கள் ஒரு சில சுருக்கங்களைத் திருகினார்கள், பின்னர் அவர்கள் ஒரு போல்ட்டை சுத்தி, கோட்ஜெகரின் மீது ஊன்றுகோல் வைத்ததால் கழுதை சூடாக இருக்கிறது.
இதன் விளைவாக, முதலில் கப்பல்துறையிலிருந்து பைலட்.jpg
பின்னர் jekichan.webp குறியீட்டிலிருந்து

நிச்சயமாக, அல்காரிதம்கள் மற்றும் கணிதத்தை நன்கு அறிந்தவர்களிடமிருந்து, அவர்கள் Aho, Ullman ஐப் படித்திருப்பார்கள் என்று எதிர்பார்க்கலாம், மேலும் பல தசாப்தங்களாக DSL தொகுப்பிகளை எழுதுவதற்கான நடைமுறைத் தொழில்துறை நிலையான கருவிகளை அவர்கள் அறிந்திருக்கிறார்கள், இல்லையா?

எழுதியவர் தந்தி-கிளை விட்டலி வால்ட்மேன், TLO வடிவம் அதன் (cli) வரம்புகளுக்கு வெளியே நிகழ்வதில் இருந்து புரிந்து கொள்ள முடியும், குழுவின் உறுப்பினர் - இப்போது TL பாகுபடுத்தும் நூலகம் ஒதுக்கப்பட்டுள்ளது. தனித்தனியாகஅவளின் அபிப்ராயம் என்ன TL பாகுபடுத்தி? ..

16.12 04:18 வாசிலி: என் கருத்துப்படி, யாரோ லெக்ஸ் + யாக்கில் தேர்ச்சி பெறவில்லை.
16.12 04:18 வாசிலி: இல்லையெனில் என்னால் அதை விளக்க முடியாது
16.12 04:18 வாசிலி: சரி, அல்லது VK இல் உள்ள வரிகளின் எண்ணிக்கைக்கு அவர்களுக்கு பணம் கொடுக்கப்பட்டது
16.12 04:19 வாசிலி: மற்றவற்றின் 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] இங்கே நீங்கள் சிந்திக்க வேண்டும், அத்தகைய TL தேவையா?
மாற்று செயலாக்கங்களை நான் குழப்ப விரும்பினால், நான் வரி முறிவுகளைச் செருகத் தொடங்குவேன், பாகுபடுத்திகளில் பாதி பல வரி வரையறைகளில் உடைந்துவிடும்
இருப்பினும், tdesktop கூட

ஒன்-லைனர்களைப் பற்றிய விஷயத்தை நினைவில் கொள்ளுங்கள், சிறிது நேரம் கழித்து அதற்குத் திரும்புவோம்.

சரி, டெலிகிராம்-கிளை அதிகாரப்பூர்வமற்றது, டெலிகிராம் டெஸ்க்டாப் அதிகாரப்பூர்வமானது, ஆனால் மற்றவை பற்றி என்ன? மற்றும் யாருக்குத் தெரியும்?.. ஆண்ட்ராய்டு கிளையண்ட் குறியீட்டில், ஸ்கீமா பாகுபடுத்தி எதுவும் இல்லை (இது திறந்த மூலத்தைப் பற்றிய கேள்விகளை எழுப்புகிறது, ஆனால் இது இரண்டாவது பகுதிக்கானது), ஆனால் வேறு பல வேடிக்கையான குறியீடுகள் இருந்தன, ஆனால் அவற்றைப் பற்றி கீழே உள்ள துணைப்பிரிவு.

வரிசையாக்கம் நடைமுறையில் வேறு என்ன கேள்விகளை எழுப்புகிறது? எடுத்துக்காட்டாக, அவை பிட் புலங்கள் மற்றும் நிபந்தனை புலங்கள் மூலம் திருகப்பட்டன:

வாசிலி: flags.0? true
கொடி அமைக்கப்பட்டால் புலம் உள்ளது மற்றும் உண்மை என்று பொருள்

வாசிலி: flags.1? int
புலம் தற்போது உள்ளது மற்றும் சீரழிக்கப்பட வேண்டும்

வாசிலி: கழுதை, எரிக்காதே, நீ என்ன செய்கிறாய்!
வாசிலி: ஆவணத்தில் எங்கோ உண்மை என்பது பூஜ்ஜிய நீளத்தின் வெற்று வகை என்று குறிப்பிடப்பட்டுள்ளது, ஆனால் அவர்களின் ஆவணங்களிலிருந்து எதையாவது சேகரிப்பது நம்பத்தகாதது
வாசிலி: திறந்த செயலாக்கங்களில் அப்படி எதுவும் இல்லை, ஆனால் நிறைய ஊன்றுகோல்கள் மற்றும் முட்டுகள் உள்ளன

டெலிதான் எப்படி? MTProto என்ற தலைப்பில் முன்னோக்கிப் பார்த்தால், ஒரு உதாரணம் - ஆவணத்தில் அத்தகைய துண்டுகள் உள்ளன, ஆனால் அடையாளம் % இது "கொடுக்கப்பட்ட வெற்று வகைக்கு ஒத்ததாக" மட்டுமே விவரிக்கப்படுகிறது, அதாவது. கீழே உள்ள எடுத்துக்காட்டுகளில், பிழை அல்லது ஆவணமற்ற ஒன்று:

Vasily, [22.06.18/18/38 XNUMX:XNUMX] ஒரே இடத்தில்:

msg_container#73f1f8dc messages:vector message = MessageContainer;

வேறு ஒன்றில்:

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

இவை இரண்டு பெரிய வேறுபாடுகள், நிஜ வாழ்க்கையில் ஒருவித நிர்வாண திசையன் வருகிறது

வெக்டார் வரையறைகளை நான் பார்த்ததில்லை, அதைக் கண்டதும் இல்லை

கையால் டெலிதானில் எழுதப்பட்ட பகுப்பாய்வு

அவரது திட்டம் வரையறையை வெளிப்படுத்தியது msg_container

மீண்டும், கேள்வி% பற்றி உள்ளது. இது விவரிக்கப்படவில்லை.

Vadim Goncharov, [22.06.18/19/22 XNUMX:XNUMX PM] மற்றும் tdesktop இல் உள்ளீர்களா?

Vasily, [22.06.18/19/23 XNUMX:XNUMX] ஆனால் ரெகுலேட்டர்களில் உள்ள அவர்களின் TL பாகுபடுத்தும் ஒருவேளை அதை சாப்பிடாது

// parsed manually

TL ஒரு அழகான சுருக்கம், யாரும் அதை முழுமையாக செயல்படுத்துவதில்லை

மேலும் அவர்களின் திட்டத்தின் பதிப்பில் % இல்லை

ஆனால் இங்கே ஆவணம் முரண்படுகிறது, எனவே xs

இது இலக்கணத்தில் காணப்பட்டது, அவர்கள் சொற்பொருளை விவரிக்க மறந்துவிடலாம்

சரி, நீங்கள் TL இல் கப்பல்துறையைப் பார்த்தீர்கள், அரை லிட்டர் இல்லாமல் அதைக் கண்டுபிடிக்க முடியாது

"சரி, சொல்லுவோம்," மற்றொரு வாசகர் கூறுவார், "நீங்கள் எல்லாவற்றையும் விமர்சிக்கிறீர்கள், எனவே அதை எப்படி காட்ட வேண்டும்."

வாசிலி பதிலளிக்கிறார்: “பாகுபடுத்தியைப் பொறுத்தவரை, எனக்கு இதுபோன்ற விஷயங்கள் தேவை

    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 % 1024 = 0 (1KB ஆல் வகுபடும்)
• 524288 % part_size = 0 (512KB பகுதி_அளவால் சமமாக வகுக்கப்பட வேண்டும்)

கடைசி பகுதி இந்த நிபந்தனைகளை பூர்த்தி செய்ய வேண்டியதில்லை, அதன் அளவு part_size ஐ விட குறைவாக இருந்தால்.

ஒவ்வொரு பகுதிக்கும் ஒரு வரிசை எண் இருக்க வேண்டும், கோப்பு_பகுதி, 0 முதல் 2,999 வரையிலான மதிப்புடன்.

கோப்பு பகிர்ந்த பிறகு, அதை சேவையகத்தில் சேமிப்பதற்கான ஒரு முறையை நீங்கள் தேர்வு செய்ய வேண்டும். பயன்படுத்த upload.saveBigFilePart கோப்பின் முழு அளவு 10 எம்பிக்கு மேல் இருந்தால் மற்றும் upload.saveFilePart சிறிய கோப்புகளுக்கு.
[…] பின்வரும் தரவு உள்ளீட்டு பிழைகளில் ஒன்று திரும்பப் பெறப்படலாம்:

• FILE_PARTS_INVALID - தவறான பகுதிகளின் எண்ணிக்கை. மதிப்பு இடையில் இல்லை 1..3000

இவற்றில் ஏதேனும் திட்டத்தில் உள்ளதா? இது எப்படியாவது TL மூலம் வெளிப்படுத்தப்படுமா? இல்லை. ஆனால் மன்னிக்கவும், பழங்கால டர்போ பாஸ்கல் கூட வழங்கிய வகைகளை விவரிக்க முடிந்தது வரம்புகள். மேலும் அவர் இன்னும் ஒரு காரியத்தைச் செய்ய முடியும், இப்போது நன்றாக அறியப்படுகிறது enum - ஒரு நிலையான (சிறிய) மதிப்புகளின் எண்ணிக்கையைக் கொண்ட ஒரு வகை. C - numeric போன்ற மொழிகளில், நாங்கள் இதுவரை வகைகளைப் பற்றி மட்டுமே பேசினோம். எண்கள். ஆனால் வரிசைகள், சரங்கள் உள்ளன ... எடுத்துக்காட்டாக, இந்த சரத்தில் ஒரு தொலைபேசி எண் மட்டுமே இருக்க முடியும் என்பதை விவரிப்பது நன்றாக இருக்கும், இல்லையா?

இவை எதுவும் TL இல் இல்லை. ஆனால், எடுத்துக்காட்டாக, JSON திட்டத்தில் உள்ளது. 512 KB இன் வகுக்கும் தன்மையைப் பற்றி வேறு யாராவது ஆட்சேபிக்க முடியுமானால், இது இன்னும் குறியீட்டில் சரிபார்க்கப்பட வேண்டும், பின்னர் வாடிக்கையாளர் வெறுமனே இருப்பதை உறுதிசெய்யவும் முடியவில்லை வரம்பிற்கு வெளியே எண்ணை அனுப்பவும் 1..3000 (மற்றும் தொடர்புடைய பிழை எழுந்திருக்க முடியாது) அது சாத்தியமாகும், இல்லையா? ..

மூலம், பிழைகள் மற்றும் திரும்ப மதிப்புகள் பற்றி. TL இல் வேலை செய்தவர்களுக்குக் கூட கண் மங்கலாக இருக்கிறது - அது உடனடியாக நமக்குப் புரியவில்லை ஒவ்வொன்றும் TL இல் உள்ள ஒரு செயல்பாடு உண்மையில் விவரிக்கப்பட்ட திரும்பும் வகையை மட்டுமல்ல, ஒரு பிழையையும் தருகிறது. ஆனால் இது TL மூலமாகவே கழிக்க முடியாது. நிச்சயமாக, இது புரிந்துகொள்ளக்கூடியது மற்றும் நடைமுறையில் nafig தேவையில்லை (உண்மையில், 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, எடுத்துக்காட்டாக, அத்தகைய நீண்ட கோடுகளுக்குள் மாற்றங்களை முன்னிலைப்படுத்த மறுக்கிறது. விளையாட்டு "10 வேறுபாடுகளைக் கண்டுபிடி", மற்றும் மூளை உடனடியாக பார்ப்பது என்னவென்றால், இரண்டு எடுத்துக்காட்டுகளிலும் தொடக்கங்களும் முடிவுகளும் ஒரே மாதிரியாக இருக்கின்றன, நீங்கள் நடுவில் எங்காவது படிக்க வேண்டும் ... என் கருத்துப்படி, இது கோட்பாட்டில் மட்டுமல்ல, ஆனால் முற்றிலும் பார்வைக்கு தெரிகிறது அழுக்கு மற்றும் ஒழுங்கற்ற.

மூலம், கோட்பாட்டின் தூய்மை பற்றி. பிட் புலங்கள் ஏன் தேவை? அவர்களுக்கு தெரியவில்லையா வாசனை வகை கோட்பாட்டின் பார்வையில் மோசமானதா? திட்டவட்டத்தின் முந்தைய பதிப்புகளில் ஒரு விளக்கத்தைக் காணலாம். முதலில், ஆம், அது அப்படித்தான், ஒவ்வொரு தும்மலுக்கும் ஒரு புதிய வகை உருவாக்கப்பட்டது. இந்த அடிப்படைகள் இன்னும் இந்த வடிவத்தில் உள்ளன, எடுத்துக்காட்டாக:

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;

நடைமுறையில், இதன் பொருள் ஒவ்வொரு API அழைப்பிற்கும் முன், மதிப்புடன் ஒரு முழு எண்ணாகும் 0x289dd1f6 முறை எண்ணுக்கு முன் சேர்க்க வேண்டும்.

பரவாயில்லை. ஆனால் அடுத்து என்ன நடந்தது? பிறகு வந்தது

invokeWithLayer3#b7475268 query:!X = X;

எனவே அடுத்தது என்ன? என யூகிக்க எளிதானது

invokeWithLayer4#dea0d430 query:!X = X;

வேடிக்கையா? இல்லை, சிரிக்க மிக விரைவில், என்ன என்று யோசி ஒவ்வொரு மற்றொரு அடுக்கில் இருந்து ஒரு கோரிக்கை அத்தகைய சிறப்பு வகைகளில் மூடப்பட்டிருக்க வேண்டும் - அவை அனைத்தும் வேறுபட்டிருந்தால், வேறு எப்படி வேறுபடுத்துவது? முன்னால் வெறும் 4 பைட்டுகளைச் சேர்ப்பது மிகவும் திறமையான முறையாகும். அதனால்

invokeWithLayer5#417a57ae query:!X = X;

ஆனால் சிறிது நேரம் கழித்து அது சில பச்சனாலியாவாக மாறும் என்பது வெளிப்படையானது. மற்றும் தீர்வு வந்தது:

புதுப்பிப்பு: லேயர் 9 இல் தொடங்கி, உதவி முறைகள் invokeWithLayerN உடன் இணைந்து பயன்படுத்தலாம் initConnection

ஹூரே! 9 பதிப்புகளுக்குப் பிறகு, 80 களில் இணைய நெறிமுறைகளில் என்ன செய்யப்பட்டது என்பதை நாங்கள் இறுதியாகப் பார்த்தோம் - இணைப்பின் தொடக்கத்தில் ஒரு முறை பதிப்பு பேச்சுவார்த்தை!

எனவே அடுத்தது என்ன?..

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

இப்போது நீங்கள் சிரிக்கலாம். மற்றொரு 9 அடுக்குகளுக்குப் பிறகு, பதிப்பு எண்ணைக் கொண்ட ஒரு உலகளாவிய கட்டமைப்பாளர் இறுதியாக சேர்க்கப்பட்டார், இது இணைப்பின் தொடக்கத்தில் ஒரு முறை மட்டுமே அழைக்கப்பட வேண்டும், மேலும் அடுக்குகளில் உள்ள பொருள் மறைந்துவிட்டதாகத் தெரிகிறது, இப்போது இது ஒரு நிபந்தனை பதிப்பு. மற்ற எல்லா இடங்களிலும். பிரச்சினை தீர்ந்துவிட்டது.

சரியா?..

Vasily, [16.07.18/14/01 XNUMX:XNUMX PM] வெள்ளிக்கிழமை நான் நினைத்தேன்:
டெலிசர்வர் கோரிக்கை இல்லாமல் நிகழ்வுகளை அனுப்புகிறது. கோரிக்கைகள் InvokeWithLayer இல் மூடப்பட்டிருக்க வேண்டும். சேவையகம் புதுப்பிப்புகளை மூடாது, பதில்கள் மற்றும் புதுப்பிப்புகளை மடிக்க எந்த அமைப்பும் இல்லை.

அந்த. வாடிக்கையாளர் எந்த லேயரில் புதுப்பிப்புகளை விரும்புகிறார் என்பதைக் குறிப்பிட முடியாது

Vadim Goncharov, [16.07.18/14/02 XNUMX:XNUMX PM] InvokeWithLayer கொள்கையளவில் ஊன்றுகோல் இல்லையா?

Vasily, [16.07.18/14/02 XNUMX:XNUMX PM] இதுதான் ஒரே வழி

வாடிம் கோஞ்சரோவ், [16.07.18/14/02 XNUMX:XNUMX PM] இதன் சாராம்சத்தில் அமர்வின் தொடக்கத்தில் அடுக்குதல்

இதன் மூலம், கிளையன்ட் தரமிறக்கம் வழங்கப்படவில்லை என்பதை இது பின்பற்றுகிறது

புதுப்பிப்புகள், அதாவது. வகை Updates திட்டத்தில், இது ஒரு API கோரிக்கைக்கு பதிலளிக்கும் வகையில் அல்ல, ஆனால் ஒரு நிகழ்வு நிகழும்போது தானாகவே சேவையகம் கிளையண்டிற்கு அனுப்புகிறது. இது ஒரு சிக்கலான தலைப்பு, இது மற்றொரு இடுகையில் விவாதிக்கப்படும், ஆனால் க்ளையன்ட் ஆஃப்லைனில் இருந்தாலும், சேவையகம் புதுப்பிப்புகளைக் குவிக்கிறது என்பதை இப்போது அறிந்து கொள்வது அவசியம்.

இவ்வாறு, மடக்க மறுக்கும் போது ஒவ்வொருவரும் தொகுப்பு அதன் பதிப்பைக் குறிக்கும், எனவே பின்வரும் சாத்தியமான சிக்கல்கள் தர்க்கரீதியாக எழுகின்றன:

• கிளையன்ட் எந்தப் பதிப்பை ஆதரிக்கிறது என்பதைக் கூறுவதற்கு முன், சேவையகம் கிளையண்டிற்கு புதுப்பிப்புகளை அனுப்புகிறது
• வாடிக்கையாளரை மேம்படுத்திய பிறகு என்ன செய்ய வேண்டும்?
• யார் உத்தரவாதம் அளிக்கிறதுலேயர் எண்ணைப் பற்றிய சர்வரின் கருத்து செயல்பாட்டில் மாறாது என்று?

இது முற்றிலும் கோட்பாட்டு சிந்தனை என்று நீங்கள் நினைக்கிறீர்களா, நடைமுறையில் இது நடக்காது, ஏனெனில் சர்வர் சரியாக எழுதப்பட்டுள்ளது (எந்தவொரு சந்தர்ப்பத்திலும், அது நன்றாக சோதிக்கப்படுகிறது)? ஹா! எப்படியாக இருந்தாலும்!

இதைத்தான் ஆகஸ்ட் மாதத்தில் நாங்கள் எதிர்கொண்டோம். ஆகஸ்ட் 14 அன்று, டெலிகிராம் சேவையகங்களில் ஏதோ புதுப்பிக்கப்படுவதாக செய்திகள் பறந்தன ... பின்னர் பதிவுகளில்:

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 இல் வேலை செய்தோம். பதிவுகளை கவனமாகப் பார்க்கிறோம் - இரண்டு வெவ்வேறு திட்டங்களில் இருந்து அடையாளங்காட்டிகள் உள்ளன!

ஒருவேளை பிரச்சனை எங்கள் அதிகாரப்பூர்வமற்ற வாடிக்கையாளரிடம் உள்ளதா? இல்லை, நாங்கள் டெலிகிராம் டெஸ்க்டாப் 1.2.17 ஐ இயக்குகிறோம் (பல லினக்ஸ் விநியோகங்களுடன் வழங்கப்பட்ட பதிப்பு), இது விதிவிலக்கு பதிவிற்கு எழுதுகிறது: MTP எதிர்பாராத வகை ஐடி #b5223b0f MTPMessageMedia இல் படித்தது…

இதேபோன்ற சிக்கல் ஏற்கனவே அதிகாரப்பூர்வமற்ற வாடிக்கையாளர்களில் ஒருவருக்கு ஏற்பட்டதாக கூகிள் காட்டியது, ஆனால் பின்னர் பதிப்பு எண்கள் மற்றும் அதன்படி, அனுமானங்கள் வேறுபட்டவை ...

அதனால் என்ன செய்வது? வாசிலியும் நானும் பிரிந்தோம்: அவர் திட்டத்தை 91 க்கு புதுப்பிக்க முயன்றார், சில நாட்கள் காத்திருந்து 73 க்கு முயற்சிக்க முடிவு செய்தேன். இரண்டு முறைகளும் வேலை செய்தன, ஆனால் அவை அனுபவபூர்வமானவை என்பதால், நீங்கள் எத்தனை பதிப்புகளில் குதிக்க வேண்டும் என்பது பற்றிய புரிதல் இல்லை. அல்லது கீழே, அல்லது நீங்கள் எவ்வளவு நேரம் காத்திருக்க வேண்டும்.

பின்னர், நான் நிலைமையை மீண்டும் உருவாக்க முடிந்தது: நாங்கள் கிளையண்டைத் தொடங்குகிறோம், அதை அணைக்கிறோம், திட்டத்தை மற்றொரு லேயருக்குத் தொகுத்து, மறுதொடக்கம் செய்து, சிக்கலை மீண்டும் பிடிக்கவும், முந்தைய நிலைக்குத் திரும்பவும் - அச்சச்சோ, திட்டத்தை மாற்றவில்லை மற்றும் கிளையண்டை மறுதொடக்கம் செய்கிறோம். நிமிடங்கள் உதவும். வெவ்வேறு அடுக்குகளிலிருந்து தரவு கட்டமைப்புகளின் கலவையைப் பெறுவீர்கள்.

விளக்கம்? பல்வேறு மறைமுக அறிகுறிகளில் இருந்து நீங்கள் யூகிக்க முடியும் என, சர்வர் வெவ்வேறு கணினிகளில் பல்வேறு வகையான செயல்முறைகளைக் கொண்டுள்ளது. பெரும்பாலும், "பஃபரிங்" க்கு பொறுப்பான சேவையகங்களில் ஒன்று, உயர்ந்தவர்கள் கொடுத்ததை வரிசையில் வைத்தது, மேலும் அவர்கள் அதை தலைமுறை நேரத்தில் இருந்த திட்டத்தில் கொடுத்தனர். இந்த வரிசை "அழுகி" இருக்கும் வரை, அதைப் பற்றி எதுவும் செய்ய முடியாது.

தவிர... ஆனால் இது ஒரு பயங்கரமான ஊன்றுகோல்?!.. இல்லை, பைத்தியக்காரத்தனமான யோசனைகளைப் பற்றி சிந்திக்கும் முன், அதிகாரப்பூர்வ வாடிக்கையாளர்களின் குறியீட்டைப் பார்ப்போம். ஆண்ட்ராய்டு பதிப்பில், நாங்கள் எந்த TL பாகுபடுத்தியும் காணவில்லை, ஆனால் (de)serialization உடன் ஒரு பெரிய கோப்பை (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;

இங்கே "கைமுறையாக உருவாக்கப்பட்ட" கருத்து, இந்தக் கோப்பின் ஒரு பகுதி மட்டுமே கையால் எழுதப்பட்டுள்ளது (பராமரிப்பு கனவை உங்களால் கற்பனை செய்ய முடியுமா?), மீதமுள்ளவை இயந்திரத்தால் உருவாக்கப்பட்டவை என்று கூறுகிறது. இருப்பினும், மற்றொரு கேள்வி எழுகிறது - ஆதாரங்கள் உள்ளன முழுமையாக இல்லை (லினக்ஸ் கர்னலில் ஜிபிஎல் கீழ் ஒரு லா ப்ளாப்ஸ்), ஆனால் இது ஏற்கனவே இரண்டாம் பகுதிக்கான தலைப்பு.

ஆனால் போதும். இந்த சீரியலேஷன் எல்லாம் துரத்துகிற நெறிமுறைக்கு செல்லலாம்.

எம்டிபிரோட்டோ

எனவே திறக்கலாம் பொது விளக்கம் и நெறிமுறையின் விரிவான விளக்கம் மற்றும் நாம் தடுமாறும் முதல் விஷயம் சொற்களஞ்சியம். மற்றும் எல்லாம் மிகுதியாக. பொதுவாக, இது டெலிகிராமின் வர்த்தக முத்திரையாகத் தெரிகிறது - வெவ்வேறு இடங்களில் உள்ள விஷயங்களை வெவ்வேறு வழிகளில் அழைக்கவும், அல்லது ஒரே வார்த்தையில் வெவ்வேறு விஷயங்களை அழைக்கவும் அல்லது நேர்மாறாகவும் (உதாரணமாக, நீங்கள் ஸ்டிக்கர் பேக்கைக் கண்டால் உயர்நிலை API இல் - இது நீங்கள் நினைத்தது அல்ல).

எடுத்துக்காட்டாக, "செய்தி" (செய்தி) மற்றும் "அமர்வு" (அமர்வு) - இங்கே அவை டெலிகிராம் கிளையண்டின் வழக்கமான இடைமுகத்தை விட வித்தியாசமான ஒன்றைக் குறிக்கின்றன. சரி, செய்தியுடன் எல்லாம் தெளிவாக உள்ளது, அதை OOP இன் அடிப்படையில் விளக்கலாம் அல்லது "பேக்கேஜ்" என்ற வார்த்தை என்று அழைக்கலாம் - இது குறைந்த, போக்குவரத்து நிலை, இடைமுகத்தில் உள்ள அதே செய்திகள் இல்லை, நிறைய உள்ளன சேவை செய்பவர்கள். ஆனால் அமர்வு ... ஆனால் முதல் விஷயங்கள் முதலில்.

போக்குவரத்து அடுக்கு

முதல் விஷயம் போக்குவரத்து. 5 விருப்பங்களைப் பற்றி நாங்கள் கூறுவோம்:

• டிசிபி
• வெப்சாக்கெட்
• HTTPS வழியாக வெப்சாக்கெட்
• , HTTP
• HTTPS ஆதரவு

Vasily, [15.06.18/15/04 XNUMX:XNUMX PM] மேலும் UDP போக்குவரத்தும் உள்ளது, ஆனால் அது ஆவணப்படுத்தப்படவில்லை

மற்றும் மூன்று வகைகளில் TCP

முதலாவது TCP இல் UDP ஐப் போன்றது, ஒவ்வொரு பாக்கெட்டிலும் ஒரு வரிசை எண் மற்றும் ஒரு crc இருக்கும்
ஒரு வண்டியில் கப்பல்துறைகளைப் படிப்பது ஏன் மிகவும் வேதனையாக இருக்கிறது?

சரி இப்போது அங்கே TCP ஏற்கனவே 4 வகைகளில் உள்ளது:

• சுருக்கப்பட்டது
• இடைநிலை
• padded இடைநிலை
• முழு

சரி, MTProxyக்கான பேடட் இடைநிலை, தெரிந்த நிகழ்வுகளின் காரணமாக இது பின்னர் சேர்க்கப்பட்டது. ஆனால் ஏன் இன்னும் இரண்டு பதிப்புகள் (மொத்தம் மூன்று), ஒருவர் எப்போது செய்ய முடியும்? முக்கிய MTProto இன் நீளம் மற்றும் பேலோடை எவ்வாறு அமைப்பது என்பதில் மட்டுமே நான்கும் அடிப்படையில் வேறுபடுகின்றன, இது மேலும் விவாதிக்கப்படும்:

• சுருக்கப்பட்டதில் இது 1 அல்லது 4 பைட்டுகள் ஆனால் 0xef இல்லை பின்னர் உடல்
• இடைநிலையில் இது 4 பைட்டுகள் நீளம் மற்றும் ஒரு புலம், மற்றும் கிளையன்ட் அனுப்ப வேண்டிய முதல் முறையாகும் 0xeeeeeeee இடைநிலை என்பதைக் குறிக்க
• நெட்வொர்க்கரின் பார்வையில் முழுவதுமாக, மிகவும் அடிமையாக்கும்: நீளம், வரிசை எண் மற்றும் அடிப்படையில் MTProto, உடல், CRC32 அல்ல. ஆம், இவை அனைத்தும் TCP மூலம். இது பைட்டுகளின் தொடர் ஸ்ட்ரீம் வடிவில் நம்பகமான போக்குவரத்தை நமக்கு வழங்குகிறது, எந்த வரிசையும் தேவையில்லை, குறிப்பாக செக்சம்கள். சரி, TCP இல் 16-பிட் செக்சம் உள்ளது என்று நான் எதிர்க்கப்படுவேன், அதனால் தரவு சிதைவு ஏற்படுகிறது. சிறப்பானது, எங்களிடம் உண்மையில் 16 பைட்டுகளை விட நீளமான ஹாஷ்கள் கொண்ட கிரிப்டோகிராஃபிக் நெறிமுறை உள்ளது என்பதைத் தவிர, இந்த எல்லா பிழைகளும் - மேலும் - SHA பொருந்தாத உயர் மட்டத்தில் பிடிக்கப்படும். இதைப் பற்றி CRC32 இல் எந்த அர்த்தமும் இல்லை.

சுருக்கப்பட்டதை, ஒரு பைட் நீளம் சாத்தியம், இடைநிலையுடன் ஒப்பிடுவோம், இது "4-பைட் தரவு சீரமைப்பு தேவைப்பட்டால்" என்பதை நியாயப்படுத்துகிறது, இது மிகவும் முட்டாள்தனமானது. என்ன, டெலிகிராம் புரோகிராமர்கள் மிகவும் விகாரமானவர்கள் என்று நம்பப்படுகிறது, அவர்களால் சாக்கெட்டிலிருந்து தரவை சீரமைக்கப்பட்ட பஃபரில் படிக்க முடியாது? நீங்கள் இன்னும் இதைச் செய்ய வேண்டும், ஏனென்றால் வாசிப்பு உங்களுக்கு எத்தனை பைட்டுகளையும் திருப்பித் தரும் (மற்றும் ப்ராக்ஸி சேவையகங்களும் உள்ளன, எடுத்துக்காட்டாக ...). அல்லது, மறுபுறம், மேலே 16 பைட்டுகளில் இருந்து அதிகமான பேடிங்குகள் இருந்தால், ஏன் சுருக்கப்பட்டதைத் தொந்தரவு செய்ய வேண்டும் - 3 பைட்டுகளைச் சேமிக்கவும் சில நேரங்களில் ?

நிகோலாய் துரோவ், உண்மையான நடைமுறை தேவையில்லாமல், நெட்வொர்க் நெறிமுறைகள் உட்பட சைக்கிள்களை கண்டுபிடிப்பதில் மிகவும் விருப்பம் கொண்டவர் என்ற எண்ணத்தை ஒருவர் பெறுகிறார்.

மற்ற போக்குவரத்து விருப்பங்கள், உட்பட. Web மற்றும் MTProxy, நாங்கள் இப்போது கருத்தில் கொள்ள மாட்டோம், ஒருவேளை மற்றொரு இடுகையில், கோரிக்கை இருந்தால். MTProxy 2018 இல் வெளியிடப்பட்ட உடனேயே, வழங்குநர்கள் விரைவாக அதைத் தடுக்கக் கற்றுக்கொண்டனர். தடை பைபாஸ்படி பாக்கெட் அளவு! மேலும் C இல் எழுதப்பட்ட (மீண்டும் Waltman ஆல்) MTProxy சேவையகம் தேவையில்லாமல் Linux விவரங்களுடன் பிணைக்கப்பட்டுள்ளது, ஆனால் அது தேவையில்லாதது (Phil Kulin உறுதிப்படுத்தும்), மேலும் Go அல்லது Node.js இல் இதே போன்ற சேவையகம் உள்ளது. நூற்றுக்கும் குறைவான வரிகள் பொருந்தும்.

ஆனால் மற்ற விஷயங்களைப் பரிசீலித்த பிறகு, பிரிவின் முடிவில் இந்த நபர்களின் தொழில்நுட்ப கல்வியறிவு பற்றிய முடிவுகளை எடுப்போம். இப்போதைக்கு, 5வது OSI லேயர், அமர்வுக்கு செல்லலாம் - அதில் அவர்கள் MTProto அமர்வை வைத்தனர்.

விசைகள், செய்திகள், அமர்வுகள், டிஃபி-ஹெல்மேன்

அவர்கள் அதை முழுமையாகச் சரியாகப் போடவில்லை... செயலில் உள்ள அமர்வுகளின் கீழ் உள்ள இடைமுகத்தில் தெரியும் அதே அமர்வு அல்ல. ஆனால் வரிசையில்.

போக்குவரத்து அடுக்கிலிருந்து அறியப்பட்ட நீளத்தின் பைட்டுகளின் சரத்தை இங்கே பெற்றுள்ளோம். இது ஒரு மறைகுறியாக்கப்பட்ட செய்தியாகவோ அல்லது எளிய உரையாகவோ இருக்கலாம் - நாம் இன்னும் முக்கிய பேச்சுவார்த்தை கட்டத்தில் இருந்து அதைச் செய்துகொண்டிருந்தால். "விசை" என்று அழைக்கப்படும் கருத்துக்களில் எதைப் பற்றி நாம் பேசுகிறோம்? டெலிகிராம் குழுவுக்கே இந்த சிக்கலை தெளிவுபடுத்துவோம் (அதிகாலை 4 மணிக்கு எனது சொந்த ஆவணத்தை ஆங்கிலத்தில் இருந்து சோர்வுற்ற மூளைக்கு மொழிபெயர்த்ததற்கு மன்னிப்பு கேட்டுக்கொள்கிறேன், சில சொற்றொடர்களை அப்படியே விட்டுவிடுவது எளிதாக இருந்தது):

என்று இரண்டு நிறுவனங்கள் உள்ளன அமர்வு - "தற்போதைய அமர்வுகள்" கீழ் அதிகாரப்பூர்வ வாடிக்கையாளர்களின் UI இல் ஒன்று, ஒவ்வொரு அமர்வும் முழு சாதனம் / OS உடன் ஒத்திருக்கும்.
இரண்டாவது எம்டிபிரோட்டோ அமர்வு, அதில் ஒரு செய்தி வரிசை எண் (குறைந்த அளவிலான அர்த்தத்தில்) உள்ளது, மற்றும் எது வெவ்வேறு TCP இணைப்புகளுக்கு இடையில் நீடிக்கலாம். பல MTProto அமர்வுகளை ஒரே நேரத்தில் அமைக்கலாம், எடுத்துக்காட்டாக, கோப்பு பதிவிறக்கங்களை விரைவுபடுத்த.

இந்த இரண்டுக்கும் இடையில் அமர்வுகள் என்பது கருத்து அங்கீகாரம். சீரழிந்த நிலையில் அப்படிச் சொல்லலாம் UI அமர்வு போலவே உள்ளது அங்கீகாரம்ஆனால் ஐயோ, இது சிக்கலானது. நாங்கள் பார்க்கிறோம்:

• புதிய சாதனத்தில் உள்ள பயனர் முதலில் உருவாக்குகிறார் அங்கீகார_விசை எஸ்எம்எஸ் மூலம் கணக்கிற்கு அதைக் கட்டுப்படுத்துகிறது - அதனால்தான் அங்கீகாரம்
• இது முதல் உள்ளே நடந்தது எம்டிபிரோட்டோ அமர்வு, இதில் உள்ளது session_id உங்களுக்குள்.
• இந்த கட்டத்தில், கலவை அங்கீகாரம் и session_id அழைக்கப்படலாம் உதாரணமாக - இந்த வார்த்தை சில வாடிக்கையாளர்களின் ஆவணங்கள் மற்றும் குறியீட்டில் காணப்படுகிறது
• அதன் பிறகு, வாடிக்கையாளர் திறக்க முடியும் பல எம்டிபிரோட்டோ அமர்வுகள் அதே கீழ் அங்கீகார_விசை - அதே DC க்கு.
• ஒரு நாள் கிளையண்ட் ஒரு கோப்பைக் கோர வேண்டும் மற்றொரு DC - மற்றும் இந்த DC க்கு புதியது உருவாக்கப்படும் அங்கீகார_விசை !
• இது ஒரு புதிய பயனர் பதிவு அல்ல, ஆனால் அதே என்று கணினிக்கு சொல்ல அங்கீகாரம் (UI அமர்வு), கிளையன்ட் API அழைப்புகளைப் பயன்படுத்துகிறது auth.exportAuthorization வீட்டில் DC auth.importAuthorization புதிய DC இல்.
• அனைத்து அதே, பல திறந்த இருக்கலாம் எம்டிபிரோட்டோ அமர்வுகள் (ஒவ்வொன்றும் அதன் சொந்த session_id) இந்த புதிய டிசிக்கு, கீழ் அவரது அங்கீகார_விசை.
• இறுதியாக, வாடிக்கையாளர் சரியான முன்னோக்கி ரகசியத்தை விரும்பலாம். ஒவ்வொரு அங்கீகார_விசை அது இருந்தது நிரந்தர விசை - ஒரு DC - மற்றும் வாடிக்கையாளர் அழைக்கலாம் auth.bindTempAuthKey உபயோகத்திற்காக தற்காலிக அங்கீகார_விசை - மீண்டும், ஒன்று மட்டுமே temp_auth_key DC ஒன்றுக்கு, அனைவருக்கும் பொதுவானது எம்டிபிரோட்டோ அமர்வுகள் இந்த DCக்கு.

அதை கவனியுங்கள் உப்பு (மற்றும் எதிர்கால உப்புகள்) மேலும் ஒன்று அங்கீகார_விசை அந்த. அனைவருக்கும் பகிரப்பட்டது எம்டிபிரோட்டோ அமர்வுகள் அதே DC க்கு.

"வெவ்வேறு TCP இணைப்புகளுக்கு இடையே" என்றால் என்ன? இதன் பொருள் இது போன்ற ஏதாவது ஒரு இணையதளத்தில் அங்கீகாரம் குக்கீ - இது இந்த சர்வரில் பல TCP இணைப்புகளைத் தொடரும் (உயிர்வாகிறது), ஆனால் ஒரு நாள் அது மோசமாகிவிடும். HTTP போலல்லாமல், MTProto இல், செய்திகள் வரிசையாக எண்ணப்பட்டு அமர்வுக்குள் உறுதிப்படுத்தப்படுகின்றன, அவை சுரங்கப்பாதையில் நுழைந்தன, இணைப்பு உடைந்தது - ஒரு புதிய இணைப்பை நிறுவிய பிறகு, சேவையகம் இந்த அமர்வில் முந்தைய அமர்வில் வழங்காத அனைத்தையும் தயவுசெய்து அனுப்பும். TCP இணைப்பு.

இருப்பினும், மேலே உள்ள தகவல் பல மாத வழக்குகளுக்குப் பிறகு சுருக்கப்பட்டது. இதற்கிடையில், நாங்கள் எங்கள் கிளையண்டை புதிதாக செயல்படுத்துகிறோமா? - ஆரம்பத்திற்கு திரும்புவோம்.

எனவே நாங்கள் உருவாக்குகிறோம் auth_key மீது டெலிகிராமில் இருந்து Diffie-Hellman இன் பதிப்புகள். ஆவணங்களை புரிந்து கொள்ள முயற்சிப்போம்...

Vasily, [19.06.18/20/05 1:255] data_with_hash := SHAXNUMX(தரவு) + தரவு + (ஏதேனும் சீரற்ற பைட்டுகள்); நீளம் XNUMX பைட்டுகளுக்கு சமமாக இருக்கும்
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] நான் இன்னும் appid கோரிக்கையை அடையவில்லை

நான் DHக்கு கோரிக்கை அனுப்பினேன்

மேலும், போக்குவரத்தில் உள்ள கப்பல்துறையில் பிழைக் குறியீட்டின் 4 பைட்டுகளுடன் பதிலளிக்க முடியும் என்று எழுதப்பட்டுள்ளது. அவ்வளவுதான்

சரி, அவர் என்னிடம் -404 என்று சொன்னார், அதனால் என்ன?

இதோ நான் அவரிடம்: "சர்வர் கீயுடன் என்க்ரிப்ட் செய்யப்பட்ட உங்கள் எஃபிக்னாவைப் பிடிக்கவும், இது போன்றவற்றின் கைரேகையுடன், எனக்கு டிஹெச் வேண்டும்", அது முட்டாள்தனமாக பதிலளிக்கிறது 404

அத்தகைய சேவையக பதிலைப் பற்றி நீங்கள் என்ன நினைக்கிறீர்கள்? என்ன செய்ய? கேட்பதற்கு யாரும் இல்லை (ஆனால் இரண்டாம் பாகத்தில் அதைப் பற்றி அதிகம்).

இங்கே கப்பல்துறையின் அனைத்து ஆர்வமும் செய்ய வேண்டும்

எனக்கு வேறு எதுவும் செய்ய வேண்டியதில்லை, நான் முன்னும் பின்னுமாக எண்களை மாற்றுவதை மட்டுமே கனவு கண்டேன்

இரண்டு 32 பிட் எண்கள். நான் எல்லோரையும் போல பேக் செய்தேன்

ஆனால் இல்லை, BE என ஒரு வரியில் முதலில் உங்களுக்கு இந்த இரண்டும் தேவை

வாடிம் கோஞ்சரோவ், [20.06.18/15/49 404:XNUMX PM] மற்றும் இதன் காரணமாக XNUMX?

Vasily, [20.06.18/15/49 XNUMX:XNUMX PM] ஆம்!

வாடிம் கோஞ்சரோவ், [20.06.18/15/50 XNUMX:XNUMX PM] அதனால் அவரால் "கண்டுபிடிக்க முடியவில்லை" என்பது எனக்குப் புரியவில்லை

வாசிலி, [20.06.18 15:50] பற்றி

அத்தகைய சிதைவை எளிய வகுப்பிகளாக நான் காணவில்லை%)

பிழை அறிக்கையிடல் கூட தேர்ச்சி பெறவில்லை

Vasily, [20.06.18/20/18 5:XNUMX PM] ஓ, MDXNUMX கூட இருக்கிறது. ஏற்கனவே மூன்று வெவ்வேறு ஹாஷ்கள்

முக்கிய கைரேகை பின்வருமாறு கணக்கிடப்படுகிறது:

digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)

SHA1 மற்றும் sha2

எனவே வைக்கலாம் auth_key டிஃபி-ஹெல்மேனின் கூற்றுப்படி, 2048 பிட்கள் அளவு உள்ளது. அடுத்தது என்ன? இந்த விசையின் கீழ் 1024 பிட்கள் எந்த வகையிலும் பயன்படுத்தப்படவில்லை என்பதை நாங்கள் கண்டுபிடித்தோம் ... ஆனால் இப்போது இதைப் பற்றி சிந்திக்கலாம். இந்த கட்டத்தில், சர்வருடன் பகிரப்பட்ட ரகசியம் உள்ளது. ஒரு TLS அமர்வின் அனலாக் நிறுவப்பட்டது, இது மிகவும் விலையுயர்ந்த செயல்முறையாகும். ஆனால் நாங்கள் யார் என்பது சர்வருக்கு இன்னும் தெரியவில்லை! இன்னும் இல்லை, உண்மையில் அங்கீகாரம். அந்த. "உள்நுழைவு-கடவுச்சொல்", ICQ இல் இருந்ததைப் போல அல்லது SSH இல் (உதாரணமாக, சில gitlab / github இல்) குறைந்தபட்சம் "உள்நுழைவு-விசை" என்று நீங்கள் நினைத்திருந்தால். நாங்கள் அநாமதேயமாகிவிட்டோம். மேலும் "இந்த ஃபோன் எண்கள் வேறொரு DC ஆல் வழங்கப்படுகின்றன" என்று சர்வர் பதில் அளித்தால்? அல்லது "உங்கள் தொலைபேசி எண் தடைசெய்யப்பட்டுள்ளது"? நாம் செய்யக்கூடிய சிறந்த விஷயம் என்னவென்றால், சாவி இன்னும் பயனுள்ளதாக இருக்கும் மற்றும் அதற்குள் அழுகாமல் இருக்கும் என்ற நம்பிக்கையில் சேமித்து வைப்பதுதான்.

மூலம், நாங்கள் அதை முன்பதிவுகளுடன் "பெற்றோம்". உதாரணமாக, நாம் சர்வரை நம்புகிறோமா? அவன் போலியா? எங்களுக்கு கிரிப்டோகிராஃபிக் சோதனைகள் தேவை:

Vasily, [21.06.18/17/53 2:XNUMX PM] அவர்கள் மொபைல் கிளையண்டுகளுக்கு XNUMXkbit எண்ணை எளிமையாக சரிபார்க்க வழங்குகிறார்கள்)

ஆனால் அது தெளிவாக இல்லை, nafeijoa

Vasily, [21.06.18/18/02 XNUMX:XNUMX] கப்பல்துறை எளிமையானது அல்ல என்று மாறினால் என்ன செய்வது என்று கூறவில்லை

சொல்லவில்லை. இந்த விஷயத்தில் ஆண்ட்ராய்டுக்கான அதிகாரப்பூர்வ கிளையன்ட் என்ன செய்கிறது என்று பார்ப்போம்? ஏ அதுதான் (ஆம், முழு கோப்பும் அங்கே சுவாரஸ்யமானது) - அவர்கள் சொல்வது போல், நான் அதை இங்கே விட்டுவிடுகிறேன்:

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

இல்லை, நிச்சயமாக அங்கே சில எண்ணின் எளிமைக்கான சோதனைகள் உள்ளன, ஆனால் தனிப்பட்ட முறையில் எனக்கு கணிதத்தில் போதிய அறிவு இல்லை.

சரி, மாஸ்டர் கீ கிடைத்தது. உள்நுழைய, அதாவது. கோரிக்கைகளை அனுப்பவும், ஏற்கனவே AES ஐப் பயன்படுத்தி மேலும் குறியாக்கம் செய்ய வேண்டியது அவசியம்.

அங்கீகரிப்பு விசையிலிருந்து எடுக்கப்பட்ட 128 பைட்டுகளால் முன்வைக்கப்பட்ட திணிப்பு பைட்டுகள் உட்பட, செய்தி அமைப்பின் SHA256 இன் 32 நடுத்தர பிட்கள் (அமர்வு, செய்தி ஐடி போன்றவை) என மெசேஜ் கீ வரையறுக்கப்படுகிறது.

Vasily, [22.06.18/14/08 XNUMX:XNUMX PM] சராசரி பிட்சுகள்

கிடைத்தது auth_key. அனைத்து. மேலும் அவர்கள் ... அது கப்பல்துறைகளில் இருந்து தெளிவாக இல்லை. திறந்த மூலக் குறியீட்டைப் படிக்க தயங்க வேண்டாம்.

MTProto 2.0 க்கு 12 முதல் 1024 பைட்டுகள் வரை திணிப்பு தேவைப்படுகிறது, அதன் விளைவாக வரும் செய்தியின் நீளம் 16 பைட்டுகளால் வகுக்கப்பட வேண்டும் என்ற நிபந்தனைக்கு உட்பட்டது.

எனவே எவ்வளவு திணிப்பு போட வேண்டும்?

ஆம், இங்கேயும், பிழை ஏற்பட்டால் 404

ஆவணத்தின் வரைபடத்தையும் உரையையும் யாராவது கவனமாகப் படித்தால், அங்கு MAC இல்லை என்பதை அவர் கவனித்தார். வேறு எங்கும் பயன்படுத்தப்படாத சில IGE பயன்முறையில் AES பயன்படுத்தப்படுகிறது. அவர்கள், நிச்சயமாக, தங்கள் கேள்விகளில் இதைப் பற்றி எழுதுகிறார்கள்... இங்கே, செய்தித் திறவுகோல், அதே நேரத்தில் ஒருமைப்பாட்டை சரிபார்க்கப் பயன்படுத்தப்படும் மறைகுறியாக்கப்பட்ட தரவின் SHA ஹாஷ் ஆகும் - மேலும் பொருந்தாத பட்சத்தில், அதற்கான ஆவணங்கள் சில காரணங்களால் அமைதியாக அவற்றைப் புறக்கணிக்க பரிந்துரைக்கிறது (ஆனால் பாதுகாப்பு பற்றி என்ன, திடீரென்று நம்மை உடைக்க முடியுமா?).

நான் ஒரு கிரிப்டோகிராபர் அல்ல, ஒருவேளை இந்த பயன்முறையில் கோட்பாட்டு பார்வையில் எந்த தவறும் இல்லை. ஆனால் டெலிகிராம் டெஸ்க்டாப்பின் உதாரணத்தைப் பயன்படுத்தி, ஒரு நடைமுறை சிக்கலை நான் நிச்சயமாக பெயரிட முடியும். இது MTProto இல் உள்ள செய்திகளைப் போலவே உள்ளூர் தற்காலிக சேமிப்பையும் (இந்த D877F783D5D3EF8C) குறியாக்குகிறது (இந்த விஷயத்தில் மட்டுமே, பதிப்பு 1.0), அதாவது. முதலில் செய்தித் திறவுகோல், பின்னர் தரவுகள் (மற்றும் எங்கோ முக்கிய பெரியது auth_key 256 பைட்டுகள், இது இல்லாமல் msg_key பயனற்றது). எனவே, பெரிய கோப்புகளில் சிக்கல் கவனிக்கப்படுகிறது. அதாவது, நீங்கள் தரவின் இரண்டு நகல்களை வைத்திருக்க வேண்டும் - மறைகுறியாக்கப்பட்ட மற்றும் மறைகுறியாக்கப்பட்ட. மெகாபைட்கள் அல்லது ஸ்ட்ரீமிங் வீடியோ இருந்தால், எடுத்துக்காட்டாக? MTProto உடன் நீங்கள் செய்ய வேண்டும் முதலில் முழு செய்தியையும் குறியாக்கம் செய்யவும் அல்லது மறைகுறியாக்கவும், பின்னர் அதை பிணையத்திற்கு அல்லது வட்டுக்கு மாற்றவும். எனவே, டெலிகிராம் டெஸ்க்டாப்பின் சமீபத்திய பதிப்புகளில் தற்காலிக சேமிப்பில் user_data மற்றொரு வடிவம் ஏற்கனவே பயன்படுத்தப்பட்டுள்ளது - CTR பயன்முறையில் AES உடன்.

Vasily, [21.06.18/01/27 20:XNUMX AM] ஓ, IGE என்றால் என்ன என்பதை நான் கண்டுபிடித்தேன்: IGE ஆனது Kerberos க்காக "அங்கீகரிக்கும் குறியாக்க பயன்முறையின்" முதல் முயற்சியாகும். இது ஒரு தோல்வியுற்ற முயற்சி (இது ஒருமைப்பாட்டைப் பாதுகாப்பதில்லை), மேலும் அகற்றப்பட வேண்டியிருந்தது. இது வேலை செய்யும் அங்கீகரிக்கும் என்க்ரிப்ஷன் பயன்முறைக்கான XNUMX ஆண்டுகால தேடலின் தொடக்கமாகும், இது சமீபத்தில் OCB மற்றும் GCM போன்ற முறைகளில் உச்சத்தை எட்டியது.

இப்போது கார்ட் பக்கத்திலிருந்து வாதங்கள்:

நிகோலாய் துரோவ் தலைமையிலான டெலிகிராமிற்குப் பின்னால் உள்ள அணி, ஆறு ஏசிஎம் சாம்பியன்களைக் கொண்டுள்ளது, அவர்களில் பாதி பேர் கணிதத்தில் பிஎச்.டி. MTProto இன் தற்போதைய பதிப்பை வெளியிட அவர்களுக்கு இரண்டு வருடங்கள் ஆனது.

என்ன வேடிக்கை. கீழ் மட்டத்திற்கு இரண்டு ஆண்டுகள்

அல்லது நாம் tls எடுத்துக் கொள்ளலாம்

சரி, குறியாக்கம் மற்றும் பிற நுணுக்கங்களைச் செய்துவிட்டோம் என்று வைத்துக்கொள்வோம். இறுதியாக TL தொடர் கோரிக்கைகளை அனுப்ப முடியுமா மற்றும் பதில்களை சீரழிக்க முடியுமா? அப்படியானால் என்ன அனுப்ப வேண்டும், எப்படி? இதோ முறை initஇணைப்புஒருவேளை இதுதானா?

Vasily, [25.06.18/18/46 XNUMX:XNUMX PM] இணைப்பைத் தொடங்கி பயனரின் சாதனம் மற்றும் பயன்பாட்டில் தகவலைச் சேமிக்கிறது.

இது app_id, device_model, system_version, app_version மற்றும் lang_code ஆகியவற்றை ஏற்றுக்கொள்கிறது.

மற்றும் சில கேள்விகள்

எப்போதும் போல் ஆவணங்கள். திறந்த மூலத்தைப் படிக்க தயங்க

InvokeWithLayer உடன் எல்லாம் தோராயமாக தெளிவாக இருந்தால், அது என்ன? எங்களிடம் உள்ளது என்று வைத்துக்கொள்வோம் - கிளையன்ட் ஏற்கனவே சர்வரிடம் ஏதாவது கேட்க வேண்டும் - நாங்கள் அனுப்ப விரும்பும் கோரிக்கை உள்ளது:

வாசிலி, [25.06.18/19/13 XNUMX:XNUMX] குறியீட்டின் மூலம் ஆராயும்போது, ​​முதல் அழைப்பு இந்த குப்பையில் மூடப்பட்டிருக்கும், மேலும் குப்பையே இன்வோக்வித்லேயரில் உள்ளது

ஏன் 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 இன் நன்கு அறியப்பட்ட நிகழ்வுகளுக்குப் பிறகு, எண்ணிக்கை கணிசமாக அதிகரித்துள்ளது.

அநாமதேய சேவையகத்தில் இந்த கட்டத்தில் நாங்கள் வந்தோம் என்பதை இப்போது நினைவில் கொள்வோம். ஐபி முகவரியைப் பெறுவது மிகவும் விலை உயர்ந்ததல்லவா? MTProto இன் மறைகுறியாக்கப்பட்ட பகுதியில் இதை ஏன் செய்யக்கூடாது? நான் ஒரு ஆட்சேபனையைக் கேட்கிறேன்: "போலி முகவரிகளுடன் பதிலளிக்கும் RKN அல்ல என்பதை நீங்கள் எப்படி உறுதிப்படுத்த முடியும்?". இதை நாங்கள் நினைவுகூருகிறோம், உண்மையில், உத்தியோகபூர்வ வாடிக்கையாளர்களில் உட்பொதிக்கப்பட்ட RSA விசைகள், அதாவது உன்னால் முடியும் கையெழுத்திட இந்த தகவல். உண்மையில், பிற சேனல்கள் மூலம் வாடிக்கையாளர்கள் பெறும் பூட்டுகளைத் தவிர்ப்பது பற்றிய தகவலுக்காக இது ஏற்கனவே செய்யப்பட்டுள்ளது (இதை MTProto இல் செய்ய முடியாது என்பது தர்க்கரீதியானது, ஏனென்றால் நீங்கள் எங்கு இணைக்க வேண்டும் என்பதை நீங்கள் இன்னும் தெரிந்து கொள்ள வேண்டும்).

சரி. வாடிக்கையாளர் அங்கீகாரத்தின் இந்த கட்டத்தில், நாங்கள் இன்னும் அங்கீகரிக்கப்படவில்லை மற்றும் எங்கள் விண்ணப்பத்தை பதிவு செய்யவில்லை. அங்கீகரிக்கப்படாத பயனருக்கு கிடைக்கும் முறைகளுக்கு சேவையகம் என்ன பதிலளிக்கிறது என்பதை இப்போது பார்க்க விரும்புகிறோம். மற்றும் இங்கே…

வாசிலி, [10.07.18 14:45] 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 திட்டத்தில், மூன்றாவது மதிப்பு

ஆம், அப்போதிருந்து, நிச்சயமாக, ஆவணங்கள் புதுப்பிக்கப்பட்டுள்ளன. விரைவில் அது மீண்டும் பொருத்தமற்றதாக ஆகலாம். ஒரு புதிய டெவலப்பர் எப்படி தெரிந்து கொள்ள வேண்டும்? ஒருவேளை நீங்கள் உங்கள் விண்ணப்பத்தை பதிவு செய்தால், அவர்கள் உங்களுக்கு அறிவிப்பார்களா? வாசிலி இதைச் செய்தார், ஆனால் ஐயோ, அவருக்கு எதுவும் அனுப்பப்படவில்லை (மீண்டும், இதைப் பற்றி இரண்டாவது பகுதியில் பேசுவோம்).

... நாங்கள் ஏற்கனவே எப்படியோ APIக்கு நகர்ந்திருப்பதை நீங்கள் கவனித்தீர்கள், அதாவது. அடுத்த நிலைக்குச் சென்று MTProto தீமில் எதையாவது தவறவிட்டீர்களா? ஆச்சரியப்பட ஒன்றுமில்லை:

Vasily, [28.06.18/02/04 2:XNUMX AM] ம்ம், அவர்கள் eXNUMXe இல் உள்ள சில அல்காரிதம்களை அலசுகிறார்கள்

Mtproto இரண்டு டொமைன்களுக்கான குறியாக்க அல்காரிதம்கள் மற்றும் விசைகள் மற்றும் ஒரு பிட் ரேப்பர் கட்டமைப்பை வரையறுக்கிறது

ஆனால் அவை தொடர்ந்து வெவ்வேறு அடுக்கு நிலைகளை கலக்கின்றன, எனவே mtproto எங்கு முடிந்தது மற்றும் அடுத்த நிலை தொடங்கியது என்பது எப்போதும் தெளிவாக இருக்காது.

அவை எவ்வாறு கலக்கப்படுகின்றன? சரி, இங்கே PFS க்கான அதே தற்காலிக விசை உள்ளது, எடுத்துக்காட்டாக (வழி, டெலிகிராம் டெஸ்க்டாப் அதை எப்படி செய்வது என்று தெரியவில்லை). இது API கோரிக்கையால் செயல்படுத்தப்படுகிறது auth.bindTempAuthKey, அதாவது மேல் மட்டத்தில் இருந்து. ஆனால் அதே நேரத்தில், இது கீழ் மட்டத்தில் குறியாக்கத்தில் தலையிடுகிறது - அதன் பிறகு, எடுத்துக்காட்டாக, நீங்கள் அதை மீண்டும் செய்ய வேண்டும். initConnection முதலியன, இது இல்லை வெறும் சாதாரண கோரிக்கை. தனித்தனியாக, DC இல் நீங்கள் ஒரு தற்காலிக விசையை மட்டுமே வைத்திருக்க முடியும் என்பதையும் இது வழங்குகிறது auth_key_id ஒவ்வொரு செய்தியிலும் குறைந்தபட்சம் ஒவ்வொரு செய்தியையும் விசையை மாற்ற உங்களை அனுமதிக்கிறது, மேலும் எந்த நேரத்திலும் தற்காலிக விசையை "மறக்க" சேவையகத்திற்கு உரிமை உண்டு - இந்த விஷயத்தில் என்ன செய்வது, ஆவணங்கள் சொல்லவில்லை ... சரி, ஏன் எதிர்கால உப்புகளின் தொகுப்பைப் போல பல விசைகளை வைத்திருப்பது சாத்தியமில்லை, ஆனால்?..

MTProto தீமில் கவனிக்க வேண்டிய வேறு சில விஷயங்கள் உள்ளன.

செய்தி செய்திகள், msg_id, msg_seqno, ஒப்புகைகள், தவறான திசையில் பிங் மற்றும் பிற தனித்தன்மைகள்

நீங்கள் ஏன் அவர்களைப் பற்றி தெரிந்து கொள்ள வேண்டும்? ஏனெனில் அவை ஒரு நிலை அதிகமாக "கசிவு" மற்றும் API உடன் பணிபுரியும் போது அவற்றைப் பற்றி நீங்கள் தெரிந்து கொள்ள வேண்டும். நாங்கள் msg_key இல் ஆர்வம் காட்டவில்லை என்று வைத்துக்கொள்வோம், கீழ்நிலையானது நமக்கான அனைத்தையும் மறைகுறியாக்கியது. ஆனால் மறைகுறியாக்கப்பட்ட தரவுக்குள், எங்களிடம் பின்வரும் புலங்கள் உள்ளன (திணிப்பு எங்குள்ளது என்பதை அறிய தரவின் நீளம், ஆனால் இது முக்கியமல்ல):

• உப்பு-int64
• அமர்வு_ஐடி - int64
• message_id - 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_X_MISSING. சரி, அதாவது, நீங்கள் இன்னும் இந்த வரிசையில் இருக்க வேண்டும் அலச. உதாரணமாக FLOOD_WAIT_3600 நீங்கள் ஒரு மணி நேரம் காத்திருக்க வேண்டும் என்று அர்த்தம், மற்றும் PHONE_MIGRATE_5இந்த முன்னொட்டுடன் கூடிய தொலைபேசி எண் 5வது 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 உடன் பணிபுரியத் தொடங்கும் ஒவ்வொருவரும் அவற்றை எதிர்கொள்ள வேண்டியிருக்கும், "திருத்தப்பட்ட - மீண்டும் தொகுக்கப்பட்ட - தொடங்கப்பட்ட" சுழற்சியில், எண் பிழைகள் அல்லது திருத்தங்களின் போது அழுகிய உப்பு பெறுவது பொதுவான விஷயம். இருப்பினும், இங்கே இரண்டு புள்ளிகள் உள்ளன:

1. இதன் மூலம் அசல் செய்தி தொலைந்து போனது. நாங்கள் சில வரிசைகளை வேலி அமைக்க வேண்டும், இதை நாங்கள் பின்னர் கருத்தில் கொள்வோம்.
2. அந்த வித்தியாசமான பிழை எண்கள் என்ன? 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 64... மீதி எண்கள் எங்கே டாமி?

ஆவணம் கூறுகிறது:

நோக்கம் பிழை_குறியீடு மதிப்புகள் குழுவாக (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 இன் காதுகள் வெளியே ஒட்டிக்கொள்கின்றன (எங்களுக்கு பைட்டுகளின் வெக்டார் தேவை, மற்றும் கீழ் இரண்டு பிட்கள் மற்றும் பழைய பிட்கள் கொடிகளில்). விஷயம் வேறு விஷயம். இதெல்லாம் ஏன் நடைமுறையில் இருக்கிறது என்று யாருக்காவது புரிகிறதா உண்மையான வாடிக்கையாளரில் தேவையா? ஆனால் கோரிக்கைகள் இங்கே விவரிக்கப்பட்டுள்ளன சுற்று பயணம்.

இதிலிருந்து ஒவ்வொரு பக்கமும் குறியாக்கம் செய்து செய்திகளை அனுப்புவது மட்டுமல்லாமல், அவற்றைப் பற்றிய தரவு, அவற்றுக்கான பதில்கள் மற்றும் அறியப்படாத நேரத்திற்குச் சேமிக்க வேண்டும். ஆவணங்கள் இந்த அம்சங்களின் நேரங்கள் அல்லது நடைமுறை பொருந்தக்கூடிய தன்மையை விவரிக்கவில்லை. இல்லை. மிகவும் ஆச்சரியமான விஷயம் என்னவென்றால், அவை உண்மையில் அதிகாரப்பூர்வ வாடிக்கையாளர்களின் குறியீட்டில் பயன்படுத்தப்படுகின்றன! வெளிப்படையாக, திறந்த ஆவணத்தில் சேர்க்கப்படாத ஒன்று அவர்களிடம் கூறப்பட்டது. குறியீட்டிலிருந்து புரிந்து கொள்ளுங்கள் ஏன், TL இன் விஷயத்தைப் போல இனி எளிதானது அல்ல - இது ஒரு (ஒப்பீட்டளவில்) தர்க்கரீதியாக தனிமைப்படுத்தப்பட்ட பகுதி அல்ல, ஆனால் பயன்பாட்டு கட்டமைப்புடன் இணைக்கப்பட்ட ஒரு பகுதி, அதாவது. பயன்பாட்டுக் குறியீட்டைப் புரிந்து கொள்ள அதிக நேரம் தேவைப்படும்.

பிங்ஸ் மற்றும் நேரங்கள். வரிசைகள்.

எல்லாவற்றிலிருந்தும், சர்வர் கட்டமைப்பைப் பற்றிய யூகங்களை நீங்கள் நினைவு கூர்ந்தால் (பின்புறத்தில் கோரிக்கைகளை விநியோகித்தல்), மிகவும் மந்தமான விஷயம் பின்வருமாறு - TCP இல் வழங்குவதற்கான அனைத்து உத்தரவாதங்களும் இருந்தபோதிலும் (தரவு வழங்கப்பட்டுள்ளது, அல்லது அதைப் பற்றி உங்களுக்குத் தெரிவிக்கப்படும். முறிவு, ஆனால் பிரச்சனையின் தருணம் வரை தரவு வழங்கப்படும்), அந்த உறுதிப்படுத்தல்கள் MTProto தானே - உத்தரவாதம் இல்லை. சேவையகம் உங்கள் செய்தியை எளிதில் இழக்கலாம் அல்லது தூக்கி எறியலாம், மேலும் பல்வேறு வகையான ஊன்றுகோல்களை வேலி போடுவதற்கு மட்டுமே இதைப் பற்றி எதுவும் செய்ய முடியாது.

மற்றும் முதலில் - செய்தி வரிசைகள். சரி, ஒன்று, ஆரம்பத்திலிருந்தே எல்லாம் தெளிவாகத் தெரிந்தது - உறுதிப்படுத்தப்படாத செய்தி சேமிக்கப்பட்டு மறுபரிசீலனை செய்யப்பட வேண்டும். மற்றும் எந்த நேரத்திற்கு பிறகு? மேலும் கேலி செய்பவருக்கு அவரைத் தெரியும். ஒருவேளை அந்த அடிமையான சேவை செய்திகள் ஊன்றுகோல் மூலம் இந்த சிக்கலை எப்படியாவது தீர்க்கும், சொல்லுங்கள், டெலிகிராம் டெஸ்க்டாப்பில் அவற்றுடன் தொடர்புடைய சுமார் 4 வரிசைகள் உள்ளன (ஒருவேளை இன்னும், ஏற்கனவே குறிப்பிட்டுள்ளபடி, இதற்காக நீங்கள் அதன் குறியீடு மற்றும் கட்டமைப்பை இன்னும் தீவிரமாக ஆராய வேண்டும்; அதே நேரத்தில். நேரம், அதை ஒரு மாதிரியாக எடுக்க முடியாது என்பதை நாங்கள் அறிவோம், MTProto திட்டத்திலிருந்து குறிப்பிட்ட எண்ணிக்கையிலான வகைகள் இதில் பயன்படுத்தப்படவில்லை).

இது ஏன் நடக்கிறது? அநேகமாக, சர்வர் புரோகிராமர்களால் க்ளஸ்டருக்குள் நம்பகத்தன்மையை உறுதிப்படுத்த முடியவில்லை, அல்லது குறைந்தபட்சம் முன் பேலன்சரில் கூட பஃபரிங் செய்ய முடியவில்லை, மேலும் இந்த சிக்கலை கிளையண்டிற்கு மாற்றியிருக்கலாம். விரக்தியின் காரணமாக, வாசிலி ஒரு மாற்று விருப்பத்தை செயல்படுத்த முயன்றார், இரண்டு வரிசைகள் மட்டுமே, TCP இலிருந்து அல்காரிதம்களைப் பயன்படுத்தி - சேவையகத்திற்கு RTT ஐ அளவிடுதல் மற்றும் அங்கீகரிக்கப்படாத கோரிக்கைகளின் எண்ணிக்கையைப் பொறுத்து "சாளரம்" அளவை (செய்திகளில்) சரிசெய்தல். அதாவது, சர்வர் சுமையை மதிப்பிடுவதற்கு இது போன்ற ஒரு கடினமான ஹூரிஸ்டிக் - நமது கோரிக்கைகளில் எத்தனை ஒரே நேரத்தில் மெல்லலாம் மற்றும் இழக்காமல் இருக்கும்.

சரி, அதாவது, நீங்கள் புரிந்துகொள்கிறீர்கள், இல்லையா? TCP இல் வேலை செய்யும் நெறிமுறையின் மேல் TCP ஐ மீண்டும் செயல்படுத்த வேண்டும் என்றால், இது மிகவும் மோசமாக வடிவமைக்கப்பட்ட நெறிமுறையைக் குறிக்கிறது.

ஆம், ஒன்றுக்கு மேற்பட்ட வரிசைகள் ஏன் தேவைப்படுகின்றன, பொதுவாக, உயர்நிலை API உடன் பணிபுரியும் நபருக்கு இது என்ன அர்த்தம்? பாருங்கள், நீங்கள் கோரிக்கை வைக்கிறீர்கள், அதைத் தொடர்கிறீர்கள், ஆனால் அதை உடனடியாக அனுப்புவது பெரும்பாலும் சாத்தியமற்றது. ஏன்? ஏனெனில் பதில் இருக்கும் msg_id, இது தற்காலிகமானதுаநான் ஒரு லேபிள், அதன் நியமனத்தை முடிந்தவரை தாமதமாக ஒத்திவைப்பது நல்லது - திடீரென்று சர்வர் அதை நிராகரித்துவிடும், ஏனெனில் நமக்கும் அதற்கும் இடையே நேரப் பொருத்தமின்மை (நிச்சயமாக, நம் நேரத்தை நிகழ்காலத்திலிருந்து மாற்றும் ஊன்றுகோலை உருவாக்கலாம். சேவையக பதில்களிலிருந்து கணக்கிடப்பட்ட டெல்டாவைச் சேர்ப்பதன் மூலம் சேவையக நேரத்திற்கு - அதிகாரப்பூர்வ கிளையன்ட்கள் இதைச் செய்கிறார்கள், ஆனால் இந்த முறை கச்சா மற்றும் தாங்கல் காரணமாக துல்லியமற்றது). எனவே, நூலகத்திலிருந்து உள்ளூர் செயல்பாட்டு அழைப்பைக் கொண்டு நீங்கள் கோரிக்கையைச் செய்யும்போது, ​​​​செய்தி பின்வரும் நிலைகளில் செல்கிறது:

1. அதே வரிசையில் உள்ளது மற்றும் குறியாக்கத்திற்காக காத்திருக்கிறது.
2. நியமிக்கப்பட்ட msg_id மற்றும் செய்தி மற்றொரு வரிசையில் சென்றது - சாத்தியமான பகிர்தல்; சாக்கெட்டுக்கு அனுப்பு.
3. a) சேவையகம் MsgsAck என்று பதிலளித்தது - செய்தி வழங்கப்பட்டது, அதை "மற்ற வரிசையில்" இருந்து நீக்குகிறோம்.
   b) அல்லது நேர்மாறாக, அவருக்கு ஏதாவது பிடிக்கவில்லை, அவர் badmsg க்கு பதிலளித்தார் - நாங்கள் "மற்ற வரிசையில்" இருந்து மீண்டும் அனுப்புகிறோம்
   c) எதுவும் தெரியவில்லை, மற்றொரு வரிசையில் இருந்து செய்தியை மீண்டும் அனுப்புவது அவசியம் - ஆனால் அது எப்போது என்று சரியாகத் தெரியவில்லை.
4. சர்வர் இறுதியாக பதிலளித்தது RpcResult - உண்மையான பதில் (அல்லது பிழை) - வழங்கப்படவில்லை, ஆனால் செயலாக்கப்பட்டது.

ஒருவேளை, கொள்கலன்களின் பயன்பாடு சிக்கலை ஓரளவு தீர்க்கும். ஒரு சில செய்திகள் ஒன்றாக நிரம்பியிருக்கும் போது, ​​சர்வர் அனைவருக்கும் ஒரே நேரத்தில் ஒரு அங்கீகாரத்துடன் பதிலளித்தது. msg_id. ஆனால் அவர் இந்த பேக்கை நிராகரிப்பார், ஏதாவது தவறு நடந்தால், முழு விஷயத்தையும் அவர் நிராகரிப்பார்.

இந்த கட்டத்தில், தொழில்நுட்பம் அல்லாத பரிசீலனைகள் செயல்பாட்டுக்கு வருகின்றன. அனுபவத்திலிருந்து, நாங்கள் பல ஊன்றுகோல்களைப் பார்த்திருக்கிறோம், கூடுதலாக, இப்போது மோசமான ஆலோசனை மற்றும் கட்டிடக்கலைக்கான பல எடுத்துக்காட்டுகளைக் காண்போம் - இதுபோன்ற சூழ்நிலைகளில், நம்புவது மற்றும் அத்தகைய முடிவுகளை எடுப்பது மதிப்புக்குரியதா? கேள்வி சொல்லாட்சி (நிச்சயமாக இல்லை).

நாம் என்ன பேசுகிறோம்? “செய்திகளைப் பற்றிய அடிமைச் செய்திகள்” என்ற தலைப்பில் “நீங்கள் முட்டாள், எங்களின் அற்புதமான யோசனையை நீங்கள் புரிந்து கொள்ளவில்லை!” போன்ற ஆட்சேபனைகளுடன் ஊகிக்கலாம். (எனவே முதலில் ஆவணங்களை எழுதுங்கள், சாதாரண மக்கள் எழுத வேண்டும், பகுத்தறிவு மற்றும் பாக்கெட் பரிமாற்ற எடுத்துக்காட்டுகளுடன், பின்னர் பேசுவோம்), பின்னர் நேரம் / காலக்கெடு என்பது முற்றிலும் நடைமுறை மற்றும் குறிப்பிட்ட பிரச்சினை, எல்லாம் நீண்ட காலமாக இங்கு அறியப்படுகிறது. ஆனால் காலக்கெடுவைப் பற்றி ஆவணங்கள் என்ன சொல்கிறது?

RPC பதிலைப் பயன்படுத்தி ஒரு கிளையண்டிலிருந்து (பொதுவாக, ஒரு RPC வினவல்) ஒரு செய்தியைப் பெறுவதை சர்வர் பொதுவாக ஒப்புக்கொள்கிறது. பதில் வர நீண்ட காலமாக இருந்தால், ஒரு சேவையகம் முதலில் ரசீது ஒப்புகையை அனுப்பலாம், மேலும் சிறிது நேரம் கழித்து, RPC பதிலையே அனுப்பலாம்.

ஒரு க்ளையன்ட் பொதுவாக ஒரு சேவையகத்திலிருந்து (பொதுவாக, RPC பதில்) ஒரு செய்தியைப் பெறுவதை ஒப்புக்கொள்கிறார் சேவையகத்திலிருந்து ஒரு செய்தி). இருப்பினும், நீண்ட காலத்திற்கு சேவையகத்திற்கு செய்திகளை அனுப்ப எந்த காரணமும் இல்லை என்றால் அல்லது சேவையகத்திலிருந்து அதிக எண்ணிக்கையிலான அங்கீகரிக்கப்படாத செய்திகள் இருந்தால் (சொல்லுங்கள், 60 க்கு மேல்), கிளையன்ட் ஒரு தனித்த ஒப்புகையை அனுப்புகிறது.

... நான் மொழிபெயர்க்கிறேன்: அது எவ்வளவு, எப்படி அவசியம் என்று நமக்குத் தெரியாது, சரி, இது இப்படி இருக்கட்டும் என்று மதிப்பிடுவோம்.

மற்றும் பிங்ஸ் பற்றி:

பிங் செய்திகள் (பிங்/பாங்)

ping#7abe77ec ping_id:long = Pong;

ஒரு பதில் பொதுவாக அதே இணைப்பிற்குத் திரும்பும்:

pong#347773c5 msg_id:long ping_id:long = Pong;

இந்த செய்திகளுக்கு ஒப்புகைகள் தேவையில்லை. ஒரு பாங் ஒரு பிங்கிற்கு பதில் மட்டுமே அனுப்பப்படுகிறது, அதே நேரத்தில் ஒரு பிங்கை இருபுறமும் தொடங்க முடியும்.

ஒத்திவைக்கப்பட்ட இணைப்பு மூடல் + பிங்

ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

பிங் போல வேலை செய்கிறது. கூடுதலாக, இதைப் பெற்ற பிறகு, சேவையகம் ஒரு டைமரைத் தொடங்குகிறது, இது முந்தைய அனைத்து டைமர்களையும் தானாக மீட்டமைக்கும் அதே வகையான புதிய செய்தியைப் பெறாவிட்டால், தற்போதைய இணைப்பு disconnect_delay வினாடிகளுக்குப் பிறகு மூடப்படும். கிளையன்ட் 60 வினாடிகளுக்கு ஒருமுறை இந்த பிங்ஸை அனுப்பினால், எடுத்துக்காட்டாக, அது disconnect_delayயை 75 வினாடிகளுக்கு சமமாக அமைக்கலாம்.

மனம் விட்டு விட்டீர்களா?! 60 வினாடிகளில், ரயில் நிலையத்திற்குள் நுழைந்து, பயணிகளை இறக்கி, ஏற்றி, மீண்டும் சுரங்கப்பாதையில் இணைப்பை இழக்கும். 120 வினாடிகளில், நீங்கள் வெளியே இருக்கும்போது, ​​​​அவர் இன்னொருவருக்கு வருவார், மேலும் இணைப்பு பெரும்பாலும் உடைந்துவிடும். சரி, கால்கள் எங்கிருந்து வளர்கின்றன என்பது தெளிவாகத் தெரிகிறது - “நான் சத்தம் கேட்டேன், ஆனால் அது எங்கே என்று எனக்குத் தெரியவில்லை”, நாக்லின் வழிமுறை மற்றும் TCP_NODELAY விருப்பம் உள்ளது, இது ஊடாடும் வேலைக்காக வடிவமைக்கப்பட்டுள்ளது. ஆனால், மன்னிக்கவும், அதன் இயல்புநிலை மதிப்பை தாமதப்படுத்தவும் - 200 மில்லிவினாடிகள். நீங்கள் உண்மையிலேயே இதேபோன்ற ஒன்றை சித்தரித்து, சாத்தியமான ஜோடி பாக்கெட்டுகளில் சேமிக்க விரும்பினால் - சரி, அதை குறைந்தபட்சம் 5 வினாடிகளுக்கு ஒத்திவைக்கவும் அல்லது “பயனர் தட்டச்சு செய்கிறார் ...” என்ற செய்தியின் நேரம் முடிந்தால் இப்போது சமமாக இருக்கும். ஆனால் இனி இல்லை.

இறுதியாக, பிங்ஸ். அதாவது, TCP இணைப்பின் உயிரோட்டத்தை சரிபார்க்கிறது. இது வேடிக்கையானது, ஆனால் சுமார் 10 ஆண்டுகளுக்கு முன்பு எங்கள் ஆசிரிய விடுதியின் தூதரைப் பற்றி நான் ஒரு விமர்சன உரையை எழுதினேன் - அங்கு ஆசிரியர்கள் வாடிக்கையாளரிடமிருந்து சேவையகத்தை பிங் செய்தனர், நேர்மாறாக அல்ல. ஆனால் மூன்றாம் ஆண்டு மாணவர்கள் ஒரு விஷயம், ஒரு சர்வதேச அலுவலகம் மற்றொரு விஷயம், இல்லையா? ..

முதலில், ஒரு சிறிய கல்வித் திட்டம். ஒரு TCP இணைப்பு, பாக்கெட் பரிமாற்றம் இல்லாத நிலையில், வாரங்கள் வாழ முடியும். இது நோக்கத்தைப் பொறுத்து நல்லது மற்றும் கெட்டது. சரி, நீங்கள் சேவையகத்துடன் SSH இணைப்பு திறந்திருந்தால், உங்கள் கணினியிலிருந்து எழுந்து, மின் திசைவியை மறுதொடக்கம் செய்து, உங்கள் இடத்திற்குத் திரும்புங்கள் - இந்த சேவையகத்தின் அமர்வு உடைக்கவில்லை (எதையும் தட்டச்சு செய்யவில்லை, பாக்கெட்டுகள் இல்லை), வசதியான. சேவையகத்தில் ஆயிரக்கணக்கான கிளையண்டுகள் இருந்தால், ஒவ்வொருவரும் ஆதாரங்களை எடுத்துக் கொண்டால் அது மோசமானது (ஹலோ போஸ்ட்கிரெஸ்!), மற்றும் கிளையன்ட் ஹோஸ்ட் நீண்ட காலத்திற்கு முன்பே மறுதொடக்கம் செய்திருக்கலாம் - ஆனால் அதைப் பற்றி எங்களுக்குத் தெரியாது.

அரட்டை/IM அமைப்புகள் இரண்டாவது வழக்கைச் சேர்ந்தவை, கூடுதல் காரணம் - ஆன்லைன் நிலைகள். பயனர் "விழுந்தால்", அதைப் பற்றி அவரது உரையாசிரியர்களுக்குத் தெரிவிக்க வேண்டியது அவசியம். இல்லையெனில், ஜாபர் உருவாக்கியவர்கள் செய்த தவறு இருக்கும் (மற்றும் 20 ஆண்டுகளாக சரி செய்யப்பட்டது) - பயனர் துண்டிக்கப்பட்டார், ஆனால் அவர் ஆன்லைனில் இருப்பதாக நம்பி அவருக்கு தொடர்ந்து செய்திகளை எழுதுகிறார்கள் (அவை இந்த சில நிமிடங்களுக்கு முன்பு முற்றிலும் தொலைந்துவிட்டன. முறிவு கண்டுபிடிக்கப்பட்டது). இல்லை, TCP_KEEPALIVE விருப்பம், TCP டைமர்கள் எவ்வாறு செயல்படுகின்றன என்பதைப் புரிந்து கொள்ளாத பலர், எங்கும் தோன்றும் (பத்து வினாடிகள் போன்ற காட்டு மதிப்புகளை அமைப்பதன் மூலம்), இங்கே உதவாது - நீங்கள் OS கர்னல் மட்டுமல்ல என்பதை உறுதிப்படுத்த வேண்டும். பயனரின் இயந்திரம் உயிருடன் உள்ளது, ஆனால் சாதாரணமாக செயல்படுகிறது, பதிலளிக்க முடியும், மற்றும் பயன்பாடு தன்னை (நீங்கள் அதை முடக்க முடியாது என்று நினைக்கிறீர்களா? உபுண்டு 18.04 இல் டெலிகிராம் டெஸ்க்டாப் எனக்கு மீண்டும் மீண்டும் செயலிழந்தது).

அதனால்தான் நீங்கள் பிங் செய்ய வேண்டும் சர்வர் கிளையன்ட், மற்றும் நேர்மாறாக அல்ல - கிளையன்ட் இதைச் செய்தால், இணைப்பு உடைந்தால், பிங் வழங்கப்படாது, இலக்கை அடைய முடியாது.

டெலிகிராமில் நாம் என்ன பார்க்கிறோம்? எல்லாம் நேர் எதிர்! சரி, அதாவது. முறையாக, நிச்சயமாக, இரு தரப்பினரும் ஒருவருக்கொருவர் பிங் செய்யலாம். நடைமுறையில், வாடிக்கையாளர்கள் ஊன்றுகோலைப் பயன்படுத்துகின்றனர் ping_delay_disconnect, இது சர்வரில் ஒரு டைமரைத் தூண்டுகிறது. சரி, மன்னிக்கவும், பிங் இல்லாமல் எவ்வளவு காலம் அங்கு வாழ வேண்டும் என்பதை முடிவு செய்வது வாடிக்கையாளரின் வணிகம் அல்ல. சர்வர், அதன் சுமை அடிப்படையில், நன்றாக தெரியும். ஆனால், நிச்சயமாக, நீங்கள் வளங்களுக்காக வருத்தப்படாவிட்டால், தீய பினோச்சியோ அவர்களே, ஊன்றுகோல் கீழே வரும் ...

அது எப்படி வடிவமைக்கப்பட்டிருக்க வேண்டும்?

கணினி நெட்வொர்க்குகளின் போக்குவரத்து (மற்றும் குறைந்த) மட்டத்தில் டெலிகிராம் / VKontakte குழுவின் மிக உயர்ந்த திறன் மற்றும் தொடர்புடைய விஷயங்களில் அவர்களின் குறைந்த தகுதி ஆகியவற்றை மேலே உள்ள உண்மைகள் தெளிவாகக் குறிப்பிடுகின்றன என்று நான் நம்புகிறேன்.

இது ஏன் மிகவும் சிக்கலானதாக மாறியது, டெலிகிராம் கட்டிடக் கலைஞர்கள் எவ்வாறு எதிர்க்க முயற்சி செய்யலாம்? TCP இணைப்பிலிருந்து தப்பிப்பிழைக்கும் ஒரு அமர்வை உருவாக்க அவர்கள் முயற்சித்தார்கள், அதாவது, நாங்கள் இப்போது வழங்காததை, பின்னர் வழங்குவோம். அவர்கள் UDP போக்குவரத்தை உருவாக்க முயற்சித்திருக்கலாம், இருப்பினும் அவர்கள் சிரமங்களுக்கு உள்ளாகி அதைக் கைவிட்டனர் (அதனால்தான் ஆவணங்கள் காலியாக உள்ளன - தற்பெருமை காட்ட எதுவும் இல்லை). ஆனால் பொதுவாக நெட்வொர்க்குகள் மற்றும் குறிப்பாக TCP எவ்வாறு வேலை செய்கிறது, நீங்கள் அதை எங்கு நம்பலாம், அதை நீங்களே எங்கு செய்ய வேண்டும் (மற்றும் எப்படி) மற்றும் இதை கிரிப்டோகிராஃபியுடன் இணைக்க முயற்சிப்பது பற்றிய புரிதல் இல்லாததால் “இரண்டில் ஒரு ஷாட் ஒரே கல்லில் பறவைகள்” - அத்தகைய சடலம் மாறியது.

எப்படி இருந்திருக்க வேண்டும்? என்ற உண்மையின் அடிப்படையில் msg_id ரீப்ளே தாக்குதல்களைத் தடுக்க கிரிப்டோகிராஃபிக் ரீதியாக அவசியமான நேர முத்திரை, அதனுடன் ஒரு தனிப்பட்ட அடையாளங்காட்டி செயல்பாட்டை இணைப்பது பிழை. எனவே, தற்போதைய கட்டமைப்பை கடுமையாக மாற்றாமல் (புதுப்பிப்புகள் த்ரெட் உருவாகும்போது, ​​இந்தத் தொடரின் மற்றொரு பகுதிக்கான உயர்நிலை API தலைப்பு), ஒருவர் செய்ய வேண்டியது:

1. கிளையண்டுடன் TCP இணைப்பை வைத்திருக்கும் சேவையகம் பொறுப்பேற்கிறது - நீங்கள் சாக்கெட்டிலிருந்து கழித்தால், பிழையை ஒப்புக்கொள்ளவும், செயலாக்கவும் அல்லது திருப்பி அனுப்பவும், இழப்பு இல்லை. பின்னர் உறுதிப்படுத்தல் என்பது ஐடியின் திசையன் அல்ல, ஆனால் "கடைசியாகப் பெறப்பட்ட seq_no" - TCP (இரண்டு எண்கள் - உங்கள் சொந்த seq மற்றும் உறுதிப்படுத்தப்பட்ட) போன்ற ஒரு எண். நாங்கள் எப்போதும் அமர்வில் இருக்கிறோம், இல்லையா?
2. ரீப்ளே தாக்குதல்களைத் தடுப்பதற்கான நேர முத்திரை ஒரு தனி களமாக மாறுகிறது. சரிபார்க்கப்பட்டது, ஆனால் வேறு எதுவும் பாதிக்கப்படவில்லை. போதும் மற்றும் uint32 - நமது உப்பு குறைந்தது ஒவ்வொரு அரை நாளுக்கும் மாறினால், தற்போதைய நேரத்தின் முழு எண் பகுதியின் கீழ் பிட்களுக்கு 16 பிட்களை ஒதுக்கலாம், மீதமுள்ளவை - ஒரு நொடியின் பகுதியளவு பகுதிக்கு (இப்போது உள்ளது போல).
3. திரும்பப் பெறப்பட்டது msg_id அனைத்து - பின்தளங்களில் கோரிக்கைகளை வேறுபடுத்தும் பார்வையில், முதலில், கிளையன்ட் ஐடி, இரண்டாவதாக, அமர்வு ஐடி மற்றும் அவற்றை இணைக்கவும். அதன்படி, கோரிக்கை அடையாளங்காட்டியாக, ஒன்று மட்டும் போதுமானது seq_no.

சிறந்த விருப்பம் அல்ல, ஒரு முழுமையான சீரற்ற ஒரு அடையாளங்காட்டியாக செயல்பட முடியும் - இது ஏற்கனவே ஒரு செய்தியை அனுப்பும் போது உயர் நிலை API இல் செய்யப்படுகிறது. கட்டிடக்கலையை ஒப்பீட்டளவில் முழுவதுமாக ரீமேக் செய்வது நல்லது, ஆனால் இது மற்றொரு பகுதிக்கான தலைப்பு, இந்த இடுகை அல்ல.

API?

தா-டாம்! எனவே, வலி ​​மற்றும் ஊன்றுகோல் நிறைந்த பாதையில் சென்றதால், கடைசியாக எங்களால் எந்தவொரு கோரிக்கையையும் சேவையகத்திற்கு அனுப்பவும் அவற்றுக்கான பதில்களைப் பெறவும் முடிந்தது, அத்துடன் சேவையகத்திலிருந்து புதுப்பிப்புகளைப் பெறவும் முடிந்தது (கோரிக்கைக்கு பதிலளிக்கவில்லை, ஆனால் யாரேனும் மிகவும் தெளிவாக இருந்தால், புஷ் போன்றவற்றை அது நமக்கு அனுப்புகிறது).

கவனம், இப்போது கட்டுரையில் ஒரே பெர்ல் உதாரணம் இருக்கும்! (தொடரியல் பற்றி நன்கு தெரியாதவர்களுக்கு, ஆசீர்வதிப்பதற்கான முதல் வாதம் பொருளின் தரவு அமைப்பு, இரண்டாவது அதன் வர்க்கம்):

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 இல் உள்ள பொதுவான Web API இன் தரவுக் கட்டமைப்பாக இருக்கலாம், ஒருவேளை வகுப்புகள் பொருள்களுடன் இணைக்கப்பட்டிருக்கலாம்?..

எனவே அது மாறிவிடும் ... அது என்ன, தோழர்களே? ஆரம்பிக்கிறது?.. HTTPS மூலம் JSON மட்டும் எளிதாக இருக்கும் அல்லவா?! அதற்கு ஈடாக நமக்கு என்ன கிடைத்தது? இந்த முயற்சிகள் மதிப்புள்ளதா?

TL+MTPproto நமக்கு என்ன அளித்துள்ளது மற்றும் என்ன மாற்று வழிகள் உள்ளன என்பதை மதிப்பீடு செய்வோம். சரி, HTTP கோரிக்கை-பதில் என்பது ஒரு மோசமான பொருத்தம், ஆனால் குறைந்த பட்சம் TLS இன் மேல் ஏதாவது உள்ளதா?

சிறிய வரிசையாக்கம். JSON போன்ற இந்த தரவு கட்டமைப்பைப் பார்க்கும்போது, ​​அதன் பைனரி மாறுபாடுகள் இருப்பது நினைவிற்கு வந்தது. MsgPack போதிய அளவு நீட்டிக்க முடியாததாகக் குறிப்போம், ஆனால் எடுத்துக்காட்டாக, CBOR - மூலம், தரநிலையில் விவரிக்கப்பட்டுள்ளது RFC 7049. வரையறுத்துள்ளமை குறிப்பிடத்தக்கது குறிச்சொற்கள், ஒரு நீட்டிப்பு பொறிமுறையாக, மற்றும் மத்தியில் ஏற்கனவே தரப்படுத்தப்பட்டது உள்ளன:

• 25 + 256 - நகல் வரிகளை வரி எண் குறிப்புடன் மாற்றுதல், இது போன்ற மலிவான சுருக்க முறை
• 26 - கிளாஸ் பெயர் மற்றும் கன்ஸ்ட்ரக்டர் வாதங்களுடன் வரிசைப்படுத்தப்பட்ட பெர்ல் பொருள்
• 27 - வகை பெயர் மற்றும் கட்டமைப்பாளர் வாதங்களுடன் வரிசைப்படுத்தப்பட்ட மொழி-சுயாதீனமான பொருள்

சரி, அதே தரவை TL மற்றும் CBOR இல் வரிசைப்படுத்த முயற்சித்தேன். ஒரு மெகாபைட்டிலிருந்து எங்காவது CBORக்கு ஆதரவாக முடிவு வேறுபடத் தொடங்கியது:

cborlen=1039673 tl_len=1095092

எனவே முடிவுக்கு: ஒப்பிடக்கூடிய செயல்திறனுடன், ஒத்திசைவு தோல்வி அல்லது அறியப்படாத அடையாளங்காட்டி பிரச்சனைக்கு உட்படாத, கணிசமாக எளிமையான வடிவங்கள் உள்ளன.

வேகமான இணைப்பை நிறுவுதல். இதன் பொருள் மீண்டும் இணைப்பிற்குப் பிறகு பூஜ்ஜிய RTT (விசை ஏற்கனவே ஒரு முறை உருவாக்கப்பட்ட போது) - முதல் MTProto செய்தியிலிருந்து பொருந்தும், ஆனால் சில முன்பதிவுகளுடன் - அவை ஒரே உப்பில் நுழைந்தன, அமர்வு அழுகவில்லை, முதலியன. பதிலுக்கு TLS நமக்கு என்ன வழங்குகிறது? தொடர்புடைய மேற்கோள்:

TLS, TLS அமர்வு டிக்கெட்டுகளில் PFS ஐப் பயன்படுத்தும் போது (RFC 5077) விசைகளை மறுபரிசீலனை செய்யாமல் மற்றும் சர்வரில் முக்கிய தகவலைச் சேமிக்காமல் மறைகுறியாக்கப்பட்ட அமர்வை மீண்டும் தொடங்குவதற்கு. முதல் இணைப்பைத் திறந்து விசைகளை உருவாக்கும் போது, ​​சேவையகம் இணைப்பின் நிலையை குறியாக்கம் செய்து கிளையண்டிற்கு அனுப்புகிறது (அமர்வு டிக்கெட் வடிவில்). அதன்படி, இணைப்பு மீண்டும் தொடங்கும் போது, ​​வாடிக்கையாளர் அமர்வுச் சீட்டு, அமர்வு விசை உள்ளிட்டவற்றை மீண்டும் சேவையகத்திற்கு அனுப்புகிறார். பயணச்சீட்டு ஒரு தற்காலிக விசையுடன் (அமர்வு டிக்கெட் விசை) குறியாக்கம் செய்யப்பட்டுள்ளது, இது சர்வரில் சேமிக்கப்பட்டு, கிளஸ்டர்டு தீர்வுகளில் SSL ஐக் கையாளும் அனைத்து முன்நிலை சேவையகங்களுக்கும் விநியோகிக்கப்பட வேண்டும்.[10] எனவே, தற்காலிக சர்வர் விசைகள் சமரசம் செய்யப்பட்டால், அமர்வு டிக்கெட்டை அறிமுகப்படுத்துவது PFS ஐ மீறலாம், எடுத்துக்காட்டாக, அவை நீண்ட நேரம் சேமிக்கப்படும் போது (OpenSSL, nginx, Apache இயல்பாக அவற்றை நிரல் இயங்கும் முழு நேரத்திலும் சேமிக்கவும்; பிரபலமான தளங்கள் விசையை பல மணிநேரம், நாட்கள் வரை பயன்படுத்தவும்).

இங்கே RTT பூஜ்ஜியமாக இல்லை, நீங்கள் குறைந்தபட்சம் ClientHello மற்றும் ServerHello ஐ பரிமாறிக்கொள்ள வேண்டும், அதன் பிறகு, முடிந்ததுடன், கிளையன்ட் ஏற்கனவே தரவை அனுப்ப முடியும். ஆனால் இங்கே நாம் புதிதாகத் திறக்கப்பட்ட இணைப்புகளைக் கொண்ட இணையம் இல்லை என்பதை நினைவில் கொள்ள வேண்டும், ஆனால் ஒரு தூதர், இதன் இணைப்பு பெரும்பாலும் ஒன்று அல்லது அதற்கு மேற்பட்ட அல்லது குறைவான நீண்ட காலம், வலைப்பக்கங்களுக்கான ஒப்பீட்டளவில் குறுகிய கோரிக்கைகள் - எல்லாமே உள்ளே மல்டிப்ளெக்ஸ். அதாவது, நாங்கள் மிகவும் மோசமான சுரங்கப்பாதை பகுதியைக் காணவில்லை என்றால், அது மிகவும் ஏற்றுக்கொள்ளத்தக்கது.

வேறு ஏதாவது மறந்துவிட்டதா? கருத்துகளில் எழுதுங்கள்.

தொடரும்!

இந்தத் தொடர் இடுகைகளின் இரண்டாம் பகுதியில், தொழில்நுட்ப சிக்கல்களைக் காட்டிலும் நிறுவனச் சிக்கல்களைக் கருத்தில் கொள்வோம் - அணுகுமுறைகள், சித்தாந்தம், இடைமுகம், பயனர்களுக்கான அணுகுமுறை போன்றவை. இருப்பினும், இங்கே வழங்கப்பட்ட தொழில்நுட்ப தகவல்களின் அடிப்படையில்.

மூன்றாம் பகுதி தொழில்நுட்ப கூறு / மேம்பாட்டு அனுபவத்தின் பகுப்பாய்வு தொடரும். நீங்கள் குறிப்பாக கற்றுக்கொள்வீர்கள்:

• பலவிதமான TL-வகைகளைக் கொண்ட சந்தடியின் தொடர்ச்சி
• சேனல்கள் மற்றும் சூப்பர் குழுக்கள் பற்றி தெரியாத விஷயங்கள்
• உரையாடல்களை விட ரோஸ்டரை விட மோசமானது
• முழுமையான vs உறவினர் செய்தி முகவரி பற்றி
• புகைப்படத்திற்கும் படத்திற்கும் என்ன வித்தியாசம்
• சாய்வு உரையில் ஈமோஜி எவ்வாறு தலையிடுகிறது

மற்றும் பிற ஊன்றுகோல்கள்! காத்திருங்கள்!

ஆதாரம்: www.habr.com