അടുത്തിടെ, ടെലിഗ്രാം എത്ര മികച്ചതാണ്, നെറ്റ്‌വർക്ക് സംവിധാനങ്ങൾ നിർമ്മിക്കുന്നതിൽ ദുറോവ് സഹോദരന്മാർ എത്ര മിടുക്കരും അനുഭവപരിചയമുള്ളവരുമാണ് തുടങ്ങിയ പോസ്റ്റുകൾ ഹബ്രെയിൽ കൂടുതലായി പ്രത്യക്ഷപ്പെടാൻ തുടങ്ങി. അതേ സമയം, വളരെ കുറച്ച് ആളുകൾ മാത്രമേ സാങ്കേതിക ഉപകരണത്തിൽ മുഴുകിയിട്ടുള്ളൂ - പരമാവധി, അവർ JSON അടിസ്ഥാനമാക്കി വളരെ ലളിതമായ (എം.ടി.പ്രോട്ടോയിൽ നിന്ന് തികച്ചും വ്യത്യസ്തമായ) ബോട്ട് API ഉപയോഗിക്കുന്നു, സാധാരണയായി സ്വീകരിക്കുക വിശ്വാസത്തിൽ സന്ദേശവാഹകനെ ചുറ്റിപ്പറ്റിയുള്ള എല്ലാ പ്രശംസകളും PR-ഉം. ഏകദേശം ഒന്നര വർഷം മുമ്പ്, എഷെലോൺ എൻ‌ജി‌ഒയിലെ എന്റെ സഹപ്രവർത്തകൻ വാസിലി (നിർഭാഗ്യവശാൽ, ഡ്രാഫ്റ്റിനൊപ്പം ഹബ്രെയെക്കുറിച്ചുള്ള അദ്ദേഹത്തിന്റെ അക്കൗണ്ട് മായ്‌ച്ചു) പേളിൽ ആദ്യം മുതൽ സ്വന്തം ടെലിഗ്രാം ക്ലയന്റ് എഴുതാൻ തുടങ്ങി, പിന്നീട് ഈ വരികളുടെ രചയിതാവ് ചേർന്നു. എന്തുകൊണ്ടാണ് പേർൾ, ചിലർ ഉടൻ ചോദിക്കും? കാരണം മറ്റ് ഭാഷകളിൽ ഇത്തരം പ്രോജക്ടുകൾ നിലവിലുണ്ട്.വാസ്തവത്തിൽ, ഇതല്ല വിഷയം, ഇല്ലാത്ത മറ്റേതെങ്കിലും ഭാഷയുണ്ടാകാം. റെഡിമെയ്ഡ് ലൈബ്രറി, അതനുസരിച്ച് രചയിതാവ് എല്ലാ വഴിക്കും പോകണം ആദ്യം മുതൽ. മാത്രമല്ല, ക്രിപ്‌റ്റോഗ്രഫി വിശ്വാസത്തിന്റെ കാര്യമാണ്, എന്നാൽ സ്ഥിരീകരിക്കുക. സുരക്ഷ ലക്ഷ്യമാക്കിയുള്ള ഒരു ഉൽപ്പന്നം ഉപയോഗിച്ച്, നിങ്ങൾക്ക് നിർമ്മാതാവിൽ നിന്നുള്ള ഒരു റെഡിമെയ്ഡ് ലൈബ്രറിയെ ആശ്രയിക്കാനും അന്ധമായി വിശ്വസിക്കാനും കഴിയില്ല (എന്നിരുന്നാലും, ഇത് രണ്ടാം ഭാഗത്തിനുള്ള വിഷയമാണ്). ഇപ്പോൾ, ലൈബ്രറി "ശരാശരി" തലത്തിൽ നന്നായി പ്രവർത്തിക്കുന്നു (ഏതെങ്കിലും API അഭ്യർത്ഥനകൾ നടത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു).

എന്നിരുന്നാലും, ഈ പോസ്റ്റുകളുടെ പരമ്പരയിൽ കൂടുതൽ ക്രിപ്റ്റോഗ്രഫിയോ ഗണിതമോ ഉണ്ടാകില്ല. എന്നാൽ മറ്റ് നിരവധി സാങ്കേതിക വിശദാംശങ്ങളും വാസ്തുവിദ്യാ ഊന്നുവടികളും ഉണ്ടാകും (ആദ്യം മുതൽ എഴുതാത്തവർക്കും, എന്നാൽ ഏത് ഭാഷയിലും ലൈബ്രറി ഉപയോഗിക്കുന്നവർക്കും ഇത് ഉപയോഗപ്രദമാണ്). അതിനാൽ, ക്ലയന്റ് ആദ്യം മുതൽ നടപ്പിലാക്കാൻ ശ്രമിക്കുകയായിരുന്നു പ്രധാന ലക്ഷ്യം ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ പ്രകാരം. അതായത്, ഔദ്യോഗിക ക്ലയന്റുകളുടെ സോഴ്സ് കോഡ് അടച്ചിട്ടുണ്ടെന്ന് നമുക്ക് അനുമാനിക്കാം (വീണ്ടും, രണ്ടാം ഭാഗത്ത് ഇത് ശരിയാണ് എന്ന വസ്തുതയുടെ വിഷയം ഞങ്ങൾ കൂടുതൽ വിശദമായി ചർച്ച ചെയ്യും. അത് സംഭവിക്കുന്നു അതിനാൽ), പക്ഷേ, പഴയ കാലത്തെപ്പോലെ, ഉദാഹരണത്തിന്, RFC പോലുള്ള ഒരു സ്റ്റാൻഡേർഡ് ഉണ്ട് - സ്പെസിഫിക്കേഷൻ അനുസരിച്ച് മാത്രം ഒരു ക്ലയന്റ് എഴുതാൻ കഴിയുമോ, സോഴ്സ് കോഡ് "നോക്കാതെ", അത് ഔദ്യോഗികമായിരിക്കട്ടെ (ടെലിഗ്രാം ഡെസ്ക്ടോപ്പ്, മൊബൈൽ), അല്ലെങ്കിൽ അനൗദ്യോഗിക ടെലിത്തോൺ?

ഉള്ളടക്ക പട്ടിക:

• ഡോക്യുമെന്റേഷൻ... അത് നിലവിലുണ്ട്, അല്ലേ? ഇത് സത്യമാണോ?..
• ഒരു യുവ എഴുത്തുകാരനായി എവിടെ തുടങ്ങണം?
• ബൈനറി സീരിയലൈസേഷൻ: TL (ടൈപ്പ് ലാംഗ്വേജ്) അതിന്റെ സ്കീമും ലെയറുകളും കൂടാതെ മറ്റ് പല ഭയാനകമായ വാക്കുകളും
  • ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ വായിക്കാൻ ആഗ്രഹിക്കാത്തവർക്കായി TL വാക്യഘടനയുടെ ഒരു ചെറിയ വിവരണം
  • ഒരിക്കലും റിലീസ് ചെയ്യാത്ത വെക്റ്റർ
  • കോഡിൽ നിലവിലുള്ള TL നടപ്പിലാക്കലുകൾ
  • തരം ഭാഷയിൽ തരങ്ങളുടെ അഭാവം
  • പതിപ്പ്. പാളികൾ
• MTPproto
  • ഗതാഗത പാളി
  • കീകൾ, സന്ദേശങ്ങൾ, സെഷനുകൾ, ഡിഫി-ഹെൽമാൻ
  • സന്ദേശ സന്ദേശങ്ങൾ, msg_id, msg_seqno, സ്ഥിരീകരണങ്ങൾ, തെറ്റായ ദിശയിലുള്ള പിംഗ്, മറ്റ് വ്യതിരിക്തതകൾ
    • RPC: അഭ്യർത്ഥനകൾ, പ്രതികരണങ്ങൾ, പിശകുകൾ. സ്ഥിരീകരണങ്ങൾ.
    • മയക്കുമരുന്ന് ആസക്തി: സന്ദേശ നിലകൾ
    • പിംഗുകളും സമയവും. ക്യൂകൾ.
    • അത് എങ്ങനെ രൂപകൽപന ചെയ്യണമായിരുന്നു?
• API?
• തുടരും!

ഡോക്യുമെന്റേഷൻ... അത് നിലവിലുണ്ട്, അല്ലേ? ഇത് സത്യമാണോ?..

ഈ ലേഖനത്തിനായുള്ള കുറിപ്പുകളുടെ ശകലങ്ങൾ കഴിഞ്ഞ വേനൽക്കാലത്ത് ശേഖരിക്കാൻ തുടങ്ങി. ഔദ്യോഗിക വെബ്സൈറ്റിൽ ഈ സമയം മുഴുവൻ https://core.telegram.org രേഖ 23 ലെയർ പോലെയായിരുന്നു, അതായത്. 2014-ൽ എവിടെയോ കുടുങ്ങി (ഓർക്കുക, അന്ന് ചാനലുകൾ പോലും ഉണ്ടായിരുന്നില്ലേ?). തീർച്ചയായും, സിദ്ധാന്തത്തിൽ, 2014-ൽ അക്കാലത്ത് പ്രവർത്തനക്ഷമതയുള്ള ഒരു ക്ലയന്റ് നടപ്പിലാക്കാൻ ഇത് ഞങ്ങളെ അനുവദിച്ചിരിക്കണം. എന്നാൽ ഈ അവസ്ഥയിൽ പോലും, ഡോക്യുമെന്റേഷൻ, ഒന്നാമതായി, അപൂർണ്ണമായിരുന്നു, രണ്ടാമതായി, സ്ഥലങ്ങളിൽ അത് സ്വയം വിരുദ്ധമായിരുന്നു. ഒരു മാസം മുമ്പ്, 2019 സെപ്റ്റംബറിൽ, അത് ആകസ്മികമായി സൈറ്റിലെ ഡോക്യുമെന്റേഷന്റെ ഒരു വലിയ അപ്‌ഡേറ്റ് ഉണ്ടെന്ന് കണ്ടെത്തി, പൂർണ്ണമായും സമീപകാല ലെയർ 105 നായി, ഇപ്പോൾ എല്ലാം വീണ്ടും വായിക്കേണ്ടതുണ്ട്. തീർച്ചയായും, പല ലേഖനങ്ങളും പരിഷ്കരിച്ചു, എന്നാൽ പലതും മാറ്റമില്ലാതെ തുടർന്നു. അതിനാൽ, ഡോക്യുമെന്റേഷനെക്കുറിച്ചുള്ള താഴെയുള്ള വിമർശനം വായിക്കുമ്പോൾ, ഇവയിൽ ചിലത് ഇനി പ്രസക്തമല്ല, എന്നാൽ ചിലത് ഇപ്പോഴും ശരിയാണെന്ന് നിങ്ങൾ ഓർക്കണം. എല്ലാത്തിനുമുപരി, ആധുനിക ലോകത്ത് 5 വർഷം വളരെക്കാലം മാത്രമല്ല, മറിച്ച് വളരെ ധാരാളം. അന്നുമുതൽ (പ്രത്യേകിച്ചും ഉപേക്ഷിച്ചതും പുനരുജ്ജീവിപ്പിച്ചതുമായ ജിയോചാറ്റ് സൈറ്റുകൾ നിങ്ങൾ കണക്കിലെടുക്കുന്നില്ലെങ്കിൽ), സ്കീമിലെ API രീതികളുടെ എണ്ണം നൂറിൽ നിന്ന് ഇരുന്നൂറ്റമ്പതിലേറെയായി വർദ്ധിച്ചു!

ഒരു യുവ എഴുത്തുകാരനായി എവിടെ തുടങ്ങണം?

നിങ്ങൾ ആദ്യം മുതൽ എഴുതുകയോ ഉപയോഗിക്കുകയോ ചെയ്യുന്നത് പ്രശ്നമല്ല, ഉദാഹരണത്തിന്, റെഡിമെയ്ഡ് ലൈബ്രറികൾ പോലെ പൈത്തണിനുള്ള ടെലിത്തൺ അഥവാ PHP-യ്‌ക്കായി മഡ്‌ലൈൻ, ഏത് സാഹചര്യത്തിലും, നിങ്ങൾക്ക് ആദ്യം ആവശ്യമാണ് നിങ്ങളുടെ അപേക്ഷ രജിസ്റ്റർ ചെയ്യുക - പാരാമീറ്ററുകൾ നേടുക api_id и api_hash (VKontakte API-യിൽ പ്രവർത്തിച്ചവർക്ക് പെട്ടെന്ന് മനസ്സിലാകും) ഇതിലൂടെ സെർവർ ആപ്ലിക്കേഷൻ തിരിച്ചറിയും. ഈ ചെയ്യണം നിയമപരമായ കാരണങ്ങളാൽ ഇത് ചെയ്യുക, പക്ഷേ ലൈബ്രറി രചയിതാക്കൾക്ക് ഇത് രണ്ടാം ഭാഗത്തിൽ പ്രസിദ്ധീകരിക്കാൻ കഴിയാത്തതിനെ കുറിച്ച് ഞങ്ങൾ കൂടുതൽ സംസാരിക്കും. ടെസ്റ്റ് മൂല്യങ്ങളിൽ നിങ്ങൾ സംതൃപ്തരായിരിക്കാം, അവ വളരെ പരിമിതമാണെങ്കിലും - ഇപ്പോൾ നിങ്ങൾക്ക് രജിസ്റ്റർ ചെയ്യാൻ കഴിയും എന്നതാണ് വസ്തുത ഒന്ന് മാത്രം ആപ്പ്, അതിനാൽ അതിൽ തലകുനിച്ച് പോകരുത്.

ഇപ്പോൾ, ഒരു സാങ്കേതിക വീക്ഷണകോണിൽ നിന്ന്, രജിസ്ട്രേഷന് ശേഷം, ഡോക്യുമെന്റേഷൻ, പ്രോട്ടോക്കോൾ മുതലായവയിലേക്കുള്ള അപ്‌ഡേറ്റുകളെക്കുറിച്ചുള്ള ടെലിഗ്രാമിൽ നിന്ന് ഞങ്ങൾക്ക് അറിയിപ്പുകൾ ലഭിക്കുമെന്ന വസ്തുതയിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ടായിരിക്കണം. അതായത്, ഡോക്കുകളുള്ള സൈറ്റ് വെറുതെ ഉപേക്ഷിക്കുകയും ക്ലയന്റുകളെ ഉണ്ടാക്കാൻ തുടങ്ങിയവരുമായി പ്രത്യേകമായി പ്രവർത്തിക്കുകയും ചെയ്തുവെന്ന് ഒരാൾക്ക് അനുമാനിക്കാം, കാരണം അത് എളുപ്പമാണ്. പക്ഷേ ഇല്ല, അങ്ങനെയൊന്നും നിരീക്ഷിച്ചില്ല, ഒരു വിവരവും വന്നില്ല.

നിങ്ങൾ ആദ്യം മുതൽ എഴുതുകയാണെങ്കിൽ, ലഭിച്ച പാരാമീറ്ററുകൾ ഉപയോഗിക്കുന്നത് യഥാർത്ഥത്തിൽ വളരെ അകലെയാണ്. എങ്കിലും https://core.telegram.org/ ആദ്യം ആരംഭിക്കുന്നതിൽ അവയെക്കുറിച്ച് സംസാരിക്കുന്നു, വാസ്തവത്തിൽ, നിങ്ങൾ ആദ്യം നടപ്പിലാക്കേണ്ടതുണ്ട് MTPproto പ്രോട്ടോക്കോൾ - എന്നാൽ നിങ്ങൾ വിശ്വസിച്ചിരുന്നെങ്കിൽ OSI മോഡൽ അനുസരിച്ച് ലേഔട്ട് പ്രോട്ടോക്കോളിന്റെ പൊതുവായ വിവരണത്തിനായി പേജിന്റെ അവസാനം, അത് പൂർണ്ണമായും വ്യർത്ഥമാണ്.

വാസ്തവത്തിൽ, MTProto-ന് മുമ്പും ശേഷവും, ഒരേസമയം നിരവധി തലങ്ങളിൽ (OS കേർണലിൽ പ്രവർത്തിക്കുന്ന വിദേശ നെറ്റ്‌വർക്കർമാർ പറയുന്നതുപോലെ, ലെയർ ലംഘനം), വലുതും വേദനാജനകവും ഭയങ്കരവുമായ ഒരു വിഷയം വഴിയിൽ വരും...

ബൈനറി സീരിയലൈസേഷൻ: TL (ടൈപ്പ് ലാംഗ്വേജ്) അതിന്റെ സ്കീമും ലെയറുകളും കൂടാതെ മറ്റ് പല ഭയാനകമായ വാക്കുകളും

ഈ വിഷയം, വാസ്തവത്തിൽ, ടെലിഗ്രാമിന്റെ പ്രശ്നങ്ങളുടെ താക്കോലാണ്. നിങ്ങൾ അത് പരിശോധിക്കാൻ ശ്രമിച്ചാൽ ഭയങ്കരമായ ധാരാളം വാക്കുകൾ ഉണ്ടാകും.

അതിനാൽ, ഡയഗ്രം ഇതാ. ഈ വാക്ക് നിങ്ങളുടെ മനസ്സിൽ വന്നാൽ പറയുക, JSON സ്കീമ, നിങ്ങൾ ശരിയായി ചിന്തിച്ചു. ലക്ഷ്യം ഒന്നുതന്നെയാണ്: കൈമാറ്റം ചെയ്യപ്പെട്ട ഡാറ്റയുടെ ഒരു കൂട്ടം വിവരിക്കാൻ ചില ഭാഷകൾ. ഇവിടെയാണ് സമാനതകൾ അവസാനിക്കുന്നത്. പേജിൽ നിന്നാണെങ്കിൽ MTPproto പ്രോട്ടോക്കോൾ, അല്ലെങ്കിൽ ഔദ്യോഗിക ക്ലയന്റിന്റെ ഉറവിട ട്രീയിൽ നിന്ന്, ഞങ്ങൾ ചില സ്കീമ തുറക്കാൻ ശ്രമിക്കും, ഞങ്ങൾ ഇതുപോലുള്ള ഒന്ന് കാണും:

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

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

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

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

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

---functions---

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

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

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

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

ഇത് ആദ്യമായി കാണുന്ന ഒരു വ്യക്തിക്ക് എഴുതിയതിന്റെ ഒരു ഭാഗം മാത്രമേ അവബോധപൂർവ്വം തിരിച്ചറിയാൻ കഴിയൂ - ശരി, ഇവ പ്രത്യക്ഷത്തിൽ ഘടനകളാണ് (പേര് എവിടെയാണെങ്കിലും, ഇടത്തോ വലത്തോ?), അവയിൽ ഫീൽഡുകളുണ്ട്, അതിന് ശേഷം ഒരു കോളണിന് ശേഷം ഒരു തരം പിന്തുടരുന്നു... മിക്കവാറും. ഇവിടെ ആംഗിൾ ബ്രാക്കറ്റുകളിൽ C++ പോലെയുള്ള ടെംപ്ലേറ്റുകൾ ഉണ്ടാകാം (വാസ്തവത്തിൽ, തീരെയില്ല). മറ്റെല്ലാ ചിഹ്നങ്ങളും എന്താണ് അർത്ഥമാക്കുന്നത്, ചോദ്യചിഹ്നങ്ങൾ, ആശ്ചര്യചിഹ്നങ്ങൾ, ശതമാനം, ഹാഷ് മാർക്കുകൾ (വ്യത്യസ്തമായി അവ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ വ്യത്യസ്ത കാര്യങ്ങൾ അർത്ഥമാക്കുന്നു), ചിലപ്പോൾ നിലവിലുള്ളതും ചിലപ്പോൾ അല്ലാത്തതുമായ ഹെക്സാഡെസിമൽ സംഖ്യകൾ - ഏറ്റവും പ്രധാനമായി, ഇതിൽ നിന്ന് എങ്ങനെ നേടാം ശരിയാണ് (സെർവർ നിരസിക്കാത്തത്) ബൈറ്റ് സ്ട്രീം? നിങ്ങൾ ഡോക്യുമെന്റേഷൻ വായിക്കേണ്ടതുണ്ട് (അതെ, സമീപത്തുള്ള JSON പതിപ്പിൽ സ്കീമയിലേക്കുള്ള ലിങ്കുകളുണ്ട് - എന്നാൽ അത് കൂടുതൽ വ്യക്തമാക്കുന്നില്ല).

പേജ് തുറക്കുക ബൈനറി ഡാറ്റ സീരിയലൈസേഷൻ കൂടാതെ കൂണുകളുടെയും വ്യതിരിക്തമായ ഗണിതത്തിന്റെയും മാന്ത്രിക ലോകത്തേക്ക് മുങ്ങുക, 4-ാം വർഷത്തിലെ മത്തന് സമാനമായ ഒന്ന്. അക്ഷരമാല, തരം, മൂല്യം, കോമ്പിനേറ്റർ, ഫങ്ഷണൽ കോമ്പിനേറ്റർ, സാധാരണ രൂപം, സംയോജിത തരം, പോളിമോർഫിക് തരം... അതെല്ലാം ആദ്യ പേജ് മാത്രം! അടുത്തത് നിങ്ങളെ കാത്തിരിക്കുന്നു TL ഭാഷ, അതിൽ നിസാരമായ ഒരു അഭ്യർത്ഥനയുടെയും പ്രതികരണത്തിന്റെയും ഉദാഹരണം ഇതിനകം അടങ്ങിയിട്ടുണ്ടെങ്കിലും, കൂടുതൽ സാധാരണ കേസുകൾക്ക് ഉത്തരം നൽകുന്നില്ല, അതിനർത്ഥം റഷ്യൻ ഭാഷയിൽ നിന്ന് ഇംഗ്ലീഷിലേക്ക് വിവർത്തനം ചെയ്ത ഗണിതത്തിന്റെ പുനരാഖ്യാനത്തിലൂടെ നിങ്ങൾ മറ്റൊരു എട്ട് എംബഡഡ് ചെയ്യേണ്ടിവരും എന്നാണ്. പേജുകൾ!

ഫങ്ഷണൽ ഭാഷകളും ഓട്ടോമാറ്റിക് തരം അനുമാനവും പരിചയമുള്ള വായനക്കാർ തീർച്ചയായും, ഈ ഭാഷയിലെ വിവരണ ഭാഷ കാണും, ഉദാഹരണത്തിൽ നിന്ന് പോലും, കൂടുതൽ പരിചിതമാണ്, ഇത് തത്വത്തിൽ മോശമല്ലെന്ന് പറയാൻ കഴിയും. ഇതിനെതിരായ എതിർപ്പുകൾ ഇവയാണ്:

• അതെ, ലക്ഷ്യം നന്നായി തോന്നുന്നു, പക്ഷേ അയ്യോ, അവൾ നേടിയിട്ടില്ല
• റഷ്യൻ സർവ്വകലാശാലകളിലെ വിദ്യാഭ്യാസം ഐടി സ്പെഷ്യാലിറ്റികൾക്കിടയിൽ പോലും വ്യത്യാസപ്പെടുന്നു - എല്ലാവരും അനുബന്ധ കോഴ്സ് എടുത്തിട്ടില്ല
• അവസാനമായി, നമ്മൾ കാണുന്നതുപോലെ, അത് പ്രായോഗികമാണ് ആവശ്യമില്ല, കാരണം വിവരിച്ച TL-ന്റെ പരിമിതമായ ഉപവിഭാഗം മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ

പറഞ്ഞതുപോലെ ലിയോനേർഡ് ചാനലിൽ #perl ഫ്രീനോഡ് ഐആർസി നെറ്റ്‌വർക്കിൽ, ടെലിഗ്രാമിൽ നിന്ന് മാട്രിക്‌സിലേക്കുള്ള ഒരു ഗേറ്റ് നടപ്പിലാക്കാൻ ശ്രമിച്ചത് (ഉദ്ധരണിയുടെ വിവർത്തനം മെമ്മറിയിൽ നിന്ന് കൃത്യമല്ല):

ആരോ ആദ്യമായി തിയറി ടൈപ്പ് ചെയ്യാൻ പരിചയപ്പെടുത്തി, ആവേശഭരിതനായി, പ്രായോഗികമായി ഇത് ആവശ്യമാണോ എന്ന് ശരിക്കും ശ്രദ്ധിക്കാതെ, അത് ഉപയോഗിച്ച് കളിക്കാൻ തുടങ്ങി.

പ്രാഥമികമായ ഒന്നായി ബെയർ-ടൈപ്പുകൾ (ഇന്റ്, ലോംഗ്, മുതലായവ) ആവശ്യം ചോദ്യങ്ങൾ ഉന്നയിക്കുന്നില്ലെങ്കിൽ - ആത്യന്തികമായി അവ സ്വമേധയാ നടപ്പിലാക്കണം - ഉദാഹരണത്തിന്, അവയിൽ നിന്ന് ഉരുത്തിരിഞ്ഞുവരാൻ നമുക്ക് ഒരു ശ്രമം നടത്താം. വെക്റ്റർ. അതായത്, വാസ്തവത്തിൽ, അറേ, തത്ഫലമായുണ്ടാകുന്ന വസ്തുക്കളെ അവയുടെ ശരിയായ പേരുകളിൽ നിങ്ങൾ വിളിക്കുകയാണെങ്കിൽ.

എന്നാൽ മുമ്പ്

ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ വായിക്കാത്തവർക്കുള്ള 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;

നിർവചനം എപ്പോഴും ആരംഭിക്കുന്നു കൺ‌സ്‌ട്രക്റ്റർ‌, അതിനുശേഷം ഐച്ഛികമായി (പ്രായോഗികമായി - എപ്പോഴും) ചിഹ്നത്തിലൂടെ # ആയിരിക്കണം ച്ര്ച്ക്സനുമ്ക്സ ഈ തരത്തിലുള്ള നോർമലൈസ് ചെയ്ത വിവരണ സ്ട്രിംഗിൽ നിന്ന്. അടുത്തതായി ഫീൽഡുകളുടെ ഒരു വിവരണം വരുന്നു; അവ നിലവിലുണ്ടെങ്കിൽ, തരം ശൂന്യമായിരിക്കാം. ഇതെല്ലാം ഒരു തുല്യ ചിഹ്നത്തോടെ അവസാനിക്കുന്നു, ഈ കൺസ്ട്രക്റ്റർ ഏത് തരത്തിലുള്ള പേരിലാണ് - അതായത്, ഉപവിഭാഗം -. തുല്യ ചിഹ്നത്തിന്റെ വലതുവശത്തുള്ള ആളാണ് ബഹുരൂപം - അതായത്, നിരവധി നിർദ്ദിഷ്ട തരങ്ങൾ അതിനോട് പൊരുത്തപ്പെടാം.

വരിക്ക് ശേഷം നിർവചനം സംഭവിക്കുകയാണെങ്കിൽ ---functions---, അപ്പോൾ വാക്യഘടന അതേപടി നിലനിൽക്കും, പക്ഷേ അർത്ഥം വ്യത്യസ്തമായിരിക്കും: കൺസ്ട്രക്റ്റർ ആർപിസി ഫംഗ്ഷന്റെ പേരായി മാറും, ഫീൽഡുകൾ പാരാമീറ്ററുകളായി മാറും (നന്നായി, അതായത്, ചുവടെ വിവരിച്ചിരിക്കുന്നതുപോലെ ഇത് നൽകിയിരിക്കുന്ന ഘടനയിൽ തന്നെ തുടരും. , ഇത് കേവലം നിയുക്ത അർത്ഥം ആയിരിക്കും), കൂടാതെ "പോളിമോർഫിക് തരം" - ലഭിച്ച ഫലത്തിന്റെ തരം. ശരിയാണ്, അത് ഇപ്പോഴും പോളിമോർഫിക്കായി തുടരും - വിഭാഗത്തിൽ നിർവചിച്ചിരിക്കുന്നു ---types---, എന്നാൽ ഈ കൺസ്ട്രക്റ്റർ "പരിഗണിക്കില്ല". വിളിക്കപ്പെടുന്ന ഫംഗ്‌ഷനുകളുടെ തരങ്ങളെ അവയുടെ ആർഗ്യുമെന്റുകൾ ഉപയോഗിച്ച് ഓവർലോഡ് ചെയ്യുന്നു, അതായത്. ചില കാരണങ്ങളാൽ, C++-ൽ ഉള്ളത് പോലെ ഒരേ പേരിലുള്ളതും എന്നാൽ വ്യത്യസ്ത ഒപ്പുകളുള്ളതുമായ നിരവധി ഫംഗ്‌ഷനുകൾ TL-ൽ നൽകിയിട്ടില്ല.

OOP അല്ലെങ്കിൽ എന്തുകൊണ്ട് "കൺസ്‌ട്രക്‌റ്റർ", "പോളിമോർഫിക്"? ശരി, വാസ്തവത്തിൽ, ആർക്കെങ്കിലും ഇതിനെക്കുറിച്ച് OOP പദങ്ങളിൽ ചിന്തിക്കുന്നത് എളുപ്പമായിരിക്കും - ഒരു അമൂർത്ത ക്ലാസ് എന്ന നിലയിൽ ഒരു പോളിമോർഫിക് തരം, കൂടാതെ കൺസ്ട്രക്‌ടർമാർ അതിന്റെ നേരിട്ടുള്ള പിൻഗാമി ക്ലാസുകളാണ്, കൂടാതെ final നിരവധി ഭാഷകളുടെ പദാവലിയിൽ. വാസ്തവത്തിൽ, തീർച്ചയായും, ഇവിടെ മാത്രം സാമ്യം OO പ്രോഗ്രാമിംഗ് ഭാഷകളിലെ യഥാർത്ഥ ഓവർലോഡഡ് കൺസ്ട്രക്റ്റർ രീതികൾക്കൊപ്പം. ഇവിടെ ഡാറ്റാ ഘടനകൾ മാത്രമായതിനാൽ, രീതികളൊന്നുമില്ല (ഫംഗ്ഷനുകളുടെയും രീതികളുടെയും വിവരണത്തിന് അവ ഉണ്ടെന്ന് തലയിൽ ആശയക്കുഴപ്പം സൃഷ്ടിക്കാൻ കഴിയുമെങ്കിലും, അത് മറ്റൊരു കാര്യമാണ്) - നിങ്ങൾക്ക് ഒരു കൺസ്ട്രക്റ്ററിനെ മൂല്യമായി കണക്കാക്കാം. ഏത് നിർമ്മിക്കുന്നു ഒരു ബൈറ്റ് സ്ട്രീം വായിക്കുമ്പോൾ ടൈപ്പ് ചെയ്യുക.

ഇത് എങ്ങനെ സംഭവിക്കുന്നു? എപ്പോഴും 4 ബൈറ്റുകൾ വായിക്കുന്ന ഡിസീരിയലൈസർ മൂല്യം കാണുന്നു 0xcrc32 - അടുത്തതായി എന്ത് സംഭവിക്കുമെന്ന് മനസ്സിലാക്കുന്നു field1 തരം ഉപയോഗിച്ച് int, അതായത്. കൃത്യമായി 4 ബൈറ്റുകൾ വായിക്കുന്നു, ഇതിൽ തരത്തോടുകൂടിയ ഓവർലൈയിംഗ് ഫീൽഡ് PolymorType വായിച്ചു. കാണുന്നു 0x2crc32 കൂടാതെ രണ്ട് ഫീൽഡുകൾ കൂടി ഉണ്ടെന്ന് മനസ്സിലാക്കുന്നു, ആദ്യം long, അതായത് നമ്മൾ 8 ബൈറ്റുകൾ വായിക്കുന്നു. തുടർന്ന് വീണ്ടും ഒരു സങ്കീർണ്ണ തരം, അത് അതേ രീതിയിൽ ഡീസിയലൈസ് ചെയ്യുന്നു. ഉദാഹരണത്തിന്, 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 ഒപ്പം , തത്ഫലമായി, സീരിയലൈസേഷൻ. പുതിയ ഫ്ലാഗുകൾ സജ്ജീകരിച്ച ഒരു ഫീൽഡ് ലഭിക്കുകയും അവയുമായി അടുത്തതായി എന്തുചെയ്യണമെന്ന് അവനറിയില്ലെങ്കിൽ പഴയ ക്ലയന്റ് എന്തുചെയ്യും?..

രണ്ടാമതായി, നമുക്ക് ഓർക്കാം ച്ര്ച്ക്സനുമ്ക്സ, ഇവിടെ പ്രധാനമായും ഉപയോഗിക്കുന്നത് ഹാഷ് ഫംഗ്ഷനുകൾ ഏത് തരം (ഡീ)സീരിയലൈസ് ചെയ്യപ്പെടുന്നുവെന്ന് അദ്വിതീയമായി നിർണ്ണയിക്കാൻ. ഇവിടെ നമ്മൾ കൂട്ടിയിടികളുടെ പ്രശ്നത്തെ അഭിമുഖീകരിക്കുന്നു - അല്ല, സംഭാവ്യത 232-ൽ ഒന്നല്ല, മറിച്ച് വളരെ വലുതാണ്. ആശയവിനിമയ ചാനലിലെ പിശകുകൾ കണ്ടെത്തുന്നതിനും (ശരിയാക്കുന്നതിനും) സിആർസി 32 രൂപകൽപ്പന ചെയ്‌തിട്ടുണ്ടെന്നും അതിനനുസരിച്ച് ഈ ഗുണങ്ങൾ മറ്റുള്ളവർക്ക് ദോഷകരമായി മെച്ചപ്പെടുത്തുന്നുവെന്നും ആരാണ് ഓർത്തത്? ഉദാഹരണത്തിന്, ബൈറ്റുകൾ പുനഃക്രമീകരിക്കുന്നതിനെക്കുറിച്ച് ഇത് ശ്രദ്ധിക്കുന്നില്ല: നിങ്ങൾ രണ്ട് വരികളിൽ നിന്ന് 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 - പക്ഷേ ഒരിടത്തുമില്ല ഈ നിർവചനം തന്നെ ആദ്യത്തെ സംഖ്യ വെക്റ്ററിന്റെ നീളത്തിന് തുല്യമായിരിക്കണം എന്ന് പറയുന്നില്ല! മാത്രമല്ല അത് എവിടെ നിന്നും വരുന്നില്ല. ഇത് മനസ്സിൽ സൂക്ഷിക്കുകയും നിങ്ങളുടെ കൈകൊണ്ട് നടപ്പിലാക്കുകയും ചെയ്യേണ്ട ഒരു ദാനമാണ്. മറ്റൊരിടത്ത്, ഡോക്യുമെന്റേഷൻ സത്യസന്ധമായി പോലും ഈ തരം യഥാർത്ഥമല്ലെന്ന് പരാമർശിക്കുന്നു:

വെക്റ്റർ ടി പോളിമോർഫിക് സ്യൂഡോടൈപ്പ് എന്നത് ഒരു "തരം" ആണ്, അതിന്റെ മൂല്യം ബോക്‌സ് ചെയ്‌തതോ നഗ്നമായതോ ആയ ഏതെങ്കിലും തരത്തിലുള്ള ടി മൂല്യങ്ങളുടെ ഒരു ശ്രേണിയാണ്.

... പക്ഷെ അതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നില്ല. ഗണിതശാസ്ത്രത്തിന്റെ നീട്ടലിലൂടെ മടുത്ത നിങ്ങൾ (ഒരു യൂണിവേഴ്സിറ്റി കോഴ്സിൽ നിന്ന് പോലും നിങ്ങൾക്ക് അറിയാമായിരിക്കും) ഉപേക്ഷിക്കാൻ തീരുമാനിക്കുകയും പ്രായോഗികമായി ഇത് എങ്ങനെ പ്രവർത്തിക്കാമെന്ന് നോക്കുകയും ചെയ്യുമ്പോൾ, നിങ്ങളുടെ തലയിൽ അവശേഷിക്കുന്ന ധാരണ ഇത് ഗുരുതരമാണ് എന്നതാണ്. ഗണിതം കാമ്പിൽ, അത് വ്യക്തമായി കണ്ടുപിടിച്ചത് കൂൾ പീപ്പിൾ (രണ്ട് ഗണിതശാസ്ത്രജ്ഞർ - ACM വിജയി), മാത്രമല്ല ആരും മാത്രമല്ല. ലക്ഷ്യം - കാണിക്കുക - നേടിയിരിക്കുന്നു.

വഴിയിൽ, നമ്പറിനെക്കുറിച്ച്. അത് നമുക്ക് ഓർമ്മിപ്പിക്കാം # അതൊരു പര്യായമാണ് nat, സ്വാഭാവിക സംഖ്യ:

ടൈപ്പ് എക്സ്പ്രഷനുകൾ ഉണ്ട് (type-expr) കൂടാതെ സംഖ്യാ പദപ്രയോഗങ്ങളും (nat-expr). എന്നിരുന്നാലും, അവ അതേ രീതിയിൽ നിർവചിച്ചിരിക്കുന്നു.

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

എന്നാൽ വ്യാകരണത്തിൽ അവ അതേ രീതിയിൽ വിവരിച്ചിരിക്കുന്നു, അതായത്. ഈ വ്യത്യാസം വീണ്ടും ഓർമ്മിക്കുകയും സ്വമേധയാ നടപ്പിലാക്കുകയും വേണം.

ശരി, അതെ, ടെംപ്ലേറ്റ് തരങ്ങൾ (vector<int>, vector<User>) ഒരു പൊതു ഐഡന്റിഫയർ ഉണ്ട് (#1cb5c415), അതായത്. കോൾ പ്രഖ്യാപിച്ചതായി നിങ്ങൾക്കറിയാമെങ്കിൽ

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

അപ്പോൾ നിങ്ങൾ ഒരു വെക്‌ടറിനായി കാത്തിരിക്കുകയല്ല, ഉപയോക്താക്കളുടെ വെക്‌ടറാണ്. കൂടുതൽ കൃത്യമായി, ചെയ്യണം കാത്തിരിക്കുക - യഥാർത്ഥ കോഡിൽ, ഓരോ ഘടകത്തിനും, നഗ്നമായ തരമല്ലെങ്കിൽ, ഒരു കൺസ്ട്രക്റ്റർ ഉണ്ടായിരിക്കും, കൂടാതെ നല്ല രീതിയിൽ നടപ്പിലാക്കുമ്പോൾ അത് പരിശോധിക്കേണ്ടതുണ്ട് - എന്നാൽ ഈ വെക്റ്ററിന്റെ എല്ലാ ഘടകങ്ങളിലും ഞങ്ങൾ കൃത്യമായി അയച്ചിട്ടുണ്ട് ആ തരം? വ്യത്യസ്‌ത ഘടകങ്ങളിൽ വ്യത്യസ്‌ത തരങ്ങൾ ഉൾക്കൊള്ളാൻ കഴിയുന്ന ഒരു അറേയ്‌ക്ക് ഏതെങ്കിലും തരത്തിലുള്ള PHP ആണെങ്കിലോ?

ഈ ഘട്ടത്തിൽ നിങ്ങൾ ചിന്തിക്കാൻ തുടങ്ങുന്നു - അത്തരമൊരു ടിഎൽ ആവശ്യമാണോ? ഒരുപക്ഷേ വണ്ടിക്ക് ഒരു ഹ്യൂമൻ സീരിയലൈസർ ഉപയോഗിക്കാൻ കഴിയുമോ, അപ്പോഴുണ്ടായിരുന്ന അതേ പ്രോട്ടോബഫ്? അതായിരുന്നു സിദ്ധാന്തം, നമുക്ക് പ്രാക്ടീസ് നോക്കാം.

കോഡിൽ നിലവിലുള്ള TL നടപ്പിലാക്കലുകൾ

ദുറോവിന്റെ ഓഹരി വിൽപ്പനയ്‌ക്കൊപ്പം പ്രസിദ്ധമായ സംഭവങ്ങൾക്ക് മുമ്പുതന്നെ VKontakte യുടെ ആഴത്തിലാണ് ടിഎൽ ജനിച്ചത്.തീർച്ചയായും), ടെലിഗ്രാമിന്റെ വികസനം ആരംഭിക്കുന്നതിന് മുമ്പുതന്നെ. കൂടാതെ ഓപ്പൺ സോഴ്സിലും ആദ്യ നടപ്പാക്കലിന്റെ സോഴ്സ് കോഡ് നിങ്ങൾക്ക് ധാരാളം തമാശയുള്ള ഊന്നുവടികൾ കണ്ടെത്താൻ കഴിയും. ടെലിഗ്രാമിൽ ഇപ്പോൾ ഉള്ളതിനേക്കാൾ പൂർണ്ണമായി ഭാഷ തന്നെ അവിടെ നടപ്പിലാക്കി. ഉദാഹരണത്തിന്, സ്കീമിൽ ഹാഷുകൾ ഉപയോഗിക്കില്ല (വ്യതിചലിക്കുന്ന സ്വഭാവമുള്ള ഒരു ബിൽറ്റ്-ഇൻ സ്യൂഡോടൈപ്പ് (ഒരു വെക്റ്റർ പോലെ) എന്നാണ് അർത്ഥമാക്കുന്നത്). അഥവാ

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] എല്ലാറ്റിനുമുപരിയായി, കഴുത ചൂടാണ്, കാരണം അവർ ഒരു കൂട്ടം അമൂർത്തതകൾ സൃഷ്ടിച്ചു, തുടർന്ന് അവയിൽ ഒരു ബോൾട്ട് അടിച്ചു, കോഡ് ജനറേറ്ററിനെ ഊന്നുവടികൾ കൊണ്ട് മറച്ചു.
ഫലമായി, ആദ്യം ഡോക്ക് pilot.jpg-ൽ നിന്ന്
തുടർന്ന് dzhekichan.webp എന്ന കോഡിൽ നിന്ന്

തീർച്ചയായും, അൽഗോരിതങ്ങളും ഗണിതവും പരിചയമുള്ള ആളുകളിൽ നിന്ന്, അവർ Aho, Ullmann എന്നിവ വായിച്ചിട്ടുണ്ടെന്നും അവരുടെ DSL കംപൈലറുകൾ എഴുതുന്നതിനായി ദശാബ്ദങ്ങളായി വ്യവസായത്തിൽ യഥാർത്ഥ നിലവാരമായി മാറിയ ഉപകരണങ്ങളുമായി പരിചിതരാണെന്നും നമുക്ക് പ്രതീക്ഷിക്കാം, അല്ലേ?

എഴുതിയത് ടെലിഗ്രാം-ക്ലി വിറ്റാലി വാൾട്ട്മാൻ ആണ്, TLO ഫോർമാറ്റ് അതിന്റെ (cli) അതിരുകൾക്ക് പുറത്ത് സംഭവിച്ചതിൽ നിന്ന് മനസ്സിലാക്കാം, ടീമിലെ ഒരു അംഗം - ഇപ്പോൾ TL പാഴ്‌സിംഗിനായി ഒരു ലൈബ്രറി അനുവദിച്ചിരിക്കുന്നു പ്രത്യേകം, അവളുടെ മതിപ്പ് എന്താണ് TL പാഴ്സർ? ..

16.12 04:18 വാസിലി: ആരെങ്കിലും lex+yacc-ൽ പ്രാവീണ്യം നേടിയിട്ടില്ലെന്ന് ഞാൻ കരുതുന്നു
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+ വരികൾ, രണ്ട് പതിവ് എക്‌സ്‌പ്രഷനുകൾ + വെക്റ്റർ പോലുള്ള പ്രത്യേക കേസുകൾ, ഇത് തീർച്ചയായും ടിഎൽ വാക്യഘടന അനുസരിച്ച് സ്കീമിൽ പ്രഖ്യാപിച്ചിട്ടുണ്ട്, പക്ഷേ അത് പാഴ്‌സ് ചെയ്യാൻ അവർ ഈ വാക്യഘടനയെ ആശ്രയിച്ചു... ചോദ്യം ഉയരുന്നു, എന്തുകൊണ്ടാണ് ഇതെല്ലാം ഒരു അത്ഭുതം?иഎന്തായാലും ഡോക്യുമെന്റേഷൻ അനുസരിച്ച് ആരും ഇത് പാഴ്‌സ് ചെയ്യാൻ പോകുന്നില്ലെങ്കിൽ ഇത് കൂടുതൽ പാളിയാണോ?!

പറയട്ടെ... CRC32 ചെക്കിങ്ങിനെക്കുറിച്ച് നമ്മൾ സംസാരിച്ചത് ഓർക്കുന്നുണ്ടോ? അതിനാൽ, ടെലിഗ്രാം ഡെസ്ക്ടോപ്പ് കോഡ് ജനറേറ്ററിൽ CRC32 കണക്കാക്കിയ തരങ്ങൾക്കുള്ള ഒഴിവാക്കലുകളുടെ ഒരു ലിസ്റ്റ് ഉണ്ട്. ചേരുന്നില്ല ഡയഗ്രാമിൽ സൂചിപ്പിച്ചിരിക്കുന്ന ഒന്നിനൊപ്പം!

Vasily, [18.12/22 49:XNUMX] ഇവിടെ ഞാൻ ചിന്തിക്കും അങ്ങനെയൊരു TL ആവശ്യമുണ്ടോ എന്ന്
ഇതര നിർവ്വഹണങ്ങളിൽ കുഴപ്പമുണ്ടാക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞാൻ ലൈൻ ബ്രേക്കുകൾ ചേർക്കാൻ തുടങ്ങും, പാഴ്സറുകളിൽ പകുതിയും മൾട്ടി-ലൈൻ നിർവചനങ്ങളിൽ തകരും
tdesktop, എന്നിരുന്നാലും

വൺ-ലൈനറിനെക്കുറിച്ചുള്ള കാര്യം ഓർക്കുക, കുറച്ച് കഴിഞ്ഞ് ഞങ്ങൾ അതിലേക്ക് മടങ്ങും.

ശരി, ടെലിഗ്രാം-ക്ലി അനൗദ്യോഗികമാണ്, ടെലിഗ്രാം ഡെസ്ക്ടോപ്പ് ഔദ്യോഗികമാണ്, എന്നാൽ മറ്റുള്ളവയുടെ കാര്യമോ? ആർക്കറിയാം?.. ആൻഡ്രോയിഡ് ക്ലയന്റ് കോഡിൽ സ്കീമ പാഴ്‌സർ ഒന്നുമില്ല (ഇത് ഓപ്പൺ സോഴ്‌സിനെക്കുറിച്ചുള്ള ചോദ്യങ്ങൾ ഉയർത്തുന്നു, പക്ഷേ ഇത് രണ്ടാം ഭാഗത്തിനുള്ളതാണ്), എന്നാൽ മറ്റ് രസകരമായ നിരവധി കോഡ് കഷണങ്ങൾ ഉണ്ടായിരുന്നു, എന്നാൽ അവയിൽ കൂടുതൽ താഴെ ഉപവിഭാഗം.

സീരിയലൈസേഷൻ പ്രായോഗികമായി മറ്റ് എന്ത് ചോദ്യങ്ങൾ ഉയർത്തുന്നു? ഉദാഹരണത്തിന്, അവർ ധാരാളം കാര്യങ്ങൾ ചെയ്തു, തീർച്ചയായും, ബിറ്റ് ഫീൽഡുകളും സോപാധിക ഫീൽഡുകളും ഉപയോഗിച്ച്:

വാസിലി: flags.0? true
ഫീൽഡ് നിലവിലുണ്ടെന്നും പതാക സജ്ജമാക്കിയാൽ ശരിയാണെന്നും അർത്ഥമാക്കുന്നു

വാസിലി: flags.1? int
ഫീൽഡ് നിലവിലുണ്ടെന്നും അത് ഡീരിയലൈസ് ചെയ്യേണ്ടതുണ്ടെന്നും അർത്ഥമാക്കുന്നു

വാസിലി: കഴുത, നിങ്ങൾ ചെയ്യുന്നതിനെക്കുറിച്ച് വിഷമിക്കേണ്ട!
വാസിലി: സത്യമെന്നത് വെറും പൂജ്യം നീളമുള്ള തരമാണെന്ന് പ്രമാണത്തിൽ എവിടെയോ പരാമർശമുണ്ട്, പക്ഷേ അവരുടെ ഡോക്‌സിൽ നിന്ന് ഒന്നും കൂട്ടിച്ചേർക്കുക അസാധ്യമാണ്
വാസിലി: ഓപ്പൺ സോഴ്‌സ് നടപ്പിലാക്കലുകളിൽ ഇത് അങ്ങനെയല്ല, പക്ഷേ ഒരു കൂട്ടം ക്രച്ചുകളും പിന്തുണകളും ഉണ്ട്

ടെലിത്തണിന്റെ കാര്യമോ? MTPproto എന്ന വിഷയത്തിലേക്ക് നോക്കുമ്പോൾ, ഒരു ഉദാഹരണം - ഡോക്യുമെന്റേഷനിൽ അത്തരം ഭാഗങ്ങളുണ്ട്, പക്ഷേ അടയാളം % അത് "ഒരു നഗ്നമായ തരവുമായി ബന്ധപ്പെട്ടത്" എന്ന് മാത്രമേ വിവരിച്ചിട്ടുള്ളൂ, അതായത്. ചുവടെയുള്ള ഉദാഹരണങ്ങളിൽ ഒരു പിശക് അല്ലെങ്കിൽ രേഖപ്പെടുത്താത്ത എന്തെങ്കിലും ഉണ്ട്:

വാസിലി, [22.06.18 18:38] ഒരിടത്ത്:

msg_container#73f1f8dc messages:vector message = MessageContainer;

മറ്റൊരു രീതിയിൽ:

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

ഇവ രണ്ട് വലിയ വ്യത്യാസങ്ങളാണ്, യഥാർത്ഥ ജീവിതത്തിൽ ഒരുതരം നഗ്ന വെക്റ്റർ വരുന്നു

ഞാൻ വെക്റ്റർ നിർവചനം കണ്ടിട്ടില്ല, അതൊന്നും കണ്ടിട്ടില്ല

ടെലിത്തണിൽ കൈകൊണ്ട് വിശകലനം എഴുതിയിരിക്കുന്നു

അദ്ദേഹത്തിന്റെ ഡയഗ്രാമിൽ നിർവചനം അഭിപ്രായപ്പെട്ടു msg_container

വീണ്ടും, ചോദ്യം ഏകദേശം% അവശേഷിക്കുന്നു. അത് വിവരിച്ചിട്ടില്ല.

വാഡിം ഗോഞ്ചറോവ്, [22.06.18 19:22] കൂടാതെ ടിഡെസ്‌ക്‌ടോപ്പിലും?

Vasily, [22.06.18 19:23] എന്നാൽ സാധാരണ എഞ്ചിനുകളിലെ അവരുടെ TL പാഴ്സർ മിക്കവാറും ഇതും കഴിക്കില്ല.

// parsed manually

TL ഒരു മനോഹരമായ സംഗ്രഹമാണ്, ആരും അത് പൂർണ്ണമായും നടപ്പിലാക്കുന്നില്ല

കൂടാതെ % അവരുടെ സ്കീമിന്റെ പതിപ്പിലില്ല

എന്നാൽ ഇവിടെ ഡോക്യുമെന്റേഷൻ തന്നെ വിരുദ്ധമാണ്, അതിനാൽ idk

ഇത് വ്യാകരണത്തിൽ കണ്ടെത്തി, അർത്ഥശാസ്ത്രം വിവരിക്കാൻ അവർക്ക് മറക്കാമായിരുന്നു

നിങ്ങൾ 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 MB-യിൽ കൂടുതലാണെങ്കിൽ upload.saveFilePart ചെറിയ ഫയലുകൾക്കായി.
[…] ഇനിപ്പറയുന്ന ഡാറ്റ ഇൻപുട്ട് പിശകുകളിലൊന്ന് നൽകാം:

• FILE_PARTS_INVALID — ഭാഗങ്ങളുടെ എണ്ണം അസാധുവാണ്. മൂല്യം തമ്മിലുള്ളതല്ല 1..3000

ഇതിലേതെങ്കിലും ഡയഗ്രാമിലുണ്ടോ? ഇത് എങ്ങനെയെങ്കിലും TL ഉപയോഗിച്ച് പ്രകടിപ്പിക്കാനാകുമോ? ഇല്ല. പക്ഷേ ക്ഷമിക്കണം, മുത്തച്ഛന്റെ ടർബോ പാസ്കലിന് പോലും വ്യക്തമാക്കിയ തരങ്ങൾ വിവരിക്കാൻ കഴിഞ്ഞു ശ്രേണികൾ. കൂടാതെ ഒരു കാര്യം കൂടി അവനറിയാമായിരുന്നു, ഇപ്പോൾ അറിയപ്പെടുന്നത് enum - ഒരു നിശ്ചിത (ചെറിയ) മൂല്യങ്ങളുടെ ഒരു കണക്ക് ഉൾക്കൊള്ളുന്ന ഒരു തരം. സി - ന്യൂമെറിക് പോലുള്ള ഭാഷകളിൽ, ഞങ്ങൾ ഇതുവരെ തരങ്ങളെക്കുറിച്ച് മാത്രമാണ് സംസാരിച്ചത് സംഖ്യകൾ. എന്നാൽ അറേകളും സ്ട്രിംഗുകളും ഉണ്ട്... ഉദാഹരണത്തിന്, ഈ സ്ട്രിംഗിൽ ഒരു ഫോൺ നമ്പർ മാത്രമേ ഉൾക്കൊള്ളാൻ കഴിയൂ എന്ന് വിവരിക്കുന്നത് നന്നായിരിക്കും, അല്ലേ?

ഇതൊന്നും TL-ൽ ഇല്ല. പക്ഷേ, ഉദാഹരണത്തിന്, JSON സ്കീമയിൽ ഉണ്ട്. 512 KB യുടെ ഡിവിസിബിലിറ്റിയെക്കുറിച്ച് മറ്റൊരാൾ വാദിച്ചാൽ, ഇത് ഇപ്പോഴും കോഡിൽ പരിശോധിക്കേണ്ടതുണ്ട്, തുടർന്ന് ക്ലയന്റ് ലളിതമായി ഉറപ്പാക്കുക കഴിഞ്ഞില്ല പരിധിക്ക് പുറത്ത് ഒരു നമ്പർ അയയ്ക്കുക 1..3000 (അനുബന്ധ പിശക് ഉണ്ടാകുമായിരുന്നില്ല) അത് സാധ്യമാകുമായിരുന്നു, അല്ലേ?..

വഴിയിൽ, പിശകുകളെക്കുറിച്ചും റിട്ടേൺ മൂല്യങ്ങളെക്കുറിച്ചും. TL-ൽ ജോലി ചെയ്തിട്ടുള്ളവർ പോലും അവരുടെ കണ്ണുകൾ മങ്ങുന്നു - അത് ഞങ്ങൾക്ക് പെട്ടെന്ന് മനസ്സിലായില്ല ഓരോന്നും TL-ലെ ഒരു ഫംഗ്‌ഷന് യഥാർത്ഥത്തിൽ വിവരിച്ച റിട്ടേൺ തരം മാത്രമല്ല, ഒരു പിശകും നൽകാം. എന്നാൽ ഇത് TL തന്നെ ഉപയോഗിച്ച് ഒരു തരത്തിലും ഊഹിക്കാൻ കഴിയില്ല. തീർച്ചയായും, ഇത് ഇതിനകം തന്നെ വ്യക്തമാണ്, പ്രായോഗികമായി ഒന്നും ആവശ്യമില്ല (വാസ്തവത്തിൽ, ആർ‌പി‌സി വ്യത്യസ്ത രീതികളിൽ ചെയ്യാമെങ്കിലും, ഞങ്ങൾ ഇതിലേക്ക് മടങ്ങാം) - എന്നാൽ അമൂർത്ത തരങ്ങളുടെ ഗണിതശാസ്ത്രത്തിന്റെ ആശയങ്ങളുടെ ശുദ്ധിയെ സംബന്ധിച്ചെന്ത് സ്വർഗ്ഗീയ ലോകത്തിൽ നിന്നോ?.. ഞാൻ ടഗ്ഗ് എടുത്തു - അത് പൊരുത്തപ്പെടുത്തുക

അവസാനമായി, വായനാക്ഷമതയെക്കുറിച്ച്? ശരി, അവിടെ, പൊതുവേ, ഞാൻ ആഗ്രഹിക്കുന്നു വിവരണം ഇത് സ്കീമയിൽ ശരിയുണ്ടോ (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 തരം ആവശ്യമാണ്. സംയോജിത സ്ഫോടനം. അങ്ങനെ, സീരിയലൈസേഷന്റെ കഠിനമായ യാഥാർത്ഥ്യത്തിന്റെ കാസ്റ്റ്-ഇരുമ്പ് കഴുതക്കെതിരെ ടിഎൽ സിദ്ധാന്തത്തിന്റെ സ്ഫടിക ശുദ്ധി വീണ്ടും തകർന്നു.

കൂടാതെ, ചില സ്ഥലങ്ങളിൽ ഈ ആളുകൾ തന്നെ സ്വന്തം ടൈപ്പോളജി ലംഘിക്കുന്നു. ഉദാഹരണത്തിന്, 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 കോളിനും മുമ്പായി, മൂല്യമുള്ള ഒരു int എന്നാണ് 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 ലെയറുകൾക്ക് ശേഷം, ഒരു പതിപ്പ് നമ്പറുള്ള ഒരു സാർവത്രിക കൺസ്ട്രക്റ്റർ അവസാനം ചേർത്തു, കണക്ഷന്റെ തുടക്കത്തിൽ ഒരു തവണ മാത്രമേ വിളിക്കാവൂ, ലെയറുകളുടെ അർത്ഥം അപ്രത്യക്ഷമായതായി തോന്നുന്നു, ഇപ്പോൾ ഇത് ഒരു സോപാധിക പതിപ്പ് മാത്രമാണ്. മറ്റെല്ലായിടത്തും. പ്രശ്നം പരിഹരിച്ചു.

കൃത്യമായി?..

വാസിലി, [16.07.18 14:01] വെള്ളിയാഴ്ച പോലും ഞാൻ ചിന്തിച്ചു:
ടെലിസെർവർ ഒരു അഭ്യർത്ഥന കൂടാതെ ഇവന്റുകൾ അയയ്ക്കുന്നു. അഭ്യർത്ഥനകൾ ഇൻവോക്ക് വിത്ത് ലെയറിൽ പൊതിഞ്ഞിരിക്കണം. സെർവർ അപ്‌ഡേറ്റുകൾ പൊതിയുന്നില്ല; പ്രതികരണങ്ങളും അപ്‌ഡേറ്റുകളും പൊതിയുന്നതിനുള്ള ഒരു ഘടനയും ഇല്ല.

ആ. ക്ലയന്റിന് അപ്‌ഡേറ്റുകൾ ആവശ്യമുള്ള ലെയർ വ്യക്തമാക്കാൻ കഴിയില്ല

വാഡിം ഗോഞ്ചറോവ്, [16.07.18 14:02] തത്വത്തിൽ InvokeWithLayer ഒരു ഊന്നുവടി അല്ലേ?

Vasily, [16.07.18 14:02] ഇതാണ് ഏക വഴി

വാഡിം ഗോഞ്ചറോവ്, [16.07.18 14:02] സെഷന്റെ തുടക്കത്തിൽ ലെയറിനോട് യോജിക്കുന്നു എന്നാണ് ഇതിനർത്ഥം.

വഴിയിൽ, ക്ലയന്റ് ഡൗൺഗ്രേഡ് നൽകിയിട്ടില്ലെന്ന് ഇത് പിന്തുടരുന്നു

അപ്ഡേറ്റുകൾ, അതായത്. തരം 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-യിൽ വായിച്ചു…

അനൗദ്യോഗിക ക്ലയന്റുകളിൽ ഒരാൾക്ക് സമാനമായ ഒരു പ്രശ്നം ഇതിനകം സംഭവിച്ചിട്ടുണ്ടെന്ന് Google കാണിച്ചു, എന്നാൽ പതിപ്പ് നമ്പറുകളും അതനുസരിച്ച്, അനുമാനങ്ങളും വ്യത്യസ്തമായിരുന്നു ...

അപ്പോൾ നമ്മൾ എന്താണ് ചെയ്യേണ്ടത്? വാസിലിയും ഞാനും പിരിഞ്ഞു: അവൻ സർക്യൂട്ട് 91 ലേക്ക് അപ്‌ഡേറ്റ് ചെയ്യാൻ ശ്രമിച്ചു, കുറച്ച് ദിവസം കാത്തിരുന്ന് 73-ൽ ശ്രമിക്കാൻ ഞാൻ തീരുമാനിച്ചു. രണ്ട് രീതികളും പ്രവർത്തിച്ചു, പക്ഷേ അവ അനുഭവപരമായതിനാൽ, നിങ്ങൾക്ക് എത്ര പതിപ്പുകൾ മുകളിലേക്കും താഴേക്കും ആവശ്യമാണെന്ന് ഒരു ധാരണയുമില്ല. ചാടാൻ, അല്ലെങ്കിൽ എത്ര സമയം കാത്തിരിക്കണം.

പിന്നീട് എനിക്ക് സാഹചര്യം പുനർനിർമ്മിക്കാൻ കഴിഞ്ഞു: ഞങ്ങൾ ക്ലയന്റ് സമാരംഭിക്കുക, അത് ഓഫ് ചെയ്യുക, സർക്യൂട്ട് മറ്റൊരു ലെയറിലേക്ക് വീണ്ടും കംപൈൽ ചെയ്യുക, പുനരാരംഭിക്കുക, പ്രശ്നം വീണ്ടും പിടിക്കുക, മുമ്പത്തേതിലേക്ക് മടങ്ങുക - ശ്ശോ, സർക്യൂട്ട് സ്വിച്ചിംഗ് ഇല്ല, ക്ലയന്റ് പുനരാരംഭിക്കുന്നു. കുറച്ച് മിനിറ്റ് സഹായിക്കും. വ്യത്യസ്ത ലെയറുകളിൽ നിന്നുള്ള ഡാറ്റാ ഘടനകളുടെ ഒരു മിശ്രിതം നിങ്ങൾക്ക് ലഭിക്കും.

വിശദീകരണം? വിവിധ പരോക്ഷ ലക്ഷണങ്ങളിൽ നിന്ന് നിങ്ങൾക്ക് ഊഹിക്കാൻ കഴിയുന്നതുപോലെ, സെർവറിൽ വ്യത്യസ്ത മെഷീനുകളിൽ വ്യത്യസ്ത തരത്തിലുള്ള നിരവധി പ്രക്രിയകൾ അടങ്ങിയിരിക്കുന്നു. മിക്കവാറും, "ബഫറിംഗിന്" ഉത്തരവാദിത്തമുള്ള സെർവർ അതിന്റെ മേലുദ്യോഗസ്ഥർ നൽകിയത് ക്യൂവിൽ ഇട്ടു, അവർ അത് ജനറേഷൻ സമയത്ത് നിലവിലിരുന്ന സ്കീമിൽ നൽകി. ഈ ക്യൂ "ദ്രവിച്ച" വരെ, അതിനെക്കുറിച്ച് ഒന്നും ചെയ്യാൻ കഴിഞ്ഞില്ല.

ഒരുപക്ഷെ... പക്ഷെ ഇത് ഭയങ്കര ഊന്നുവടിയാണോ?!.. അല്ല, ഭ്രാന്തൻ ആശയങ്ങളെക്കുറിച്ച് ചിന്തിക്കുന്നതിന് മുമ്പ്, നമുക്ക് ഔദ്യോഗിക ക്ലയന്റുകളുടെ കോഡ് നോക്കാം. ആൻഡ്രോയിഡ് പതിപ്പിൽ ഞങ്ങൾ TL പാഴ്‌സറൊന്നും കണ്ടെത്തുന്നില്ല, എന്നാൽ (ഡി)സീരിയലൈസേഷൻ ഉള്ള ഒരു കനത്ത ഫയൽ (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;

"സ്വമേധയാ സൃഷ്‌ടിച്ച" ഈ കമന്റ് സൂചിപ്പിക്കുന്നത് ഈ ഫയലിന്റെ ഒരു ഭാഗം മാത്രമേ സ്വമേധയാ എഴുതിയിട്ടുള്ളൂ (മുഴുവൻ അറ്റകുറ്റപ്പണി പേടിസ്വപ്‌നം നിങ്ങൾക്ക് സങ്കൽപ്പിക്കാനാകുമോ?), ബാക്കിയുള്ളവ യന്ത്രം സൃഷ്ടിച്ചതാണെന്നും. എന്നിരുന്നാലും, മറ്റൊരു ചോദ്യം ഉയർന്നുവരുന്നു - ഉറവിടങ്ങൾ ലഭ്യമാണ് പൂർണ്ണമായും അല്ല (ലിനക്സ് കെർണലിലെ ഒരു ലാ ജിപിഎൽ ബ്ലോബ്സ്), എന്നാൽ ഇത് ഇതിനകം രണ്ടാം ഭാഗത്തിനുള്ള ഒരു വിഷയമാണ്.

എന്നാൽ മതി. ഈ സീരിയലൈസേഷൻ പ്രവർത്തിക്കുന്ന പ്രോട്ടോക്കോളിലേക്ക് നമുക്ക് പോകാം.

MTPproto

അതിനാൽ, നമുക്ക് തുറക്കാം പൊതുവായ വിവരണം и പ്രോട്ടോക്കോളിന്റെ വിശദമായ വിവരണം നമ്മൾ ആദ്യം ഇടറുന്നത് പദപ്രയോഗമാണ്. ഒപ്പം എല്ലാറ്റിന്റെയും സമൃദ്ധിയോടെ. പൊതുവേ, ഇത് ടെലിഗ്രാമിന്റെ ഒരു പ്രൊപ്രൈറ്ററി സവിശേഷതയാണെന്ന് തോന്നുന്നു - വ്യത്യസ്ത സ്ഥലങ്ങളിൽ കാര്യങ്ങൾ വ്യത്യസ്തമായി വിളിക്കുക, അല്ലെങ്കിൽ ഒരു വാക്ക് ഉപയോഗിച്ച് വ്യത്യസ്ത കാര്യങ്ങൾ, അല്ലെങ്കിൽ തിരിച്ചും (ഉദാഹരണത്തിന്, ഒരു ഉയർന്ന തലത്തിലുള്ള API-യിൽ, നിങ്ങൾ ഒരു സ്റ്റിക്കർ പായ്ക്ക് കാണുകയാണെങ്കിൽ, അത് അങ്ങനെയല്ല. നിങ്ങൾ എന്താണ് ചിന്തിച്ചത്).

ഉദാഹരണത്തിന്, "സന്ദേശം", "സെഷൻ" എന്നിവ അർത്ഥമാക്കുന്നത് സാധാരണ ടെലിഗ്രാം ക്ലയന്റ് ഇന്റർഫേസിൽ നിന്ന് വ്യത്യസ്തമായ ഒന്നിനെയാണ്. ശരി, സന്ദേശത്തിൽ എല്ലാം വ്യക്തമാണ്, ഇത് OOP പദങ്ങളിൽ വ്യാഖ്യാനിക്കാം, അല്ലെങ്കിൽ "പാക്കറ്റ്" എന്ന വാക്ക് വിളിക്കാം - ഇത് താഴ്ന്ന, ഗതാഗത നിലയാണ്, ഇന്റർഫേസിലെ അതേ സന്ദേശങ്ങൾ ഇല്ല, നിരവധി സേവന സന്ദേശങ്ങളുണ്ട് . എന്നാൽ സെഷൻ ... എന്നാൽ ആദ്യം കാര്യങ്ങൾ ആദ്യം.

ഗതാഗത പാളി

ആദ്യത്തെ കാര്യം ഗതാഗതമാണ്. അവർ 5 ഓപ്ഷനുകളെക്കുറിച്ച് ഞങ്ങളോട് പറയും:

• TCP
• വെബ്‌സോക്കറ്റ്
• HTTPS വഴിയുള്ള വെബ്‌സോക്കറ്റ്
• HTTP
• എച്ച്ടിടിപിഎസ്

Vasily, [15.06.18 15:04] UDP ട്രാൻസ്പോർട്ടും ഉണ്ട്, പക്ഷേ അത് രേഖപ്പെടുത്തിയിട്ടില്ല

മൂന്ന് വേരിയന്റുകളിൽ ടിസിപിയും

ആദ്യത്തേത് TCP-യെക്കാൾ UDP-ക്ക് സമാനമാണ്, ഓരോ പാക്കറ്റിലും ഒരു സീക്വൻസ് നമ്പറും crc-യും ഉൾപ്പെടുന്നു
ഒരു വണ്ടിയിൽ രേഖകൾ വായിക്കുന്നത് വളരെ വേദനാജനകമായിരിക്കുന്നത് എന്തുകൊണ്ട്?

ശരി, അത് ഇപ്പോൾ ഉണ്ട് TCP ഇതിനകം 4 വേരിയന്റുകളിൽ:

• സംഗ്രഹിച്ചിരിക്കുന്നു
• ഇന്റർമീഡിയറ്റ്
• പാഡഡ് ഇന്റർമീഡിയറ്റ്
• നിറഞ്ഞ

ശരി, ശരി, MTProxy-യ്‌ക്കായുള്ള പാഡഡ് ഇന്റർമീഡിയറ്റ്, അറിയപ്പെടുന്ന ഇവന്റുകൾ കാരണം ഇത് പിന്നീട് ചേർത്തു. എന്നാൽ ഒന്ന് കൊണ്ട് നിങ്ങൾക്ക് ലഭിക്കുമ്പോൾ എന്തിനാണ് രണ്ട് പതിപ്പുകൾ (ആകെ മൂന്ന്)? പ്രധാന MTPproto-യുടെ ദൈർഘ്യവും പേലോഡും എങ്ങനെ സജ്ജീകരിക്കാം എന്നതിൽ മാത്രമാണ് നാലും അടിസ്ഥാനപരമായി വ്യത്യാസപ്പെട്ടിരിക്കുന്നത്, അത് കൂടുതൽ ചർച്ചചെയ്യും:

• ചുരുക്കിയതിൽ ഇത് 1 അല്ലെങ്കിൽ 4 ബൈറ്റുകൾ ആണ്, എന്നാൽ 0xef അല്ല, പിന്നെ ബോഡി
• ഇന്റർമീഡിയറ്റിൽ ഇത് 4 ബൈറ്റ് നീളവും ഒരു ഫീൽഡും ആണ്, ക്ലയന്റ് ആദ്യമായി അയയ്‌ക്കേണ്ടതാണ് 0xeeeeeeee ഇത് ഇന്റർമീഡിയറ്റ് ആണെന്ന് സൂചിപ്പിക്കാൻ
• പൂർണ്ണമായി, ഒരു നെറ്റ്‌വർക്കറുടെ വീക്ഷണകോണിൽ നിന്ന് ഏറ്റവും ആസക്തിയുള്ളത്: നീളം, സീക്വൻസ് നമ്പർ, പ്രധാനമായും MTProto, ബോഡി, CRC32 അല്ല. അതെ, ഇതെല്ലാം ടിസിപിയുടെ മുകളിലാണ്. ഇത് ഒരു സീക്വൻഷ്യൽ ബൈറ്റ് സ്ട്രീമിന്റെ രൂപത്തിൽ ഞങ്ങൾക്ക് വിശ്വസനീയമായ ഗതാഗതം നൽകുന്നു; സീക്വൻസുകളൊന്നും ആവശ്യമില്ല, പ്രത്യേകിച്ച് ചെക്ക്സം. ശരി, ഇപ്പോൾ ടിസിപിക്ക് 16-ബിറ്റ് ചെക്ക്‌സം ഉണ്ടെന്ന് ആരെങ്കിലും എന്നെ എതിർക്കും, അതിനാൽ ഡാറ്റ അഴിമതി സംഭവിക്കുന്നു. കൊള്ളാം, എന്നാൽ യഥാർത്ഥത്തിൽ 16 ബൈറ്റുകളേക്കാൾ ദൈർഘ്യമുള്ള ഹാഷുകളുള്ള ഒരു ക്രിപ്‌റ്റോഗ്രാഫിക് പ്രോട്ടോക്കോൾ ഞങ്ങളുടെ പക്കലുണ്ട്, ഈ പിശകുകളെല്ലാം - അതിലും കൂടുതലും - ഉയർന്ന തലത്തിലുള്ള ഒരു SHA പൊരുത്തക്കേട് പിടിക്കപ്പെടും. ഇതിന് മുകളിൽ CRC32-ൽ കാര്യമില്ല.

"4-ബൈറ്റ് ഡാറ്റ വിന്യാസം ആവശ്യമാണെങ്കിൽ" എന്ന് ന്യായീകരിക്കുന്ന ഇന്റർമീഡിയറ്റുമായി ഒരു ബൈറ്റ് ദൈർഘ്യം സാധ്യമാകുന്ന സംക്ഷിപ്തമായി താരതമ്യം ചെയ്യാം, ഇത് തികച്ചും അസംബന്ധമാണ്. എന്താണ്, ടെലിഗ്രാം പ്രോഗ്രാമർമാർ ഒരു സോക്കറ്റിൽ നിന്ന് ഒരു വിന്യസിച്ച ബഫറിലേക്ക് ഡാറ്റ വായിക്കാൻ കഴിയാത്തത്ര കഴിവില്ലാത്തവരാണെന്ന് വിശ്വസിക്കപ്പെടുന്നു? നിങ്ങൾ ഇപ്പോഴും ഇത് ചെയ്യേണ്ടതുണ്ട്, കാരണം വായന നിങ്ങൾക്ക് എത്ര ബൈറ്റുകളും തിരികെ നൽകും (ഉദാഹരണത്തിന് പ്രോക്സി സെർവറുകളും ഉണ്ട്...). അല്ലെങ്കിൽ മറുവശത്ത്, 16 ബൈറ്റുകൾക്ക് മുകളിൽ ഇപ്പോഴും കനത്ത പാഡിംഗ് ഉണ്ടെങ്കിൽ സംക്ഷിപ്തത്തെ തടയുന്നത് എന്തുകൊണ്ട് - 3 ബൈറ്റുകൾ സംരക്ഷിക്കുക ചിലപ്പോൾ ?

യഥാർത്ഥ പ്രായോഗിക ആവശ്യമില്ലാതെ നെറ്റ്‌വർക്ക് പ്രോട്ടോക്കോളുകൾ ഉൾപ്പെടെയുള്ള ചക്രങ്ങൾ പുനർനിർമ്മിക്കാൻ നിക്കോളായ് ഡുറോവ് ശരിക്കും ഇഷ്ടപ്പെടുന്നുവെന്ന ധാരണ ഒരാൾക്ക് ലഭിക്കുന്നു.

മറ്റ് ഗതാഗത ഓപ്ഷനുകൾ, ഉൾപ്പെടെ. Web, MTProxy, ഞങ്ങൾ ഇപ്പോൾ പരിഗണിക്കില്ല, ഒരുപക്ഷേ മറ്റൊരു പോസ്റ്റിൽ, ഒരു അഭ്യർത്ഥന ഉണ്ടെങ്കിൽ. ഇതേ MTProxy-യെ കുറിച്ച്, 2018-ൽ പുറത്തിറങ്ങിയതിന് തൊട്ടുപിന്നാലെ, ദാതാക്കൾ അത് തടയാൻ വേഗത്തിൽ പഠിച്ചുവെന്ന് മാത്രം ഓർക്കുക. ബൈപാസ് തടയൽ, ഓണാണ് പാക്കേജ് വലിപ്പം! കൂടാതെ സിയിൽ എഴുതിയ (വീണ്ടും വാൾട്ട്മാൻ) MTProxy സെർവർ ലിനക്സ് സ്പെസിഫിക്കുകളുമായി അമിതമായി ബന്ധപ്പെട്ടിരിക്കുന്നു എന്ന വസ്തുതയും, ഇത് ആവശ്യമില്ലെങ്കിലും (ഫിൽ കുലിൻ സ്ഥിരീകരിക്കും), Go അല്ലെങ്കിൽ Node.js-ൽ സമാനമായ സെർവർ ഉണ്ടാകും. നൂറിൽ താഴെ വരികളിൽ ഒതുങ്ങുന്നു.

എന്നാൽ ഈ ആളുകളുടെ സാങ്കേതിക സാക്ഷരതയെക്കുറിച്ച് ഞങ്ങൾ മറ്റ് പ്രശ്നങ്ങൾ പരിഗണിച്ച ശേഷം വിഭാഗത്തിന്റെ അവസാനം നിഗമനങ്ങളിൽ എത്തിച്ചേരും. ഇപ്പോൾ, നമുക്ക് OSI ലെയർ 5, സെഷനിലേക്ക് പോകാം - അതിൽ അവർ MTProto സെഷൻ സ്ഥാപിച്ചു.

കീകൾ, സന്ദേശങ്ങൾ, സെഷനുകൾ, ഡിഫി-ഹെൽമാൻ

അവർ അത് കൃത്യമായി അവിടെ സ്ഥാപിച്ചിട്ടില്ല... ഒരു സെഷൻ എന്നത് സജീവ സെഷനുകൾക്ക് കീഴിലുള്ള ഇന്റർഫേസിൽ ദൃശ്യമാകുന്ന അതേ സെഷൻ അല്ല. എന്നാൽ ക്രമത്തിൽ.

അതിനാൽ ട്രാൻസ്പോർട്ട് ലെയറിൽ നിന്ന് അറിയപ്പെടുന്ന ദൈർഘ്യമുള്ള ഒരു ബൈറ്റ് സ്ട്രിംഗ് ഞങ്ങൾക്ക് ലഭിച്ചു. ഇത് ഒന്നുകിൽ എൻക്രിപ്റ്റ് ചെയ്‌ത സന്ദേശമോ പ്ലെയിൻടെക്‌സ്‌റ്റോ ആണ് - ഞങ്ങൾ ഇപ്പോഴും പ്രധാന കരാറിന്റെ ഘട്ടത്തിലാണെങ്കിൽ യഥാർത്ഥത്തിൽ അത് ചെയ്യുന്നുണ്ടെങ്കിൽ. "കീ" എന്ന് വിളിക്കപ്പെടുന്ന ആശയങ്ങളിൽ ഏതിനെക്കുറിച്ചാണ് നമ്മൾ സംസാരിക്കുന്നത്? ടെലിഗ്രാം ടീമിന് തന്നെ ഈ പ്രശ്നം വ്യക്തമാക്കാം (പുലർച്ചെ 4 മണിക്ക് തളർന്ന തലച്ചോറുമായി ഇംഗ്ലീഷിൽ നിന്ന് എന്റെ സ്വന്തം ഡോക്യുമെന്റേഷൻ വിവർത്തനം ചെയ്തതിന് ഞാൻ ക്ഷമ ചോദിക്കുന്നു, ചില വാക്യങ്ങൾ അതേപടി ഉപേക്ഷിക്കുന്നത് എളുപ്പമായിരുന്നു):

എന്ന് വിളിക്കപ്പെടുന്ന രണ്ട് സ്ഥാപനങ്ങൾ ഉണ്ട് സമ്മേളനം - "നിലവിലെ സെഷനുകൾ" എന്നതിന് കീഴിലുള്ള ഔദ്യോഗിക ക്ലയന്റുകളുടെ യുഐയിൽ ഒന്ന്, ഓരോ സെഷനും ഒരു മുഴുവൻ ഉപകരണം / ഒഎസുമായി യോജിക്കുന്നു.
രണ്ടാമത്തേത് MTPproto സെഷൻ, അതിൽ സന്ദേശത്തിന്റെ സീക്വൻസ് നമ്പർ (താഴ്ന്ന നിലയിലുള്ള അർത്ഥത്തിൽ) ഉണ്ട്, ഏതാണ് വ്യത്യസ്ത TCP കണക്ഷനുകൾക്കിടയിൽ നിലനിൽക്കും. ഒരേ സമയം നിരവധി MTProto സെഷനുകൾ ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയും, ഉദാഹരണത്തിന്, ഫയൽ ഡൗൺലോഡ് വേഗത്തിലാക്കാൻ.

ഇവ രണ്ടിനും ഇടയിൽ സെഷനുകൾ ഒരു ആശയം ഉണ്ട് അംഗീകാരം. അധഃപതിച്ച സാഹചര്യത്തിൽ നമുക്ക് അങ്ങനെ പറയാം UI സെഷൻ പോലെ തന്നെയാണ് അംഗീകാരം, പക്ഷേ അയ്യോ, എല്ലാം സങ്കീർണ്ണമാണ്. നമുക്ക് നോക്കാം:

• പുതിയ ഉപകരണത്തിലെ ഉപയോക്താവ് ആദ്യം സൃഷ്ടിക്കുന്നു auth_key അത് അക്കൗണ്ടിലേക്ക് ബന്ധിപ്പിക്കുന്നു, ഉദാഹരണത്തിന് SMS വഴി - അതുകൊണ്ടാണ് അംഗീകാരം
• ആദ്യത്തേതിനുള്ളിൽ അത് സംഭവിച്ചു MTPproto സെഷൻ, ഉള്ളത് session_id നിങ്ങളുടെ ഉള്ളിൽ.
• ഈ ഘട്ടത്തിൽ, കോമ്പിനേഷൻ അംഗീകാരം и session_id വിളിക്കാമായിരുന്നു അധികാരം - ഈ വാക്ക് ചില ക്ലയന്റുകളുടെ ഡോക്യുമെന്റേഷനിലും കോഡിലും ദൃശ്യമാകുന്നു
• തുടർന്ന്, ഉപഭോക്താവിന് തുറക്കാൻ കഴിയും പലതും MTPproto സെഷനുകൾ അതേ കീഴിൽ auth_key - അതേ ഡിസിയിലേക്ക്.
• തുടർന്ന്, ഒരു ദിവസം ക്ലയന്റ് ഫയൽ അഭ്യർത്ഥിക്കേണ്ടതുണ്ട് മറ്റൊരു ഡിസി - ഈ DC-യ്‌ക്കായി ഒരു പുതിയത് സൃഷ്‌ടിക്കും auth_key !
• രജിസ്‌റ്റർ ചെയ്യുന്നത് പുതിയ ഉപയോക്താവല്ലെന്നും അത് തന്നെയാണെന്നും സിസ്റ്റത്തെ അറിയിക്കാൻ അംഗീകാരം (UI സെഷൻ), ക്ലയന്റ് API കോളുകൾ ഉപയോഗിക്കുന്നു auth.exportAuthorization വീട്ടിൽ ഡി.സി auth.importAuthorization പുതിയ ഡിസിയിൽ.
• എല്ലാം ഒന്നുതന്നെയാണ്, പലതും തുറന്നിരിക്കാം MTPproto സെഷനുകൾ (ഓരോന്നിനും അതിന്റേതായ session_id) ഈ പുതിയ ഡിസിക്ക്, കീഴിൽ അവന്റെ auth_key.
• അവസാനമായി, ക്ലയന്റ് തികഞ്ഞ ഫോർവേഡ് രഹസ്യം ആഗ്രഹിച്ചേക്കാം. ഓരോ auth_key ആയിരുന്നു സ്ഥിരമായ കീ - ഓരോ ഡിസിക്കും - കൂടാതെ ക്ലയന്റിന് വിളിക്കാം auth.bindTempAuthKey ഉപയോഗത്തിന് താൽക്കാലികം auth_key - വീണ്ടും, ഒന്ന് മാത്രം temp_auth_key ഓരോ ഡിസിക്കും, എല്ലാവർക്കും പൊതുവായത് MTPproto സെഷനുകൾ ഈ ഡി.സി.

അത് ശ്രദ്ധിക്കുക ഉപ്പ് (ഭാവി ലവണങ്ങൾ) എന്നിവയും ഒന്നാണ് auth_key ആ. എല്ലാവർക്കും ഇടയിൽ പങ്കിട്ടു MTPproto സെഷനുകൾ അതേ ഡി.സി.

"വ്യത്യസ്ത TCP കണക്ഷനുകൾക്കിടയിൽ" എന്താണ് അർത്ഥമാക്കുന്നത്? അതിനാൽ ഇത് അർത്ഥമാക്കുന്നത് അതുപോലത്തെ ഒരു വെബ്‌സൈറ്റിലെ അംഗീകൃത കുക്കി - നൽകിയിരിക്കുന്ന സെർവറിലേക്കുള്ള നിരവധി ടിസിപി കണക്ഷനുകൾ അത് നിലനിൽക്കുന്നു (അതിജീവിക്കുന്നു), എന്നാൽ ഒരു ദിവസം അത് മോശമാകും. HTTP-യിൽ നിന്ന് വ്യത്യസ്തമായി, ഒരു സെഷനിലെ MTProto സന്ദേശങ്ങൾ ക്രമാനുഗതമായി അക്കമിട്ട് സ്ഥിരീകരിക്കുന്നു; അവർ തുരങ്കത്തിൽ പ്രവേശിച്ചാൽ, കണക്ഷൻ തകരാറിലായി - ഒരു പുതിയ കണക്ഷൻ സ്ഥാപിച്ച ശേഷം, സെർവർ ഈ സെഷനിൽ മുമ്പത്തെ ഡെലിവർ ചെയ്യാത്തതെല്ലാം ദയയോടെ അയയ്ക്കും. TCP കണക്ഷൻ.

എന്നിരുന്നാലും, നിരവധി മാസത്തെ അന്വേഷണത്തിന് ശേഷം മുകളിലുള്ള വിവരങ്ങൾ സംഗ്രഹിച്ചിരിക്കുന്നു. അതിനിടയിൽ, ഞങ്ങൾ ഞങ്ങളുടെ ക്ലയന്റ് ആദ്യം മുതൽ നടപ്പിലാക്കുന്നുണ്ടോ? - നമുക്ക് തുടക്കത്തിലേക്ക് മടങ്ങാം.

അതിനാൽ നമുക്ക് സൃഷ്ടിക്കാം auth_key ആ സമയത്ത് ടെലിഗ്രാമിൽ നിന്നുള്ള ഡിഫി-ഹെൽമാൻ പതിപ്പുകൾ. ഡോക്യുമെന്റേഷൻ മനസ്സിലാക്കാൻ ശ്രമിക്കാം...

Vasily, [19.06.18 20:05] data_with_hash := SHA1(ഡാറ്റ) + ഡാറ്റ + (ഏതെങ്കിലും ക്രമരഹിതമായ ബൈറ്റുകൾ); ദൈർഘ്യം 255 ബൈറ്റുകൾക്ക് തുല്യമാണ്;
encrypted_data := RSA(data_with_hash, server_public_key); 255-ബൈറ്റ് നീളമുള്ള ഒരു സംഖ്യ (ബിഗ് എൻഡിയൻ) ആവശ്യമായ മോഡുലസിൽ ആവശ്യമായ ശക്തിയിലേക്ക് ഉയർത്തുന്നു, ഫലം 256-ബൈറ്റ് സംഖ്യയായി സംഭരിക്കുന്നു.

അവർക്ക് കുറച്ച് ഡോപ്പ് ഡിഎച്ച് ഉണ്ട്

ആരോഗ്യമുള്ള ഒരു വ്യക്തിയുടെ DH പോലെ തോന്നുന്നില്ല
dx-ൽ രണ്ട് പൊതു കീകളില്ല

ശരി, അവസാനം ഇത് ക്രമീകരിച്ചു, പക്ഷേ ഒരു അവശിഷ്ടം അവശേഷിച്ചു - നമ്പർ ഫാക്ടർ ചെയ്യാൻ അദ്ദേഹത്തിന് കഴിഞ്ഞുവെന്ന് ക്ലയന്റ് ചെയ്ത ജോലിയുടെ തെളിവ്. DoS ആക്രമണങ്ങൾക്കെതിരായ പരിരക്ഷയുടെ തരം. കൂടാതെ RSA കീ ഒരു ദിശയിൽ ഒരു തവണ മാത്രമേ ഉപയോഗിക്കൂ, പ്രധാനമായും എൻക്രിപ്ഷനായി new_nonce. എന്നാൽ ഈ ലളിതമായ ഓപ്പറേഷൻ വിജയിക്കുമ്പോൾ, നിങ്ങൾ എന്ത് നേരിടേണ്ടിവരും?

Vasily, [20.06.18/00/26 XNUMX:XNUMX] എനിക്ക് ഇതുവരെ appid അഭ്യർത്ഥന ലഭിച്ചിട്ടില്ല

ഞാൻ ഈ അഭ്യർത്ഥന DH-ന് അയച്ചു

കൂടാതെ, ഒരു പിശക് കോഡിന്റെ 4 ബൈറ്റുകൾ ഉപയോഗിച്ച് പ്രതികരിക്കാൻ കഴിയുമെന്ന് ട്രാൻസ്പോർട്ട് ഡോക്കിൽ പറയുന്നു. അത്രയേയുള്ളൂ

ശരി, അവൻ എന്നോട് പറഞ്ഞു -404, അപ്പോൾ എന്താണ്?

അതുകൊണ്ട് ഞാൻ അവനോട് പറഞ്ഞു: “ഇതുപോലുള്ള ഫിംഗർപ്രിന്റ് ഉള്ള സെർവർ കീ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത നിങ്ങളുടെ ബുൾഷിറ്റ് പിടിക്കൂ, എനിക്ക് DH വേണം,” അത് ഒരു മണ്ടൻ 404 എന്ന് പ്രതികരിച്ചു.

ഈ സെർവർ പ്രതികരണത്തെക്കുറിച്ച് നിങ്ങൾ എന്താണ് ചിന്തിക്കുന്നത്? എന്തുചെയ്യും? ചോദിക്കാൻ ആരുമില്ല (എന്നാൽ അതിനെക്കുറിച്ച് കൂടുതൽ രണ്ടാം ഭാഗത്തിൽ).

ഇവിടെ എല്ലാ പലിശയും ഡോക്കിലാണ് ചെയ്യുന്നത്

എനിക്ക് മറ്റൊന്നും ചെയ്യാനില്ല, അക്കങ്ങൾ അങ്ങോട്ടും ഇങ്ങോട്ടും മാറ്റുന്നത് ഞാൻ സ്വപ്നം കണ്ടു

രണ്ട് 32 ബിറ്റ് നമ്പറുകൾ. എല്ലാവരെയും പോലെ ഞാനും അവരെ പാക്ക് ചെയ്തു

എന്നാൽ ഇല്ല, ഇവ രണ്ടും ആദ്യം വരിയിൽ BE ആയി ചേർക്കേണ്ടതുണ്ട്

വാഡിം ഗോഞ്ചറോവ്, [20.06.18 15:49] ഈ 404 കാരണം?

വാസിലി, [20.06.18 15:49] അതെ!

വാഡിം ഗോഞ്ചറോവ്, [20.06.18 15:50] അതിനാൽ അവന് എന്താണ് "കണ്ടെത്താൻ കഴിയാത്തത്" എന്ന് എനിക്ക് മനസ്സിലാകുന്നില്ല

വാസിലി, [20.06.18 15:50] ഏകദേശം

എനിക്ക് അത്തരം ഒരു വിഘടനം പ്രധാന ഘടകങ്ങളിലേക്ക് കണ്ടെത്താനായില്ല%)

പിശക് റിപ്പോർട്ടുചെയ്യൽ പോലും ഞങ്ങൾ കൈകാര്യം ചെയ്തില്ല

വാസിലി, [20.06.18 20:18] ഓ, MD5 ഉം ഉണ്ട്. ഇതിനകം മൂന്ന് വ്യത്യസ്ത ഹാഷുകൾ

പ്രധാന വിരലടയാളം ഇനിപ്പറയുന്ന രീതിയിൽ കണക്കാക്കുന്നു:

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

SHA1, sha2 എന്നിവ

അതുകൊണ്ട് വെക്കാം auth_key Diffie-Hellman ഉപയോഗിച്ച് ഞങ്ങൾക്ക് 2048 ബിറ്റുകൾ ലഭിച്ചു. അടുത്തത് എന്താണ്? അടുത്തതായി, ഈ കീയുടെ താഴത്തെ 1024 ബിറ്റുകൾ ഒരു തരത്തിലും ഉപയോഗിക്കുന്നില്ലെന്ന് ഞങ്ങൾ കണ്ടെത്തുന്നു... എന്നാൽ ഇപ്പോൾ ഇതിനെക്കുറിച്ച് ചിന്തിക്കാം. ഈ ഘട്ടത്തിൽ, ഞങ്ങൾക്ക് സെർവറുമായി പങ്കിട്ട ഒരു രഹസ്യമുണ്ട്. TLS സെഷന്റെ ഒരു അനലോഗ് സ്ഥാപിച്ചു, ഇത് വളരെ ചെലവേറിയ നടപടിക്രമമാണ്. എന്നാൽ ഞങ്ങൾ ആരാണെന്ന് സെർവറിന് ഇപ്പോഴും അറിയില്ല! ഇതുവരെ ഇല്ല, യഥാർത്ഥത്തിൽ. അംഗീകാരം. ആ. നിങ്ങൾ ഒരിക്കൽ ICQ-ൽ ചെയ്‌തതുപോലെ "ലോഗിൻ-പാസ്‌വേഡ്" അല്ലെങ്കിൽ SSH-ൽ (ഉദാഹരണത്തിന്, ചില gitlab/github-ൽ) പോലെ "ലോഗിൻ-കീ" എന്നതിന്റെ അടിസ്ഥാനത്തിൽ നിങ്ങൾ ചിന്തിച്ചിട്ടുണ്ടെങ്കിൽ. ഞങ്ങൾക്ക് ഒരു അജ്ഞാതനെ ലഭിച്ചു. "ഈ ഫോൺ നമ്പറുകൾ മറ്റൊരു DC ആണ് സർവീസ് ചെയ്യുന്നത്" എന്ന് സെർവർ ഞങ്ങളോട് പറഞ്ഞാലോ? അല്ലെങ്കിൽ "നിങ്ങളുടെ ഫോൺ നമ്പർ നിരോധിച്ചിരിക്കുന്നു" എന്നതുപോലും? നമുക്ക് ചെയ്യാൻ കഴിയുന്ന ഏറ്റവും മികച്ചത്, താക്കോൽ ഉപയോഗപ്രദമാകുമെന്ന പ്രതീക്ഷയിൽ സൂക്ഷിക്കുക എന്നതാണ്, അപ്പോഴേക്കും ചീഞ്ഞഴുകിപ്പോകില്ല.

വഴിയിൽ, ഞങ്ങൾ അത് റിസർവേഷനുകളോടെ "സ്വീകരിച്ചു". ഉദാഹരണത്തിന്, ഞങ്ങൾ സെർവറിനെ വിശ്വസിക്കുന്നുണ്ടോ? വ്യാജമാണെങ്കിലോ? ക്രിപ്‌റ്റോഗ്രാഫിക് പരിശോധനകൾ ആവശ്യമാണ്:

Vasily, [21.06.18 17:53] അവർ മൊബൈൽ ക്ലയന്റുകൾക്ക് 2kbit നമ്പർ പ്രൈമലിറ്റി% പരിശോധിക്കാൻ വാഗ്ദാനം ചെയ്യുന്നു)

എന്നാൽ അത് വ്യക്തമല്ല, നഫീജോവ

Vasily, [21.06.18 18:02] അത് ലളിതമല്ലെങ്കിൽ എന്തുചെയ്യണമെന്ന് പ്രമാണം പറയുന്നില്ല

പറഞ്ഞിട്ടില്ല. ഈ സാഹചര്യത്തിൽ ഔദ്യോഗിക ആൻഡ്രോയിഡ് ക്ലയന്റ് എന്താണ് ചെയ്യുന്നതെന്ന് നോക്കാം? എ അതാണത് (അതെ, മുഴുവൻ ഫയലും രസകരമാണ്) - അവർ പറയുന്നത് പോലെ, ഞാൻ ഇത് ഇവിടെ ഉപേക്ഷിക്കും:

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

ഇല്ല, തീർച്ചയായും അത് ഇപ്പോഴും അവിടെയുണ്ട് ചിലത് ഒരു സംഖ്യയുടെ പ്രാഥമികതയ്ക്കായി പരിശോധനകൾ ഉണ്ട്, എന്നാൽ വ്യക്തിപരമായി എനിക്ക് ഗണിതശാസ്ത്രത്തിൽ വേണ്ടത്ര അറിവില്ല.

ശരി, ഞങ്ങൾക്ക് മാസ്റ്റർ കീ ലഭിച്ചു. ലോഗിൻ ചെയ്യാൻ, അതായത്. അഭ്യർത്ഥനകൾ അയയ്ക്കുക, നിങ്ങൾ AES ഉപയോഗിച്ച് കൂടുതൽ എൻക്രിപ്ഷൻ നടത്തേണ്ടതുണ്ട്.

അംഗീകൃത കീയിൽ നിന്ന് എടുത്ത 128 ബൈറ്റുകൾ മുൻ‌കൂട്ടി തയ്യാറാക്കിയ പാഡിംഗ് ബൈറ്റുകൾ ഉൾപ്പെടെ, സന്ദേശ ബോഡിയുടെ (സെഷൻ, സന്ദേശ ഐഡി മുതലായവ ഉൾപ്പെടെ) SHA256-ന്റെ 32 മധ്യ ബിറ്റുകളാണ് സന്ദേശ കീ നിർവചിച്ചിരിക്കുന്നത്.

Vasily, [22.06.18 14:08] ശരാശരി, ബിച്ച്, ബിറ്റുകൾ

ലഭിച്ചു auth_key. എല്ലാം. അവർക്കപ്പുറം... അത് പ്രമാണത്തിൽ നിന്ന് വ്യക്തമല്ല. ഓപ്പൺ സോഴ്സ് കോഡ് പഠിക്കാൻ മടിക്കേണ്ടതില്ല.

MTPproto 2.0 ന് 12 മുതൽ 1024 ബൈറ്റുകൾ വരെ പാഡിംഗ് ആവശ്യമാണെന്ന കാര്യം ശ്രദ്ധിക്കുക, ഫലമായുണ്ടാകുന്ന സന്ദേശ ദൈർഘ്യം 16 ബൈറ്റുകൾ കൊണ്ട് ഹരിക്കാമെന്ന വ്യവസ്ഥയ്ക്ക് വിധേയമാണ്.

അപ്പോൾ നിങ്ങൾ എത്ര പാഡിംഗ് ചേർക്കണം?

അതെ, ഒരു പിശകുണ്ടായാൽ 404 ഉണ്ട്

ഡോക്യുമെന്റേഷന്റെ ഡയഗ്രാമും വാചകവും ആരെങ്കിലും ശ്രദ്ധാപൂർവ്വം പഠിച്ചാൽ, അവിടെ MAC ഇല്ലെന്ന് അവർ ശ്രദ്ധിച്ചു. മറ്റെവിടെയും ഉപയോഗിക്കാത്ത ഒരു നിശ്ചിത ഐജിഇ മോഡിലാണ് AES ഉപയോഗിക്കുന്നത്. അവർ തീർച്ചയായും അവരുടെ പതിവുചോദ്യങ്ങളിൽ ഇതിനെക്കുറിച്ച് എഴുതുന്നു... ഇവിടെ, സന്ദേശ കീ തന്നെ, ഡീക്രിപ്റ്റ് ചെയ്ത ഡാറ്റയുടെ SHA ഹാഷ് കൂടിയാണ്, സമഗ്രത പരിശോധിക്കാൻ ഉപയോഗിക്കുന്നു - കൂടാതെ ഒരു പൊരുത്തക്കേട് ഉണ്ടായാൽ, ചില കാരണങ്ങളാൽ ഡോക്യുമെന്റേഷൻ അവരെ നിശബ്ദമായി അവഗണിക്കാൻ ശുപാർശ ചെയ്യുന്നു (എന്നാൽ സുരക്ഷയുടെ കാര്യമോ, അവർ നമ്മെ തകർത്താലോ?).

ഞാൻ ഒരു ക്രിപ്‌റ്റോഗ്രാഫർ അല്ല, സൈദ്ധാന്തിക വീക്ഷണകോണിൽ നിന്ന് ഈ സാഹചര്യത്തിൽ ഈ മോഡിൽ തെറ്റൊന്നുമില്ലായിരിക്കാം. പക്ഷേ, ടെലിഗ്രാം ഡെസ്‌ക്‌ടോപ്പ് ഉദാഹരണമായി ഉപയോഗിച്ചുകൊണ്ട് എനിക്ക് ഒരു പ്രായോഗിക പ്രശ്‌നത്തിന് വ്യക്തമായി പേരിടാൻ കഴിയും. ഇത് പ്രാദേശിക കാഷെ (ഈ D877F783D5D3EF8C) MTProto-യിലെ സന്ദേശങ്ങൾ പോലെ തന്നെ എൻക്രിപ്റ്റ് ചെയ്യുന്നു (ഈ സാഹചര്യത്തിൽ പതിപ്പ് 1.0 ൽ മാത്രം), അതായത്. ആദ്യം സന്ദേശ കീ, പിന്നെ ഡാറ്റ തന്നെ (എവിടെയെങ്കിലും പ്രധാന വലിയത് മാറ്റിനിർത്തുക auth_key 256 ബൈറ്റുകൾ, കൂടാതെ msg_key ഉപയോഗശൂന്യം). അതിനാൽ, വലിയ ഫയലുകളിൽ പ്രശ്നം ശ്രദ്ധേയമാകും. അതായത്, നിങ്ങൾ ഡാറ്റയുടെ രണ്ട് പകർപ്പുകൾ സൂക്ഷിക്കേണ്ടതുണ്ട് - എൻക്രിപ്റ്റ് ചെയ്തതും ഡീക്രിപ്റ്റ് ചെയ്തതും. കൂടാതെ മെഗാബൈറ്റുകളോ സ്ട്രീമിംഗ് വീഡിയോകളോ ഉണ്ടെങ്കിൽ, ഉദാഹരണത്തിന്?.. സിഫർടെക്‌സ്‌റ്റിന് ശേഷം MAC ഉള്ള ക്ലാസിക് സ്കീമുകൾ അത് സ്ട്രീം വായിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു, അത് ഉടനടി സംപ്രേഷണം ചെയ്യുന്നു. എന്നാൽ MTPproto ഉപയോഗിച്ച് നിങ്ങൾ ചെയ്യേണ്ടി വരും ആദ്യം മുഴുവൻ സന്ദേശവും എൻക്രിപ്റ്റ് ചെയ്യുക അല്ലെങ്കിൽ ഡീക്രിപ്റ്റ് ചെയ്യുക, തുടർന്ന് അത് നെറ്റ്വർക്കിലേക്കോ ഡിസ്കിലേക്കോ മാറ്റുക. അതിനാൽ, കാഷെയിലെ ടെലിഗ്രാം ഡെസ്ക്ടോപ്പിന്റെ ഏറ്റവും പുതിയ പതിപ്പുകളിൽ user_data മറ്റൊരു ഫോർമാറ്റും ഉപയോഗിക്കുന്നു - CTR മോഡിൽ AES ഉപയോഗിച്ച്.

വാസിലി, [21.06.18 01:27] ഓ, ഐജിഇ എന്താണെന്ന് ഞാൻ കണ്ടെത്തി: കെർബറോസിനായി "ആധികാരികമാക്കുന്ന എൻക്രിപ്ഷൻ മോഡിന്റെ" ആദ്യ ശ്രമമായിരുന്നു ഐജിഇ. ഇത് ഒരു പരാജയപ്പെട്ട ശ്രമമായിരുന്നു (ഇത് സമഗ്രത പരിരക്ഷ നൽകുന്നില്ല), അത് നീക്കം ചെയ്യേണ്ടിവന്നു. പ്രവർത്തിക്കുന്ന ഒരു പ്രാമാണീകരണ എൻക്രിപ്ഷൻ മോഡിനായുള്ള 20 വർഷത്തെ അന്വേഷണത്തിന്റെ തുടക്കമായിരുന്നു അത്, ഇത് അടുത്തിടെ OCB, GCM പോലുള്ള മോഡുകളിൽ അവസാനിച്ചു.

ഇപ്പോൾ വണ്ടിയുടെ ഭാഗത്ത് നിന്നുള്ള വാദങ്ങൾ:

ടെലിഗ്രാമിന് പിന്നിൽ, നിക്കോളായ് ഡുറോവിന്റെ നേതൃത്വത്തിലുള്ള ടീം, ആറ് എസിഎം ചാമ്പ്യന്മാരാണ്, അവരിൽ പകുതിയും ഗണിതശാസ്ത്രത്തിൽ പിഎച്ച്.ഡി. MTPproto-യുടെ നിലവിലെ പതിപ്പ് പുറത്തിറക്കാൻ അവർക്ക് ഏകദേശം രണ്ട് വർഷമെടുത്തു.

അത് രസകരമാണ്. താഴത്തെ നിലയിൽ രണ്ട് വർഷം

അല്ലെങ്കിൽ നിങ്ങൾക്ക് tls എടുക്കാം

ശരി, ഞങ്ങൾ എൻക്രിപ്ഷനും മറ്റ് സൂക്ഷ്മതകളും ചെയ്തുവെന്ന് പറയാം. ടിഎല്ലിൽ സീരിയലൈസ് ചെയ്ത അഭ്യർത്ഥനകൾ അയയ്‌ക്കാനും പ്രതികരണങ്ങൾ നിരാകരിക്കാനും ഒടുവിൽ സാധിക്കുമോ? അപ്പോൾ എന്ത്, എങ്ങനെ അയയ്ക്കണം? ഇവിടെ, നമുക്ക് രീതി പറയാം initകണക്ഷൻ, ഒരുപക്ഷേ ഇതാണോ?

Vasily, [25.06.18 18:46] കണക്ഷൻ ആരംഭിക്കുകയും ഉപയോക്താവിന്റെ ഉപകരണത്തിലും ആപ്ലിക്കേഷനിലും വിവരങ്ങൾ സംരക്ഷിക്കുകയും ചെയ്യുന്നു.

ഇത് app_id, device_model, system_version, app_version, lang_code എന്നിവ സ്വീകരിക്കുന്നു.

ഒപ്പം ചില ചോദ്യങ്ങളും

എല്ലായ്പ്പോഴും എന്നപോലെ ഡോക്യുമെന്റേഷൻ. ഓപ്പൺ സോഴ്സ് പഠിക്കാൻ മടിക്കേണ്ടതില്ല

invokeWithLayer ഉപയോഗിച്ച് എല്ലാം ഏകദേശം വ്യക്തമായിരുന്നെങ്കിൽ, ഇവിടെ എന്താണ് തെറ്റ്? ഇത് മാറുന്നു, ഞങ്ങൾക്ക് ഉണ്ടെന്ന് പറയാം - ക്ലയന്റിന് ഇതിനകം സെർവറിനോട് എന്തെങ്കിലും ചോദിക്കാനുണ്ടായിരുന്നു - ഞങ്ങൾ അയയ്ക്കാൻ ആഗ്രഹിക്കുന്ന ഒരു അഭ്യർത്ഥനയുണ്ട്:

വാസിലി, [25.06.18 19:13] കോഡ് ഉപയോഗിച്ച് വിലയിരുത്തുമ്പോൾ, ആദ്യത്തെ കോൾ ഈ ക്രാപ്പിൽ പൊതിഞ്ഞതാണ്, കൂടാതെ ക്രാപ്പ് തന്നെ ഇൻവോക്ക്വിത്ത്ലെയറിൽ പൊതിഞ്ഞതാണ്.

എന്തുകൊണ്ട് 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 ലഭിക്കും. ഞങ്ങൾ തെറ്റായ ഡിസിയിലാണെങ്കിൽ (ഈ രാജ്യത്തെ ടെലിഫോൺ നമ്പറുകൾ മറ്റൊന്നാണ് നൽകുന്നത്, ഉദാഹരണത്തിന്), ആവശ്യമുള്ള ഡിസിയുടെ നമ്പറിൽ ഞങ്ങൾക്ക് ഒരു പിശക് ലഭിക്കും. ഡിസി നമ്പർ വഴി ഏത് ഐപി വിലാസത്തിലാണ് നിങ്ങൾ കണക്‌റ്റ് ചെയ്യേണ്ടതെന്ന് കണ്ടെത്താൻ, ഞങ്ങളെ സഹായിക്കുക help.getConfig. ഒരു സമയത്ത് 5 എൻട്രികൾ മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ, എന്നാൽ 2018 ലെ പ്രശസ്തമായ ഇവന്റുകൾക്ക് ശേഷം, എണ്ണം ഗണ്യമായി വർദ്ധിച്ചു.

അജ്ഞാതമായി സെർവറിൽ ഞങ്ങൾ ഈ ഘട്ടത്തിലെത്തി എന്ന് ഇപ്പോൾ ഓർക്കുക. ഒരു ഐപി വിലാസം ലഭിക്കാൻ വളരെ ചെലവേറിയതല്ലേ? MTPproto-യുടെ എൻക്രിപ്റ്റ് ചെയ്യാത്ത ഭാഗത്ത് എന്തുകൊണ്ട് ഇതും മറ്റ് പ്രവർത്തനങ്ങളും ചെയ്തുകൂടാ? ഞാൻ എതിർപ്പ് കേൾക്കുന്നു: "തെറ്റായ വിലാസങ്ങളിൽ പ്രതികരിക്കുന്നത് ആർകെഎൻ അല്ലെന്ന് നമുക്ക് എങ്ങനെ ഉറപ്പാക്കാനാകും?" ഇത് ഞങ്ങൾ ഓർക്കുന്നു, പൊതുവേ, ഔദ്യോഗിക ക്ലയന്റുകൾ 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-യിലേക്ക് മാറിയതായി നിങ്ങൾ ശ്രദ്ധിച്ചു, അതായത്. അടുത്ത ഘട്ടത്തിലേക്ക്, MTPproto വിഷയത്തിൽ എന്തെങ്കിലും നഷ്ടമായോ? അതിശയിക്കാനില്ല:

Vasily, [28.06.18 02:04] Mm, അവർ e2e-യിലെ ചില അൽഗോരിതങ്ങളിലൂടെ അലയുകയാണ്

Mtproto രണ്ട് ഡൊമെയ്‌നുകൾക്കുമുള്ള എൻക്രിപ്ഷൻ അൽഗോരിതങ്ങളും കീകളും, കൂടാതെ ഒരു റാപ്പർ ഘടനയും നിർവ്വചിക്കുന്നു

എന്നാൽ അവ സ്റ്റാക്കിന്റെ വിവിധ തലങ്ങൾ നിരന്തരം കലർത്തുന്നു, അതിനാൽ mtproto എവിടെയാണ് അവസാനിച്ചതെന്നും അടുത്ത ലെവൽ ആരംഭിച്ചതെന്നും എല്ലായ്പ്പോഴും വ്യക്തമല്ല.

അവ എങ്ങനെ കലർത്തുന്നു? ശരി, PFS-നുള്ള അതേ താൽക്കാലിക കീ ഇതാ, ഉദാഹരണത്തിന് (വഴിയിൽ, ടെലിഗ്രാം ഡെസ്ക്ടോപ്പിന് ഇത് ചെയ്യാൻ കഴിയില്ല). ഒരു API അഭ്യർത്ഥന പ്രകാരമാണ് ഇത് നടപ്പിലാക്കുന്നത് auth.bindTempAuthKey, അതായത്. ഉയർന്ന തലത്തിൽ നിന്ന്. എന്നാൽ അതേ സമയം അത് താഴ്ന്ന നിലയിലുള്ള എൻക്രിപ്ഷനിൽ ഇടപെടുന്നു - അതിന് ശേഷം, ഉദാഹരണത്തിന്, നിങ്ങൾ അത് വീണ്ടും ചെയ്യേണ്ടതുണ്ട്. initConnection മുതലായവ., ഇതല്ല വെറും സാധാരണ അഭ്യർത്ഥന. ഫീൽഡ് ആണെങ്കിലും നിങ്ങൾക്ക് ഒരു ഡിസിക്ക് ഒരു താൽക്കാലിക കീ മാത്രമേ ഉണ്ടാകൂ എന്നതാണ് പ്രത്യേകത auth_key_id ഓരോ സന്ദേശത്തിലും കുറഞ്ഞത് എല്ലാ സന്ദേശങ്ങളെങ്കിലും കീ മാറ്റാൻ നിങ്ങളെ അനുവദിക്കുന്നു, കൂടാതെ എപ്പോൾ വേണമെങ്കിലും താൽക്കാലിക കീ "മറക്കാൻ" സെർവറിന് അവകാശമുണ്ട് - ഈ സാഹചര്യത്തിൽ എന്തുചെയ്യണമെന്ന് ഡോക്യുമെന്റേഷൻ പറയുന്നില്ല ... ശരി, എന്തുകൊണ്ട്? ഭാവിയിലെ ഒരു കൂട്ടം ലവണങ്ങൾ പോലെ നിങ്ങൾക്ക് നിരവധി കീകൾ ഇല്ലേ, കൂടാതെ?..

MTProto തീമിനെക്കുറിച്ച് ശ്രദ്ധിക്കേണ്ട മറ്റ് ചില കാര്യങ്ങളുണ്ട്.

സന്ദേശ സന്ദേശങ്ങൾ, msg_id, msg_seqno, സ്ഥിരീകരണങ്ങൾ, തെറ്റായ ദിശയിലുള്ള പിംഗ്, മറ്റ് വ്യതിരിക്തതകൾ

എന്തുകൊണ്ടാണ് നിങ്ങൾ അവരെക്കുറിച്ച് അറിയേണ്ടത്? അവർ ഉയർന്ന തലത്തിലേക്ക് "ലീക്ക്" ആയതിനാൽ, API-യിൽ പ്രവർത്തിക്കുമ്പോൾ നിങ്ങൾ അവയെക്കുറിച്ച് അറിഞ്ഞിരിക്കണം. msg_key-യിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമില്ലെന്ന് കരുതുക; താഴത്തെ നില ഞങ്ങൾക്കായി എല്ലാം ഡീക്രിപ്റ്റ് ചെയ്തു. എന്നാൽ ഡീക്രിപ്റ്റ് ചെയ്ത ഡാറ്റയ്ക്കുള്ളിൽ ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന ഫീൽഡുകൾ ഉണ്ട് (ഡാറ്റയുടെ ദൈർഘ്യവും, അതിനാൽ പാഡിംഗ് എവിടെയാണെന്ന് ഞങ്ങൾക്കറിയാം, പക്ഷേ അത് പ്രധാനമല്ല):

• ഉപ്പ് - int64
• session_id - int64
• message_id — int64
• seq_no - int32

മുഴുവൻ ഡിസിക്കും ഒരു ഉപ്പ് മാത്രമേയുള്ളൂവെന്ന് ഞങ്ങൾ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ. എന്തിനാണ് അവളെ കുറിച്ച് അറിയുന്നത്? അഭ്യർത്ഥന ഉള്ളതുകൊണ്ടല്ല 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! എങ്ങനെ? ശരി, ഉദാഹരണത്തിന്, സെർവർ ഞങ്ങൾക്ക് എന്തെങ്കിലും അയയ്‌ക്കുന്നു, അത് അയയ്‌ക്കുന്നു, ഞങ്ങൾ സ്വയം നിശബ്ദത പാലിക്കുന്നു, അതിന്റെ സന്ദേശങ്ങളുടെ രസീത് സ്ഥിരീകരിക്കുന്ന സേവന സന്ദേശങ്ങളിൽ മാത്രം പ്രതികരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഞങ്ങളുടെ ഔട്ട്‌ഗോയിംഗ് സ്ഥിരീകരണങ്ങൾക്ക് ഒരേ ഔട്ട്‌ഗോയിംഗ് നമ്പർ ഉണ്ടായിരിക്കും. നിങ്ങൾക്ക് ടിസിപി പരിചിതമാണെങ്കിൽ, ഇത് എങ്ങനെയെങ്കിലും വന്യമാണെന്ന് തോന്നുന്നു, പക്ഷേ അത് വളരെ വന്യമല്ലെന്ന് തോന്നുന്നു, കാരണം ടിസിപിയിൽ seq_no മാറില്ല, പക്ഷേ സ്ഥിരീകരണം പോകുന്നു seq_no മറുവശത്ത്, നിങ്ങളെ വിഷമിപ്പിക്കാൻ ഞാൻ തിടുക്കം കൂട്ടും. MTPproto-യിൽ സ്ഥിരീകരണങ്ങൾ നൽകിയിട്ടുണ്ട് അല്ല ആ സമയത്ത് seq_no, TCP പോലെ, എന്നാൽ വഴി msg_id !

ഇത് എന്താണ് msg_id, ഈ മേഖലകളിൽ ഏറ്റവും പ്രധാനപ്പെട്ടത്? പേര് സൂചിപ്പിക്കുന്നത് പോലെ ഒരു അദ്വിതീയ സന്ദേശ ഐഡന്റിഫയർ. ഇത് ഒരു 64-ബിറ്റ് നമ്പറായി നിർവചിച്ചിരിക്കുന്നു, അതിൽ ഏറ്റവും താഴ്ന്ന ബിറ്റുകൾക്ക് വീണ്ടും "സെർവർ-നോട്ട്-സെർവർ" മാജിക് ഉണ്ട്, ബാക്കിയുള്ളവ യുണിക്സ് ടൈംസ്റ്റാമ്പ് ആണ്, ഫ്രാക്ഷണൽ ഭാഗം ഉൾപ്പെടെ, 32 ബിറ്റുകൾ ഇടത്തേക്ക് മാറ്റി. ആ. ടൈംസ്റ്റാമ്പ് പെർസെ (കൂടാതെ സമയങ്ങളിൽ വളരെയധികം വ്യത്യാസമുള്ള സന്ദേശങ്ങൾ സെർവർ നിരസിക്കും). ഇതിൽ നിന്ന് പൊതുവെ ഇത് ക്ലയന്റിന് ആഗോളമായ ഒരു ഐഡന്റിഫയർ ആണെന്ന് മാറുന്നു. അത് നൽകി - നമുക്ക് ഓർക്കാം session_id - ഞങ്ങൾക്ക് ഉറപ്പുണ്ട്: ഒരു സാഹചര്യത്തിലും ഒരു സെഷനു വേണ്ടിയുള്ള സന്ദേശം മറ്റൊരു സെഷനിലേക്ക് അയയ്ക്കാൻ കഴിയില്ല. അതായത്, ഇതിനകം ഉണ്ടെന്ന് മാറുന്നു മൂന്ന് ലെവൽ - സെഷൻ, സെഷൻ നമ്പർ, സന്ദേശ ഐഡി. എന്തുകൊണ്ടാണ് അത്തരം അമിത സങ്കീർണ്ണത, ഈ രഹസ്യം വളരെ വലുതാണ്.

അങ്ങനെയാണെങ്കിൽ, msg_id ആവശ്യമായ...

RPC: അഭ്യർത്ഥനകൾ, പ്രതികരണങ്ങൾ, പിശകുകൾ. സ്ഥിരീകരണങ്ങൾ.

നിങ്ങൾ ശ്രദ്ധിച്ചിരിക്കാം, ഉത്തരങ്ങൾ ഉണ്ടെങ്കിലും ഡയഗ്രാമിൽ എവിടെയും പ്രത്യേക "ആർപിസി അഭ്യർത്ഥന ഉണ്ടാക്കുക" തരമോ പ്രവർത്തനമോ ഇല്ല. എല്ലാത്തിനുമുപരി, ഞങ്ങൾക്ക് ഉള്ളടക്കവുമായി ബന്ധപ്പെട്ട സന്ദേശങ്ങളുണ്ട്! അതാണ്, ഏതെങ്കിലും സന്ദേശം ഒരു അഭ്യർത്ഥനയായിരിക്കാം! അല്ലെങ്കിൽ ആകരുത്. എല്ലാത്തിനുമുപരി, ഓരോന്നും ആകുന്നു msg_id. എന്നാൽ ഉത്തരങ്ങളുണ്ട്:

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

ഇത് ഏത് സന്ദേശത്തിനാണ് പ്രതികരണമെന്ന് സൂചിപ്പിക്കുന്നത് ഇവിടെയാണ്. അതിനാൽ, API-യുടെ ഉയർന്ന തലത്തിൽ, നിങ്ങളുടെ അഭ്യർത്ഥനയുടെ നമ്പർ എന്താണെന്ന് നിങ്ങൾ ഓർമ്മിക്കേണ്ടതുണ്ട് - ജോലി അസമന്വിതമാണെന്നും ഒരേ സമയം നിരവധി അഭ്യർത്ഥനകൾ പുരോഗമിക്കുമെന്നും വിശദീകരിക്കേണ്ട ആവശ്യമില്ലെന്ന് ഞാൻ കരുതുന്നു, ഏത് ക്രമത്തിലും നൽകാവുന്ന ഉത്തരങ്ങൾ? തത്വത്തിൽ, ഇതിൽ നിന്നും തൊഴിലാളികളില്ല എന്ന പിശക് സന്ദേശങ്ങളിൽ നിന്നും, ഇതിന് പിന്നിലെ ആർക്കിടെക്ചർ കണ്ടെത്താനാകും: നിങ്ങളുമായി ഒരു TCP കണക്ഷൻ നിലനിർത്തുന്ന സെർവർ ഒരു ഫ്രണ്ട്-എൻഡ് ബാലൻസറാണ്, ഇത് ബാക്ക്‌എൻഡുകളിലേക്ക് അഭ്യർത്ഥനകൾ കൈമാറുകയും അവ വഴി തിരികെ ശേഖരിക്കുകയും ചെയ്യുന്നു. message_id. ഇവിടെ എല്ലാം വ്യക്തവും യുക്തിസഹവും നല്ലതുമാണെന്ന് തോന്നുന്നു.

അതെ?.. പിന്നെ ആലോചിച്ചാലോ? എല്ലാത്തിനുമുപരി, RPC പ്രതികരണത്തിനും ഒരു ഫീൽഡ് ഉണ്ട് msg_id! “എന്റെ ഉത്തരത്തിന് നിങ്ങൾ ഉത്തരം നൽകുന്നില്ല!” എന്ന് ഞങ്ങൾ സെർവറിനോട് ആക്രോശിക്കേണ്ടതുണ്ടോ? അതെ, സ്ഥിരീകരണങ്ങളെക്കുറിച്ച് എന്താണ് ഉണ്ടായിരുന്നത്? പേജിനെക്കുറിച്ച് സന്ദേശങ്ങളെക്കുറിച്ചുള്ള സന്ദേശങ്ങൾ എന്താണെന്ന് നമ്മോട് പറയുന്നു

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

അതു ഓരോ ഭാഗത്തും ചെയ്യണം. എന്നാൽ എല്ലായ്പ്പോഴും അല്ല! നിങ്ങൾക്ക് ഒരു RpcResult ലഭിച്ചാൽ, അത് തന്നെ ഒരു സ്ഥിരീകരണമായി വർത്തിക്കുന്നു. അതായത്, സെർവറിന് നിങ്ങളുടെ അഭ്യർത്ഥനയോട് MsgsAck ഉപയോഗിച്ച് പ്രതികരിക്കാൻ കഴിയും - "എനിക്കിത് ലഭിച്ചു." RpcResult ഉടനടി പ്രതികരിക്കാൻ കഴിയും. അത് രണ്ടും ആകാം.

അതെ, നിങ്ങൾ ഇപ്പോഴും ഉത്തരം നൽകേണ്ടതുണ്ട്! സ്ഥിരീകരണം. അല്ലെങ്കിൽ, സെർവർ അത് വിതരണം ചെയ്യാൻ കഴിയില്ലെന്ന് കണക്കാക്കുകയും അത് നിങ്ങൾക്ക് വീണ്ടും അയയ്ക്കുകയും ചെയ്യും. വീണ്ടും ബന്ധിപ്പിച്ചതിനു ശേഷവും. എന്നാൽ ഇവിടെ, തീർച്ചയായും, സമയപരിധിയുടെ പ്രശ്നം ഉയർന്നുവരുന്നു. നമുക്ക് അവരെ കുറച്ച് കഴിഞ്ഞ് നോക്കാം.

അതിനിടയിൽ, സാധ്യമായ ചോദ്യ നിർവ്വഹണ പിശകുകൾ നോക്കാം.

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

ഓ, ആരെങ്കിലും ആക്രോശിക്കും, ഇവിടെ കൂടുതൽ മാനുഷികമായ ഒരു ഫോർമാറ്റ് ഉണ്ട് - ഒരു വരിയുണ്ട്! നിനക്കാവശ്യത്തിനുള്ള സമയമെടുക്കുക. ഇവിടെ പിശകുകളുടെ പട്ടിക, എന്നാൽ തീർച്ചയായും പൂർണ്ണമല്ല. അതിൽ നിന്നാണ് കോഡ് എന്ന് മനസ്സിലാക്കുന്നത് അതുപോലത്തെ HTTP പിശകുകൾ (തീർച്ചയായും, പ്രതികരണങ്ങളുടെ സെമാന്റിക്‌സ് മാനിക്കപ്പെടുന്നില്ല, ചില സ്ഥലങ്ങളിൽ അവ ക്രമരഹിതമായി കോഡുകൾക്കിടയിൽ വിതരണം ചെയ്യപ്പെടുന്നു), കൂടാതെ ലൈൻ ഇതുപോലെ കാണപ്പെടുന്നു CAPITAL_LETTERS_AND_NUMBERS. ഉദാഹരണത്തിന്, PHONE_NUMBER_OCCUPIED അല്ലെങ്കിൽ FILE_PART_Х_MISSING. ശരി, അതായത്, നിങ്ങൾക്ക് ഇപ്പോഴും ഈ ലൈൻ ആവശ്യമാണ് പാഴ്സ്. ഉദാഹരണത്തിന്, FLOOD_WAIT_3600 നിങ്ങൾ ഒരു മണിക്കൂർ കാത്തിരിക്കണം എന്നാണ് അർത്ഥമാക്കുന്നത് PHONE_MIGRATE_5, ഈ പ്രിഫിക്സുള്ള ഒരു ടെലിഫോൺ നമ്പർ 5-ാം ഡിസിയിൽ രജിസ്റ്റർ ചെയ്തിരിക്കണം. ഞങ്ങൾക്ക് ഒരു തരം ഭാഷയുണ്ട്, അല്ലേ? ഞങ്ങൾക്ക് ഒരു സ്ട്രിംഗിൽ നിന്ന് ഒരു വാദം ആവശ്യമില്ല, പതിവുള്ളവർ ചെയ്യും, ശരി.

വീണ്ടും, ഇത് സേവന സന്ദേശങ്ങളുടെ പേജിലല്ല, പക്ഷേ, ഈ പ്രോജക്റ്റിൽ ഇതിനകം പതിവുള്ളതുപോലെ, വിവരങ്ങൾ കണ്ടെത്താനാകും മറ്റൊരു ഡോക്യുമെന്റേഷൻ പേജിൽ. അല്ലെങ്കിൽ സംശയം ജനിപ്പിക്കുന്നു. ഒന്നാമതായി, നോക്കൂ, ടൈപ്പിംഗ്/ലെയർ ലംഘനം - RpcError കൂടുണ്ടാക്കാം RpcResult. എന്തുകൊണ്ട് പുറത്ത് പാടില്ല? എന്താണ് നമ്മൾ കണക്കിലെടുക്കാത്തത്?.. അതനുസരിച്ച്, എവിടെയാണ് ഗ്യാരണ്ടി RpcError ഉൾച്ചേർത്തിരിക്കില്ല RpcResult, എന്നാൽ നേരിട്ട് അല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ കൂടുകയാണോ?.. അതിനു കഴിയുന്നില്ലെങ്കിൽ, എന്തുകൊണ്ട് അത് ഉയർന്ന തലത്തിൽ അല്ല, അതായത്. അതു കാണുന്നില്ല req_msg_id ? ..

എന്നാൽ സേവന സന്ദേശങ്ങളെക്കുറിച്ച് നമുക്ക് തുടരാം. സെർവർ വളരെക്കാലമായി ചിന്തിക്കുകയാണെന്ന് ക്ലയന്റ് ചിന്തിച്ചേക്കാം, കൂടാതെ ഈ അത്ഭുതകരമായ അഭ്യർത്ഥന നടത്തുക:

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

ഈ ചോദ്യത്തിന് സാധ്യമായ മൂന്ന് ഉത്തരങ്ങളുണ്ട്, വീണ്ടും സ്ഥിരീകരണ സംവിധാനവുമായി വിഭജിക്കുന്നു; അവ എന്തായിരിക്കണമെന്ന് മനസിലാക്കാൻ ശ്രമിക്കുന്നു (സ്ഥിരീകരണം ആവശ്യമില്ലാത്ത തരങ്ങളുടെ പൊതുവായ ലിസ്റ്റ് എന്താണെന്ന്) ഗൃഹപാഠമായി വായനക്കാരന് അവശേഷിക്കുന്നു (ശ്രദ്ധിക്കുക: വിവരങ്ങൾ ടെലിഗ്രാം ഡെസ്ക്ടോപ്പ് സോഴ്സ് കോഡ് പൂർത്തിയായിട്ടില്ല).

മയക്കുമരുന്ന് ആസക്തി: സന്ദേശ നിലകൾ

പൊതുവേ, TL, MTPproto, ടെലിഗ്രാം എന്നിവയിലെ പല സ്ഥലങ്ങളും പൊതുവെ ശാഠ്യത്തിന്റെ ഒരു വികാരം അവശേഷിപ്പിക്കുന്നു, എന്നാൽ മര്യാദ, നയം, മറ്റുള്ളവ എന്നിവ കാരണം മൃദു കഴിവുകൾ ഞങ്ങൾ അതിനെക്കുറിച്ച് മാന്യമായി മൗനം പാലിക്കുകയും സംഭാഷണങ്ങളിലെ അശ്ലീലങ്ങൾ സെൻസർ ചെയ്യുകയും ചെയ്തു. എന്നിരുന്നാലും, ഈ സ്ഥലംОപേജിന്റെ ഭൂരിഭാഗവും ഏകദേശം സന്ദേശങ്ങളെക്കുറിച്ചുള്ള സന്ദേശങ്ങൾ വളരെക്കാലമായി നെറ്റ്‌വർക്ക് പ്രോട്ടോക്കോളുകളുമായി പ്രവർത്തിക്കുകയും വ്യത്യസ്ത അളവിലുള്ള വക്രതയുടെ സൈക്കിളുകൾ കാണുകയും ചെയ്ത എനിക്ക് പോലും ഇത് ഞെട്ടിക്കുന്നതാണ്.

സ്ഥിരീകരണങ്ങളോടെ ഇത് നിരുപദ്രവകരമായി ആരംഭിക്കുന്നു. അടുത്തതായി അവർ ഞങ്ങളോട് പറയുന്നു

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 ന്റെ ചെവികൾ വീണ്ടും പുറത്തേക്ക് തള്ളിനിൽക്കുന്നു (ഞങ്ങൾക്ക് ബൈറ്റുകളുടെ ഒരു വെക്റ്റർ ആവശ്യമാണ്, താഴെയുള്ള രണ്ട് ബിറ്റുകളിൽ ഒരു enum ഉണ്ടായിരുന്നു, ഉയർന്ന രണ്ട് ബിറ്റുകളിൽ ഫ്ലാഗുകൾ ഉണ്ടായിരുന്നു). കാര്യം വേറെയാണ്. ഇതൊക്കെ എന്തിനാണ് പ്രയോഗത്തിലുള്ളതെന്ന് ആർക്കെങ്കിലും മനസ്സിലായോ? ഒരു യഥാർത്ഥ ക്ലയന്റിൽ ആവശ്യമുണ്ടോ?.. പ്രയാസത്തോടെ, എന്നാൽ ഒരാൾ ഡീബഗ്ഗിംഗിൽ ഏർപ്പെട്ടിരിക്കുകയും ഒരു സംവേദനാത്മക മോഡിൽ ഏർപ്പെട്ടിരിക്കുകയും ചെയ്താൽ എന്തെങ്കിലും പ്രയോജനം സങ്കൽപ്പിക്കാൻ കഴിയും - സെർവറിനോട് എന്താണ്, എങ്ങനെ എന്ന് ചോദിക്കുക. എന്നാൽ ഇവിടെ അഭ്യർത്ഥനകൾ വിവരിക്കുന്നു റൗണ്ട് ട്രിപ്പ്.

ഓരോ കക്ഷിയും സന്ദേശങ്ങൾ എൻക്രിപ്റ്റ് ചെയ്യുകയും അയക്കുകയും ചെയ്യുക മാത്രമല്ല, തങ്ങളെ കുറിച്ചുള്ള വിവരങ്ങളും അവരോടുള്ള പ്രതികരണങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങളും അജ്ഞാതമായ സമയത്തേക്ക് സംഭരിക്കുകയും വേണം. ഡോക്യുമെന്റേഷൻ ഈ സവിശേഷതകളുടെ സമയത്തെയോ പ്രായോഗിക പ്രയോഗത്തെയോ വിവരിക്കുന്നില്ല. ഒന്നുമില്ല. ഏറ്റവും അത്ഭുതകരമായ കാര്യം, അവ യഥാർത്ഥത്തിൽ ഔദ്യോഗിക ക്ലയന്റുകളുടെ കോഡിൽ ഉപയോഗിക്കുന്നു എന്നതാണ്! പബ്ലിക് ഡോക്യുമെന്റേഷനിൽ ഉൾപ്പെടുത്താത്ത ചിലത് അവരോട് പറഞ്ഞതായി തോന്നുന്നു. കോഡിൽ നിന്ന് മനസ്സിലാക്കുക എന്തുകൊണ്ട്, TL-ന്റെ കാര്യത്തിലെന്നപോലെ ലളിതമല്ല - ഇത് ഒരു (താരതമ്യേന) യുക്തിപരമായി ഒറ്റപ്പെട്ട ഭാഗമല്ല, മറിച്ച് ആപ്ലിക്കേഷൻ ആർക്കിടെക്ചറുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന ഒരു ഭാഗമാണ്, അതായത്. ആപ്ലിക്കേഷൻ കോഡ് മനസ്സിലാക്കാൻ കൂടുതൽ സമയം വേണ്ടിവരും.

പിംഗുകളും സമയവും. ക്യൂകൾ.

എല്ലാത്തിൽ നിന്നും, സെർവർ ആർക്കിടെക്ചറിനെക്കുറിച്ചുള്ള ഊഹങ്ങൾ (ബാക്കെൻഡുകളിലുടനീളം അഭ്യർത്ഥനകളുടെ വിതരണം) ഞങ്ങൾ ഓർക്കുന്നുവെങ്കിൽ, വളരെ സങ്കടകരമായ ഒരു കാര്യം പിന്തുടരുന്നു - TCP-യിലെ എല്ലാ ഡെലിവറി ഗ്യാരന്റികളും ഉണ്ടായിരുന്നിട്ടും (ഒന്നുകിൽ ഡാറ്റ ഡെലിവർ ചെയ്‌തിരിക്കുന്നു, അല്ലെങ്കിൽ നിങ്ങളെ വിടവിനെക്കുറിച്ച് നിങ്ങളെ അറിയിക്കും, പക്ഷേ പ്രശ്നം ഉണ്ടാകുന്നതിന് മുമ്പ് ഡാറ്റ ഡെലിവർ ചെയ്യും), MTPproto-യിലെ തന്നെ സ്ഥിരീകരണങ്ങൾ - യാതൊരു ഉറപ്പുമില്ല. സെർവറിന് നിങ്ങളുടെ സന്ദേശം എളുപ്പത്തിൽ നഷ്‌ടപ്പെടാനോ വലിച്ചെറിയാനോ കഴിയും, അതിനെക്കുറിച്ച് ഒന്നും ചെയ്യാൻ കഴിയില്ല, വ്യത്യസ്ത തരം ക്രച്ചുകൾ ഉപയോഗിക്കുക.

ഒന്നാമതായി - സന്ദേശ ക്യൂകൾ. ശരി, ഒരു കാര്യം കൊണ്ട് തുടക്കം മുതൽ എല്ലാം വ്യക്തമായിരുന്നു - സ്ഥിരീകരിക്കാത്ത ഒരു സന്ദേശം സംഭരിക്കുകയും വീണ്ടും അയയ്ക്കുകയും വേണം. പിന്നെ എത്ര സമയം കഴിഞ്ഞ്? തമാശക്കാരന് അവനെ അറിയാം. ഒരുപക്ഷേ ആ അഡിക്റ്റഡ് സേവന സന്ദേശങ്ങൾ ക്രച്ചസ് ഉപയോഗിച്ച് ഈ പ്രശ്നം എങ്ങനെയെങ്കിലും പരിഹരിക്കും, പറയുക, ടെലിഗ്രാം ഡെസ്ക്ടോപ്പിൽ അവയുമായി ബന്ധപ്പെട്ട ഏകദേശം 4 ക്യൂകളുണ്ട് (ഒരുപക്ഷേ കൂടുതൽ, ഇതിനകം സൂചിപ്പിച്ചതുപോലെ, ഇതിനായി നിങ്ങൾ അതിന്റെ കോഡും ആർക്കിടെക്ചറും കൂടുതൽ ഗൗരവമായി പരിശോധിക്കേണ്ടതുണ്ട്; അതേ സമയം. സമയം, ഇത് ഒരു സാമ്പിളായി എടുക്കാൻ കഴിയില്ലെന്ന് ഞങ്ങൾക്കറിയാം; MTPproto സ്കീമിൽ നിന്നുള്ള ഒരു നിശ്ചിത എണ്ണം തരങ്ങൾ അതിൽ ഉപയോഗിച്ചിട്ടില്ല).

എന്തുകൊണ്ടാണ് ഇത് സംഭവിക്കുന്നത്? ഒരുപക്ഷേ, സെർവർ പ്രോഗ്രാമർമാർക്ക് ക്ലസ്റ്ററിനുള്ളിൽ വിശ്വാസ്യത ഉറപ്പാക്കാൻ കഴിഞ്ഞില്ല, അല്ലെങ്കിൽ ഫ്രണ്ട് ബാലൻസറിൽ ബഫറിംഗ് പോലും, ഈ പ്രശ്നം ക്ലയന്റിലേക്ക് മാറ്റി. നിരാശയിൽ നിന്ന്, വാസിലി ഒരു ബദൽ ഓപ്ഷൻ നടപ്പിലാക്കാൻ ശ്രമിച്ചു, രണ്ട് ക്യൂകൾ മാത്രം, ടിസിപിയിൽ നിന്നുള്ള അൽഗോരിതം ഉപയോഗിച്ച് - സെർവറിലേക്ക് RTT അളക്കുക, സ്ഥിരീകരിക്കാത്ത അഭ്യർത്ഥനകളുടെ എണ്ണം അനുസരിച്ച് "വിൻഡോ" (സന്ദേശങ്ങളിൽ) വലുപ്പം ക്രമീകരിക്കുക. അതായത്, സെർവറിന്റെ ലോഡ് വിലയിരുത്തുന്നതിനുള്ള ഒരു പരുക്കൻ ഹ്യൂറിസ്റ്റിക്, ഞങ്ങളുടെ എത്ര അഭ്യർത്ഥനകൾ ഒരേ സമയം ചവച്ചരച്ച് നഷ്‌ടപ്പെടില്ല എന്നതാണ്.

ശരി, അതായത്, നിങ്ങൾ മനസ്സിലാക്കുന്നു, അല്ലേ? ടിസിപിയിൽ പ്രവർത്തിക്കുന്ന ഒരു പ്രോട്ടോക്കോളിനു മുകളിൽ വീണ്ടും ടിസിപി നടപ്പിലാക്കണമെങ്കിൽ, ഇത് വളരെ മോശമായി രൂപകൽപ്പന ചെയ്ത പ്രോട്ടോക്കോൾ സൂചിപ്പിക്കുന്നു.

ഓ, നിങ്ങൾക്ക് എന്തിന് ഒന്നിലധികം ക്യൂ ആവശ്യമാണ്, എന്തായാലും ഉയർന്ന തലത്തിലുള്ള API ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന ഒരു വ്യക്തിക്ക് ഇത് എന്താണ് അർത്ഥമാക്കുന്നത്? നോക്കൂ, നിങ്ങൾ ഒരു അഭ്യർത്ഥന നടത്തുന്നു, അത് സീരിയലൈസ് ചെയ്യുന്നു, പക്ഷേ പലപ്പോഴും നിങ്ങൾക്ക് അത് ഉടനടി അയയ്ക്കാൻ കഴിയില്ല. എന്തുകൊണ്ട്? കാരണം ഉത്തരം ആയിരിക്കും msg_id, ഇത് താൽക്കാലികമാണ്аഞാനൊരു ലേബലാണ്, അസൈൻമെന്റ് കഴിയുന്നത്ര വൈകുന്നത് വരെ നീട്ടിവെക്കുന്നതാണ് നല്ലത് - നമ്മളും അവനും തമ്മിലുള്ള സമയ പൊരുത്തക്കേട് കാരണം സെർവർ അത് നിരസിച്ചാൽ (തീർച്ചയായും, നമ്മുടെ സമയത്തെ വർത്തമാനത്തിൽ നിന്ന് മാറ്റുന്ന ഒരു ഊന്നുവടി ഉണ്ടാക്കാം. സെർവറിന്റെ പ്രതികരണങ്ങളിൽ നിന്ന് കണക്കാക്കിയ ഒരു ഡെൽറ്റ ചേർത്ത് സെർവറിലേക്ക് - ഔദ്യോഗിക ക്ലയന്റുകളാണ് ഇത് ചെയ്യുന്നത്, പക്ഷേ ബഫറിംഗ് കാരണം ഇത് അസംസ്കൃതവും കൃത്യമല്ലാത്തതുമാണ്). അതിനാൽ, ലൈബ്രറിയിൽ നിന്ന് ഒരു ലോക്കൽ ഫംഗ്‌ഷൻ കോൾ ഉപയോഗിച്ച് നിങ്ങൾ ഒരു അഭ്യർത്ഥന നടത്തുമ്പോൾ, സന്ദേശം ഇനിപ്പറയുന്ന ഘട്ടങ്ങളിലൂടെ കടന്നുപോകുന്നു:

1. ഇത് ഒരു ക്യൂവിൽ കിടക്കുന്നു, എൻക്രിപ്ഷൻ കാത്തിരിക്കുന്നു.
2. നിയമിച്ചു msg_id സന്ദേശം മറ്റൊരു ക്യൂവിലേക്ക് പോയി - ഫോർവേഡിംഗ് സാധ്യമാണ്; സോക്കറ്റിലേക്ക് അയയ്ക്കുക.
3. a) സെർവർ MsgsAck പ്രതികരിച്ചു - സന്ദേശം കൈമാറി, ഞങ്ങൾ അത് "മറ്റ് ക്യൂവിൽ" നിന്ന് ഇല്ലാതാക്കുന്നു.
   b) അല്ലെങ്കിൽ തിരിച്ചും, അയാൾക്ക് എന്തെങ്കിലും ഇഷ്ടപ്പെട്ടില്ല, അവൻ ബാഡ്‌ംസ്ജിന് ഉത്തരം നൽകി - “മറ്റൊരു ക്യൂവിൽ” നിന്ന് വീണ്ടും അയയ്‌ക്കുക
   c) ഒന്നും അറിയില്ല, സന്ദേശം മറ്റൊരു ക്യൂവിൽ നിന്ന് വീണ്ടും അയയ്ക്കേണ്ടതുണ്ട് - എന്നാൽ എപ്പോഴാണെന്ന് കൃത്യമായി അറിയില്ല.
4. സെർവർ ഒടുവിൽ പ്രതികരിച്ചു RpcResult - യഥാർത്ഥ പ്രതികരണം (അല്ലെങ്കിൽ പിശക്) - ഡെലിവർ ചെയ്യപ്പെടുക മാത്രമല്ല, പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു.

മിക്കവാറും, കണ്ടെയ്നറുകളുടെ ഉപയോഗം ഭാഗികമായി പ്രശ്നം പരിഹരിക്കും. ഒരു കൂട്ടം സന്ദേശങ്ങൾ ഒന്നായി പാക്ക് ചെയ്യുമ്പോൾ, സെർവർ അവയ്‌ക്കെല്ലാം ഒരേസമയം ഒരു സ്ഥിരീകരണത്തോടെ പ്രതികരിച്ചു. msg_id. പക്ഷേ, എന്തെങ്കിലും തെറ്റ് സംഭവിച്ചാൽ, അവൻ ഈ പായ്ക്ക് പൂർണ്ണമായും നിരസിക്കും.

ഈ ഘട്ടത്തിൽ സാങ്കേതികമല്ലാത്ത പരിഗണനകൾ പ്രവർത്തിക്കുന്നു. അനുഭവത്തിൽ നിന്ന്, ഞങ്ങൾ നിരവധി ഊന്നുവടികൾ കണ്ടിട്ടുണ്ട്, കൂടാതെ, മോശം ഉപദേശത്തിന്റെയും വാസ്തുവിദ്യയുടെയും കൂടുതൽ ഉദാഹരണങ്ങൾ ഞങ്ങൾ ഇപ്പോൾ കാണും - അത്തരം സാഹചര്യങ്ങളിൽ, വിശ്വസിക്കുന്നതും അത്തരം തീരുമാനങ്ങൾ എടുക്കുന്നതും മൂല്യവത്താണോ? ചോദ്യം വാചാടോപമാണ് (തീർച്ചയായും അല്ല).

നമ്മൾ എന്തിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്? "സന്ദേശങ്ങളെക്കുറിച്ചുള്ള മയക്കുമരുന്ന് സന്ദേശങ്ങൾ" എന്ന വിഷയത്തിൽ "നിങ്ങൾ വിഡ്ഢിയാണ്, ഞങ്ങളുടെ മികച്ച പദ്ധതി നിങ്ങൾക്ക് മനസ്സിലായില്ല!" എന്നതുപോലുള്ള എതിർപ്പുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇപ്പോഴും ഊഹിക്കാം. (സാധാരണ ആളുകൾ ചെയ്യേണ്ടത് പോലെ ആദ്യം ഡോക്യുമെന്റേഷൻ എഴുതുക, പാക്കറ്റ് എക്സ്ചേഞ്ചിന്റെ യുക്തിയും ഉദാഹരണങ്ങളും സഹിതം, പിന്നെ ഞങ്ങൾ സംസാരിക്കും), തുടർന്ന് സമയങ്ങൾ/സമയപരിധികൾ തികച്ചും പ്രായോഗികവും നിർദ്ദിഷ്ടവുമായ ചോദ്യമാണ്, ഇവിടെയുള്ളതെല്ലാം വളരെക്കാലമായി അറിയപ്പെടുന്നു. കാലഹരണപ്പെടലിനെക്കുറിച്ച് ഡോക്യുമെന്റേഷൻ നമ്മോട് എന്താണ് പറയുന്നത്?

ഒരു RPC പ്രതികരണം ഉപയോഗിച്ച് ഒരു ക്ലയന്റിൽ നിന്ന് (സാധാരണയായി, ഒരു RPC അന്വേഷണം) ഒരു സന്ദേശത്തിന്റെ രസീത് ഒരു സെർവർ സാധാരണയായി അംഗീകരിക്കുന്നു. ഒരു പ്രതികരണം വളരെക്കാലം നീണ്ടുനിൽക്കുകയാണെങ്കിൽ, ഒരു സെർവർ ആദ്യം ഒരു രസീത് അക്നോളജ്മെന്റ് അയച്ചേക്കാം, കുറച്ച് കഴിഞ്ഞ്, RPC പ്രതികരണം തന്നെ.

ഒരു സെർവറിൽ നിന്നുള്ള സന്ദേശത്തിന്റെ രസീത് (സാധാരണയായി, ഒരു RPC പ്രതികരണം) ഒരു ക്ലയന്റ് സാധാരണയായി അംഗീകരിക്കുന്നു, അത് വളരെ വൈകി കൈമാറിയില്ലെങ്കിൽ (അത് ജനറേറ്റ് ചെയ്താൽ, രസീത് കഴിഞ്ഞ് 60-120 സെക്കൻഡ് കഴിഞ്ഞ്, അടുത്ത RPC അന്വേഷണത്തിലേക്ക് ഒരു അംഗീകാരം ചേർക്കുക. സെർവറിൽ നിന്നുള്ള ഒരു സന്ദേശം). എന്നിരുന്നാലും, ദീർഘനാളത്തേക്ക് സെർവറിലേക്ക് സന്ദേശങ്ങൾ അയയ്‌ക്കുന്നതിന് കാരണമില്ലെങ്കിൽ അല്ലെങ്കിൽ സെർവറിൽ നിന്ന് ധാരാളം അംഗീകൃതമല്ലാത്ത സന്ദേശങ്ങൾ ഉണ്ടെങ്കിൽ (പറയുക, 16-ലധികം), ക്ലയന്റ് ഒരു സ്റ്റാൻഡ്-എലോൺ അംഗീകാരം കൈമാറുന്നു.

... ഞാൻ വിവർത്തനം ചെയ്യുന്നു: നമുക്ക് അത് എത്രയാണെന്നും എങ്ങനെ വേണമെന്നും നമുക്ക് തന്നെ അറിയില്ല, അതിനാൽ ഇത് ഇതുപോലെ ആയിരിക്കട്ടെ എന്ന് നമുക്ക് അനുമാനിക്കാം.

പിംഗുകളെക്കുറിച്ച്:

പിംഗ് സന്ദേശങ്ങൾ (PING/PONG)

ping#7abe77ec ping_id:long = Pong;

ഒരു പ്രതികരണം സാധാരണയായി അതേ കണക്ഷനിലേക്ക് തിരികെ നൽകും:

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

ഈ സന്ദേശങ്ങൾക്ക് അംഗീകാരങ്ങൾ ആവശ്യമില്ല. ഒരു പിങ്ങിന്റെ പ്രതികരണമായി മാത്രമേ ഒരു പോംഗ് കൈമാറ്റം ചെയ്യപ്പെടുകയുള്ളൂ, ഒരു പിംഗ് ഇരുവശത്തും ആരംഭിക്കാൻ കഴിയും.

മാറ്റിവച്ച കണക്ഷൻ ക്ലോഷർ + PING

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

പിംഗ് പോലെ പ്രവർത്തിക്കുന്നു. കൂടാതെ, ഇത് ലഭിച്ചതിന് ശേഷം, സെർവർ ഒരു ടൈമർ ആരംഭിക്കുന്നു, അത് മുമ്പത്തെ എല്ലാ ടൈമറുകളും സ്വയമേവ പുനഃസജ്ജമാക്കുന്ന അതേ തരത്തിലുള്ള ഒരു പുതിയ സന്ദേശം ലഭിച്ചില്ലെങ്കിൽ, നിലവിലെ കണക്ഷൻ disconnect_delay സെക്കൻഡുകൾക്ക് ശേഷം അത് അടയ്ക്കും. ക്ലയന്റ് ഓരോ 60 സെക്കൻഡിലും ഒരിക്കൽ ഈ പിംഗുകൾ അയയ്ക്കുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, അത് 75 സെക്കൻഡിന് തുല്യമായ disconnect_delay സജ്ജമാക്കിയേക്കാം.

നിനക്ക് ഭ്രാന്താണോ?! 60 സെക്കൻഡുകൾക്കുള്ളിൽ, ട്രെയിൻ സ്റ്റേഷനിൽ പ്രവേശിക്കുകയും യാത്രക്കാരെ ഇറക്കുകയും കയറ്റുകയും ചെയ്യും, വീണ്ടും ടണലിലെ ബന്ധം നഷ്ടപ്പെടും. 120 സെക്കൻഡിനുള്ളിൽ, നിങ്ങൾ അത് കേൾക്കുമ്പോൾ, അത് മറ്റൊന്നിൽ എത്തും, കണക്ഷൻ മിക്കവാറും തകരും. ശരി, കാലുകൾ എവിടെ നിന്നാണ് വരുന്നതെന്ന് വ്യക്തമാണ് - “ഞാൻ ഒരു റിംഗിംഗ് കേട്ടു, പക്ഷേ അത് എവിടെയാണെന്ന് അറിയില്ല”, അവിടെ നാഗലിന്റെ അൽഗോരിതം, സംവേദനാത്മക ജോലികൾക്കായി ഉദ്ദേശിച്ചുള്ള TCP_NODELAY ഓപ്ഷനും ഉണ്ട്. പക്ഷേ, ക്ഷമിക്കണം, അതിന്റെ ഡിഫോൾട്ട് മൂല്യം - 200 മുറുകെ പിടിക്കുക മില്ലിസെക്കന്റുകൾ നിങ്ങൾക്ക് ശരിക്കും സമാനമായ എന്തെങ്കിലും ചിത്രീകരിക്കാനും സാധ്യമായ രണ്ട് പാക്കറ്റുകളിൽ സംരക്ഷിക്കാനും താൽപ്പര്യമുണ്ടെങ്കിൽ, അത് 5 സെക്കൻഡ് നേരത്തേക്ക് മാറ്റിവെക്കുക, അല്ലെങ്കിൽ “ഉപയോക്താവ് ടൈപ്പ് ചെയ്യുന്നു...” എന്ന സന്ദേശത്തിന്റെ സമയപരിധി ഇപ്പോൾ. പക്ഷേ ഇനി വേണ്ട.

ഒടുവിൽ, പിംഗ്സ്. അതായത്, ടിസിപി കണക്ഷന്റെ ലൈവ്നെസ് പരിശോധിക്കുന്നു. ഇത് തമാശയാണ്, പക്ഷേ ഏകദേശം 10 വർഷം മുമ്പ് ഞാൻ ഞങ്ങളുടെ ഫാക്കൽറ്റിയുടെ ഡോമിലെ സന്ദേശവാഹകനെക്കുറിച്ച് ഒരു വിമർശനാത്മക വാചകം എഴുതി - അവിടെയുള്ള രചയിതാക്കളും ക്ലയന്റിൽ നിന്ന് സെർവറിനെ പിംഗ് ചെയ്തു, തിരിച്ചും അല്ല. എന്നാൽ മൂന്നാം വർഷ വിദ്യാർത്ഥികൾ ഒരു കാര്യമാണ്, ഒരു അന്താരാഷ്ട്ര ഓഫീസ് മറ്റൊന്നാണ്, അല്ലേ?

ആദ്യം, ഒരു ചെറിയ വിദ്യാഭ്യാസ പരിപാടി. ഒരു ടിസിപി കണക്ഷൻ, പാക്കറ്റ് എക്സ്ചേഞ്ചിന്റെ അഭാവത്തിൽ, ആഴ്ചകളോളം ജീവിക്കാം. ഉദ്ദേശ്യത്തെ ആശ്രയിച്ച് ഇത് നല്ലതും ചീത്തയുമാണ്. നിങ്ങൾക്ക് സെർവറിലേക്ക് ഒരു SSH കണക്ഷൻ തുറന്നിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾ കമ്പ്യൂട്ടറിൽ നിന്ന് എഴുന്നേറ്റു, റൂട്ടർ റീബൂട്ട് ചെയ്തു, നിങ്ങളുടെ സ്ഥലത്തേക്ക് മടങ്ങിയെത്തുന്നത് നല്ലതാണ് - ഈ സെർവറിലൂടെയുള്ള സെഷൻ കീറിയില്ല (നിങ്ങൾ ഒന്നും ടൈപ്പ് ചെയ്തില്ല, പാക്കറ്റുകളൊന്നുമില്ല) , അത് സൗകര്യപ്രദമാണ്. സെർവറിൽ ആയിരക്കണക്കിന് ക്ലയന്റുകളുണ്ടെങ്കിൽ അത് മോശമാണ്, ഓരോരുത്തരും റിസോഴ്‌സുകൾ (ഹലോ, പോസ്റ്റ്‌ഗ്രെസ്!) ഏറ്റെടുക്കുന്നു, കൂടാതെ ക്ലയന്റിന്റെ ഹോസ്റ്റ് വളരെക്കാലം മുമ്പ് റീബൂട്ട് ചെയ്തിരിക്കാം - പക്ഷേ ഞങ്ങൾക്ക് അതിനെക്കുറിച്ച് അറിയില്ല.

ഒരു അധിക കാരണത്താൽ ചാറ്റ്/ഐഎം സിസ്റ്റങ്ങൾ രണ്ടാമത്തെ കേസിൽ ഉൾപ്പെടുന്നു - ഓൺലൈൻ സ്റ്റാറ്റസുകൾ. ഉപയോക്താവ് “വീണുപോയി” എങ്കിൽ, നിങ്ങൾ ഇതിനെക്കുറിച്ച് അവന്റെ സംഭാഷകരെ അറിയിക്കേണ്ടതുണ്ട്. അല്ലാത്തപക്ഷം, ജബ്ബറിന്റെ സ്രഷ്‌ടാക്കൾ വരുത്തിയ (20 വർഷത്തേക്ക് തിരുത്തിയ) ഒരു തെറ്റിൽ നിങ്ങൾ അവസാനിക്കും - ഉപയോക്താവ് വിച്ഛേദിച്ചു, പക്ഷേ അവൻ ഓൺലൈനിലാണെന്ന് വിശ്വസിച്ച് അവർ അദ്ദേഹത്തിന് സന്ദേശങ്ങൾ എഴുതുന്നത് തുടരുന്നു (ഇവയും ഇവയിൽ പൂർണ്ണമായും നഷ്ടപ്പെട്ടു. വിച്ഛേദിക്കുന്നത് കണ്ടെത്തുന്നതിന് കുറച്ച് മിനിറ്റ് മുമ്പ്). ഇല്ല, TCP_KEEPALIVE ഓപ്ഷൻ, TCP ടൈമറുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് മനസിലാക്കാത്ത പലരും ക്രമരഹിതമായി (പത്തു സെക്കന്റുകൾ പോലെ വന്യമായ മൂല്യങ്ങൾ സജ്ജീകരിച്ചുകൊണ്ട്) എറിയുന്നത് ഇവിടെ സഹായിക്കില്ല - OS കേർണൽ മാത്രമല്ലെന്ന് നിങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട്. ഉപയോക്താവിന്റെ മെഷീൻ സജീവമാണ്, പക്ഷേ സാധാരണ രീതിയിൽ പ്രവർത്തിക്കുന്നു, പ്രതികരിക്കാൻ കഴിയും, കൂടാതെ ആപ്ലിക്കേഷനും (ഇത് മരവിപ്പിക്കാൻ കഴിയില്ലെന്ന് നിങ്ങൾ കരുതുന്നുണ്ടോ? ഉബുണ്ടു 18.04-ലെ ടെലിഗ്രാം ഡെസ്ക്ടോപ്പ് എനിക്ക് ഒന്നിലധികം തവണ മരവിച്ചു).

അതുകൊണ്ടാണ് നിങ്ങൾ പിംഗ് ചെയ്യേണ്ടത് സെർവർ ക്ലയന്റ്, തിരിച്ചും അല്ല - ക്ലയന്റ് ഇത് ചെയ്യുകയാണെങ്കിൽ, കണക്ഷൻ തകരാറിലാണെങ്കിൽ, പിംഗ് വിതരണം ചെയ്യില്ല, ലക്ഷ്യം കൈവരിക്കില്ല.

ടെലിഗ്രാമിൽ നമ്മൾ എന്താണ് കാണുന്നത്? ഇത് നേരെ വിപരീതമാണ്! ശരി, അതായത്. ഔപചാരികമായി, തീർച്ചയായും, ഇരുവശത്തും പരസ്പരം പിംഗ് ചെയ്യാൻ കഴിയും. പ്രായോഗികമായി, ഉപഭോക്താക്കൾ ഒരു ഊന്നുവടി ഉപയോഗിക്കുന്നു ping_delay_disconnect, ഇത് സെർവറിൽ ടൈമർ സജ്ജമാക്കുന്നു. ക്ഷമിക്കണം, പിംഗ് ഇല്ലാതെ എത്ര കാലം അവിടെ താമസിക്കണമെന്ന് തീരുമാനിക്കേണ്ടത് ക്ലയന്റല്ല. സെർവർ, അതിന്റെ ലോഡിനെ അടിസ്ഥാനമാക്കി, നന്നായി അറിയാം. പക്ഷേ, തീർച്ചയായും, നിങ്ങൾ വിഭവങ്ങളെ കാര്യമാക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾ നിങ്ങളുടെ സ്വന്തം ദുഷ്ട പിനോച്ചിയോ ആയിരിക്കും, ഒരു ഊന്നുവടി ചെയ്യും ...

അത് എങ്ങനെ രൂപകൽപന ചെയ്യണമായിരുന്നു?

ടെലിഗ്രാം/VKontakte ടീം കമ്പ്യൂട്ടർ നെറ്റ്‌വർക്കുകളുടെ ഗതാഗത (താഴ്ന്ന) തലത്തിലും പ്രസക്തമായ കാര്യങ്ങളിൽ അവരുടെ കുറഞ്ഞ യോഗ്യതകളിലും വളരെ കഴിവുള്ളവരല്ലെന്ന് മുകളിൽ പറഞ്ഞ വസ്തുതകൾ വ്യക്തമായി സൂചിപ്പിക്കുന്നുവെന്ന് ഞാൻ വിശ്വസിക്കുന്നു.

എന്തുകൊണ്ടാണ് ഇത് വളരെ സങ്കീർണ്ണമായത്, ടെലിഗ്രാം ആർക്കിടെക്റ്റുകൾക്ക് എങ്ങനെ എതിർക്കാൻ കഴിയും? 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-ലെ ഒരു സാധാരണ വെബ് API-യുടെ ഡാറ്റാ ഘടനയായിരിക്കാം, ക്ലാസുകളും ഒബ്‌ജക്‌റ്റുകളിൽ അറ്റാച്ച് ചെയ്‌തിരിക്കുന്നതൊഴിച്ചാൽ?..

അപ്പോ ഇങ്ങനെയൊക്കെയാണ് സംഭവിക്കുന്നത്... എന്താണ് സഖാക്കളേ? തുടങ്ങുന്നു?..എച്ച്ടിടിപിഎസിലൂടെയുള്ള JSON മാത്രം ലളിതമാകില്ലേ?! പകരം നമുക്ക് എന്താണ് ലഭിച്ചത്? പ്രയത്നം വിലപ്പെട്ടോ?

TL+MTPproto എന്താണ് ഞങ്ങൾക്ക് നൽകിയതെന്നും ഏതൊക്കെ ഇതരമാർഗങ്ങൾ സാധ്യമാണെന്നും നമുക്ക് വിലയിരുത്താം. ശരി, അഭ്യർത്ഥന-പ്രതികരണ മോഡലിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്ന HTTP, ഒരു മോശം അനുയോജ്യമാണോ, എന്നാൽ TLS-ന് മുകളിൽ എന്തെങ്കിലും ഉണ്ടോ?

കോംപാക്ട് സീരിയലൈസേഷൻ. JSON-ന് സമാനമായ ഈ ഡാറ്റാ ഘടന കാണുമ്പോൾ, ഇതിന്റെ ബൈനറി പതിപ്പുകൾ ഉണ്ടെന്ന് ഞാൻ ഓർക്കുന്നു. നമുക്ക് MsgPack വേണ്ടത്ര വിപുലീകരിക്കാൻ കഴിയാത്തതായി അടയാളപ്പെടുത്താം, പക്ഷേ, ഉദാഹരണത്തിന്, CBOR - ഒരു സ്റ്റാൻഡേർഡ് വിവരിച്ചിരിക്കുന്നു RFC 7049. അത് നിർവചിക്കുന്നു എന്നത് ശ്രദ്ധേയമാണ് ടാഗുകൾ, ഒരു വിപുലീകരണ സംവിധാനമായി, ഒപ്പം ഇതിനകം സ്റ്റാൻഡേർഡ് ചെയ്തിട്ടുണ്ട് ലഭ്യമാണ്:

• 25 + 256 - ആവർത്തിച്ചുള്ള വരികൾ ലൈൻ നമ്പറിലേക്ക് റഫറൻസ് ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു, അത്തരമൊരു വിലകുറഞ്ഞ കംപ്രഷൻ രീതി
• 26 - ക്ലാസ് നാമവും കൺസ്ട്രക്റ്റർ ആർഗ്യുമെന്റുകളും ഉള്ള സീരിയലൈസ് ചെയ്ത പേൾ ഒബ്ജക്റ്റ്
• 27 - തരം നാമവും കൺസ്ട്രക്റ്റർ ആർഗ്യുമെന്റുകളും ഉള്ള സീരിയലൈസ് ചെയ്ത ഭാഷാ-സ്വതന്ത്ര ഒബ്‌ജക്റ്റ്

ശരി, സ്ട്രിംഗും ഒബ്‌ജക്‌റ്റ് പാക്കിംഗും പ്രവർത്തനക്ഷമമാക്കി TL-ലും CBOR-ലും ഒരേ ഡാറ്റ സീരിയലൈസ് ചെയ്യാൻ ഞാൻ ശ്രമിച്ചു. ഫലം ഒരു മെഗാബൈറ്റിൽ നിന്ന് എവിടെയോ CBOR-ന് അനുകൂലമായി വ്യത്യാസപ്പെടാൻ തുടങ്ങി:

cborlen=1039673 tl_len=1095092

അങ്ങനെയാണെങ്കിൽ, ഉപസംഹാരം: സിൻക്രൊണൈസേഷൻ പരാജയത്തിന്റെയോ അജ്ഞാത ഐഡന്റിഫയറിന്റെയോ പ്രശ്‌നത്തിന് വിധേയമല്ലാത്ത, താരതമ്യപ്പെടുത്താവുന്ന കാര്യക്ഷമതയോടെ, ഗണ്യമായി ലളിതമായ ഫോർമാറ്റുകൾ ഉണ്ട്.

വേഗത്തിലുള്ള കണക്ഷൻ സ്ഥാപനം. ഇതിനർത്ഥം പുനഃസംയോജനത്തിനു ശേഷം പൂജ്യം RTT (കീ ഇതിനകം ഒരു തവണ ജനറേറ്റ് ചെയ്‌തിരിക്കുമ്പോൾ) - ആദ്യത്തെ MTPproto സന്ദേശത്തിൽ നിന്ന് ബാധകമാണ്, എന്നാൽ ചില റിസർവേഷനുകൾക്കൊപ്പം - അതേ ഉപ്പ് അടിക്കുക, സെഷൻ ചീഞ്ഞതല്ല, മുതലായവ. പകരം TLS എന്താണ് വാഗ്ദാനം ചെയ്യുന്നത്? വിഷയത്തെക്കുറിച്ചുള്ള ഉദ്ധരണി:

TLS-ൽ PFS ഉപയോഗിക്കുമ്പോൾ, TLS സെഷൻ ടിക്കറ്റുകൾ (RFC 5077) കീകൾ വീണ്ടും ചർച്ച ചെയ്യാതെയും സെർവറിൽ പ്രധാന വിവരങ്ങൾ സൂക്ഷിക്കാതെയും ഒരു എൻക്രിപ്റ്റ് ചെയ്ത സെഷൻ പുനരാരംഭിക്കുന്നതിന്. ആദ്യ കണക്ഷൻ തുറന്ന് കീകൾ സൃഷ്ടിക്കുമ്പോൾ, സെർവർ കണക്ഷൻ നില എൻക്രിപ്റ്റ് ചെയ്യുകയും ക്ലയന്റിലേക്ക് കൈമാറുകയും ചെയ്യുന്നു (ഒരു സെഷൻ ടിക്കറ്റിന്റെ രൂപത്തിൽ). അതനുസരിച്ച്, കണക്ഷൻ പുനരാരംഭിക്കുമ്പോൾ, ക്ലയന്റ് സെഷൻ കീ ഉൾപ്പെടെ ഒരു സെഷൻ ടിക്കറ്റ് സെർവറിലേക്ക് തിരികെ അയയ്ക്കുന്നു. ടിക്കറ്റ് തന്നെ ഒരു താൽകാലിക കീ (സെഷൻ ടിക്കറ്റ് കീ) ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നു, അത് സെർവറിൽ സൂക്ഷിക്കുകയും ക്ലസ്റ്റേർഡ് സൊല്യൂഷനുകളിൽ SSL പ്രോസസ്സ് ചെയ്യുന്ന എല്ലാ ഫ്രണ്ട്‌എൻഡ് സെർവറുകളിലും വിതരണം ചെയ്യുകയും വേണം.[10]. അതിനാൽ, താൽക്കാലിക സെർവർ കീകൾ വിട്ടുവീഴ്ച ചെയ്യപ്പെടുകയാണെങ്കിൽ ഒരു സെഷൻ ടിക്കറ്റിന്റെ ആമുഖം PFS ലംഘിച്ചേക്കാം, ഉദാഹരണത്തിന്, അവ ദീർഘകാലത്തേക്ക് സൂക്ഷിക്കുമ്പോൾ (ഓപ്പൺഎസ്എസ്എൽ, nginx, Apache പ്രോഗ്രാമിന്റെ മുഴുവൻ സമയവും സ്ഥിരസ്ഥിതിയായി സൂക്ഷിക്കുന്നു; ജനപ്രിയ സൈറ്റുകൾ ഉപയോഗിക്കുന്നു നിരവധി മണിക്കൂറുകൾക്കുള്ള താക്കോൽ, ദിവസങ്ങൾ വരെ).

ഇവിടെ RTT പൂജ്യമല്ല, നിങ്ങൾ കുറഞ്ഞത് ClientHello, ServerHello എന്നിവ കൈമാറ്റം ചെയ്യേണ്ടതുണ്ട്, അതിനുശേഷം ക്ലയന്റ് പൂർത്തിയാക്കിയതിനൊപ്പം ഡാറ്റ അയയ്ക്കാൻ കഴിയും. എന്നാൽ ഇവിടെ നമ്മൾ ഓർക്കണം, പുതിയതായി തുറന്ന കണക്ഷനുകളുടെ കൂട്ടം ഉള്ള ഒരു കൂട്ടം വെബ് ഇല്ല, മറിച്ച് ഒരു മെസഞ്ചർ ആണ്, ഇതിന്റെ കണക്ഷൻ പലപ്പോഴും ഒന്നോ അതിലധികമോ ദീർഘകാല, വെബ് പേജുകളിലേക്കുള്ള താരതമ്യേന ഹ്രസ്വമായ അഭ്യർത്ഥനകളാണ് - എല്ലാം മൾട്ടിപ്ലക്‌സ് ചെയ്തതാണ്. ആന്തരികമായി. അതായത്, ഞങ്ങൾ വളരെ മോശം സബ്‌വേ വിഭാഗത്തിൽ എത്തിയില്ലെങ്കിൽ അത് തികച്ചും സ്വീകാര്യമാണ്.

മറ്റെന്തെങ്കിലും മറന്നോ? അഭിപ്രായങ്ങളിൽ എഴുതുക.

തുടരും!

ഈ പോസ്റ്റുകളുടെ പരമ്പരയുടെ രണ്ടാം ഭാഗത്തിൽ ഞങ്ങൾ സാങ്കേതികമല്ല, സംഘടനാപരമായ പ്രശ്നങ്ങൾ പരിഗണിക്കും - സമീപനങ്ങൾ, പ്രത്യയശാസ്ത്രം, ഇന്റർഫേസ്, ഉപയോക്താക്കളോടുള്ള മനോഭാവം മുതലായവ. എന്നിരുന്നാലും, ഇവിടെ അവതരിപ്പിച്ച സാങ്കേതിക വിവരങ്ങളുടെ അടിസ്ഥാനത്തിൽ.

മൂന്നാം ഭാഗം സാങ്കേതിക ഘടകം / വികസന അനുഭവം വിശകലനം ചെയ്യുന്നത് തുടരും. നിങ്ങൾ പഠിക്കും, പ്രത്യേകിച്ച്:

• വൈവിധ്യമാർന്ന TL തരങ്ങളുള്ള പാൻഡമോണിയത്തിന്റെ തുടർച്ച
• ചാനലുകളെയും സൂപ്പർ ഗ്രൂപ്പുകളെയും കുറിച്ച് അജ്ഞാതമായ കാര്യങ്ങൾ
• എന്തുകൊണ്ട് ഡയലോഗുകൾ റോസ്റ്ററിനേക്കാൾ മോശമാണ്
• കേവല vs ആപേക്ഷിക സന്ദേശ വിലാസത്തെക്കുറിച്ച്
• ഫോട്ടോയും ചിത്രവും തമ്മിലുള്ള വ്യത്യാസം എന്താണ്
• ഇമോജി ഇറ്റാലിക് വാചകത്തിൽ എങ്ങനെ ഇടപെടുന്നു

മറ്റ് ഊന്നുവടികളും! ഇവിടെത്തന്നെ നിൽക്കുക!

അവലംബം: www.habr.com