તાજેતરમાં, ટેલિગ્રામ કેટલું સારું છે, ડુરોવ ભાઈઓ નેટવર્ક સિસ્ટમ બનાવવા માટે કેટલા તેજસ્વી અને અનુભવી છે વગેરે વિશેની પોસ્ટ્સ વધુ વખત હેબ્રે પર દેખાવા લાગી છે. તે જ સમયે, બહુ ઓછા લોકો ખરેખર તકનીકી ઉપકરણમાં ડૂબી ગયા છે - મોટાભાગે, તેઓ JSON પર આધારિત એકદમ સરળ (અને MTProto કરતાં તદ્દન અલગ) Bot API નો ઉપયોગ કરે છે, અને સામાન્ય રીતે ફક્ત સ્વીકારે છે. વિશ્વાસ પર તમામ વખાણ અને પીઆર જે મેસેન્જરની આસપાસ ફરે છે. લગભગ દોઢ વર્ષ પહેલાં, એશેલોન એનજીઓ વેસિલીમાં મારા સાથીદારે (કમનસીબે, ડ્રાફ્ટની સાથે હેબ્રે પરનું તેમનું એકાઉન્ટ ભૂંસી નાખવામાં આવ્યું હતું) પર્લમાં શરૂઆતથી પોતાનો ટેલિગ્રામ ક્લાયંટ લખવાનું શરૂ કર્યું, અને પછીથી આ રેખાઓના લેખક જોડાયા. શા માટે પર્લ, કેટલાક તરત જ પૂછશે? કારણ કે આવા પ્રોજેક્ટ્સ અન્ય ભાષાઓમાં પહેલાથી જ અસ્તિત્વમાં છે. હકીકતમાં, આ મુદ્દો નથી, ત્યાં કોઈ અન્ય ભાષા હોઈ શકે છે જ્યાં કોઈ ન હોય. તૈયાર પુસ્તકાલય, અને તે મુજબ લેખકે બધી રીતે જવું જોઈએ શરૂઆતથી. વધુમાં, ક્રિપ્ટોગ્રાફી એ વિશ્વાસની બાબત છે, પરંતુ ચકાસો. સુરક્ષાને ધ્યાનમાં રાખીને ઉત્પાદન સાથે, તમે નિર્માતા પાસેથી તૈયાર કરેલી લાઇબ્રેરી પર આધાર રાખી શકતા નથી અને તેના પર આંધળો વિશ્વાસ કરી શકતા નથી (જો કે, આ બીજા ભાગ માટેનો વિષય છે). આ ક્ષણે, લાઇબ્રેરી "સરેરાશ" સ્તરે ખૂબ સારી રીતે કાર્ય કરે છે (તમને કોઈપણ API વિનંતીઓ કરવાની મંજૂરી આપે છે).

જો કે, પોસ્ટ્સની આ શ્રેણીમાં વધુ ક્રિપ્ટોગ્રાફી અથવા ગણિત હશે નહીં. પરંતુ અન્ય ઘણી ટેકનિકલ વિગતો અને આર્કિટેક્ચરલ ક્રૉચ હશે (જેઓ શરૂઆતથી લખશે નહીં, પરંતુ કોઈપણ ભાષામાં લાઇબ્રેરીનો ઉપયોગ કરશે તેમના માટે પણ ઉપયોગી). તેથી, મુખ્ય ધ્યેય ક્લાયંટને શરૂઆતથી અમલમાં મૂકવાનો પ્રયાસ કરવાનો હતો સત્તાવાર દસ્તાવેજો અનુસાર. એટલે કે, ચાલો માની લઈએ કે સત્તાવાર ક્લાયંટનો સ્રોત કોડ બંધ છે (ફરીથી, બીજા ભાગમાં આપણે આ સત્ય છે તે હકીકતના વિષયને વધુ વિગતવાર આવરીશું. તે થાય છે તેથી), પરંતુ, જૂના દિવસોની જેમ, ઉદાહરણ તરીકે, આરએફસી જેવું ધોરણ છે - શું એકલા સ્પષ્ટીકરણ અનુસાર ક્લાયંટ લખવાનું શક્ય છે, સ્ત્રોત કોડને "જોયા વિના", તે સત્તાવાર હોય (ટેલિગ્રામ ડેસ્કટોપ, મોબાઇલ), અથવા બિનસત્તાવાર ટેલિથોન?

ઑગ્લેવલેનિએ:

• દસ્તાવેજીકરણ... તે અસ્તિત્વમાં છે, બરાબર? શુ તે સાચુ છે?..
• યુવા લેખક તરીકે ક્યાંથી શરૂઆત કરવી?
• દ્વિસંગી ક્રમાંકન: TL (ટાઈપ લેંગ્વેજ) અને તેની સ્કીમ, અને સ્તરો, અને અન્ય ઘણા ડરામણા શબ્દો
  • અધિકૃત દસ્તાવેજો વાંચવા માંગતા ન હોય તેવા લોકો માટે TL સિન્ટેક્સના સબસેટનું ટૂંકું વર્ણન
  • વેક્ટર, જે ક્યારેય રિલીઝ થયું ન હતું
  • કોડમાં હાલના TL અમલીકરણો
  • પ્રકાર ભાષામાં પ્રકારોનો અભાવ
  • વર્ઝનીંગ. સ્તરો
• એમટીપીટ્રોટો
  • પરિવહન સ્તર
  • કી, સંદેશાઓ, સત્રો, ડિફી-હેલમેન
  • સંદેશ સંદેશાઓ, 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/ અને ગેટીંગ સ્ટાર્ટમાં તેમના વિશે વાત કરે છે સૌ પ્રથમ, હકીકતમાં, તમારે પ્રથમ અમલ કરવો પડશે MTProto પ્રોટોકોલ - પરંતુ જો તમે માનતા હોવ OSI મોડેલ અનુસાર લેઆઉટ પ્રોટોકોલના સામાન્ય વર્ણન માટે પૃષ્ઠના અંતે, પછી તે સંપૂર્ણપણે નિરર્થક છે.

વાસ્તવમાં, એમટીપ્રોટો પહેલાં અને પછી બંને, એકસાથે અનેક સ્તરો પર (ઓએસ કર્નલમાં કામ કરતા વિદેશી નેટવર્કર્સ કહે છે કે, સ્તરનું ઉલ્લંઘન), એક મોટો, પીડાદાયક અને ભયંકર વિષય આવી જશે...

દ્વિસંગી ક્રમાંકન: TL (ટાઈપ લેંગ્વેજ) અને તેની સ્કીમ, અને સ્તરો, અને અન્ય ઘણા ડરામણા શબ્દો

આ વિષય, હકીકતમાં, ટેલિગ્રામની સમસ્યાઓની ચાવી છે. અને જો તમે તેને સમજવાનો પ્રયત્ન કરશો તો ઘણા ભયંકર શબ્દો હશે.

તો, અહીં આકૃતિ છે. જો આ શબ્દ તમારા મગજમાં આવે તો કહો, JSON સ્કીમા, તમે સાચું વિચાર્યું. ધ્યેય એ જ છે: પ્રસારિત ડેટાના સંભવિત સમૂહનું વર્ણન કરવા માટે કેટલીક ભાષા. આ તે છે જ્યાં સમાનતા સમાપ્ત થાય છે. જો પૃષ્ઠ પરથી MTProto પ્રોટોકોલ, અથવા સત્તાવાર ક્લાયંટના સ્ત્રોત વૃક્ષમાંથી, અમે કેટલીક સ્કીમા ખોલવાનો પ્રયાસ કરીશું, અમે કંઈક આના જેવું જોઈશું:

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

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

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

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

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

---functions---

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

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

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

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

આને પહેલીવાર જોનાર વ્યક્તિ સાહજિક રીતે જે લખેલું છે તેના ભાગને જ ઓળખી શકશે - સારું, આ દેખીતી રીતે રચનાઓ છે (જોકે નામ ક્યાં છે, ડાબી બાજુ કે જમણી બાજુ?), તેમાં ક્ષેત્રો છે, જેના પછી કોલોન પછી એક પ્રકાર આવે છે... કદાચ. અહીં કોણ કૌંસમાં કદાચ C++ જેવા નમૂનાઓ છે (હકીકતમાં, ખરેખર નથી). અને અન્ય તમામ પ્રતીકોનો અર્થ શું છે, પ્રશ્ન ચિહ્નો, ઉદ્ગારવાચક ચિહ્નો, ટકાવારી, હેશ ચિહ્નો (અને દેખીતી રીતે તેનો અર્થ જુદી જુદી જગ્યાએ જુદી જુદી વસ્તુઓ થાય છે), ક્યારેક હાજર હોય છે અને ક્યારેક નહીં, હેક્સાડેસિમલ નંબરો - અને સૌથી અગત્યનું, આમાંથી કેવી રીતે મેળવવું સાચો એક (જે સર્વર દ્વારા નકારવામાં આવશે નહીં) બાઈટ સ્ટ્રીમ? તમારે દસ્તાવેજો વાંચવા પડશે (હા, નજીકના JSON સંસ્કરણમાં સ્કીમાની લિંક્સ છે - પરંતુ તે તેને વધુ સ્પષ્ટ કરતું નથી).

પેજ ખોલો દ્વિસંગી ડેટા સીરીયલાઇઝેશન અને મશરૂમ્સ અને અલગ ગણિતની જાદુઈ દુનિયામાં ડૂબકી લગાવો, 4થા વર્ષમાં મટન જેવું જ કંઈક. આલ્ફાબેટ, પ્રકાર, મૂલ્ય, કોમ્બીનેટર, ફંક્શનલ કોમ્બીનેટર, નોર્મલ ફોર્મ, કમ્પોઝીટ ટાઈપ, પોલીમોર્ફિક ટાઈપ... અને આ બધું માત્ર પ્રથમ પેજ છે! આગળ તમારી રાહ જુએ છે TL ભાષા, જે, જો કે તે પહેલાથી જ તુચ્છ વિનંતી અને પ્રતિસાદનું ઉદાહરણ ધરાવે છે, તે વધુ લાક્ષણિક કેસો માટે બિલકુલ જવાબ આપતું નથી, જેનો અર્થ એ છે કે તમારે અન્ય આઠ એમ્બેડેડ પર રશિયનમાંથી અંગ્રેજીમાં અનુવાદિત ગણિતના પુન: કહેવામાંથી પસાર થવું પડશે. પૃષ્ઠો

કાર્યાત્મક ભાષાઓ અને સ્વચાલિત પ્રકાર અનુમાનથી પરિચિત વાચકો, અલબત્ત, આ ભાષામાં વર્ણનની ભાષા જોશે, ઉદાહરણથી પણ, વધુ પરિચિત, અને કહી શકે છે કે આ ખરેખર સૈદ્ધાંતિક રીતે ખરાબ નથી. આ અંગેના વાંધાઓ છે:

• હા, હેતુ સારું લાગે છે, પરંતુ અફસોસ, તેણી હાંસલ નથી
• રશિયન યુનિવર્સિટીઓમાં શિક્ષણ IT વિશેષતાઓમાં પણ બદલાય છે - દરેક વ્યક્તિએ અનુરૂપ અભ્યાસક્રમ લીધો નથી
• છેવટે, જેમ આપણે જોઈશું, વ્યવહારમાં તે છે જરૂરી નથી, કારણ કે વર્ણવેલ TL નો માત્ર મર્યાદિત સબસેટ વપરાય છે

તેમ કહ્યું છે લીઓનર્ડ ચેનલ પર #perl ફ્રીનોડ આઇઆરસી નેટવર્કમાં, જેમણે ટેલિગ્રામથી મેટ્રિક્સ સુધીના ગેટને અમલમાં મૂકવાનો પ્રયાસ કર્યો હતો (અવતરણનો અનુવાદ મેમરીમાંથી અચોક્કસ છે):

એવું લાગે છે કે કોઈને પ્રથમ વખત થિયરી ટાઈપ કરવા માટે રજૂ કરવામાં આવ્યું હતું, તે ઉત્સાહિત થઈ ગયો, અને તેની સાથે રમવાનો પ્રયાસ કરવાનું શરૂ કર્યું, વ્યવહારમાં તેની જરૂર હતી કે કેમ તેની ખરેખર કાળજી ન લીધી.

તમારા માટે જુઓ, જો કોઈ પ્રાથમિક વસ્તુ તરીકે બેર-ટાઈપ (int, long, etc.) ની જરૂરિયાત પ્રશ્નો ઉભા કરતી નથી - આખરે તે જાતે જ અમલમાં મૂકવા જોઈએ - ઉદાહરણ તરીકે, ચાલો તેમાંથી મેળવવાનો પ્રયાસ કરીએ. વેક્ટર. એટલે કે હકીકતમાં એરે, જો તમે પરિણામી વસ્તુઓને તેમના યોગ્ય નામોથી બોલાવો છો.

પરંતુ પહેલા

જેઓ સત્તાવાર દસ્તાવેજો વાંચતા નથી તેમના માટે TL સિન્ટેક્સના સબસેટનું ટૂંકું વર્ણન

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

fixed#abcdef34 id:int = Type2;

fixedVec set:Vector<Type2> = FixedVec;

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

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

વ્યાખ્યા હંમેશા શરૂ થાય છે બાંધનાર, જે પછી વૈકલ્પિક રીતે (વ્યવહારમાં - હંમેશા) પ્રતીક દ્વારા # હોવું જ જોઈએ સીઆરસી 32 આ પ્રકારના સામાન્યકૃત વર્ણન શબ્દમાળામાંથી. આગળ ક્ષેત્રોનું વર્ણન આવે છે; જો તેઓ અસ્તિત્વમાં હોય, તો પ્રકાર ખાલી હોઈ શકે છે. આ બધું એક સમાન ચિહ્ન સાથે સમાપ્ત થાય છે, જે પ્રકારનું નામ આ કન્સ્ટ્રક્ટર - એટલે કે, હકીકતમાં, પેટાપ્રકાર - સંબંધિત છે. સમાન ચિહ્નની જમણી બાજુનો વ્યક્તિ છે પોલીમોર્ફિક - એટલે કે, કેટલાક વિશિષ્ટ પ્રકારો તેને અનુરૂપ હોઈ શકે છે.

જો વ્યાખ્યા રેખા પછી થાય છે ---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 અને , પરિણામે, ક્રમાંકન. અને જૂના ક્લાયન્ટ શું કરશે જો તેને નવા ફ્લેગ સેટ સાથે ફીલ્ડ મળે, અને તે જાણતો નથી કે તેની સાથે આગળ શું કરવું?..

બીજું, ચાલો યાદ કરીએ સીઆરસી 32, જેનો ઉપયોગ અહીં અનિવાર્યપણે તરીકે થાય છે હેશ કાર્યો વિશિષ્ટ રીતે નક્કી કરવા માટે કે કયા પ્રકારનું (ડી) ક્રમાંકિત કરવામાં આવી રહ્યું છે. અહીં આપણે અથડામણની સમસ્યાનો સામનો કરી રહ્યા છીએ - અને ના, સંભાવના 232 માં એક નથી, પરંતુ ઘણી વધારે છે. કોને યાદ છે કે CRC32 સંચાર ચેનલમાં ભૂલો શોધવા (અને સુધારવા) માટે રચાયેલ છે, અને તે મુજબ અન્યના નુકસાન માટે આ ગુણધર્મોને સુધારે છે? ઉદાહરણ તરીકે, તે બાઇટ્સને ફરીથી ગોઠવવાની કાળજી લેતું નથી: જો તમે બે લીટીઓમાંથી CRC32 ની ગણતરી કરો છો, તો બીજામાં તમે પ્રથમ 4 બાઇટને આગામી 4 બાઇટ સાથે સ્વેપ કરો છો - તે સમાન હશે. જ્યારે અમારું ઇનપુટ લેટિન મૂળાક્ષરો (અને થોડું વિરામચિહ્ન) માંથી ટેક્સ્ટ શબ્દમાળાઓ હોય છે, અને આ નામો ખાસ કરીને રેન્ડમ નથી, ત્યારે આવી પુન: ગોઠવણીની સંભાવના ઘણી વધી જાય છે.

બાય ધ વે, કોણે તપાસ્યું કે ત્યાં શું હતું? ખરેખર CRC32? પ્રારંભિક સ્ત્રોતોમાંના એક (વોલ્ટમેન પહેલા પણ) પાસે હેશ ફંક્શન હતું જે દરેક અક્ષરને 239 નંબરથી ગુણાકાર કરે છે, આ લોકો દ્વારા ખૂબ પ્રિય છે, હા હા!

છેલ્લે, ઠીક છે, અમને સમજાયું કે ફીલ્ડ પ્રકાર સાથે કન્સ્ટ્રક્ટર Vector<int> и Vector<PolymorType> અલગ CRC32 હશે. ઓનલાઈન કામગીરી વિશે શું? અને સૈદ્ધાંતિક દૃષ્ટિકોણથી, શું આ પ્રકારનો ભાગ બની જાય છે? ચાલો કહીએ કે આપણે દસ હજાર સંખ્યાઓની એરે પસાર કરીએ છીએ, સાથે સાથે Vector<int> બધું સ્પષ્ટ છે, લંબાઈ અને અન્ય 40000 બાઇટ્સ. જો આ Vector<Type2>, જેમાં માત્ર એક ક્ષેત્રનો સમાવેશ થાય છે int અને તે પ્રકારમાં એકલું છે - શું આપણે 10000xabcdef0 34 વખત અને પછી 4 બાઇટ્સનું પુનરાવર્તન કરવાની જરૂર છે? int, અથવા ભાષા આપણા માટે તેને કન્સ્ટ્રક્ટરથી સ્વતંત્ર કરવામાં સક્ષમ છે fixedVec અને 80000 બાઇટ્સને બદલે, ફરીથી માત્ર 40000 ટ્રાન્સફર કરો?

આ બિલકુલ નિષ્ક્રિય સૈદ્ધાંતિક પ્રશ્ન નથી - કલ્પના કરો કે તમને જૂથ વપરાશકર્તાઓની સૂચિ પ્રાપ્ત થઈ છે, જેમાંના દરેક પાસે આઈડી, પ્રથમ નામ, છેલ્લું નામ છે - મોબાઇલ કનેક્શન પર ટ્રાન્સફર કરાયેલ ડેટાની માત્રામાં તફાવત નોંધપાત્ર હોઈ શકે છે. તે ચોક્કસપણે ટેલિગ્રામ સીરીયલાઇઝેશનની અસરકારકતા છે જેની અમને જાહેરાત કરવામાં આવે છે.

તો…

વેક્ટર, જે ક્યારેય રિલીઝ થયું ન હતું

જો તમે કોમ્બિનેટર્સ વગેરેના વર્ણનના પૃષ્ઠોમાંથી પસાર થવાનો પ્રયાસ કરો છો, તો તમે જોશો કે એક વેક્ટર (અને મેટ્રિક્સ પણ) ઔપચારિક રીતે અનેક શીટ્સના ટ્યુપલ્સ દ્વારા આઉટપુટ કરવાનો પ્રયાસ કરી રહ્યો છે. પરંતુ અંતે તેઓ ભૂલી જાય છે, અંતિમ પગલું અવગણવામાં આવે છે, અને વેક્ટરની વ્યાખ્યા સરળ રીતે આપવામાં આવે છે, જે હજુ સુધી એક પ્રકાર સાથે જોડાયેલી નથી. શું બાબત છે? ભાષાઓમાં પ્રોગ્રામિંગ, ખાસ કરીને વિધેયાત્મક, તે રચનાને વારંવાર વર્ણવવા માટે એકદમ લાક્ષણિક છે - તેના આળસુ મૂલ્યાંકન સાથે કમ્પાઇલર બધું જ સમજી શકશે અને પોતે કરશે. ભાષામાં ડેટા સીરીયલાઇઝેશન જે જરૂરી છે તે કાર્યક્ષમતા છે: તે ફક્ત વર્ણન કરવા માટે પૂરતું છે યાદી, એટલે કે બે તત્વોનું માળખું - પ્રથમ ડેટા તત્વ છે, બીજું એ જ માળખું છે અથવા પૂંછડી માટે ખાલી જગ્યા છે (પેક (cons) લિસ્પમાં). પરંતુ આ દેખીતી રીતે જરૂર પડશે દરેક તત્વ તેના પ્રકારનું વર્ણન કરવા માટે વધારાના 4 બાઇટ્સ (ટીએલના કિસ્સામાં CRC32) ખર્ચે છે. એરે પણ સરળતાથી વર્ણવી શકાય છે નિશ્ચિત કદ, પરંતુ અગાઉથી અજ્ઞાત લંબાઈના એરેના કિસ્સામાં, અમે તોડી નાખીએ છીએ.

તેથી, TL વેક્ટરને આઉટપુટ કરવાની મંજૂરી આપતું નથી, તેથી તેને બાજુ પર ઉમેરવાનું હતું. આખરે દસ્તાવેજો કહે છે:

સીરીયલાઇઝેશન હંમેશા સમાન કન્સ્ટ્રક્ટર “વેક્ટર” (const 0x1cb5c415 = crc32(“vector t:Type # [ t ] = Vector t”) નો ઉપયોગ કરે છે જે પ્રકાર t ના ચલના ચોક્કસ મૂલ્ય પર આધારિત નથી.

વૈકલ્પિક પરિમાણ t નું મૂલ્ય સીરીયલાઇઝેશનમાં સામેલ નથી કારણ કે તે પરિણામના પ્રકારમાંથી લેવામાં આવ્યું છે (હંમેશા ડીસીરિયલાઇઝેશન પહેલા જાણીતું છે).

નજીકથી જુઓ: vector {t:Type} # [ t ] = Vector t - પણ ક્યાંય નથી આ વ્યાખ્યા પોતે કહેતી નથી કે પ્રથમ સંખ્યા વેક્ટરની લંબાઈ જેટલી હોવી જોઈએ! અને તે ક્યાંયથી આવતું નથી. આ એક આપેલ છે જેને ધ્યાનમાં રાખવાની અને તમારા હાથથી અમલમાં મૂકવાની જરૂર છે. અન્યત્ર, દસ્તાવેજીકરણ પણ પ્રમાણિકપણે ઉલ્લેખ કરે છે કે પ્રકાર વાસ્તવિક નથી:

વેક્ટર ટી પોલીમોર્ફિક સ્યુડોટાઇપ એ એક "પ્રકાર" છે જેનું મૂલ્ય એ કોઈપણ પ્રકારના ટીના મૂલ્યોનો ક્રમ છે, ક્યાં તો બોક્સવાળી અથવા એકદમ.

... પરંતુ તેના પર ધ્યાન કેન્દ્રિત કરતું નથી. જ્યારે તમે, ગણિતના સ્ટ્રેચિંગથી કંટાળી ગયા છો (કદાચ તમને યુનિવર્સિટીના કોર્સમાંથી પણ જાણતા હશે), ત્યારે તમે હાર માનવાનું નક્કી કરો છો અને વાસ્તવમાં તેની સાથે વ્યવહારમાં કેવી રીતે કામ કરવું તે જુઓ છો, ત્યારે તમારા મગજમાં છાપ રહે છે કે આ ગંભીર છે. મૂળમાં ગણિત, તે સ્પષ્ટપણે કૂલ લોકો (બે ગણિતશાસ્ત્રીઓ - ACM વિજેતા) દ્વારા શોધવામાં આવ્યું હતું, અને માત્ર કોઈએ નહીં. ધ્યેય - બતાવવાનું - પ્રાપ્ત થયું છે.

માર્ગ દ્વારા, સંખ્યા વિશે. ચાલો તમને તે યાદ અપાવીએ # તે એક સમાનાર્થી છે nat, કુદરતી સંખ્યા:

ત્યાં પ્રકારના સમીકરણો છે (ટાઇપ-એક્સપ્ર) અને સંખ્યાત્મક સમીકરણો (nat-expr). જો કે, તેઓ સમાન રીતે વ્યાખ્યાયિત કરવામાં આવે છે.

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

પરંતુ વ્યાકરણમાં તેઓનું વર્ણન એ જ રીતે કરવામાં આવ્યું છે, એટલે કે. આ તફાવત ફરીથી યાદ રાખવો જોઈએ અને હાથ દ્વારા અમલમાં મૂકવો જોઈએ.

સારું, હા, ટેમ્પલેટ પ્રકારો (vector<int>, vector<User>) પાસે સામાન્ય ઓળખકર્તા છે (#1cb5c415), એટલે કે જો તમે જાણો છો કે કૉલની જાહેરાત કરવામાં આવી છે

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

તો પછી તમે હવે માત્ર એક વેક્ટરની નહીં, પણ વપરાશકર્તાઓના વેક્ટરની રાહ જોઈ રહ્યા છો. વધુ સ્પષ્ટ રીતે, જોઈએ રાહ જુઓ - વાસ્તવિક કોડમાં, દરેક તત્વ, જો એકદમ પ્રકાર ન હોય તો, એક કન્સ્ટ્રક્ટર હશે, અને અમલીકરણમાં સારી રીતે તે તપાસવું જરૂરી છે - પરંતુ અમને આ વેક્ટરના દરેક ઘટકમાં બરાબર મોકલવામાં આવ્યા હતા. તે પ્રકાર? જો તે કોઈ પ્રકારનું PHP હોય, જેમાં એરે વિવિધ તત્વોમાં વિવિધ પ્રકારો સમાવી શકે?

આ બિંદુએ તમે વિચારવાનું શરૂ કરો - શું આવા TL જરૂરી છે? કદાચ કાર્ટ માટે માનવ સીરીયલાઇઝરનો ઉપયોગ કરવો શક્ય હશે, તે જ પ્રોટોબફ જે પહેલાથી અસ્તિત્વમાં છે? તે સિદ્ધાંત હતો, ચાલો પ્રેક્ટિસ જોઈએ.

કોડમાં હાલના TL અમલીકરણો

દુરોવના શેરના વેચાણ સાથેની પ્રખ્યાત ઘટનાઓ પહેલા પણ TL નો જન્મ VKontakte ના ઊંડાણોમાં થયો હતો અને (કદાચ), ટેલિગ્રામનો વિકાસ શરૂ થયો તે પહેલાં જ. અને ઓપન સોર્સમાં પ્રથમ અમલીકરણનો સ્રોત કોડ તમને ઘણી રમુજી ક્રૉચ મળી શકે છે. અને ભાષા પોતે ટેલિગ્રામમાં છે તેના કરતાં વધુ સંપૂર્ણ રીતે લાગુ કરવામાં આવી હતી. ઉદાહરણ તરીકે, સ્કીમમાં હેશનો બિલકુલ ઉપયોગ થતો નથી (એટલે ​​કે બિલ્ટ-ઇન સ્યુડોટાઇપ (વેક્ટરની જેમ) વિચલિત વર્તન સાથે). અથવા

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 ના પ્રથમ પ્રકાશિત અમલીકરણ વિશે હતું. ચાલો ટેલિગ્રામ ક્લાયંટમાં અમલીકરણને ધ્યાનમાં લઈએ.

વેસિલીને શબ્દ:

વેસિલી, [09.10.18 17:07] સૌથી વધુ, ગર્દભ ગરમ છે કારણ કે તેઓએ અમૂર્તતાનો સમૂહ બનાવ્યો, અને પછી તેના પર બોલ્ટ માર્યો, અને કોડ જનરેટરને ક્રેચથી ઢાંકી દીધો.
પરિણામે, પ્રથમ dock pilot.jpg થી
પછી કોડ dzhekichan.webp થી

અલબત્ત, એલ્ગોરિધમ્સ અને ગણિતથી પરિચિત લોકો પાસેથી, અમે અપેક્ષા રાખી શકીએ કે તેઓએ Aho, Ullmann વાંચ્યું છે અને તેમના DSL કમ્પાઇલર્સ લખવા માટે દાયકાઓથી ઉદ્યોગમાં વાસ્તવિક ધોરણ બની ગયેલા સાધનોથી તેઓ પરિચિત છે, ખરું ને?

દ્વારા ટેલિગ્રામ-ક્લી વિટાલી વાલ્ટમેન છે, જેમ કે તેની (cli) સીમાઓની બહાર TLO ફોર્મેટની ઘટના પરથી સમજી શકાય છે, ટીમના સભ્ય - હવે 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+ લીટીઓ, કેટલાક નિયમિત અભિવ્યક્તિઓ + વેક્ટર જેવા વિશિષ્ટ કેસ, જે, અલબત્ત, TL વાક્યરચના મુજબ હોવા જોઈએ તે રીતે યોજનામાં જાહેર કરવામાં આવે છે, પરંતુ તેઓ તેને પાર્સ કરવા માટે આ વાક્યરચના પર આધાર રાખે છે... પ્રશ્ન એ ઊભો થાય છે કે આ બધું ચમત્કાર કેમ હતું?иજો કોઈ પણ રીતે દસ્તાવેજીકરણ અનુસાર તેનું વિશ્લેષણ કરવા જઈ રહ્યું નથી તો તે વધુ સ્તરવાળી છે?!

બાય ધ વે... યાદ છે આપણે CRC32 ચેકિંગ વિશે વાત કરી હતી? તેથી, ટેલિગ્રામ ડેસ્કટોપ કોડ જનરેટરમાં તે પ્રકારો માટે અપવાદોની સૂચિ છે જેમાં ગણતરી કરેલ CRC32 મેળ ખાતો નથી ડાયાગ્રામમાં દર્શાવેલ એક સાથે!

વેસિલી, [18.12/22 49:XNUMX] અને અહીં હું વિચારીશ કે આવા TLની જરૂર છે કે કેમ
જો હું વૈકલ્પિક અમલીકરણો સાથે ગડબડ કરવા માંગુ છું, તો હું લાઇન બ્રેક્સ દાખલ કરવાનું શરૂ કરીશ, અડધા વિશ્લેષકો બહુ-લાઇન વ્યાખ્યાઓ પર તૂટી જશે
tdesktop, જોકે, પણ

વન-લાઇનર વિશેનો મુદ્દો યાદ રાખો, અમે થોડી વાર પછી તેના પર પાછા આવીશું.

ઠીક છે, ટેલિગ્રામ-ક્લી એ બિનસત્તાવાર છે, ટેલિગ્રામ ડેસ્કટોપ સત્તાવાર છે, પરંતુ અન્યનું શું? કોણ જાણે છે?.. એન્ડ્રોઇડ ક્લાયંટ કોડમાં કોઈ સ્કીમા પાર્સર જ નહોતું (જે ઓપન સોર્સ વિશે પ્રશ્નો ઉભા કરે છે, પરંતુ આ બીજા ભાગ માટે છે), પરંતુ કોડના અન્ય કેટલાક રમુજી ટુકડાઓ હતા, પરંતુ તેના પર વધુ નીચે પેટા વિભાગ.

ક્રમાંકન વ્યવહારમાં અન્ય કયા પ્રશ્નો ઉભા કરે છે? ઉદાહરણ તરીકે, તેઓએ ઘણી બધી વસ્તુઓ કરી, અલબત્ત, બીટ ફીલ્ડ્સ અને શરતી ફીલ્ડ્સ સાથે:

વેસિલી: flags.0? true
મતલબ કે ક્ષેત્ર હાજર છે અને જો ધ્વજ સેટ કરેલ હોય તો તે સાચું છે

વેસિલી: flags.1? int
મતલબ કે ક્ષેત્ર હાજર છે અને તેને ડીસીરિયલાઈઝ કરવાની જરૂર છે

વેસિલી: ગર્દભ, તમે શું કરી રહ્યાં છો તેની ચિંતા કરશો નહીં!
વેસિલી: દસ્તાવેજમાં ક્યાંક એવો ઉલ્લેખ છે કે સાચું એકદમ શૂન્ય-લંબાઈ પ્રકાર છે, પરંતુ તેમના દસ્તાવેજમાંથી કંઈપણ એસેમ્બલ કરવું અશક્ય છે
વેસિલી: ઓપન સોર્સ અમલીકરણમાં પણ આવું નથી, પરંતુ ક્રેચ અને સપોર્ટનો સમૂહ છે.

ટેલિથોન વિશે શું? MTProto ના વિષય તરફ આગળ જોતા, એક ઉદાહરણ - દસ્તાવેજીકરણમાં આવા ટુકડાઓ છે, પરંતુ ચિહ્ન % તે ફક્ત "આપેલ બેર-ટાઈપને અનુરૂપ" તરીકે વર્ણવવામાં આવે છે, એટલે કે. નીચેના ઉદાહરણોમાં કાં તો ભૂલ છે અથવા કંઈક બિનદસ્તાવેજીકૃત છે:

વેસિલી, [22.06.18 18:38] એક જગ્યાએ:

msg_container#73f1f8dc messages:vector message = MessageContainer;

અલગ રીતે:

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

અને આ બે મોટા તફાવત છે, વાસ્તવિક જીવનમાં અમુક પ્રકારનો નગ્ન વેક્ટર આવે છે

મેં એકદમ વેક્ટર વ્યાખ્યા જોઈ નથી અને એક પણ આવી નથી

વિશ્લેષણ ટેલિથોનમાં હાથ દ્વારા લખવામાં આવે છે

તેમના આકૃતિમાં વ્યાખ્યાની ટિપ્પણી કરવામાં આવી છે msg_container

ફરીથી, પ્રશ્ન % વિશે રહે છે. તેનું વર્ણન નથી.

Vadim Goncharov, [22.06.18 19:22] અને tdesktop માં?

વેસિલી, [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 ) અને નીચેની શરતો પૂરી કરવી આવશ્યક છે:

• 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 - એક પ્રકાર જેમાં મૂલ્યોની નિશ્ચિત (નાની) સંખ્યાની ગણતરી હોય છે. C - ન્યુમેરિક જેવી ભાષાઓમાં, નોંધ કરો કે અત્યાર સુધી આપણે ફક્ત પ્રકારો વિશે જ વાત કરી છે સંખ્યાઓ. પણ એરે, સ્ટ્રીંગ્સ પણ છે... ઉદાહરણ તરીકે, એ વર્ણન કરવું સરસ રહેશે કે આ સ્ટ્રિંગમાં માત્ર ફોન નંબર હોઈ શકે છે, ખરું ને?

આમાંથી કંઈ TL માં નથી. પરંતુ ત્યાં છે, ઉદાહરણ તરીકે, JSON સ્કીમામાં. અને જો કોઈ અન્ય વ્યક્તિ 512 KB ની વિભાજ્યતા વિશે દલીલ કરી શકે છે, કે આને હજુ પણ કોડમાં તપાસવાની જરૂર છે, તો ખાતરી કરો કે ક્લાયંટ ફક્ત હું ના કરી શક્યો શ્રેણીની બહારનો નંબર મોકલો 1..3000 (અને અનુરૂપ ભૂલ ઊભી થઈ શકી ન હોત) તે શક્ય બન્યું હોત, ખરું? ..

માર્ગ દ્વારા, ભૂલો અને વળતર મૂલ્યો વિશે. જેમણે TL સાથે કામ કર્યું છે તેઓ પણ તેમની આંખો ઝાંખી કરે છે - તે તરત જ અમારા પર દેખાતું ન હતું દરેક TL માં ફંક્શન વાસ્તવમાં ફક્ત વર્ણવેલ રીટર્ન પ્રકાર જ નહીં, પણ એક ભૂલ પણ પરત કરી શકે છે. પરંતુ આ TL નો ઉપયોગ કરીને કોઈપણ રીતે અનુમાનિત કરી શકાતું નથી. અલબત્ત, તે પહેલેથી જ સ્પષ્ટ છે અને વ્યવહારમાં કંઈપણની જરૂર નથી (જોકે વાસ્તવમાં, આરપીસી જુદી જુદી રીતે કરી શકાય છે, અમે પછીથી આ પર પાછા આવીશું) - પરંતુ અમૂર્ત પ્રકારોના ગણિતની વિભાવનાઓની શુદ્ધતા વિશે શું? સ્વર્ગીય વિશ્વમાંથી?.. મેં ટગ ઉપાડ્યું - તેથી તેને મેચ કરો.

અને છેલ્લે, વાંચનક્ષમતા વિશે શું? સારું, ત્યાં, સામાન્ય રીતે, હું ઈચ્છું છું વર્ણન તે સ્કીમામાં બરાબર છે (જેએસઓએન સ્કીમામાં, ફરીથી, તે છે), પરંતુ જો તમે પહેલેથી જ તેની સાથે તાણમાં છો, તો પછી વ્યવહારુ બાજુ વિશે શું - અપડેટ્સ દરમિયાન ઓછામાં ઓછા તુચ્છ રીતે જોવું? પર તમારા માટે જુઓ વાસ્તવિક ઉદાહરણો:

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

અથવા

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

તે દરેક પર આધાર રાખે છે, પરંતુ GitHub, ઉદાહરણ તરીકે, આવી લાંબી લાઇનોમાં ફેરફારોને પ્રકાશિત કરવાનો ઇનકાર કરે છે. રમત "10 તફાવતો શોધો", અને મગજ તરત જ જે જુએ છે તે એ છે કે બંને ઉદાહરણોની શરૂઆત અને અંત સમાન છે, તમારે મધ્યમાં ક્યાંક કંટાળાજનક રીતે વાંચવાની જરૂર છે... મારા મતે, આ ફક્ત સિદ્ધાંતમાં નથી, પરંતુ કેવળ દૃષ્ટિની ગંદા અને ઢાળવાળું.

માર્ગ દ્વારા, સિદ્ધાંતની શુદ્ધતા વિશે. શા માટે આપણને બીટ ફીલ્ડ્સની જરૂર છે? એવું નથી લાગતું કે તેઓ ગંધ પ્રકાર સિદ્ધાંતના દૃષ્ટિકોણથી ખરાબ? સમજૂતી રેખાકૃતિના પહેલાનાં સંસ્કરણોમાં જોઈ શકાય છે. શરૂઆતમાં, હા, તે આવું હતું, દરેક છીંક માટે એક નવો પ્રકાર બનાવવામાં આવ્યો હતો. આ રૂડીમેન્ટ્સ હજી પણ આ સ્વરૂપમાં અસ્તિત્વમાં છે, ઉદાહરણ તરીકે:

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

પરંતુ હવે કલ્પના કરો, જો તમારી પાસે તમારા બંધારણમાં 5 વૈકલ્પિક ક્ષેત્રો છે, તો તમારે તમામ સંભવિત વિકલ્પો માટે 32 પ્રકારનાં ક્ષેત્રોની જરૂર પડશે. સંયુક્ત વિસ્ફોટ. આમ, TL થિયરીની સ્ફટિક શુદ્ધતા ફરી એકવાર શ્રેણીબદ્ધતાની કઠોર વાસ્તવિકતાના કાસ્ટ-આયર્ન ગધેડા સામે વિખેરાઈ ગઈ.

આ ઉપરાંત, કેટલાક સ્થળોએ આ વ્યક્તિઓ પોતે જ તેમની પોતાની ટાઇપોલોજીનું ઉલ્લંઘન કરે છે. ઉદાહરણ તરીકે, MTProto (આગલું પ્રકરણ) માં પ્રતિભાવ Gzip દ્વારા સંકુચિત કરી શકાય છે, બધું બરાબર છે - સિવાય કે સ્તરો અને સર્કિટનું ઉલ્લંઘન થાય છે. ફરી એકવાર, તે RpcResult પોતે ન હતું જે લણવામાં આવ્યું હતું, પરંતુ તેના સમાવિષ્ટો. સારું, આ કેમ કરવું?.. મારે એક ક્રૉચ કાપવી પડી જેથી કમ્પ્રેશન ગમે ત્યાં કામ કરી શકે.

અથવા બીજું ઉદાહરણ, અમને એકવાર ભૂલ મળી - તે મોકલવામાં આવી હતી InputPeerUser вместо InputUser. અથવા ઊલટું. પરંતુ તે કામ કર્યું! એટલે કે, સર્વર પ્રકાર વિશે ધ્યાન આપતું નથી. આ કેવી રીતે હોઈ શકે? ટેલિગ્રામ-ક્લીના કોડ ટુકડાઓ દ્વારા અમને જવાબ આપવામાં આવી શકે છે:

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

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

બીજા શબ્દોમાં કહીએ તો, આ તે છે જ્યાં ક્રમાંકન કરવામાં આવે છે જાતે, જનરેટેડ કોડ નથી! કદાચ સર્વર સમાન રીતે અમલમાં મૂકાયેલ છે?.. સૈદ્ધાંતિક રીતે, જો એકવાર કરવામાં આવે તો આ કાર્ય કરશે, પરંતુ અપડેટ દરમિયાન પછીથી તેને કેવી રીતે સપોર્ટ કરી શકાય? શું આ યોજનાની શોધ શા માટે કરવામાં આવી હતી? અને અહીં આપણે આગળના પ્રશ્ન પર આગળ વધીએ છીએ.

વર્ઝનીંગ. સ્તરો

શા માટે યોજનાકીય સંસ્કરણોને સ્તરો કહેવામાં આવે છે તે ફક્ત પ્રકાશિત યોજનાશાસ્ત્રના ઇતિહાસના આધારે અનુમાન કરી શકાય છે. દેખીતી રીતે, શરૂઆતમાં લેખકોએ વિચાર્યું કે મૂળભૂત વસ્તુઓ અપરિવર્તિત યોજનાનો ઉપયોગ કરીને કરી શકાય છે, અને માત્ર જ્યાં જરૂરી હોય ત્યાં, ચોક્કસ વિનંતીઓ માટે, સૂચવે છે કે તેઓ એક અલગ સંસ્કરણનો ઉપયોગ કરીને કરવામાં આવી રહ્યા છે. સૈદ્ધાંતિક રીતે, એક સારો વિચાર પણ - અને નવો હશે, જેમ કે તે હતા, "મિશ્રિત", જૂનાની ટોચ પર સ્તરવાળી. પરંતુ ચાલો જોઈએ કે તે કેવી રીતે કરવામાં આવ્યું. સાચું, હું તેને શરૂઆતથી જ જોઈ શક્યો ન હતો - તે રમુજી છે, પરંતુ બેઝ લેયરનો આકૃતિ ફક્ત અસ્તિત્વમાં નથી. સ્તરો 2 થી શરૂ થયા. દસ્તાવેજીકરણ અમને વિશેષ TL લક્ષણ વિશે જણાવે છે:

જો ક્લાયંટ લેયર 2 ને સપોર્ટ કરે છે, તો નીચેના કન્સ્ટ્રક્ટરનો ઉપયોગ કરવો આવશ્યક છે:

invokeWithLayer2#289dd1f6 {X:Type} query:!X = X;

વ્યવહારમાં, આનો અર્થ એ છે કે દરેક API કૉલ પહેલાં, મૂલ્ય સાથે પૂર્ણાંક 0x289dd1f6 પદ્ધતિ નંબર પહેલાં ઉમેરવું આવશ્યક છે.

સામાન્ય લાગે છે. પણ આગળ શું થયું? પછી દેખાયા

invokeWithLayer3#b7475268 query:!X = X;

તો આગળ શું છે? જેમ તમે ધારી શકો છો,

invokeWithLayer4#dea0d430 query:!X = X;

રમુજી? ના, હસવું બહુ વહેલું છે, એ હકીકત વિશે વિચારો દરેક બીજા સ્તરની વિનંતીને આવા વિશિષ્ટ પ્રકારમાં આવરિત કરવાની જરૂર છે - જો તે બધા તમારા માટે અલગ હોય, તો તમે તેમને કેવી રીતે અલગ કરી શકો? અને આગળ ફક્ત 4 બાઇટ્સ ઉમેરવા એ એક સુંદર કાર્યક્ષમ પદ્ધતિ છે. તેથી,

invokeWithLayer5#417a57ae query:!X = X;

પરંતુ તે સ્પષ્ટ છે કે થોડા સમય પછી આ એક પ્રકારનું બચ્ચનલિયા બની જશે. અને ઉકેલ આવ્યો:

અપડેટ: લેયર 9 થી શરૂ કરીને, સહાયક પદ્ધતિઓ invokeWithLayerN સાથે જ ઉપયોગ કરી શકાય છે initConnection

હુરે! 9 સંસ્કરણો પછી, અમે આખરે 80 ના દાયકામાં ઇન્ટરનેટ પ્રોટોકોલમાં શું કરવામાં આવ્યું હતું તે તરફ આવ્યા - કનેક્શનની શરૂઆતમાં એકવાર સંસ્કરણ પર સંમત થયા!

તો આગળ શું છે?..

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

પરંતુ હવે તમે હજી પણ હસી શકો છો. માત્ર અન્ય 9 સ્તરો પછી, સંસ્કરણ નંબર સાથેનો એક સાર્વત્રિક કન્સ્ટ્રક્ટર આખરે ઉમેરવામાં આવ્યો હતો, જેને કનેક્શનની શરૂઆતમાં ફક્ત એક જ વાર કૉલ કરવાની જરૂર છે, અને સ્તરોનો અર્થ અદૃશ્ય થઈ ગયો હોય તેવું લાગતું હતું, હવે તે માત્ર એક શરતી સંસ્કરણ છે, જેમ કે બીજે બધે. પ્રશ્ન ઉકેલાઈ ગયો.

બરાબર?..

વેસિલી, [16.07.18 14:01] શુક્રવારે પણ મેં વિચાર્યું:
ટેલિસર્વર વિનંતી વિના ઇવેન્ટ્સ મોકલે છે. વિનંતીઓ InvokeWithLayer માં આવરિત હોવી આવશ્યક છે. સર્વર અપડેટ્સને લપેટી શકતું નથી; પ્રતિસાદો અને અપડેટ્સને રેપ કરવા માટે કોઈ માળખું નથી.

તે. ક્લાયંટ તે સ્તરનો ઉલ્લેખ કરી શકતો નથી જેમાં તેને અપડેટ્સ જોઈએ છે

વાદિમ ગોંચારોવ, [16.07.18 14:02] શું InvokeWithLayer સિદ્ધાંતમાં ક્રૉચ નથી?

Vasily, [16.07.18 14:02] આ એકમાત્ર રસ્તો છે

Vadim Goncharov, [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 અનપેક્ષિત પ્રકાર id #b5223b0f MTPMessageMedia માં વાંચવામાં આવે છે…

ગૂગલે બતાવ્યું કે બિનસત્તાવાર ક્લાયંટમાંના એકને સમાન સમસ્યા આવી હતી, પરંતુ પછી સંસ્કરણ નંબરો અને, તે મુજબ, ધારણાઓ અલગ હતી...

તો આપણે શું કરવું જોઈએ? વેસિલી અને હું અલગ થઈ ગયા: તેણે સર્કિટને 91 પર અપડેટ કરવાનો પ્રયાસ કર્યો, મેં થોડા દિવસો રાહ જોવાનું અને 73 પર પ્રયાસ કરવાનું નક્કી કર્યું. બંને પદ્ધતિઓ કામ કરતી હતી, પરંતુ તે પ્રયોગમૂલક હોવાથી, તમારે કેટલા વર્ઝન ઉપર અથવા નીચેની જરૂર છે તેની કોઈ સમજણ નથી. કૂદકો મારવો, અથવા તમારે કેટલો સમય રાહ જોવી પડશે.

પાછળથી હું પરિસ્થિતિને પુનઃઉત્પાદિત કરવામાં સક્ષમ હતો: અમે ક્લાયંટને લોંચ કરીએ છીએ, તેને બંધ કરીએ છીએ, સર્કિટને બીજા સ્તરમાં ફરીથી કમ્પાઇલ કરીએ છીએ, ફરીથી શરૂ કરીએ છીએ, સમસ્યાને ફરીથી પકડીએ છીએ, પાછલા એક પર પાછા આવો - અરે, સર્કિટ સ્વિચિંગની કોઈ માત્રા નથી અને ક્લાયંટ પુનઃપ્રારંભ થાય છે. થોડી મિનિટો મદદ કરશે. તમને વિવિધ સ્તરોમાંથી ડેટા સ્ટ્રક્ચર્સનું મિશ્રણ પ્રાપ્ત થશે.

સમજૂતી? જેમ તમે વિવિધ પરોક્ષ લક્ષણો પરથી અનુમાન લગાવી શકો છો, સર્વર વિવિધ મશીનો પર વિવિધ પ્રકારની ઘણી પ્રક્રિયાઓ ધરાવે છે. મોટે ભાગે, સર્વર કે જે "બફરિંગ" માટે જવાબદાર છે તેના ઉપરી અધિકારીઓએ તેને જે આપ્યું તે કતારમાં મૂક્યું, અને તેઓએ તે યોજનામાં આપ્યું જે પેઢીના સમયે હતી. અને આ કતાર "સડેલી" ન થાય ત્યાં સુધી, તેના વિશે કંઇ કરી શકાતું નથી.

કદાચ... પરંતુ આ એક ભયંકર ક્રચ છે?!.. ના, ઉન્મત્ત વિચારો વિશે વિચારતા પહેલા, ચાલો સત્તાવાર ગ્રાહકોના કોડ જોઈએ. એન્ડ્રોઇડ વર્ઝનમાં અમને કોઈ TL પાર્સર મળતું નથી, પરંતુ અમને (ડી) સીરીયલાઇઝેશન સાથે એક મોટી ફાઇલ (ગીટહબ તેને સ્પર્શ કરવાનો ઇનકાર કરે છે) શોધીએ છીએ. અહીં કોડ સ્નિપેટ્સ છે:

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;

આ ટિપ્પણી "મેન્યુઅલી બનાવેલ" સૂચવે છે કે આ ફાઇલનો માત્ર એક ભાગ મેન્યુઅલી લખવામાં આવ્યો હતો (શું તમે આખા જાળવણીના દુઃસ્વપ્નની કલ્પના કરી શકો છો?), અને બાકીનું મશીન-જનરેટેડ હતું. જો કે, પછી બીજો પ્રશ્ન ઊભો થાય છે - તે સ્ત્રોતો ઉપલબ્ધ છે સંપૂર્ણપણે નથી (લિનક્સ કર્નલમાં la GPL બ્લોબ્સ), પરંતુ આ પહેલાથી જ બીજા ભાગ માટેનો વિષય છે.

પરંતુ પર્યાપ્ત. ચાલો પ્રોટોકોલ પર આગળ વધીએ જેની ઉપર આ બધી સીરીયલાઇઝેશન ચાલે છે.

એમટીપીટ્રોટો

તો, ચાલો ખોલીએ સામાન્ય વર્ણન и પ્રોટોકોલનું વિગતવાર વર્ણન અને પ્રથમ વસ્તુ જે આપણે ઠોકર ખાઈએ છીએ તે છે પરિભાષા. અને દરેક વસ્તુની વિપુલતા સાથે. સામાન્ય રીતે, આ ટેલિગ્રામની માલિકીનું લક્ષણ હોય તેવું લાગે છે - અલગ-અલગ જગ્યાએ વસ્તુઓને અલગ-અલગ રીતે કૉલ કરવી, અથવા એક શબ્દથી અલગ-અલગ વસ્તુઓ કરવી, અથવા ઊલટું (ઉદાહરણ તરીકે, ઉચ્ચ-સ્તરના APIમાં, જો તમે સ્ટીકર પેક જુઓ છો, તો તે નથી. તમે શું વિચાર્યું).

ઉદાહરણ તરીકે, "સંદેશ" અને "સત્ર" નો અર્થ અહીં સામાન્ય ટેલિગ્રામ ક્લાયંટ ઈન્ટરફેસ કરતાં કંઈક અલગ છે. ઠીક છે, સંદેશ સાથે બધું સ્પષ્ટ છે, તેને OOP શબ્દોમાં અર્થઘટન કરી શકાય છે, અથવા ફક્ત "પેકેટ" શબ્દ તરીકે ઓળખવામાં આવે છે - આ એક નીચું, પરિવહન સ્તર છે, ત્યાં ઇન્ટરફેસ જેવા જ સંદેશા નથી, ઘણા સેવા સંદેશાઓ છે . પરંતુ સત્ર... પરંતુ પ્રથમ વસ્તુઓ પ્રથમ.

પરિવહન સ્તર

પ્રથમ વસ્તુ પરિવહન છે. તેઓ અમને 5 વિકલ્પો વિશે જણાવશે:

• ટીસીપી
• વેબસોકેટ
• HTTPS પર વેબસોકેટ
• HTTP
• HTTPS

વેસિલી, [15.06.18 15:04] UDP પરિવહન પણ છે, પરંતુ તે દસ્તાવેજીકૃત નથી

અને ત્રણ વેરિઅન્ટમાં TCP

પહેલું TCP પર UDP જેવું જ છે, દરેક પેકેટમાં ક્રમ નંબર અને crcનો સમાવેશ થાય છે
શા માટે કાર્ટ પરના દસ્તાવેજો વાંચવાથી આટલું પીડાદાયક છે?

સારું, તે હવે છે TCP પહેલેથી જ 4 ચલોમાં છે:

• સંક્ષિપ્તમાં
• મધ્યમ
• ગાદીવાળાં મધ્યવર્તી
• પૂર્ણ

ઠીક છે, MTProxy માટે પેડેડ ઇન્ટરમીડિયેટ, આ પછીથી જાણીતી ઘટનાઓને કારણે ઉમેરવામાં આવ્યું હતું. પરંતુ જ્યારે તમે એક સાથે મેળવી શકો ત્યારે શા માટે વધુ બે સંસ્કરણો (કુલ ત્રણ)? મુખ્ય MTProtoની લંબાઈ અને પેલોડ કેવી રીતે સેટ કરવી તે ચારેય આવશ્યકપણે અલગ પડે છે, જેની આગળ ચર્ચા કરવામાં આવશે:

• સંક્ષિપ્તમાં તે 1 અથવા 4 બાઇટ્સ છે, પરંતુ 0xef નહીં, પછી શરીર
• ઇન્ટરમીડિયેટમાં આ 4 બાઇટ્સ લંબાઈ અને ફીલ્ડ છે, અને પ્રથમ વખત ક્લાયંટે મોકલવું આવશ્યક છે 0xeeeeeeee તે મધ્યવર્તી છે તે દર્શાવવા માટે
• સંપૂર્ણ રીતે, નેટવર્કરના દૃષ્ટિકોણથી, સૌથી વધુ વ્યસનકારક: લંબાઈ, ક્રમ નંબર, અને તે એક નહીં જે મુખ્યત્વે MTProto, શરીર, CRC32 છે. હા, આ બધું TCP ની ટોચ પર છે. જે અમને ક્રમિક બાઈટ સ્ટ્રીમના રૂપમાં વિશ્વસનીય પરિવહન પૂરું પાડે છે; કોઈ સિક્વન્સની જરૂર નથી, ખાસ કરીને ચેકસમ્સની. ઠીક છે, હવે કોઈ મારી સામે વાંધો ઉઠાવશે કે TCP પાસે 16-બીટ ચેકસમ છે, તેથી ડેટા કરપ્શન થાય છે. સરસ, પરંતુ અમારી પાસે વાસ્તવમાં 16 બાઇટ્સથી વધુ લાંબી હેશ સાથેનો ક્રિપ્ટોગ્રાફિક પ્રોટોકોલ છે, આ બધી ભૂલો - અને તેનાથી પણ વધુ - ઉચ્ચ સ્તરે SHA મિસમેચ દ્વારા પકડવામાં આવશે. આના ઉપર CRC32 માં કોઈ બિંદુ નથી.

ચાલો સંક્ષિપ્તની તુલના કરીએ, જેમાં એક બાઈટ લંબાઈ શક્ય છે, મધ્યવર્તી સાથે, જે "જો 4-બાઈટ ડેટા ગોઠવણીની જરૂર હોય તો" વાજબી ઠેરવે છે, જે તદ્દન વાહિયાત છે. શું, એવું માનવામાં આવે છે કે ટેલિગ્રામ પ્રોગ્રામર્સ એટલા અસમર્થ છે કે તેઓ સૉકેટમાંથી સંરેખિત બફરમાં ડેટા વાંચી શકતા નથી? તમારે હજી પણ આ કરવું પડશે, કારણ કે વાંચન તમને ગમે તેટલા બાઇટ્સ પરત કરી શકે છે (અને ત્યાં પ્રોક્સી સર્વર્સ પણ છે, ઉદાહરણ તરીકે...). અથવા બીજી બાજુ, જો આપણી પાસે હજુ પણ 16 બાઈટ્સની ટોચ પર ભારે પેડિંગ હશે તો સંક્ષિપ્તમાં કેમ બ્લોક કરો - 3 બાઈટ બચાવો ક્યારેક ?

કોઈને એવી છાપ મળે છે કે નિકોલાઈ દુરોવ ખરેખર કોઈપણ વાસ્તવિક વ્યવહારિક જરૂરિયાત વિના, નેટવર્ક પ્રોટોકોલ સહિત વ્હીલ્સને ફરીથી શોધવાનું પસંદ કરે છે.

અન્ય પરિવહન વિકલ્પો, સહિત. વેબ અને MTProxy, અમે હવે વિચારીશું નહીં, કદાચ બીજી પોસ્ટમાં, જો વિનંતી હશે તો. આ જ MTProxy વિશે, ચાલો હમણાં જ યાદ રાખીએ કે 2018 માં રિલીઝ થયાના થોડા સમય પછી, પ્રદાતાઓએ ઝડપથી તેને અવરોધિત કરવાનું શીખી લીધું હતું, જેનો હેતુ બાયપાસ બ્લોકીંગદ્વારા પેકેજ કદ! અને એ પણ હકીકત એ છે કે C માં લખાયેલ MTProxy સર્વર (ફરીથી વોલ્ટમેન દ્વારા) લિનક્સ વિશિષ્ટતાઓ સાથે વધુ પડતું જોડાયેલું હતું, જો કે આ બિલકુલ જરૂરી ન હતું (ફિલ કુલીન પુષ્ટિ કરશે), અને તે સમાન સર્વર કાં તો Go અથવા Node.js માં હશે. સો કરતાં ઓછી લાઇનમાં ફિટ.

પરંતુ અમે અન્ય મુદ્દાઓને ધ્યાનમાં લીધા પછી વિભાગના અંતે આ લોકોની તકનીકી સાક્ષરતા વિશે તારણો દોરીશું. હમણાં માટે, ચાલો OSI સ્તર 5, સત્ર તરફ આગળ વધીએ - જેના પર તેઓએ MTProto સત્ર મૂક્યું.

કી, સંદેશાઓ, સત્રો, ડિફી-હેલમેન

તેઓએ તેને ત્યાં સંપૂર્ણપણે યોગ્ય રીતે મૂક્યું નથી... સત્ર એ એ જ સત્ર નથી જે સક્રિય સત્રો હેઠળના ઇન્ટરફેસમાં દેખાય છે. પરંતુ ક્રમમાં.

તેથી અમને પરિવહન સ્તરમાંથી જાણીતી લંબાઈની બાઈટ સ્ટ્રિંગ મળી. આ કાં તો એન્ક્રિપ્ટેડ સંદેશ અથવા સાદો લખાણ છે - જો આપણે હજી પણ મુખ્ય કરારના તબક્કે છીએ અને ખરેખર કરી રહ્યા છીએ. આપણે "કી" તરીકે ઓળખાતા ખ્યાલોના સમૂહમાંથી કયા વિશે વાત કરી રહ્યા છીએ? ચાલો ટેલિગ્રામ ટીમ માટે જ આ મુદ્દાને સ્પષ્ટ કરીએ (હું સવારે 4 વાગ્યે થાકેલા મગજ સાથે અંગ્રેજીમાંથી મારા પોતાના દસ્તાવેજોનું ભાષાંતર કરવા બદલ માફી માંગુ છું, કેટલાક શબ્દસમૂહો જેમ છે તેમ છોડી દેવાનું સરળ હતું):

ત્યાં બે સંસ્થાઓ કહેવાય છે સત્ર - "વર્તમાન સત્રો" હેઠળના અધિકૃત ક્લાયંટના UI માં એક, જ્યાં દરેક સત્ર સમગ્ર ઉપકરણ / OS ને અનુલક્ષે છે.
બીજું - MTProto સત્ર, જેમાં સંદેશનો ક્રમ નંબર છે (નીચા-સ્તરના અર્થમાં) અને જે વિવિધ TCP જોડાણો વચ્ચે ટકી શકે છે. એક જ સમયે કેટલાક MTProto સત્રો ઇન્સ્ટોલ કરી શકાય છે, ઉદાહરણ તરીકે, ફાઇલ ડાઉનલોડિંગને ઝડપી બનાવવા માટે.

આ બંને વચ્ચે સત્રો એક ખ્યાલ છે અધિકૃતતા. અધોગતિના કિસ્સામાં, અમે કહી શકીએ કે UI સત્ર જેવું જ છે અધિકૃતતા, પરંતુ અફસોસ, બધું જટિલ છે. ચાલો જોઈએ:

• નવા ઉપકરણ પર વપરાશકર્તા પ્રથમ જનરેટ કરે છે auth_key અને તેને એકાઉન્ટ સાથે બાંધે છે, ઉદાહરણ તરીકે SMS દ્વારા - તેથી જ અધિકૃતતા
• તે પ્રથમ અંદર થયું MTProto સત્ર, જેની પાસે હોય session_id તમારી અંદર.
• આ પગલા પર, સંયોજન અધિકૃતતા и session_id કહી શકાય ઉદાહરણ - આ શબ્દ કેટલાક ગ્રાહકોના દસ્તાવેજીકરણ અને કોડમાં દેખાય છે
• પછી, ક્લાયંટ ખોલી શકે છે કેટલાક MTProto સત્રો તે જ હેઠળ auth_key - એ જ ડીસીને.
• પછી, એક દિવસ ક્લાયન્ટને ફાઇલની વિનંતી કરવાની જરૂર પડશે અન્ય ડીસી - અને આ માટે એક નવું DC જનરેટ કરવામાં આવશે auth_key !
• સિસ્ટમને જાણ કરવા માટે કે તે કોઈ નવો વપરાશકર્તા નથી જે નોંધણી કરી રહ્યો છે, પરંતુ તે જ છે અધિકૃતતા (UI સત્ર), ક્લાયંટ API કૉલ્સનો ઉપયોગ કરે છે auth.exportAuthorization ઘર ડીસી માં auth.importAuthorization નવા ડીસીમાં.
• બધું એકસરખું છે, ઘણા ખુલ્લા હોઈ શકે છે MTProto સત્રો (દરેક તેની પોતાની સાથે session_id) આ નવા ડીસી માટે, હેઠળ તેના auth_key.
• છેલ્લે, ક્લાયન્ટ પરફેક્ટ ફોરવર્ડ સિક્રસી ઇચ્છે છે. દરેક auth_key હતી કાયમી કી - ડીસી દીઠ - અને ક્લાયંટ કૉલ કરી શકે છે auth.bindTempAuthKey ઉપયોગ માટે કામચલાઉ auth_key - અને ફરીથી, માત્ર એક temp_auth_key ડીસી દીઠ, બધા માટે સામાન્ય MTProto સત્રો આ ડીસીને.

આ ધ્યાન માં રાખો મીઠું (અને ભાવિ ક્ષાર) પણ એક પર છે auth_key તે દરેકની વચ્ચે વહેંચાયેલું MTProto સત્રો એ જ ડીસીને.

"વિવિધ TCP જોડાણો વચ્ચે" નો અર્થ શું થાય છે? તો આનો અર્થ છે જેવું કંઈક વેબસાઇટ પર અધિકૃતતા કૂકી - તે આપેલ સર્વર પર ઘણા TCP કનેક્શન્સ ચાલુ રહે છે (ટકી રહે છે), પરંતુ એક દિવસ તે ખરાબ થઈ જાય છે. માત્ર HTTPથી વિપરીત, MTProtoમાં સત્રની અંદરના સંદેશાઓ ક્રમિક રીતે ક્રમાંકિત અને પુષ્ટિ કરવામાં આવે છે; જો તેઓ ટનલમાં પ્રવેશ્યા હોય, તો કનેક્શન તૂટી ગયું હતું - નવું કનેક્શન સ્થાપિત કર્યા પછી, સર્વર કૃપા કરીને આ સત્રમાં તે બધું મોકલશે જે તેણે અગાઉના સમયમાં વિતરિત કર્યું ન હતું. TCP કનેક્શન.

જો કે, ઉપરોક્ત માહિતીનો સારાંશ ઘણા મહિનાઓની તપાસ પછી આપવામાં આવ્યો છે. આ દરમિયાન, શું અમે અમારા ક્લાયન્ટને શરૂઆતથી અમલમાં મૂકીએ છીએ? - ચાલો શરૂઆત પર પાછા જઈએ.

તો ચાલો જનરેટ કરીએ auth_key પર ટેલિગ્રામમાંથી ડિફી-હેલમેન સંસ્કરણો. ચાલો દસ્તાવેજો સમજવાનો પ્રયત્ન કરીએ...

વેસિલી, [19.06.18 20:05] data_with_hash := SHA1(ડેટા) + ડેટા + (કોઈપણ રેન્ડમ બાઈટ); જેમ કે લંબાઈ 255 બાઇટ્સ સમાન છે;
encrypted_data := RSA(data_with_hash, server_public_key); 255-બાઇટ લાંબો નંબર (મોટો એન્ડિયન) જરૂરી મોડ્યુલસ પર જરૂરી પાવર સુધી વધારવામાં આવે છે, અને પરિણામ 256-બાઇટ નંબર તરીકે સંગ્રહિત થાય છે.

તેઓ કેટલાક ડોપ DH છે

તંદુરસ્ત વ્યક્તિના DH જેવું લાગતું નથી
dx માં કોઈ બે સાર્વજનિક કી નથી

ઠીક છે, અંતે આને ઉકેલવામાં આવ્યું હતું, પરંતુ એક અવશેષ રહી ગયો - કામનો પુરાવો ક્લાયંટ દ્વારા કરવામાં આવે છે કે તે સંખ્યાને પરિબળ કરવામાં સક્ષમ હતો. DoS હુમલા સામે રક્ષણનો પ્રકાર. અને આરએસએ કીનો ઉપયોગ ફક્ત એક જ દિશામાં થાય છે, અનિવાર્યપણે એન્ક્રિપ્શન માટે new_nonce. પરંતુ જ્યારે આ મોટે ભાગે સરળ ઓપરેશન સફળ થશે, ત્યારે તમારે શું સામનો કરવો પડશે?

વેસિલી, [20.06.18/00/26 XNUMX:XNUMX] હું હજી સુધી એપિડ વિનંતી પર પહોંચ્યો નથી

મેં આ વિનંતી DH ને મોકલી છે

અને, પરિવહન ડોકમાં તે કહે છે કે તે ભૂલ કોડના 4 બાઇટ્સ સાથે પ્રતિસાદ આપી શકે છે. બસ એટલું જ

સારું, તેણે મને કહ્યું -404, તો શું?

તેથી મેં તેને કહ્યું: "આ રીતે ફિંગરપ્રિન્ટ સાથે સર્વર કી સાથે એન્ક્રિપ્ટેડ તમારી બુલશીટને પકડો, મને DH જોઈએ છે," અને તેણે મૂર્ખ 404 સાથે જવાબ આપ્યો.

તમે આ સર્વર પ્રતિસાદ વિશે શું વિચારો છો? શુ કરવુ? પૂછવા માટે કોઈ નથી (પરંતુ બીજા ભાગમાં તે વિશે વધુ).

અહીં તમામ રસ ડોક પર કરવામાં આવે છે

મારે બીજું કંઈ કરવાનું નથી, મેં ફક્ત નંબરોને આગળ અને પાછળ ફેરવવાનું સપનું જોયું

બે 32 બીટ નંબરો. મેં તેમને બીજા બધાની જેમ પેક કર્યા

પરંતુ ના, આ બેને પહેલા BE તરીકે લીટીમાં ઉમેરવાની જરૂર છે

Vadim Goncharov, [20.06.18 15:49] અને આને કારણે 404?

વેસિલી, [20.06.18 15:49] હા!

Vadim Goncharov, [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 ડિફી-હેલમેનનો ઉપયોગ કરીને અમને 2048 બિટ્સ કદમાં મળ્યા છે. આગળ શું છે? આગળ આપણે શોધી કાઢીએ છીએ કે આ કીના નીચેના 1024 બિટ્સ કોઈપણ રીતે ઉપયોગમાં લેવાતા નથી... પરંતુ ચાલો આ વિશે અત્યારે વિચારીએ. આ પગલા પર, અમારી પાસે સર્વર સાથે વહેંચાયેલ રહસ્ય છે. TLS સત્રનું એનાલોગ સ્થાપિત કરવામાં આવ્યું છે, જે ખૂબ જ ખર્ચાળ પ્રક્રિયા છે. પરંતુ સર્વર હજી પણ આપણે કોણ છીએ તે વિશે કંઈપણ જાણતું નથી! હજુ સુધી નથી, ખરેખર. અધિકૃતતા. તે. જો તમે "લોગિન-પાસવર્ડ" ના સંદર્ભમાં વિચાર્યું હોય, જેમ કે તમે એકવાર ICQ માં કર્યું હતું, અથવા ઓછામાં ઓછું "લોગિન-કી", SSH ની જેમ (ઉદાહરણ તરીકે, અમુક gitlab/github પર). અમને એક અનામી મળ્યો. જો સર્વર અમને કહે કે "આ ફોન નંબરો બીજા DC દ્વારા સેવા આપવામાં આવે છે" તો શું? અથવા તો “તમારા ફોન નંબર પર પ્રતિબંધ છે”? ચાવીને એ આશામાં રાખવાનું શ્રેષ્ઠ છે કે તે ઉપયોગી થશે અને ત્યાં સુધીમાં તે બગડશે નહીં.

માર્ગ દ્વારા, અમે તેને આરક્ષણ સાથે "પ્રાપ્ત" કર્યું. ઉદાહરણ તરીકે, શું આપણે સર્વર પર વિશ્વાસ કરીએ છીએ? જો તે નકલી હોય તો શું? ક્રિપ્ટોગ્રાફિક તપાસની જરૂર પડશે:

વેસિલી, [21.06.18 17:53] તેઓ મોબાઇલ ક્લાયંટને પ્રાથમિકતા% માટે 2kbit નંબર તપાસવાની ઓફર કરે છે)

પરંતુ તે બિલકુલ સ્પષ્ટ નથી, nafeijoa

વેસિલી, [21.06.18 18:02] દસ્તાવેજ એ જણાવતું નથી કે જો તે સરળ ન હોય તો શું કરવું

કહ્યું નથી. ચાલો જોઈએ કે આ કિસ્સામાં સત્તાવાર Android ક્લાયંટ શું કરે છે? એ તે શું છે (અને હા, આખી ફાઇલ રસપ્રદ છે) - જેમ તેઓ કહે છે, હું આને અહીં છોડીશ:

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

ના, અલબત્ત તે હજુ પણ છે કેટલાક સંખ્યાની પ્રાથમિકતા માટે પરીક્ષણો છે, પરંતુ વ્યક્તિગત રીતે મારી પાસે હવે ગણિતનું પૂરતું જ્ઞાન નથી.

ઠીક છે, અમને માસ્ટર કી મળી. લૉગ ઇન કરવા માટે, એટલે કે. વિનંતીઓ મોકલો, તમારે AES નો ઉપયોગ કરીને વધુ એન્ક્રિપ્શન કરવાની જરૂર છે.

મેસેજ કીને મેસેજ બોડીના SHA128 ના 256 મિડલ બિટ્સ તરીકે વ્યાખ્યાયિત કરવામાં આવે છે (સત્ર, મેસેજ ID, વગેરે સહિત), પેડિંગ બાઇટ્સ સહિત, ઓથોરાઇઝેશન કીમાંથી લીધેલા 32 બાઇટ્સ દ્વારા પ્રીપેન્ડ કરવામાં આવે છે.

વેસિલી, [22.06.18 14:08] સરેરાશ, કૂતરી, બિટ્સ

પ્રાપ્ત auth_key. બધા. તેમનાથી આગળ... તે દસ્તાવેજમાંથી સ્પષ્ટ નથી. ઓપન સોર્સ કોડનો અભ્યાસ કરવા માટે નિઃસંકોચ.

નોંધ કરો કે MTProto 2.0 ને 12 થી 1024 બાઇટ્સ પેડિંગની આવશ્યકતા છે, હજુ પણ તે શરતને આધીન છે કે પરિણામી સંદેશની લંબાઈ 16 બાઇટ દ્વારા વિભાજિત કરી શકાય.

તો તમારે કેટલું પેડિંગ ઉમેરવું જોઈએ?

અને હા, ભૂલના કિસ્સામાં 404 પણ છે

જો કોઈએ દસ્તાવેજીકરણના ડાયાગ્રામ અને ટેક્સ્ટનો કાળજીપૂર્વક અભ્યાસ કર્યો, તો તેઓએ નોંધ્યું કે ત્યાં કોઈ MAC નથી. અને તે AES નો ઉપયોગ ચોક્કસ IGE મોડમાં થાય છે જેનો ઉપયોગ બીજે ક્યાંય થતો નથી. તેઓ, અલબત્ત, આ વિશે તેમના FAQ માં લખે છે... અહીં, જેમ કે, મેસેજ કી પોતે પણ ડિક્રિપ્ટેડ ડેટાની SHA હેશ છે, જેનો ઉપયોગ અખંડિતતા ચકાસવા માટે થાય છે - અને જો મેળ ન ખાતી હોય તો, કોઈ કારણસર દસ્તાવેજીકરણ તેમને ચુપચાપ અવગણવાની ભલામણ કરે છે (પરંતુ સુરક્ષા વિશે શું, જો તેઓ અમને તોડે તો શું?).

હું ક્રિપ્ટોગ્રાફર નથી, કદાચ સૈદ્ધાંતિક દૃષ્ટિકોણથી આ કિસ્સામાં આ મોડમાં કંઈ ખોટું નથી. પરંતુ ઉદાહરણ તરીકે ટેલિગ્રામ ડેસ્કટોપનો ઉપયોગ કરીને હું વ્યવહારિક સમસ્યાનું સ્પષ્ટ નામ આપી શકું છું. તે સ્થાનિક કેશ (આ તમામ D877F783D5D3EF8C) ને MTProto માં સંદેશાઓની જેમ જ એન્ક્રિપ્ટ કરે છે (માત્ર આ કિસ્સામાં સંસ્કરણ 1.0), એટલે કે. પહેલા મેસેજ કી, પછી ડેટા પોતે (અને ક્યાંક મુખ્ય ને બાજુ પર રાખીને auth_key 256 બાઇટ્સ, જેના વિના msg_key નકામું). તેથી, સમસ્યા મોટી ફાઇલો પર ધ્યાનપાત્ર બને છે. જેમ કે, તમારે ડેટાની બે નકલો રાખવાની જરૂર છે - એન્ક્રિપ્ટેડ અને ડિક્રિપ્ટેડ. અને જો ત્યાં મેગાબાઇટ્સ અથવા સ્ટ્રીમિંગ વિડિયો છે, ઉદાહરણ તરીકે?.. સાઇફરટેક્સ્ટ પછી MAC સાથે ક્લાસિક સ્કીમ્સ તમને તેને સ્ટ્રીમ વાંચવાની મંજૂરી આપે છે, તરત જ તેને ટ્રાન્સમિટ કરે છે. પરંતુ MTProto સાથે તમારે કરવું પડશે પ્રથમ સમગ્ર સંદેશને એન્ક્રિપ્ટ અથવા ડિક્રિપ્ટ કરો, માત્ર પછી તેને નેટવર્ક અથવા ડિસ્ક પર સ્થાનાંતરિત કરો. તેથી, કેશમાં ટેલિગ્રામ ડેસ્કટોપના નવીનતમ સંસ્કરણોમાં user_data અન્ય ફોર્મેટનો પણ ઉપયોગ થાય છે - CTR મોડમાં AES સાથે.

વેસિલી, [21.06.18 01:27] ઓહ, મને જાણવા મળ્યું કે IGE શું છે: IGE એ "પ્રમાણીકરણ એન્ક્રિપ્શન મોડ"નો પ્રથમ પ્રયાસ હતો, જે મૂળ રૂપે કર્બરોસ માટે હતો. તે નિષ્ફળ પ્રયાસ હતો (તે અખંડિતતા સુરક્ષા પ્રદાન કરતું નથી), અને તેને દૂર કરવું પડ્યું હતું. તે એક પ્રમાણીકરણ એન્ક્રિપ્શન મોડ માટે 20 વર્ષની શોધની શરૂઆત હતી જે કાર્ય કરે છે, જે તાજેતરમાં OCB અને GCM જેવા મોડ્સમાં પરિણમ્યું હતું.

અને હવે કાર્ટ બાજુની દલીલો:

નિકોલાઈ દુરોવની આગેવાની હેઠળની ટેલિગ્રામ પાછળની ટીમમાં છ ACM ચેમ્પિયનનો સમાવેશ થાય છે, જેમાંથી અડધા ગણિતમાં Ph.D. એમટીપ્રોટોના વર્તમાન સંસ્કરણને બહાર પાડવામાં તેમને લગભગ બે વર્ષ લાગ્યાં.

તે રમુજી છે. નીચલા સ્તરે બે વર્ષ

અથવા તમે માત્ર tls લઈ શકો છો

ઠીક છે, ચાલો કહીએ કે અમે એન્ક્રિપ્શન અને અન્ય ઘોંઘાટ કરી લીધી છે. શું આખરે TL માં અનુક્રમિત વિનંતીઓ મોકલવી અને પ્રતિસાદોને ડીસીરિયલાઈઝ કરવું શક્ય છે? તો તમારે શું અને કેવી રીતે મોકલવું જોઈએ? અહીં, ચાલો, પદ્ધતિ કહીએ initConnection, કદાચ આ તે છે?

વેસિલી, [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 પ્રાપ્ત થાય છે. અને જો આપણે ખોટા ડીસીમાં છીએ (ઉદાહરણ તરીકે, આ દેશમાં ટેલિફોન નંબરો બીજા દ્વારા આપવામાં આવે છે), તો પછી અમને ઇચ્છિત ડીસીની સંખ્યા સાથે ભૂલ પ્રાપ્ત થશે. તમારે DC નંબર દ્વારા કયા IP સરનામા સાથે કનેક્ટ કરવાની જરૂર છે તે શોધવા માટે, અમને મદદ કરો help.getConfig. એક સમયે ફક્ત 5 એન્ટ્રીઓ હતી, પરંતુ 2018 ની પ્રખ્યાત ઘટનાઓ પછી, સંખ્યામાં નોંધપાત્ર વધારો થયો છે.

હવે યાદ રાખીએ કે આપણે સર્વર પર અજ્ઞાત રૂપે આ તબક્કે પહોંચ્યા છીએ. શું માત્ર IP સરનામું મેળવવું ખૂબ ખર્ચાળ નથી? MTProto ના એનક્રિપ્ટેડ ભાગમાં આ અને અન્ય કામગીરી શા માટે ન કરવી? મને વાંધો સંભળાય છે: "અમે કેવી રીતે ખાતરી કરી શકીએ કે તે RKN નથી જે ખોટા સરનામા સાથે જવાબ આપશે?" આ માટે અમને યાદ છે કે, સામાન્ય રીતે, સત્તાવાર ગ્રાહકો RSA કી એમ્બેડ કરેલી છે, એટલે કે તમે માત્ર કરી શકો છો સબ્સ્ક્રાઇબ કરો આ માહિતી. વાસ્તવમાં, આ પહેલેથી જ અન્ય ચેનલો દ્વારા ક્લાયન્ટ્સને પ્રાપ્ત થતી બ્લોકીંગને બાયપાસ કરવાની માહિતી માટે કરવામાં આવી રહ્યું છે (તાર્કિક રીતે, આ એમટીપ્રોટોમાં જ થઈ શકતું નથી; તમારે ક્યાં કનેક્ટ કરવું તે પણ જાણવાની જરૂર છે).

બરાબર. ક્લાયંટ અધિકૃતતાના આ તબક્કે, અમે હજુ સુધી અધિકૃત નથી અને અમારી અરજી રજીસ્ટર કરી નથી. અમે હમણાં જ જોવા માંગીએ છીએ કે સર્વર અનધિકૃત વપરાશકર્તા માટે ઉપલબ્ધ પદ્ધતિઓ પર શું પ્રતિસાદ આપે છે. અને અહીં…

વેસિલી, [10.07.18 14:45] https://core.telegram.org/method/help.getConfig

config#7dae33e0 [...] = Config;
help.getConfig#c4f9186b = Config;

https://core.telegram.org/api/datacenter

config#232d5905 [...] = Config;
help.getConfig#c4f9186b = Config;

યોજનામાં, પ્રથમ આવે છે બીજા

tdesktop સ્કીમામાં ત્રીજું મૂલ્ય છે

હા, ત્યારથી, અલબત્ત, દસ્તાવેજીકરણ અપડેટ કરવામાં આવ્યું છે. જો કે તે ટૂંક સમયમાં ફરીથી અપ્રસ્તુત બની શકે છે. શિખાઉ વિકાસકર્તાને કેવી રીતે જાણવું જોઈએ? કદાચ જો તમે તમારી અરજી રજીસ્ટર કરો, તો તેઓ તમને જાણ કરશે? વેસિલીએ આ કર્યું, પરંતુ અફસોસ, તેઓએ તેને કંઈપણ મોકલ્યું નહીં (ફરીથી, અમે બીજા ભાગમાં આ વિશે વાત કરીશું).

...તમે નોંધ્યું છે કે અમે પહેલાથી જ કોઈક રીતે API પર ખસેડ્યા છીએ, એટલે કે. આગલા સ્તર પર, અને MTProto વિષયમાં કંઈક ચૂકી ગયા? કોઈ આશ્ચર્ય નથી:

વેસિલી, [28.06.18 02:04] એમએમ, તેઓ e2e પરના કેટલાક અલ્ગોરિધમ્સ દ્વારા ગડબડ કરી રહ્યા છે

Mtproto બંને ડોમેન્સ માટે એન્ક્રિપ્શન એલ્ગોરિધમ્સ અને કી, તેમજ થોડી રેપર સ્ટ્રક્ચરને વ્યાખ્યાયિત કરે છે

પરંતુ તેઓ સતત સ્ટેકના વિવિધ સ્તરોને મિશ્રિત કરે છે, તેથી તે હંમેશા સ્પષ્ટ નથી હોતું કે mtproto ક્યાં સમાપ્ત થયું અને આગલું સ્તર ક્યાં શરૂ થયું

તેઓ કેવી રીતે ભળી જાય છે? ઠીક છે, અહીં PFS માટે સમાન અસ્થાયી કી છે, ઉદાહરણ તરીકે (તે રીતે, ટેલિગ્રામ ડેસ્કટૉપ તે કરી શકતું નથી). તે API વિનંતી દ્વારા ચલાવવામાં આવે છે auth.bindTempAuthKey, એટલે કે ટોચના સ્તરથી. પરંતુ તે જ સમયે તે નીચલા સ્તરે એન્ક્રિપ્શનમાં દખલ કરે છે - તે પછી, ઉદાહરણ તરીકે, તમારે તેને ફરીથી કરવાની જરૂર છે initConnection વગેરે, આ નથી માત્ર સામાન્ય વિનંતી. ખાસ વાત એ છે કે તમારી પાસે ડીસી દીઠ માત્ર એક જ કામચલાઉ કી હોઈ શકે છે, જો કે ફીલ્ડ auth_key_id દરેક સંદેશમાં તમને ઓછામાં ઓછા દરેક સંદેશમાં કી બદલવાની મંજૂરી આપે છે, અને સર્વરને કોઈપણ સમયે અસ્થાયી કીને "ભૂલી જવાનો" અધિકાર છે - દસ્તાવેજીકરણ કહેતું નથી કે આ કિસ્સામાં શું કરવું... સારું, શા માટે શક્ય નથી તમારી પાસે ઘણી ચાવીઓ નથી, જેમ કે ભાવિ ક્ષારના સમૂહ સાથે, અને?..

MTProto થીમ વિશે નોંધવા જેવી બીજી કેટલીક બાબતો છે.

સંદેશ સંદેશાઓ, msg_id, msg_seqno, પુષ્ટિકરણ, ખોટી દિશામાં પિંગ્સ અને અન્ય રૂઢિપ્રયોગો

તમારે તેમના વિશે શા માટે જાણવાની જરૂર છે? કારણ કે તેઓ ઉચ્ચ સ્તર પર "લીક" થાય છે, અને API સાથે કામ કરતી વખતે તમારે તેમના વિશે જાગૃત રહેવાની જરૂર છે. ચાલો ધારીએ કે અમને msg_key માં રસ નથી; નીચલા સ્તરે અમારા માટે બધું ડિક્રિપ્ટ કર્યું છે. પરંતુ ડિક્રિપ્ટેડ ડેટાની અંદર અમારી પાસે નીચેના ફીલ્ડ્સ છે (ડેટાની લંબાઈ પણ, તેથી અમે જાણીએ છીએ કે પેડિંગ ક્યાં છે, પરંતુ તે મહત્વપૂર્ણ નથી):

• મીઠું - int64
• સેશન_આઈડી - int64
• મેસેજ_આઈડી - 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! કેવી રીતે? સારું, ઉદાહરણ તરીકે, સર્વર અમને કંઈક મોકલે છે, મોકલે છે, અને અમે પોતે મૌન રહીએ છીએ, ફક્ત તેના સંદેશાઓની પ્રાપ્તિની પુષ્ટિ કરતા સેવા સંદેશાઓ સાથે પ્રતિસાદ આપીએ છીએ. આ કિસ્સામાં, અમારા આઉટગોઇંગ કન્ફર્મેશનમાં સમાન આઉટગોઇંગ નંબર હશે. જો તમે TCP થી પરિચિત છો અને વિચાર્યું છે કે આ કોઈક રીતે જંગલી લાગે છે, પરંતુ તે ખૂબ જંગલી નથી લાગતું, કારણ કે TCP માં seq_no બદલાતું નથી, પરંતુ પુષ્ટિ થાય છે seq_no બીજી બાજુ, હું તમને નારાજ કરવા ઉતાવળ કરીશ. MTProto માં પુષ્ટિકરણો આપવામાં આવે છે ના પર seq_no, જેમ TCP માં, પરંતુ દ્વારા msg_id !

આ શું છે msg_id, આ ક્ષેત્રોમાં સૌથી મહત્વપૂર્ણ? એક અનન્ય સંદેશ ઓળખકર્તા, જેમ કે નામ સૂચવે છે. તેને 64-બીટ નંબર તરીકે વ્યાખ્યાયિત કરવામાં આવે છે, જેમાંથી સૌથી નીચા બિટ્સમાં ફરીથી "સર્વર-નોટ-સર્વર" જાદુ હોય છે, અને બાકીનો યુનિક્સ ટાઇમસ્ટેમ્પ છે, જેમાં અપૂર્ણાંક ભાગનો સમાવેશ થાય છે, 32 બિટ્સ ડાબી તરફ ખસેડવામાં આવે છે. તે. ટાઈમસ્ટેમ્પ પ્રતિ સે (અને સમય સાથેના સંદેશાઓ કે જે ખૂબ જ અલગ હોય સર્વર દ્વારા નકારવામાં આવશે). આમાંથી તે તારણ આપે છે કે સામાન્ય રીતે આ એક ઓળખકર્તા છે જે ક્લાયંટ માટે વૈશ્વિક છે. આપેલ છે - ચાલો યાદ કરીએ session_id - અમને ખાતરી છે: કોઈ પણ સંજોગોમાં એક સત્ર માટેનો સંદેશ બીજા સત્રમાં મોકલી શકાતો નથી. એટલે કે, તે તારણ આપે છે કે ત્યાં પહેલેથી જ છે ત્રણ સ્તર - સત્ર, સત્ર નંબર, સંદેશ આઈડી. શા માટે આવી ગૂંચવણો, આ રહસ્ય ખૂબ જ મહાન છે.

અને તેથી, msg_id માટે જરૂરી...

RPC: વિનંતીઓ, જવાબો, ભૂલો. પુષ્ટિકરણો.

જેમ તમે નોંધ્યું હશે, ડાયાગ્રામમાં ક્યાંય પણ કોઈ વિશેષ "RPC વિનંતી કરો" પ્રકાર અથવા કાર્ય નથી, જો કે જવાબો છે. છેવટે, અમારી પાસે સામગ્રી-સંબંધિત સંદેશાઓ છે! તે જ, કોઈપણ સંદેશ વિનંતી હોઈ શકે છે! અથવા ન હોવું જોઈએ. અંતમાં, દરેક છે msg_id. પરંતુ ત્યાં જવાબો છે:

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

આ તે છે જ્યાં તે સૂચવવામાં આવે છે કે આ કયા સંદેશનો પ્રતિસાદ છે. તેથી, API ના ટોચના સ્તરે, તમારે યાદ રાખવું પડશે કે તમારી વિનંતીનો નંબર શું હતો - મને લાગે છે કે કાર્ય અસુમેળ છે તે સમજાવવાની જરૂર નથી, અને તે જ સમયે ઘણી વિનંતીઓ પ્રગતિમાં હોઈ શકે છે, જેના જવાબો કોઈપણ ક્રમમાં પરત કરી શકાય છે? સૈદ્ધાંતિક રીતે, આ અને કોઈ કામદારો જેવા ભૂલ સંદેશાઓમાંથી, આની પાછળનું આર્કિટેક્ચર શોધી શકાય છે: સર્વર કે જે તમારી સાથે TCP કનેક્શન જાળવી રાખે છે તે ફ્રન્ટ-એન્ડ બેલેન્સર છે, તે વિનંતીઓને બેકએન્ડ્સ પર ફોરવર્ડ કરે છે અને તેના દ્વારા પાછા એકત્રિત કરે છે. message_id. એવું લાગે છે કે અહીં બધું સ્પષ્ટ, તાર્કિક અને સારું છે.

હા?.. અને જો તમે તેના વિશે વિચારો છો? છેવટે, RPC પ્રતિસાદમાં પણ એક ક્ષેત્ર છે msg_id! શું આપણે સર્વર પર ચીસો પાડવાની જરૂર છે "તમે મારા જવાબનો જવાબ આપતા નથી!"? અને હા, પુષ્ટિ વિશે શું હતું? પૃષ્ઠ વિશે સંદેશાઓ વિશે સંદેશાઓ અમને કહે છે કે શું છે

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

અને તે દરેક બાજુએ થવું જોઈએ. પરંતુ હંમેશા નહીં! જો તમને RpcResult પ્રાપ્ત થાય છે, તો તે પોતે જ પુષ્ટિ તરીકે કામ કરે છે. એટલે કે, સર્વર તમારી વિનંતીનો MsgsAck સાથે પ્રતિસાદ આપી શકે છે - જેમ કે, “મને તે પ્રાપ્ત થયું છે.” RpcResult તરત જ જવાબ આપી શકે છે. તે બંને હોઈ શકે છે.

અને હા, જવાબ તો તારે જ આપવાનો છે! પુષ્ટિકરણ. નહિંતર, સર્વર તેને અવિતરિત ગણશે અને તે તમને ફરીથી મોકલશે. પુનઃજોડાણ પછી પણ. પરંતુ અહીં, અલબત્ત, સમયસમાપ્તિનો મુદ્દો ઉભો થાય છે. ચાલો તેમને થોડી વાર પછી જોઈએ.

આ દરમિયાન, ચાલો સંભવિત ક્વેરી એક્ઝેક્યુશન ભૂલો જોઈએ.

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

ઓહ, કોઈ ઉદ્ગાર કરશે, અહીં વધુ માનવીય ફોર્મેટ છે - ત્યાં એક રેખા છે! તમારો સમય લો. અહીં ભૂલોની યાદી, પરંતુ અલબત્ત પૂર્ણ નથી. તેમાંથી આપણે શીખીએ છીએ કે કોડ છે જેવું કંઈક HTTP ભૂલો (સારું, અલબત્ત, પ્રતિસાદોના અર્થશાસ્ત્રને માન આપવામાં આવતું નથી, કેટલીક જગ્યાએ તે કોડ્સ વચ્ચે અવ્યવસ્થિત રીતે વિતરિત કરવામાં આવે છે), અને લાઇન આના જેવી લાગે છે CAPITAL_LETTERS_AND_NUMBERS. ઉદાહરણ તરીકે, PHONE_NUMBER_OCCUPIED અથવા FILE_PART_Х_MISSING. સારું, એટલે કે, તમારે હજી પણ આ લાઇનની જરૂર પડશે વિશ્લેષણ. ઉદાહરણ તરીકે FLOOD_WAIT_3600 અર્થ થશે કે તમારે એક કલાક રાહ જોવી પડશે, અને PHONE_MIGRATE_5, કે આ ઉપસર્ગ સાથેનો ટેલિફોન નંબર 5મી ડીસીમાં નોંધાયેલ હોવો આવશ્યક છે. આપણી પાસે એક પ્રકારની ભાષા છે ને? અમને સ્ટ્રિંગમાંથી દલીલની જરૂર નથી, નિયમિત લોકો કરશે, ઠીક છે.

ફરીથી, આ સેવા સંદેશા પૃષ્ઠ પર નથી, પરંતુ, આ પ્રોજેક્ટ સાથે પહેલાથી જ સામાન્ય છે તેમ, માહિતી શોધી શકાય છે અન્ય દસ્તાવેજીકરણ પૃષ્ઠ પર. અથવા શંકા વ્યક્ત કરો. પ્રથમ, જુઓ, ટાઇપિંગ/સ્તરનું ઉલ્લંઘન - RpcError માં નેસ્ટ કરી શકાય છે RpcResult. બહાર કેમ નહીં? અમે શું ધ્યાનમાં ન લીધું?.. તે મુજબ, તેની ગેરંટી ક્યાં છે RpcError માં એમ્બેડ ન થઈ શકે RpcResult, પરંતુ સીધા અથવા અન્ય પ્રકારમાં નેસ્ટેડ બનો?.. અને જો તે ન કરી શકે, તો તે શા માટે ટોચના સ્તરે નથી, એટલે કે. તે ખૂટે છે req_msg_id ? ..

પરંતુ ચાલો સેવા સંદેશાઓ વિશે ચાલુ રાખીએ. ક્લાયંટ વિચારી શકે છે કે સર્વર લાંબા સમયથી વિચારી રહ્યું છે અને આ અદ્ભુત વિનંતી કરે છે:

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

આ પ્રશ્નના ત્રણ સંભવિત જવાબો છે, જે ફરીથી પુષ્ટિકરણ પદ્ધતિ સાથે છેદે છે; તેઓ શું હોવા જોઈએ તે સમજવાનો પ્રયાસ કરી રહ્યા છીએ (અને કયા પ્રકારોની સામાન્ય સૂચિ કે જેને પુષ્ટિની જરૂર નથી) હોમવર્ક તરીકે રીડર પર છોડી દેવામાં આવે છે (નોંધ: માહિતી ટેલિગ્રામ ડેસ્કટોપ સોર્સ કોડ પૂર્ણ નથી).

ડ્રગ વ્યસન: સંદેશ સ્થિતિઓ

સામાન્ય રીતે, TL, MTProto અને Telegram માં ઘણી જગ્યાઓ સામાન્ય રીતે જીદની લાગણી છોડી દે છે, પરંતુ નમ્રતા, કુનેહ અને અન્ય વ્યવહાર આવડત અમે નમ્રતાપૂર્વક તેના વિશે મૌન રાખ્યું, અને સંવાદોમાં અશ્લીલતાને સેન્સર કરી. જો કે, આ સ્થળОમોટાભાગના પૃષ્ઠ વિશે છે સંદેશાઓ વિશે સંદેશાઓ તે મારા માટે પણ આઘાતજનક છે, જે લાંબા સમયથી નેટવર્ક પ્રોટોકોલ સાથે કામ કરી રહ્યો છે અને તેણે વિવિધ પ્રકારની કુટિલતાની સાયકલ જોઈ છે.

તે નિર્દોષ રીતે, પુષ્ટિકરણ સાથે શરૂ થાય છે. આગળ તેઓ અમને વિશે કહે છે

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

ઠીક છે, MTProto સાથે કામ કરવાનું શરૂ કરનાર દરેક વ્યક્તિએ તેમની સાથે વ્યવહાર કરવો પડશે; "સુધારેલ - પુનઃસંકલિત - લોન્ચ" ચક્રમાં, સંપાદન દરમિયાન ખરાબ થવામાં વ્યવસ્થાપિત થયેલ નંબર ભૂલો અથવા મીઠું મેળવવું એ એક સામાન્ય બાબત છે. જો કે, અહીં બે મુદ્દા છે:

1. મતલબ કે મૂળ સંદેશ ખોવાઈ ગયો છે. અમારે કેટલીક કતાર બનાવવાની જરૂર છે, અમે તેને પછીથી જોઈશું.
2. આ વિચિત્ર ભૂલ નંબરો શું છે? 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 64... અન્ય નંબરો ક્યાં છે, ટોમી?

દસ્તાવેજીકરણ જણાવે છે:

હેતુ એ છે કે error_code મૂલ્યો જૂથબદ્ધ છે (error_code >> 4): ઉદાહરણ તરીકે, કોડ 0x40 — 0x4f કન્ટેનર વિઘટનમાં ભૂલોને અનુરૂપ છે.

પરંતુ, પ્રથમ, બીજી દિશામાં શિફ્ટ, અને બીજું, તે કોઈ વાંધો નથી, અન્ય કોડ ક્યાં છે? લેખકના માથામાં?.. જો કે, આ નજીવી બાબતો છે.

સંદેશની સ્થિતિઓ અને સંદેશની નકલો વિશેના સંદેશાઓમાં વ્યસનની શરૂઆત થાય છે:

• સંદેશ સ્થિતિ માહિતી માટે વિનંતી
  જો કોઈપણ પક્ષે તેના આઉટગોઇંગ સંદેશાઓની સ્થિતિ અંગે થોડા સમય માટે માહિતી પ્રાપ્ત કરી ન હોય, તો તે અન્ય પક્ષ પાસેથી સ્પષ્ટપણે વિનંતી કરી શકે છે:
  msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;
• સંદેશાઓની સ્થિતિ સંબંધિત માહિતીપ્રદ સંદેશ
  msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;
  અહીં, info એ એક સ્ટ્રિંગ છે જેમાં આવનારા msg_ids સૂચિમાંથી દરેક સંદેશ માટે સંદેશની સ્થિતિની બરાબર એક બાઇટ શામેલ છે:
  • 1 = સંદેશ વિશે કશું જ જાણીતું નથી (msg_id ખૂબ ઓછી છે, અન્ય પક્ષ કદાચ તેને ભૂલી ગયો હશે)
  • 2 = સંદેશ પ્રાપ્ત થયો નથી (msg_id સંગ્રહિત ઓળખકર્તાઓની શ્રેણીમાં આવે છે; જો કે, અન્ય પક્ષને ચોક્કસપણે આવો સંદેશ મળ્યો નથી)
  • 3 = સંદેશ પ્રાપ્ત થયો નથી (msg_id ખૂબ વધારે છે; જો કે, અન્ય પક્ષને ચોક્કસપણે તે હજી સુધી પ્રાપ્ત થયો નથી)
  • 4 = સંદેશ પ્રાપ્ત થયો (નોંધ કરો કે આ પ્રતિભાવ તે જ સમયે એક રસીદ સ્વીકૃતિ પણ છે)
  • +8 = સંદેશ પહેલેથી જ સ્વીકૃત છે
  • +16 = સંદેશને સ્વીકૃતિની જરૂર નથી
  • +32 = સંદેશમાં સમાવિષ્ટ RPC ક્વેરી પ્રક્રિયા થઈ રહી છે અથવા પ્રક્રિયા પહેલાથી જ પૂર્ણ છે
  • +64 = સંદેશ માટે સામગ્રી-સંબંધિત પ્રતિસાદ પહેલેથી જ જનરેટ કરેલ છે
  • +128 = અન્ય પક્ષ એ હકીકત માટે જાણે છે કે સંદેશ પહેલેથી જ પ્રાપ્ત થયો છે
    આ પ્રતિભાવને સ્વીકૃતિની જરૂર નથી. તે સંબંધિત msgs_state_req ની સ્વીકૃતિ છે.
    નોંધ કરો કે જો તે અચાનક બહાર આવે છે કે અન્ય પક્ષ પાસે કોઈ સંદેશ નથી જે તેને મોકલવામાં આવ્યો હોય તેવું લાગે છે, તો સંદેશ ફક્ત ફરીથી મોકલી શકાય છે. જો અન્ય પક્ષને એક જ સમયે સંદેશની બે નકલો પ્રાપ્ત થવી જોઈએ, તો પણ ડુપ્લિકેટને અવગણવામાં આવશે. (જો ઘણો સમય પસાર થઈ ગયો હોય, અને મૂળ msg_id હવે માન્ય નથી, તો સંદેશને msg_copy માં લપેટવો જોઈએ).
• સંદેશાઓની સ્થિતિનો સ્વૈચ્છિક સંચાર
  કોઈપણ પક્ષ સ્વેચ્છાએ અન્ય પક્ષ દ્વારા પ્રસારિત સંદેશાઓની સ્થિતિ વિશે અન્ય પક્ષને જાણ કરી શકે છે.
  msgs_all_info#8cc0d131 msg_ids:Vector long info:string = MsgsAllInfo
• એક સંદેશની સ્થિતિનો વિસ્તૃત સ્વૈચ્છિક સંચાર
  ...
  msg_detailed_info#276d3ec6 msg_id:long answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
msg_new_detailed_info#809db6df answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
• સંદેશાઓ ફરીથી મોકલવા માટે સ્પષ્ટ વિનંતી
  msg_resend_req#7d861a08 msg_ids:Vector long = MsgResendReq;
  રિમોટ પાર્ટી વિનંતી કરેલ સંદેશાઓને ફરીથી મોકલીને તરત જ જવાબ આપે છે […]
• જવાબો ફરીથી મોકલવા માટે સ્પષ્ટ વિનંતી
  msg_resend_ans_req#8610baeb msg_ids:Vector long = MsgResendReq;
  રિમોટ પાર્ટી તરત જ ફરીથી મોકલીને જવાબ આપે છે જવાબો વિનંતી કરેલા સંદેશાઓને […]
• સંદેશ નકલો
  કેટલીક પરિસ્થિતિઓમાં, msg_id સાથેનો જૂનો સંદેશ જે હવે માન્ય નથી તેને ફરીથી મોકલવાની જરૂર છે. પછી, તે નકલ કન્ટેનરમાં આવરિત છે:
  msg_copy#e06046b2 orig_message:Message = MessageCopy;
  એકવાર પ્રાપ્ત થયા પછી, સંદેશ પર પ્રક્રિયા કરવામાં આવે છે જાણે કે રેપર ત્યાં ન હોય. જો કે, જો તે ચોક્કસ માટે જાણીતું હોય કે orig_message.msg_id સંદેશ પ્રાપ્ત થયો હતો, તો નવા સંદેશ પર પ્રક્રિયા કરવામાં આવતી નથી (જ્યારે તે જ સમયે, તે અને orig_message.msg_id સ્વીકારવામાં આવે છે). orig_message.msg_id નું મૂલ્ય કન્ટેનરના msg_id કરતાં ઓછું હોવું જોઈએ.

ચાલો શું વિશે મૌન પણ રાખીએ msgs_state_info ફરીથી અપૂર્ણ TL ના કાન ચોંટી રહ્યા છે (અમને બાઈટના વેક્ટરની જરૂર હતી, અને નીચેના બે બિટ્સમાં એક એનમ હતું, અને ઉપરના બે બિટ્સમાં ફ્લેગ હતા). વાત જુદી છે. કોઈ સમજે છે કે આ બધું વ્યવહારમાં કેમ છે? વાસ્તવિક ગ્રાહકમાં જરૂરી છે?.. મુશ્કેલી સાથે, પરંતુ જો કોઈ વ્યક્તિ ડિબગીંગમાં રોકાયેલ હોય, અને ઇન્ટરેક્ટિવ મોડમાં હોય તો કોઈ લાભની કલ્પના કરી શકે છે - સર્વરને પૂછો કે શું અને કેવી રીતે. પરંતુ અહીં વિનંતીઓ વર્ણવેલ છે રાઉન્ડ ટ્રીપ.

તે અનુસરે છે કે દરેક પક્ષે માત્ર એન્ક્રિપ્ટ અને સંદેશા મોકલવા જ જોઈએ નહીં, પરંતુ અજ્ઞાત સમય માટે તેમના વિશે, તેમના જવાબો વિશેનો ડેટા પણ સંગ્રહિત કરવો જોઈએ. દસ્તાવેજીકરણ આ સુવિધાઓના સમય અથવા વ્યવહારિક લાગુ પાડવાનું વર્ણન કરતું નથી. કોઈ રીતે. સૌથી અદ્ભુત બાબત એ છે કે તેઓ ખરેખર સત્તાવાર ગ્રાહકોના કોડમાં ઉપયોગમાં લેવાય છે! દેખીતી રીતે તેઓને કંઈક કહેવામાં આવ્યું હતું જે જાહેર દસ્તાવેજીકરણમાં સમાવેલ નથી. કોડ પરથી સમજો શા માટે, હવે TL ના કિસ્સામાં જેટલું સરળ નથી - તે (પ્રમાણમાં) તાર્કિક રીતે અલગ ભાગ નથી, પરંતુ એપ્લિકેશન આર્કિટેક્ચર સાથે જોડાયેલ એક ભાગ છે, એટલે કે. એપ્લિકેશન કોડ સમજવા માટે નોંધપાત્ર રીતે વધુ સમયની જરૂર પડશે.

પિંગ્સ અને સમય. કતારો.

દરેક વસ્તુમાંથી, જો આપણે સર્વર આર્કિટેક્ચર (બેકએન્ડમાં વિનંતીઓનું વિતરણ) વિશેના અનુમાનોને યાદ રાખીએ, તો તેના બદલે એક દુઃખદ બાબત અનુસરે છે - TCP માં તમામ ડિલિવરી ગેરંટી હોવા છતાં (કાં તો ડેટા વિતરિત કરવામાં આવે છે, અથવા તમને વિરામ વિશે જાણ કરવામાં આવશે, પરંતુ જ્યાં સુધી સમસ્યા ન આવે ત્યાં સુધી ડેટા વિતરિત કરવામાં આવશે), તે પુષ્ટિ એમટીપ્રોટોમાં જ - કોઈ ગેરંટી નથી. સર્વર તમારો સંદેશ સરળતાથી ગુમાવી શકે છે અથવા ફેંકી શકે છે, અને તેના વિશે કંઈ કરી શકાતું નથી, ફક્ત વિવિધ પ્રકારની ક્રૉચનો ઉપયોગ કરો.

અને સૌ પ્રથમ - સંદેશ કતાર. ઠીક છે, એક વસ્તુ સાથે બધું શરૂઆતથી જ સ્પષ્ટ હતું - એક અપ્રમાણિત સંદેશ સંગ્રહિત અને ગુસ્સો હોવો જોઈએ. અને કેટલા સમય પછી? અને જેસ્ટર તેને ઓળખે છે. કદાચ તે વ્યસની સેવા સંદેશાઓ કોઈક રીતે આ સમસ્યાને ક્રૉચ વડે હલ કરે છે, કહો કે, ટેલિગ્રામ ડેસ્કટોપમાં તેમને અનુરૂપ લગભગ 4 કતાર છે (કદાચ વધુ, પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, આ માટે તમારે તેના કોડ અને આર્કિટેક્ચરને વધુ ગંભીરતાથી શોધવાની જરૂર છે; તે જ સમયે સમય, અમે જાણીએ છીએ કે તે નમૂના તરીકે લઈ શકાતું નથી; MTProto યોજનામાંથી ચોક્કસ સંખ્યામાં પ્રકારોનો તેમાં ઉપયોગ થતો નથી).

આવું કેમ થઈ રહ્યું છે? સંભવતઃ, સર્વર પ્રોગ્રામરો ક્લસ્ટરની અંદર વિશ્વસનીયતાની ખાતરી કરવામાં અસમર્થ હતા, અથવા આગળના બેલેન્સર પર બફરિંગ પણ કરી શક્યા ન હતા, અને આ સમસ્યા ક્લાયંટને સ્થાનાંતરિત કરી હતી. નિરાશામાંથી, વેસિલીએ TCP ના એલ્ગોરિધમનો ઉપયોગ કરીને, ફક્ત બે કતાર સાથે વૈકલ્પિક વિકલ્પ અમલમાં મૂકવાનો પ્રયાસ કર્યો - સર્વર પર RTT માપવા અને પુષ્ટિ વિનાની વિનંતીઓની સંખ્યાના આધારે "વિંડો" (સંદેશાઓમાં) નું કદ સમાયોજિત કરવું. એટલે કે, સર્વરના લોડનું મૂલ્યાંકન કરવા માટે આટલું રફ હ્યુરિસ્ટિક એ છે કે અમારી કેટલી વિનંતીઓ તે એક જ સમયે ચાવી શકે છે અને ગુમાવી શકતી નથી.

સારું, એટલે કે, તમે સમજો છો, બરાબર ને? જો તમારે TCP પર ચાલતા પ્રોટોકોલની ટોચ પર TCP ફરીથી અમલમાં મૂકવો હોય, તો આ ખૂબ જ ખરાબ રીતે ડિઝાઇન કરેલ પ્રોટોકોલ સૂચવે છે.

ઓહ હા, શા માટે તમને એક કરતાં વધુ કતારની જરૂર છે, અને કોઈપણ રીતે ઉચ્ચ-સ્તરની API સાથે કામ કરતી વ્યક્તિ માટે આનો અર્થ શું છે? જુઓ, તમે વિનંતી કરો છો, તેને શ્રેણીબદ્ધ કરો છો, પરંતુ ઘણી વાર તમે તેને તરત મોકલી શકતા નથી. શા માટે? કારણ કે જવાબ હશે msg_id, જે કામચલાઉ છેаહું એક લેબલ છું, જેનું અસાઇનમેન્ટ શક્ય તેટલા મોડે સુધી મોકૂફ રાખવામાં આવે છે - જો સર્વર અમારી અને તેની વચ્ચેના સમયની મેળ ખાતી ન હોવાને કારણે તેને નકારે છે (અલબત્ત, અમે વર્તમાનમાંથી અમારો સમય બદલી નાખે તેવી ક્રૉચ બનાવી શકીએ છીએ. સર્વરના પ્રતિસાદોમાંથી ગણતરી કરેલ ડેલ્ટા ઉમેરીને સર્વરમાં - સત્તાવાર ક્લાયન્ટ આ કરે છે, પરંતુ તે બફરિંગને કારણે અશુદ્ધ અને અચોક્કસ છે). તેથી, જ્યારે તમે લાઇબ્રેરીમાંથી સ્થાનિક ફંક્શન કૉલ સાથે વિનંતી કરો છો, ત્યારે સંદેશ નીચેના તબક્કાઓમાંથી પસાર થાય છે:

1. તે એક કતારમાં આવેલું છે અને એન્ક્રિપ્શનની રાહ જુએ છે.
2. નિયુક્ત msg_id અને સંદેશ બીજી કતારમાં ગયો - શક્ય ફોરવર્ડિંગ; સોકેટ પર મોકલો.
3. a) સર્વરે MsgsAck નો જવાબ આપ્યો - સંદેશ વિતરિત કરવામાં આવ્યો હતો, અમે તેને "અન્ય કતાર"માંથી કાઢી નાખીએ છીએ.
   b) અથવા તેનાથી વિપરિત, તેને કંઈક ગમ્યું ન હતું, તેણે ખરાબ એમએસજીનો જવાબ આપ્યો - "બીજી કતાર"માંથી ફરીથી મોકલો
   c) કંઈ જાણી શકાયું નથી, સંદેશને બીજી કતારમાંથી મોકલવાની જરૂર છે - પરંતુ તે બરાબર ક્યારે ખબર નથી.
4. સર્વરે આખરે જવાબ આપ્યો RpcResult - વાસ્તવિક પ્રતિભાવ (અથવા ભૂલ) - માત્ર વિતરિત જ નહીં, પણ પ્રક્રિયા પણ.

કદાચ, કન્ટેનરનો ઉપયોગ આંશિક રીતે સમસ્યા હલ કરી શકે છે. આ ત્યારે થાય છે જ્યારે સંદેશાઓનો સમૂહ એકમાં પેક કરવામાં આવે છે, અને સર્વરે તે બધાને એક સાથે, એકમાં પુષ્ટિ સાથે પ્રતિસાદ આપ્યો હતો. msg_id. પરંતુ તે આ પેકને પણ નકારશે, જો કંઈક ખોટું થયું હોય, તો તે સંપૂર્ણ રીતે.

અને આ બિંદુએ બિન-તકનીકી વિચારણાઓ અમલમાં આવે છે. અનુભવથી, અમે ઘણા ક્રૉચ જોયા છે, અને વધુમાં, અમે હવે ખરાબ સલાહ અને આર્કિટેક્ચરના વધુ ઉદાહરણો જોશું - આવી પરિસ્થિતિઓમાં, શું વિશ્વાસ કરવો અને આવા નિર્ણયો લેવા યોગ્ય છે? પ્રશ્ન રેટરિકલ છે (અલબત્ત નહીં).

આપણે શું વાત કરી રહ્યા છીએ? જો "સંદેશાઓ વિશે ડ્રગ સંદેશાઓ" વિષય પર તમે હજી પણ "તમે મૂર્ખ છો, તમે અમારી તેજસ્વી યોજના સમજી શક્યા નથી!" જેવા વાંધાઓ સાથે અનુમાન કરી શકો છો. (તેથી પહેલા દસ્તાવેજો લખો, જેમ કે સામાન્ય લોકોએ, તર્ક અને પેકેટ એક્સચેન્જના ઉદાહરણો સાથે, પછી આપણે વાત કરીશું), પછી સમય/સમયસમાપ્તિ એ એકદમ વ્યવહારુ અને ચોક્કસ પ્રશ્ન છે, અહીં બધું લાંબા સમયથી જાણીતું છે. દસ્તાવેજીકરણ અમને સમયસમાપ્તિ વિશે શું કહે છે?

સર્વર સામાન્ય રીતે RPC પ્રતિસાદનો ઉપયોગ કરીને ક્લાયન્ટ (સામાન્ય રીતે, RPC ક્વેરી) તરફથી સંદેશની પ્રાપ્તિને સ્વીકારે છે. જો પ્રતિસાદ આવવામાં લાંબો સમય હોય, તો સર્વર પહેલા રસીદની સ્વીકૃતિ મોકલી શકે છે, અને થોડા અંશે પછી, RPC પ્રતિસાદ પોતે જ.

ક્લાયન્ટ સામાન્ય રીતે સર્વર (સામાન્ય રીતે, RPC પ્રતિસાદ) તરફથી સંદેશની પ્રાપ્તિ સ્વીકારે છે જો તે ખૂબ મોડું ટ્રાન્સમિટ ન થયું હોય તો આગલી RPC ક્વેરી પર એક સ્વીકૃતિ ઉમેરીને (જો તે જનરેટ કરવામાં આવે તો, કહો, રસીદ પછી 60-120 સેકન્ડમાં). સર્વર તરફથી સંદેશ). જો કે, જો લાંબા સમય સુધી સર્વર પર સંદેશા મોકલવાનું કોઈ કારણ ન હોય અથવા સર્વર તરફથી મોટી સંખ્યામાં અસ્વીકાર્ય સંદેશાઓ હોય (કહો કે, 16 થી વધુ), તો ક્લાયંટ એકલા સ્વીકૃતિ પ્રસારિત કરે છે.

... હું ભાષાંતર કરું છું: આપણે પોતે જાણતા નથી કે આપણને તેની કેટલી અને કેવી રીતે જરૂર છે, તેથી ચાલો માની લઈએ કે તેને આના જેવું રહેવા દો.

અને પિંગ્સ વિશે:

પિંગ સંદેશાઓ (PING/PONG)

ping#7abe77ec ping_id:long = Pong;

પ્રતિસાદ સામાન્ય રીતે સમાન કનેક્શન પર પાછો આવે છે:

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

આ સંદેશાઓને સ્વીકૃતિઓની જરૂર નથી. પૉંગ માત્ર પિંગના પ્રતિભાવમાં પ્રસારિત થાય છે જ્યારે પિંગ બંને બાજુથી શરૂ કરી શકાય છે.

વિલંબિત કનેક્શન બંધ + PING

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

પિંગ જેવું કામ કરે છે. વધુમાં, આ પ્રાપ્ત થયા પછી, સર્વર એક ટાઈમર શરૂ કરે છે જે વર્તમાન કનેક્શન ડિસ્કનેક્ટ_ડેલે સેકન્ડ પછી બંધ કરશે સિવાય કે તે સમાન પ્રકારનો નવો સંદેશ પ્રાપ્ત કરે જે અગાઉના તમામ ટાઈમરને આપમેળે રીસેટ કરે છે. જો ક્લાયંટ દર 60 સેકન્ડમાં એકવાર આ પિંગ્સ મોકલે છે, ઉદાહરણ તરીકે, તે 75 સેકન્ડની બરાબર ડિસ્કનેક્ટ_ડેલે સેટ કરી શકે છે.

શું તમે પાગલ છો?! 60 સેકન્ડમાં, ટ્રેન સ્ટેશનમાં પ્રવેશ કરશે, ઉતરશે અને મુસાફરોને ઉપાડશે, અને ફરીથી ટનલમાં સંપર્ક ગુમાવશે. 120 સેકન્ડમાં, જ્યારે તમે તેને સાંભળો છો, ત્યારે તે બીજા એક પર પહોંચશે અને મોટાભાગે કનેક્શન તૂટી જશે. ઠીક છે, તે સ્પષ્ટ છે કે પગ ક્યાંથી આવે છે - "મેં એક રિંગિંગ સાંભળ્યું, પરંતુ તે ક્યાં છે તે ખબર નથી", ત્યાં નાગલનું અલ્ગોરિધમ અને TCP_NODELAY વિકલ્પ છે, જે ઇન્ટરેક્ટિવ કાર્ય માટે બનાવાયેલ છે. પરંતુ, માફ કરશો, તેની ડિફોલ્ટ મૂલ્ય - 200 ને પકડી રાખો મિલીસેકન્ડ જો તમે ખરેખર કંઈક આવું જ ચિત્રિત કરવા અને સંભવિત બે પેકેટો પર સાચવવા માંગતા હો, તો તેને 5 સેકન્ડ માટે બંધ કરી દો, અથવા "વપરાશકર્તા ટાઈપ કરી રહ્યો છે..." સંદેશનો સમય સમાપ્ત થઈ ગયો છે. પરંતુ વધુ નહીં.

અને છેલ્લે, પિંગ્સ. એટલે કે, TCP કનેક્શનની જીવંતતા તપાસી રહ્યું છે. તે રમુજી છે, પરંતુ લગભગ 10 વર્ષ પહેલાં મેં અમારા ફેકલ્ટીના ડોર્મના મેસેન્જર વિશે એક જટિલ લખાણ લખ્યું હતું - ત્યાંના લેખકોએ ક્લાયંટમાંથી સર્વરને પિંગ પણ કર્યું હતું, અને ઊલટું નહીં. પરંતુ ત્રીજા વર્ષના વિદ્યાર્થીઓ એક વસ્તુ છે, અને આંતરરાષ્ટ્રીય ઓફિસ બીજી વસ્તુ છે, બરાબર?

પ્રથમ, થોડો શૈક્ષણિક કાર્યક્રમ. TCP કનેક્શન, પેકેટ એક્સચેન્જની ગેરહાજરીમાં, અઠવાડિયા સુધી જીવી શકે છે. હેતુ પર આધાર રાખીને આ સારું અને ખરાબ બંને છે. જો તમારી પાસે સર્વર પર SSH કનેક્શન ખુલ્લું હોય તો સારું છે, તમે કમ્પ્યુટરમાંથી ઉભા થયા, રાઉટર રીબૂટ કર્યું, તમારા સ્થાને પાછા ફર્યા - આ સર્વર દ્વારા સત્ર ફાટ્યું ન હતું (તમે કંઈપણ ટાઇપ કર્યું ન હતું, ત્યાં કોઈ પેકેટ નહોતા) , તે અનુકૂળ છે. જો સર્વર પર હજારો ક્લાયંટ હોય તો તે ખરાબ છે, દરેક સંસાધનો લે છે (હેલો, પોસ્ટગ્રેસ!), અને ક્લાયંટના હોસ્ટ લાંબા સમય પહેલા રીબૂટ થઈ શકે છે - પરંતુ અમને તેના વિશે જાણ થશે નહીં.

ચેટ/IM સિસ્ટમો એક વધારાના કારણ માટે બીજા કેસમાં આવે છે - ઑનલાઇન સ્થિતિઓ. જો વપરાશકર્તા "પડ્યો", તો તમારે તેના ઇન્ટરલોક્યુટર્સને આ વિશે જાણ કરવાની જરૂર છે. નહિંતર, તમે એક ભૂલ સાથે સમાપ્ત થશો જે જબ્બરના નિર્માતાઓએ (અને 20 વર્ષથી સુધારેલ) - વપરાશકર્તાએ ડિસ્કનેક્ટ કર્યું છે, પરંતુ તેઓ તેને ઑનલાઇન છે એમ માનીને તેને સંદેશા લખવાનું ચાલુ રાખે છે (જે આમાં પણ સંપૂર્ણપણે ખોવાઈ ગયા હતા. ડિસ્કનેક્ટ શોધ્યું તેની થોડી મિનિટો પહેલાં). ના, TCP_KEEPALIVE વિકલ્પ, જે ઘણા લોકો સમજી શકતા નથી કે TCP ટાઈમર કેવી રીતે કામ કરે છે તે અવ્યવસ્થિત રીતે ફેંકી દે છે (દસ સેકન્ડ જેવા જંગલી મૂલ્યો સેટ કરીને), અહીં મદદ કરશે નહીં - તમારે ખાતરી કરવાની જરૂર છે કે માત્ર OS કર્નલ જ નહીં. વપરાશકર્તાનું મશીન જીવંત છે, પણ સામાન્ય રીતે કાર્ય કરે છે, પ્રતિસાદ આપવા સક્ષમ છે, અને એપ્લિકેશન પોતે (શું તમને લાગે છે કે તે સ્થિર થઈ શકતું નથી? ઉબુન્ટુ 18.04 પર ટેલિગ્રામ ડેસ્કટોપ મારા માટે એક કરતા વધુ વખત સ્થિર થઈ ગયું છે).

તેથી જ તમારે પિંગ કરવું પડશે સર્વર ક્લાયંટ, અને ઊલટું નહીં - જો ક્લાયંટ આ કરે છે, જો કનેક્શન તૂટી ગયું હોય, તો પિંગ વિતરિત કરવામાં આવશે નહીં, ધ્યેય પ્રાપ્ત થશે નહીં.

ટેલિગ્રામ પર આપણે શું જોઈએ છીએ? તે બરાબર વિરુદ્ધ છે! સારું, તે છે. ઔપચારિક રીતે, અલબત્ત, બંને પક્ષો એકબીજાને પિંગ કરી શકે છે. વ્યવહારમાં, ગ્રાહકો ક્રૉચનો ઉપયોગ કરે છે ping_delay_disconnect, જે સર્વર પર ટાઈમર સેટ કરે છે. ઠીક છે, માફ કરશો, તે ક્લાયંટ પર નિર્ભર નથી કે તે પિંગ વિના કેટલો સમય ત્યાં રહેવા માંગે છે. સર્વર, તેના લોડના આધારે, વધુ સારી રીતે જાણે છે. પરંતુ, અલબત્ત, જો તમને સંસાધનોનો વાંધો ન હોય, તો પછી તમે તમારા પોતાના દુષ્ટ પિનોચિઓ બનશો, અને એક ક્રૉચ કરશે ...

તે કેવી રીતે ડિઝાઇન કરવામાં આવ્યું હોવું જોઈએ?

હું માનું છું કે ઉપરોક્ત તથ્યો સ્પષ્ટપણે સૂચવે છે કે ટેલિગ્રામ/વીકોન્ટાક્ટે ટીમ કોમ્પ્યુટર નેટવર્કના પરિવહન (અને નીચલા) સ્તર અને સંબંધિત બાબતોમાં તેમની ઓછી લાયકાતના ક્ષેત્રમાં ખૂબ સક્ષમ નથી.

તે આટલું જટિલ કેમ બન્યું, અને ટેલિગ્રામ આર્કિટેક્ટ્સ કેવી રીતે વાંધો ઉઠાવવાનો પ્રયાસ કરી શકે? હકીકત એ છે કે તેઓએ એક સત્ર બનાવવાનો પ્રયાસ કર્યો જે TCP કનેક્શન વિરામથી બચી જાય, એટલે કે, જે હમણાં વિતરિત કરવામાં આવ્યું નથી, અમે પછીથી વિતરિત કરીશું. તેઓએ કદાચ UDP ટ્રાન્સપોર્ટ બનાવવાનો પણ પ્રયાસ કર્યો હતો, પરંતુ તેઓને મુશ્કેલીઓનો સામનો કરવો પડ્યો અને તેને છોડી દીધો (તેથી જ દસ્તાવેજો ખાલી છે - તેમાં બડાઈ મારવા જેવું કંઈ નથી). પરંતુ સામાન્ય રીતે નેટવર્ક્સ અને ખાસ કરીને TCP કેવી રીતે કાર્ય કરે છે, તમે તેના પર ક્યાં આધાર રાખી શકો છો અને તમારે તે જાતે કરવાની ક્યાં જરૂર છે (અને કેવી રીતે) તેની સમજના અભાવને કારણે અને આને સંકેતલિપી સાથે જોડવાનો પ્રયાસ “બે પક્ષીઓ સાથે. એક પથ્થર", આ પરિણામ છે.

તે કેવી રીતે જરૂરી હતું? તે હકીકતના આધારે msg_id રીપ્લે હુમલાઓને રોકવા માટે ક્રિપ્ટોગ્રાફિક દૃષ્ટિકોણથી જરૂરી ટાઇમસ્ટેમ્પ છે, તેની સાથે અનન્ય ઓળખકર્તા કાર્ય જોડવું એ ભૂલ છે. તેથી, વર્તમાન આર્કિટેક્ચરને મૂળભૂત રીતે બદલ્યા વિના (જ્યારે અપડેટ્સ સ્ટ્રીમ જનરેટ થાય છે, તે પોસ્ટ્સની આ શ્રેણીના બીજા ભાગ માટે ઉચ્ચ-સ્તરનો API વિષય છે), તમારે આની જરૂર પડશે:

1. ક્લાયન્ટ સાથે TCP કનેક્શન ધરાવતું સર્વર જવાબદારી લે છે - જો તેણે સોકેટમાંથી વાંચ્યું હોય, તો કૃપા કરીને સ્વીકારો, પ્રક્રિયા કરો અથવા ભૂલ પરત કરો, કોઈ નુકસાન નહીં. પછી પુષ્ટિકરણ એ id નું વેક્ટર નથી, પરંતુ ફક્ત "છેલ્લી પ્રાપ્ત થયેલ seq_no" - માત્ર એક સંખ્યા, જેમ કે TCP (બે નંબરો - તમારો seq અને પુષ્ટિ થયેલ એક). આપણે હંમેશા સત્રમાં જ હોઈએ છીએ, ખરું ને?
2. રિપ્લે હુમલાઓને રોકવા માટેનો ટાઇમસ્ટેમ્પ એક અલગ ક્ષેત્ર બની જાય છે, એક લા નોન્સ. તે ચકાસાયેલ છે, પરંતુ અન્ય કંઈપણ અસર કરતું નથી. પૂરતું અને uint32 - જો આપણું મીઠું ઓછામાં ઓછું દર અડધા દિવસમાં બદલાય છે, તો આપણે વર્તમાન સમયના પૂર્ણાંક ભાગના લો-ઓર્ડર બિટ્સને 16 બિટ્સ ફાળવી શકીએ છીએ, બાકીના - સેકન્ડના અપૂર્ણાંક ભાગમાં (હવેની જેમ).
3. દૂર msg_id બિલકુલ - બેકએન્ડ્સ પર વિનંતીઓને અલગ પાડવાના દૃષ્ટિકોણથી, ત્યાં, પ્રથમ, ક્લાયંટ આઈડી અને બીજું, સત્ર આઈડી, તેમને જોડે છે. તદનુસાર, વિનંતી ઓળખકર્તા તરીકે માત્ર એક જ વસ્તુ પૂરતી છે seq_no.

આ સૌથી સફળ વિકલ્પ પણ નથી; એક સંપૂર્ણ રેન્ડમ ઓળખકર્તા તરીકે સેવા આપી શકે છે - માર્ગ દ્વારા, સંદેશ મોકલતી વખતે આ ઉચ્ચ સ્તરીય API માં પહેલેથી જ કરવામાં આવે છે. આર્કિટેક્ચરને રિલેટિવથી એબ્સોલ્યુટમાં સંપૂર્ણપણે રીમેક કરવું વધુ સારું રહેશે, પરંતુ આ બીજા ભાગ માટેનો વિષય છે, આ પોસ્ટનો નહીં.

API?

તા-દામ! તેથી, પીડા અને ક્રેચેસથી ભરેલા માર્ગમાંથી સંઘર્ષ કર્યા પછી, અમે આખરે સર્વરને કોઈપણ વિનંતીઓ મોકલી શક્યા અને તેના કોઈપણ જવાબો પ્રાપ્ત કરી શક્યા, તેમજ સર્વર તરફથી અપડેટ્સ પ્રાપ્ત કરી શક્યા (વિનંતિના જવાબમાં નહીં, પરંતુ તે પોતે જ. અમને મોકલે છે, જેમ કે PUSH, જો કોઈ તે રીતે સ્પષ્ટ હોય તો).

ધ્યાન આપો, હવે લેખમાં પર્લનું એકમાત્ર ઉદાહરણ હશે! (જેઓ વાક્યરચનાથી પરિચિત નથી તેમના માટે, આશીર્વાદની પ્રથમ દલીલ એ ઑબ્જેક્ટનું ડેટા માળખું છે, બીજો તેનો વર્ગ છે):

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

હા, હેતુસર બગાડનાર નથી - જો તમે હજી સુધી તે વાંચ્યું નથી, તો આગળ વધો અને તે કરો!

ઓહ, વાઇ~~... આ શું દેખાય છે? કંઈક ખૂબ જ પરિચિત... કદાચ આ JSON માં લાક્ષણિક વેબ API નું ડેટા માળખું છે, સિવાય કે વર્ગો પણ ઑબ્જેક્ટ સાથે જોડાયેલા હોય?..

તો આ કેવી રીતે બહાર આવે છે... આ બધું શું છે, સાથીઓ?... આટલો પ્રયાસ - અને અમે વેબ પ્રોગ્રામરો જ્યાં આરામ કરવા માટે રોકાયા. માત્ર શરૂ?..શું HTTPS પર માત્ર JSON સરળ નહીં હોય?! બદલામાં અમને શું મળ્યું? શું પ્રયત્નો તે યોગ્ય હતા?

ચાલો મૂલ્યાંકન કરીએ કે TL+MTProtoએ આપણને શું આપ્યું અને કયા વિકલ્પો શક્ય છે. ઠીક છે, HTTP, જે વિનંતી-પ્રતિસાદ મોડેલ પર ધ્યાન કેન્દ્રિત કરે છે, તે ખરાબ ફિટ છે, પરંતુ ઓછામાં ઓછું TLS ની ટોચ પર કંઈક છે?

કોમ્પેક્ટ સીરીયલાઇઝેશન. JSON જેવું જ આ ડેટા સ્ટ્રક્ચર જોઈને, મને યાદ છે કે તેના બાઈનરી વર્ઝન છે. ચાલો MsgPack ને અપર્યાપ્ત રીતે એક્સ્ટેન્સિબલ તરીકે ચિહ્નિત કરીએ, પરંતુ ત્યાં છે, ઉદાહરણ તરીકે, CBOR - માર્ગ દ્વારા, માં વર્ણવેલ ધોરણ આરએફસી 7049. તે એ હકીકત માટે નોંધપાત્ર છે કે તે વ્યાખ્યાયિત કરે છે ટagsગ્સ, વિસ્તરણ પદ્ધતિ તરીકે, અને વચ્ચે પહેલેથી પ્રમાણિત ઉપલબ્ધ:

• 25 + 256 - લાઇન નંબરના સંદર્ભ સાથે પુનરાવર્તિત રેખાઓ બદલવી, આવી સસ્તી કમ્પ્રેશન પદ્ધતિ
• 26 - વર્ગના નામ અને કન્સ્ટ્રક્ટર દલીલો સાથે શ્રેણીબદ્ધ પર્લ ઑબ્જેક્ટ
• 27 - પ્રકારનું નામ અને કન્સ્ટ્રક્ટર દલીલો સાથે ક્રમાંકિત ભાષા-સ્વતંત્ર ઑબ્જેક્ટ

ઠીક છે, મેં સમાન ડેટાને TL અને CBOR માં સ્ટ્રિંગ અને ઑબ્જેક્ટ પેકિંગ સક્ષમ સાથે શ્રેણીબદ્ધ કરવાનો પ્રયાસ કર્યો. પરિણામ મેગાબાઈટથી ક્યાંક CBOR ની તરફેણમાં બદલાવા લાગ્યું:

cborlen=1039673 tl_len=1095092

અને તેથી, નિષ્કર્ષ: ત્યાં નોંધપાત્ર રીતે સરળ ફોર્મેટ્સ છે જે તુલનાત્મક કાર્યક્ષમતા સાથે, સિંક્રનાઇઝેશન નિષ્ફળતા અથવા અજાણ્યા ઓળખકર્તાની સમસ્યાને આધિન નથી.

ઝડપી જોડાણ સ્થાપના. આનો અર્થ એ છે કે પુનઃજોડાણ પછી શૂન્ય RTT (જ્યારે કી પહેલેથી જ એકવાર જનરેટ થઈ ગઈ હોય) - પહેલા જ MTProto સંદેશથી લાગુ, પરંતુ કેટલાક રિઝર્વેશન સાથે - સમાન મીઠું મારવું, સત્ર સડેલું નથી, વગેરે. તેના બદલે TLS અમને શું ઑફર કરે છે? વિષય પર અવતરણ:

TLS માં PFS નો ઉપયોગ કરતી વખતે, TLS સત્ર ટિકિટ (આરએફસી 5077) કીને ફરીથી વાટાઘાટો કર્યા વિના અને સર્વર પર કી માહિતી સંગ્રહિત કર્યા વિના એન્ક્રિપ્ટેડ સત્ર ફરી શરૂ કરવા માટે. પ્રથમ કનેક્શન ખોલતી વખતે અને કીઓ બનાવતી વખતે, સર્વર કનેક્શન સ્થિતિને એન્ક્રિપ્ટ કરે છે અને તેને ક્લાયંટને ટ્રાન્સમિટ કરે છે (સત્ર ટિકિટના સ્વરૂપમાં). તદનુસાર, જ્યારે કનેક્શન ફરી શરૂ થાય છે, ત્યારે ક્લાયંટ સત્ર કી સહિત, સત્રની ટિકિટ સર્વર પર પાછા મોકલે છે. ટિકિટ પોતે જ અસ્થાયી કી (સેશન ટિકિટ કી) વડે એન્ક્રિપ્ટેડ છે, જે સર્વર પર સંગ્રહિત છે અને ક્લસ્ટર્ડ સોલ્યુશન્સમાં SSL પર પ્રક્રિયા કરતા તમામ ફ્રન્ટએન્ડ સર્વર્સમાં વિતરિત થવી જોઈએ.[10] આમ, જો અસ્થાયી સર્વર કી સાથે ચેડા કરવામાં આવે તો સત્ર ટિકિટની રજૂઆત PFSનું ઉલ્લંઘન કરી શકે છે, ઉદાહરણ તરીકે, જ્યારે તેઓ લાંબા સમય સુધી સંગ્રહિત થાય છે (OpenSSL, nginx, Apache તેમને પ્રોગ્રામના સમગ્ર સમયગાળા માટે ડિફોલ્ટ રૂપે સંગ્રહિત કરે છે; લોકપ્રિય સાઇટ્સ ઉપયોગ કરે છે. કેટલાક કલાકો સુધીની ચાવી, દિવસો સુધી).

અહીં RTT શૂન્ય નથી, તમારે ઓછામાં ઓછા ClientHello અને ServerHelloની આપ-લે કરવાની જરૂર છે, જેના પછી ક્લાયન્ટ ફિનિશ્ડ સાથે ડેટા મોકલી શકે છે. પરંતુ અહીં આપણે યાદ રાખવું જોઈએ કે અમારી પાસે વેબ નથી, તેના નવા ખોલેલા કનેક્શનના સમૂહ સાથે, પરંતુ એક મેસેન્જર છે, જેનું કનેક્શન ઘણીવાર એક અને વધુ કે ઓછા લાંબા સમય સુધી ચાલતું હોય છે, વેબ પૃષ્ઠોની પ્રમાણમાં ટૂંકી વિનંતીઓ - બધું મલ્ટિપ્લેક્સ્ડ છે. આંતરિક રીતે એટલે કે, જો આપણે ખરેખર ખરાબ સબવે વિભાગમાં ન આવ્યા હોય તો તે તદ્દન સ્વીકાર્ય છે.

બીજું કંઈક ભૂલી ગયા છો? ટિપ્પણીઓમાં લખો.

ચાલુ રહી શકાય!

પોસ્ટ્સની આ શ્રેણીના બીજા ભાગમાં અમે તકનીકી નહીં, પરંતુ સંસ્થાકીય મુદ્દાઓ - અભિગમો, વિચારધારા, ઇન્ટરફેસ, વપરાશકર્તાઓ પ્રત્યેનું વલણ વગેરે પર વિચાર કરીશું. જો કે, અહીં પ્રસ્તુત કરાયેલી તકનીકી માહિતીના આધારે.

ત્રીજો ભાગ તકનીકી ઘટક/વિકાસ અનુભવનું વિશ્લેષણ કરવાનું ચાલુ રાખશે. તમે શીખી શકશો, ખાસ કરીને:

• TL પ્રકારોની વિવિધતા સાથે રોગચાળો ચાલુ રાખવો
• ચેનલો અને સુપરગ્રુપ્સ વિશે અજાણી વસ્તુઓ
• શા માટે સંવાદો રોસ્ટર કરતાં વધુ ખરાબ છે
• સંપૂર્ણ વિ સંબંધિત સંદેશ સંબોધન વિશે
• ફોટો અને ઈમેજ વચ્ચે શું તફાવત છે
• ઇમોજી ઇટાલિક ટેક્સ્ટમાં કેવી રીતે દખલ કરે છે

અને અન્ય crutches! જોડાયેલા રહો!

સોર્સ: www.habr.com