ბოლო დროს ჰაბრეზე უფრო ხშირად გამოჩნდა პოსტები იმის შესახებ, თუ რამდენად კარგია Telegram, რამდენად ბრწყინვალე და გამოცდილი არიან ძმები დუროვები ქსელური სისტემების მშენებლობაში და ა.შ. ამავდროულად, ძალიან ცოტა ადამიანი მართლაც ჩაეფლო ტექნიკურ მოწყობილობაში - მაქსიმუმ ისინი იყენებენ საკმაოდ მარტივ (და ძალიან განსხვავებულს MTProto-სგან) JSON-ზე დაფუძნებულ Bot API-ს და ჩვეულებრივ იღებენ რწმენაზე ყველა ის ქება და პიარი, რომელიც მესინჯერის გარშემო ტრიალებს. თითქმის წელიწადნახევრის წინ ჩემმა კოლეგამ NPO Echelon Vasily-ში (სამწუხაროდ, მისი ანგარიში Habré-ზე დრაფტთან ერთად წაიშალა) დაიწყო საკუთარი Telegram კლიენტის წერა ნულიდან პერლში, მოგვიანებით კი ამ სტრიქონების ავტორი შეუერთდა. რატომ Perl, ზოგიერთი მაშინვე იკითხება? იმის გამო, რომ უკვე არსებობს ასეთი პროექტები სხვა ენებზე, ფაქტობრივად, ეს არ არის მთავარი, შეიძლება იყოს ნებისმიერი სხვა ენა, სადაც დასრულებული ბიბლიოთეკა, და შესაბამისად ავტორმა ყველა გზა უნდა გაიაროს ნულიდან. უფრო მეტიც, კრიპტოგრაფია ასეთი რამ არის - ენდე, მაგრამ გადაამოწმე. უსაფრთხოებაზე ორიენტირებული პროდუქტით, თქვენ არ შეგიძლიათ დაეყრდნოთ მხოლოდ გამყიდველის მზა ბიბლიოთეკას და ბრმად დაიჯეროთ ეს (თუმცა, ეს არის მეორე ნაწილის მეტი თემა). ამ დროისთვის, ბიბლიოთეკა საკმაოდ კარგად მუშაობს "შუა" დონეზე (საშუალებას გაძლევთ განახორციელოთ ნებისმიერი API მოთხოვნა).

თუმცა, ამ პოსტების სერიაში ბევრი კრიპტოგრაფია და მათემატიკა არ იქნება. მაგრამ იქნება ბევრი სხვა ტექნიკური დეტალი და არქიტექტურული ხელჯოხები (ის ასევე გამოადგება მათ, ვინც ნულიდან არ დაწერს, მაგრამ ბიბლიოთეკას ნებისმიერ ენაზე გამოიყენებს). ასე რომ, მთავარი მიზანი იყო კლიენტის განხორციელების მცდელობა ნულიდან ოფიციალური დოკუმენტაციის მიხედვით. ანუ, დავუშვათ, რომ ოფიციალური კლიენტების წყაროს კოდი დახურულია (კიდევ ერთხელ, მეორე ნაწილში, ჩვენ უფრო დეტალურად გამოვავლენთ თემას, თუ რა არის ეს სინამდვილეში ხდება ასე რომ), მაგრამ, როგორც ძველ დღეებში, მაგალითად, არსებობს სტანდარტი, როგორიცაა RFC - შესაძლებელია თუ არა კლიენტის დაწერა მხოლოდ სპეციფიკაციის მიხედვით, წყაროს კოდის „დათვალიერების გარეშე“, თუნდაც ოფიციალური (Telegram Desktop, მობილური). ), თუნდაც არაოფიციალური ტელემარათონი?

დამყარება:

დოკუმენტაცია ... არის? Მართალია?..
საიდან იწყებ, როგორც ახალგაზრდა მწერალი?
ორობითი სერიალიზაცია: TL (Type Language) და მისი სქემა, ფენები და მრავალი სხვა საშინელი სიტყვა
MT პროტო
API?
Გაგრძელება იქნება!

დოკუმენტაცია ... არის? Მართალია?..

ამ სტატიისთვის შენიშვნების ფრაგმენტების შეგროვება გასულ ზაფხულს დაიწყო. მთელი ეს დრო ოფიციალურ საიტზე https://core.telegram.org დოკუმენტაცია იყო 23-ე ფენის, ე.ი. სადღაც 2014 წელს გაიჭედა (გახსოვს, მაშინ ჯერ არხებიც კი არ იყო?). რა თქმა უნდა, თეორიულად, ამან შესაძლებელი უნდა ყოფილიყო იმ დროისთვის ფუნქციონალური კლიენტის დანერგვა 2014 წელს. მაგრამ ამ მდგომარეობაშიც კი, დოკუმენტაცია, ჯერ ერთი, არასრული იყო და მეორეც, ადგილებზე ის ეწინააღმდეგებოდა თავის თავს. ერთი თვის წინ, 2019 წლის სექტემბერში, ეს იყო შემთხვევით აღმოჩნდა, რომ საიტს აქვს დოკუმენტაციის დიდი განახლება, სრულიად ახალი Layer 105-ისთვის, შენიშვნა, რომ ახლა ყველაფერი ხელახლა უნდა წაიკითხოს. მართლაც, ბევრი სტატია გადაიხედა, მაგრამ ბევრი უცვლელი დარჩა. ამიტომ, დოკუმენტაციის შესახებ ქვემოთ მოყვანილი კრიტიკის წაკითხვისას უნდა გაითვალისწინოთ, რომ ზოგიერთი მათგანი აღარ არის აქტუალური, მაგრამ ზოგიერთი მაინც საკმაოდ. ყოველივე ამის შემდეგ, თანამედროვე სამყაროში 5 წელი უბრალოდ ბევრი არ არის, არამედ ძალიან ბევრი. მას შემდეგ (განსაკუთრებით თუ არ გაითვალისწინებთ გადაგდებულ და გაცოცხლებულ გეოჩატებს) სქემაში API მეთოდების რაოდენობა ასიდან ორას ორმოცდაათზე მეტს გაიზარდა!

საიდან იწყებ, როგორც ახალგაზრდა მწერალი?

არ აქვს მნიშვნელობა ნულიდან წერთ თუ იყენებთ, მაგალითად, მზა ბიბლიოთეკებს, როგორიცაა ტელეთონი პითონისთვის ან Madeline PHP-სთვის, ნებისმიერ შემთხვევაში, ჯერ დაგჭირდებათ დაარეგისტრირეთ თქვენი განაცხადი - მიიღეთ პარამეტრები api_id и api_hash (მათ, ვინც მუშაობდა VKontakte API-სთან, მაშინვე ესმით), რომლითაც სერვერი ამოიცნობს აპლიკაციას. ეს უნდა იურიდიული მიზეზების გამო, მაგრამ უფრო მეტს ვისაუბრებთ იმაზე, თუ რატომ არ შეუძლიათ ბიბლიოთეკის ავტორებს მისი გამოქვეყნება მეორე ნაწილში. ალბათ კმაყოფილი დარჩებით ტესტის მნიშვნელობებით, თუმცა ისინი ძალიან შეზღუდულია - ფაქტია, რომ ახლა შეგიძლიათ დარეგისტრირდეთ თქვენს ნომერზე მხოლოდ ერთი განაცხადის, ასე რომ არ ჩქარობენ თავსატეხი.

ახლა ტექნიკური თვალსაზრისით უნდა გვაინტერესებდეს, რომ რეგისტრაციის შემდეგ ტელეგრამიდან უნდა მივიღოთ შეტყობინებები დოკუმენტაციის, პროტოკოლის განახლებების შესახებ და ა.შ. ანუ, შეიძლება ვივარაუდოთ, რომ ნავსადგომებით საიტი უბრალოდ "გაიტანა" და განაგრძო მუშაობა კონკრეტულად მათთან, ვინც დაიწყო კლიენტების შექმნა, რადგან. უფრო ადვილია. მაგრამ არა, მსგავსი არაფერი დაფიქსირებულა, ინფორმაცია არ მოსულა.

და თუ ნულიდან წერთ, მაშინ მიღებული პარამეტრების გამოყენება რეალურად ჯერ კიდევ შორს არის. მიუხედავად იმისა https://core.telegram.org/ და პირველ რიგში მათზე საუბრობს დაწყებაში, ფაქტობრივად, ჯერ უნდა განახორციელოთ MTProto პროტოკოლი - მაგრამ თუ გჯერა განლაგება OSI მოდელის მიხედვით პროტოკოლის ზოგადი აღწერილობის გვერდის ბოლოს, მაშინ სრულიად უშედეგოდ.

სინამდვილეში, როგორც MTProto-მდე, ისე მის შემდეგ, ერთდროულად რამდენიმე დონეზე (როგორც OS-ის ბირთვში მომუშავე უცხოელი ქსელის წარმომადგენლები ამბობენ, ფენის დარღვევა), დიდი, მტკივნეული და საშინელი თემა ხელს შეუშლის ...

ორობითი სერიალიზაცია: TL (Type Language) და მისი სქემა, ფენები და მრავალი სხვა საშინელი სიტყვა

ეს თემა, ფაქტობრივად, არის Telegram-ის პრობლემების გასაღები. და ბევრი საშინელი სიტყვა იქნება, თუ შეეცდებით მასში ჩაღრმავებას.

ასე რომ, სქემა. თუ გახსოვთ ეს სიტყვა, თქვით: 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 FreeNode IRC ქსელში, ცდილობს განახორციელოს კარიბჭე Telegram-დან Matrix-მდე (ციტატის თარგმანი მეხსიერებიდან არასწორია):

ისეთი შეგრძნებაა, თითქოს ადამიანი, ვინც პირველად შემოიტანა ტიპის თეორია, აღფრთოვანდა და დაიწყო მასთან თამაშის მცდელობა, სულაც არ აინტერესებდა, საჭირო იყო თუ არა პრაქტიკაში.

თავად ნახეთ, შიშველი ტიპების (ინტ, გრძელი და ა.შ.) საჭიროება, როგორც რაღაც ელემენტარული, არ ბადებს კითხვებს - საბოლოო ჯამში, ისინი ხელით უნდა განხორციელდეს - მაგალითად, ვცადოთ მათგან გამოყვანა. ვექტორი. ანუ, ფაქტობრივად, მასივითუ მიღებულ ნივთებს თავიანთ სახელებს უწოდებთ.

მაგრამ ადრე

TL სინტაქსის ქვეჯგუფის მოკლე აღწერა მათთვის, ვინც არ კითხულობს ოფიციალურ დოკუმენტაციას

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

fixed#abcdef34 id:int = Type2;

fixedVec set:Vector<Type2> = FixedVec;

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

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

ყოველთვის იწყება განსაზღვრება დიზაინერი, რის შემდეგაც, სურვილისამებრ (პრაქტიკაში, ყოველთვის) სიმბოლოს მეშვეობით # უნდა იყოს CRC32 მოცემული ტიპის აღწერილობის ნორმალიზებული სტრიქონიდან. შემდეგ მოდის ველების აღწერა, თუ ისინი არიან - ტიპი შეიძლება იყოს ცარიელი. ეს ყველაფერი სრულდება ტოლობის ნიშნით, იმ ტიპის სახელწოდებით, რომელსაც მიეკუთვნება მოცემული კონსტრუქტორი - ანუ ფაქტობრივად ქვეტიპი. ტოლობის ნიშნის მარჯვნივ არის ტიპი პოლიმორფული - ანუ შეიძლება შეესაბამებოდეს რამდენიმე სპეციფიკურ ტიპს.

თუ განსაზღვრება ხდება ხაზის შემდეგ ---functions---, მაშინ სინტაქსი იგივე დარჩება, მაგრამ მნიშვნელობა განსხვავებული იქნება: კონსტრუქტორი გახდება RPC ფუნქციის სახელი, ველები გახდება პარამეტრები (კარგად, ანუ დარჩება ზუსტად იგივე მოცემული სტრუქტურა, როგორც ქვემოთ არის აღწერილი, ეს იქნება მხოლოდ მოცემული მნიშვნელობა), და "პოლიმორფული ტიპი" არის დაბრუნებული შედეგის ტიპი. მართალია, ის მაინც დარჩება პოლიმორფული - მხოლოდ განყოფილებაში განსაზღვრული ---types---, და ეს კონსტრუქტორი არ განიხილება. აკრიფეთ მოწოდებული ფუნქციების გადატვირთვები მათი არგუმენტებით, ე.ი. რატომღაც, რამდენიმე ფუნქცია იგივე სახელით, მაგრამ განსხვავებული ხელმოწერით, როგორც C++-ში, არ არის გათვალისწინებული TL-ში.

რატომ "კონსტრუქტორი" და "პოლიმორფული" თუ ის არ არის OOP? სინამდვილეში, ვინმესთვის უფრო ადვილი იქნება ამაზე ფიქრი OOP-ის თვალსაზრისით - პოლიმორფული ტიპი, როგორც აბსტრაქტული კლასი, და კონსტრუქტორები მისი პირდაპირი შთამომავალი კლასებია, უფრო მეტიც. final რიგი ენების ტერმინოლოგიაში. სინამდვილეში, რა თქმა უნდა, აქ მსგავსება რეალური გადატვირთული კონსტრუქტორის მეთოდებით OO პროგრამირების ენებში. ვინაიდან აქ მხოლოდ მონაცემთა სტრუქტურებია, არ არსებობს მეთოდები (თუმცა ქვემოთ მოცემული ფუნქციების და მეთოდების აღწერამ შეიძლება გამოიწვიოს დაბნეულობა იმის შესახებ, თუ რა არის ისინი, მაგრამ ეს სხვა რამეზეა) - შეგიძლიათ წარმოიდგინოთ კონსტრუქტორი, როგორც ღირებულება, საიდანაც შენდება აკრიფეთ ბაიტების ნაკადის წაკითხვისას.

როგორ ხდება ეს? დესერიალიზატორი, რომელიც ყოველთვის კითხულობს 4 ბაიტს, ხედავს მნიშვნელობას 0xcrc32 - და ხვდება რა იქნება შემდეგ field1 ტიპით int, ე.ი. კითხულობს ზუსტად 4 ბაიტს, ამ გადაფარებულ ველზე ტიპის PolymorType წაიკითხეთ. Ხედავს 0x2crc32 და ესმის, რომ კიდევ ორი ველია, პირველი longასე რომ, ჩვენ ვკითხულობთ 8 ბაიტს. და შემდეგ ისევ რთული ტიპი, რომელიც დესერილიზებულია იმავე გზით. Მაგალითად, Type3 შეიძლება გამოცხადდეს სქემაში, როგორც კი ორი კონსტრუქტორი, შესაბამისად, შემდგომში უნდა შეხვდეს რომელიმეს 0x12abcd34, რის შემდეგაც თქვენ უნდა წაიკითხოთ კიდევ 4 ბაიტი intან 0x6789cdef, რის შემდეგაც არაფერი იქნება. სხვა არაფერი - თქვენ უნდა ჩააგდოთ გამონაკლისი. ნებისმიერ შემთხვევაში, ამის შემდეგ ვუბრუნდებით 4 ბაიტის კითხვას int ზღვარი field_c в constructorTwo და ამაზე ვამთავრებთ ჩვენი წაკითხვას PolymorType.

ბოლოს თუ დაიჭირეს 0xdeadcrc ამისთვის constructorThree, შემდეგ ყველაფერი უფრო რთულდება. ჩვენი პირველი სფერო bit_flags_of_what_really_present ტიპით # - სინამდვილეში, ეს მხოლოდ ტიპის მეტსახელია natნიშნავს "ბუნებრივ რიცხვს". ანუ, ფაქტობრივად, unsigned int ერთადერთი შემთხვევაა, სხვათა შორის, როდესაც ხელმოუწერელი რიცხვები გვხვდება რეალურ სქემებში. ასე რომ, შემდეგი არის კონსტრუქცია კითხვის ნიშნით, რაც ნიშნავს, რომ ეს არის ველი - ის იქნება მავთულზე მხოლოდ იმ შემთხვევაში, თუ შესაბამისი ბიტი დაყენებულია მითითებულ ველში (დაახლოებით, როგორც სამიანი ოპერატორი). ასე რომ, დავუშვათ, რომ ეს ბიტი იყო ჩართული, მაშინ უნდა წაიკითხოთ ველი, როგორიცაა Type, რომელსაც ჩვენს მაგალითში აქვს 2 კონსტრუქტორი. ერთი ცარიელია (მხოლოდ იდენტიფიკატორისგან შედგება), მეორეს აქვს ველი ids ტიპით ids:Vector<long>.

შეიძლება ფიქრობთ, რომ შაბლონებიც და გენერიკებიც კარგია ან ჯავა. Მაგრამ არა. თითქმის. ეს ერთი კუთხის ფრჩხილების შემთხვევაში რეალურ სქემებში და ის გამოიყენება მხოლოდ ვექტორისთვის. ბაიტის ნაკადში ეს იქნება 4 CRC32 ბაიტი თავად Vector ტიპისთვის, ყოველთვის იგივე, შემდეგ 4 ბაიტი - მასივის ელემენტების რაოდენობა და შემდეგ თავად ეს ელემენტები.

ამას დაუმატეთ ის ფაქტი, რომ სერიალიზაცია ყოველთვის ხდება 4 ბაიტის სიტყვებში, ყველა ტიპი მისი მრავლობითია - აღწერილია ჩაშენებული ტიპებიც. bytes и string სიგრძის ხელით სერიულიზაციით და ამ გასწორებით 4-ით - კარგად, როგორც ჩანს, ნორმალურად ჟღერს და შედარებით ეფექტურადაც კი? მიუხედავად იმისა, რომ TL-ს ამტკიცებენ, რომ ეფექტური ორობითი სერიულიზაციაა, მაგრამ ჯანდაბა მათ, ნებისმიერი გაფართოებით, თუნდაც ლოგიკური მნიშვნელობებით და ერთსიმბოლოიანი სტრიქონებით 4 ბაიტამდე, იქნება თუ არა JSON ბევრად სქელი? შეხედეთ, არასაჭირო ველებსაც კი შეიძლება გამოტოვოთ ცოტა დროშები, ყველაფერი კარგადაა და მომავლისთვისაც კი გაფართოვდება, მოგვიანებით დაამატეთ ახალი არჩევითი ველები კონსტრუქტორს?..

მაგრამ არა, თუ წაიკითხავთ არა ჩემს მოკლე აღწერას, არამედ სრულ დოკუმენტაციას და იფიქრეთ განხორციელებაზე. პირველ რიგში, კონსტრუქტორის CRC32 გამოითვლება ნორმალიზებული სქემის ტექსტის აღწერილობის სტრიქონით (წაშალეთ ზედმეტი სივრცე და ა.შ.) - ასე რომ, თუ ახალი ველი დაემატება, შეიცვლება აღწერის ტიპის სტრიქონი და, შესაბამისად, მისი CRC32 და, შესაბამისად, სერიალიზაცია. და რას გააკეთებდა ძველი კლიენტი, თუ მიიღებდა ველს ახალი დროშებით დაყენებული, მაგრამ მან არ იცოდა რა უნდა გააკეთოს მათთან შემდეგ? ..

მეორეც, გავიხსენოთ CRC32, რომელიც აქ ძირითადად გამოიყენება როგორც ჰეშის ფუნქციები ცალსახად განისაზღვროს რა ტიპის ხდება (დე)სერიალიზაცია. აქ ჩვენ შეჯახების პრობლემის წინაშე ვდგავართ - და არა, ალბათობა არ არის ერთი 232-ში, არამედ ბევრად მეტი. ვის გაახსენდა, რომ CRC32 შექმნილია იმისთვის, რომ აღმოაჩინოს (და გამოასწოროს) შეცდომები საკომუნიკაციო არხში და, შესაბამისად, გააუმჯობესოს ეს თვისებები სხვების საზიანოდ? მაგალითად, მას არ აინტერესებს ბაიტების პერმუტაცია: თუ თქვენ ითვლით CRC32-ს ორი ხაზიდან, მეორეში თქვენ შეცვლით პირველ 4 ბაიტს მომდევნო 4 ბაიტით - ეს იგივე იქნება. როდესაც ჩვენ გვაქვს ტექსტის სტრიქონები ლათინური ანბანიდან (და ცოტა სასვენი ნიშნები) შეყვანის სახით, და ეს სახელები განსაკუთრებით შემთხვევითი არ არის, ასეთი პერმუტაციის ალბათობა მნიშვნელოვნად იზრდება.

სხვათა შორის, ვინ შეამოწმა რა იყო ნამდვილად CRC32? ერთ-ერთ ადრეულ წყაროში (უოლტმენამდეც კი) არსებობდა ჰეშის ფუნქცია, რომელიც ამრავლებდა თითოეულ სიმბოლოს 239 რიცხვზე, ამ ხალხისთვის ასე საყვარელი, ჰა ჰა!

საბოლოოდ, კარგი, მივხვდით, რომ კონსტრუქტორები ველის ტიპისაა Vector<int> и Vector<PolymorType> ექნება განსხვავებული CRC32. და რაც შეეხება პრეზენტაციას ხაზზე? და თეორიის თვალსაზრისით, ხდება თუ არა ის ტიპის ნაწილი? ვთქვათ, ჩვენ გადავცემთ ათი ათასი ნომრის მასივს Vector<int> ყველაფერი გასაგებია, სიგრძე და კიდევ 40000 ბაიტი. და თუ ეს Vector<Type2>, რომელიც შედგება მხოლოდ ერთი ველისაგან int და ის ერთადერთია ტიპში - უნდა გავიმეოროთ 10000xabcdef0 34 ჯერ და შემდეგ 4 ბაიტი int, ან ენას შეუძლია ჩვენთვის ამის ჩვენება კონსტრუქტორისგან fixedVec და 80000 ბაიტის ნაცვლად ისევ გადავიტან მხოლოდ 40000?

ეს სულაც არ არის უსაქმური თეორიული კითხვა - წარმოიდგინეთ, რომ მიიღებთ ჯგუფის მომხმარებელთა სიას, რომელთაგან თითოეულს აქვს ID, სახელი, გვარი - სხვაობა მობილური კავშირის საშუალებით გადაცემული მონაცემების რაოდენობაში შეიძლება იყოს მნიშვნელოვანი. ეს არის Telegram-ის სერიალიზაციის ეფექტურობა, რომელიც რეკლამირებულია ჩვენთან.

ასე რომ ...

ვექტორი, რომლის დადგენა ვერ მოხერხდა

თუ შეეცდებით კომბინატორების აღწერის გვერდებს და დაახლოებით, დაინახავთ, რომ ვექტორი (და თუნდაც მატრიცა) ფორმალურად ცდილობს რამდენიმე ფურცლის გამოტანას ტოპების მეშვეობით. მაგრამ საბოლოოდ ისინი ჭრიან, საბოლოო ნაბიჯი გამოტოვებულია და უბრალოდ მოცემულია ვექტორის განმარტება, რომელიც ასევე არ არის დაკავშირებული ტიპთან. რა შუაშია აქ? ენებში პროგრამირება, განსაკუთრებით ფუნქციონალური, საკმაოდ ტიპიურია სტრუქტურის რეკურსიულად აღწერა - შემდგენელი თავისი ზარმაცი შეფასებით ყველაფერს გაიგებს და გააკეთებს. ენაში მონაცემთა სერიალიზაცია მაგრამ საჭიროა ეფექტურობა: საკმარისია უბრალოდ აღწეროთ список, ე.ი. ორი ელემენტის სტრუქტურა - პირველი არის მონაცემთა ელემენტი, მეორე არის იგივე სტრუქტურა ან ცარიელი ადგილი კუდისთვის (პაკეტი (cons) ლისპში). მაგრამ ამას აშკარად დასჭირდება თითოეულ ელემენტი დამატებით ხარჯავს 4 ბაიტს (CRC32 TL-ის შემთხვევაში) მისი ტიპის აღსაწერად. მასივის აღწერა მარტივია ფიქსირებული ზომა, მაგრამ მანამდე უცნობი სიგრძის მასივის შემთხვევაში ვწყვეტთ.

ასე რომ, რადგან TL არ გაძლევთ საშუალებას გამოიყვანოთ ვექტორი, ის უნდა დაემატოს მხარეს. საბოლოო ჯამში, დოკუმენტაციაში ნათქვამია:

სერიალიზაცია ყოველთვის იყენებს ერთსა და იმავე კონსტრუქტორს „ვექტორს“ (const 0x1cb5c415 = crc32 („ვექტორი t:Type # [t ] = Vector t“), რომელიც არ არის დამოკიდებული t ტიპის ცვლადის კონკრეტულ მნიშვნელობაზე.

არჩევითი პარამეტრის მნიშვნელობა t არ არის ჩართული სერიალიზაციაში, რადგან ის მიღებულია შედეგის ტიპიდან (ყოველთვის ცნობილი იყო დესერიალიზაციამდე).

დააკვირდით: vector {t:Type} # [ t ] = Vector t - მაგრამ არსად თავად განმარტება არ ამბობს, რომ პირველი რიცხვი უნდა იყოს ვექტორის სიგრძის ტოლი! და ეს არსად არ მოყვება. ეს არის მოცემულობა, რომელიც უნდა გახსოვდეთ და განახორციელოთ თქვენი ხელებით. სხვაგან, დოკუმენტაცია გულწრფელადაც კი აღნიშნავს, რომ ტიპი ყალბია:

Vector t პოლიმორფული ფსევდოტიპი არის "ტიპი", რომლის მნიშვნელობა არის ნებისმიერი t ტიპის მნიშვნელობების თანმიმდევრობა, ყუთში ან შიშველი.

... მაგრამ არ აკეთებს მასზე ფოკუსირებას. როცა მათემატიკის გაჭიმვით დაღლილი (შეიძლება უნივერსიტეტის კურსიდანაც გიცნობდეთ), გადაწყვეტთ ქულების აღებას და უყუროთ, თუ როგორ უნდა იმუშაოთ პრაქტიკაში, თავში შთაბეჭდილება რჩება: აქ სერიოზული მათემატიკა ემყარება , აშკარად Cool People (ორი მათემატიკოსი - ACM-ის გამარჯვებული) და არა ვინმე. მიზანი - გაფუჭება - მიღწეულია.

სხვათა შორის, რაოდენობის შესახებ. გავიხსენოთ # ეს არის სინონიმი natბუნებრივი რიცხვი:

არის ტიპის გამონათქვამები (typeexpr) და რიცხვითი გამონათქვამები (nat-expr). თუმცა, ისინი იმავე გზით არის განსაზღვრული.
type-expr ::= expr
nat-expr ::= expr
მაგრამ გრამატიკაში ისინი ერთნაირად არის აღწერილი, ე.ი. ეს განსხვავება კვლავ უნდა დაიმახსოვროთ და ხელით განხორციელდეს.

დიახ, შაბლონის ტიპები (vector<int>, vector<User>გქონდეთ საერთო იდენტიფიკატორი (#1cb5c415), ე.ი. თუ იცით ზარი გამოცხადებულია როგორც

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

მაშინ თქვენ ელოდებით არა მხოლოდ ვექტორს, არამედ მომხმარებელთა ვექტორს. Უფრო ზუსტად, უნდა დაველოდოთ - რეალურ კოდში, თითოეულ ელემენტს, თუ არა შიშველ ტიპს, ექნება კონსტრუქტორი და კარგი თვალსაზრისით განხორციელებისას საჭირო იქნება შემოწმება - და ჩვენ გამოგვიგზავნეს ზუსტად ამ ვექტორის თითოეულ ელემენტში იმ ტიპის? და თუ ეს იყო რაიმე სახის PHP, რომელშიც მასივი შეიძლება შეიცავდეს სხვადასხვა ტიპებს სხვადასხვა ელემენტებში?

ამ დროს იწყებ ფიქრს - საჭიროა თუ არა ასეთი TL? იქნებ ეტლისთვის შესაძლებელი იყოს ადამიანის სერიალიზატორის გამოყენება, იგივე პროტობუფი, რომელიც მაშინ უკვე არსებობდა? ეს იყო თეორია, მოდი პრაქტიკას მივხედოთ.

არსებული TL დანერგვები კოდში

TL დაიბადა VKontakte-ს ნაწლავებში ჯერ კიდევ ცნობილ მოვლენებამდე, დუროვის წილის გაყიდვით და (აუცილებლად), ჯერ კიდევ Telegram-ის განვითარებამდე. და ღია კოდით პირველი განხორციელების წყაროები შეგიძლიათ იპოვოთ ბევრი სასაცილო ხელჯოხები. და თავად ენა იქ უფრო სრულად იქნა დანერგილი, ვიდრე ახლა არის Telegram-ში. მაგალითად, ჰეშები საერთოდ არ გამოიყენება სქემაში (იგულისხმება ჩაშენებული ფსევდოტიპი (როგორც ვექტორი) დევიანტური ქცევით). ან

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>;

ეს არის hashmap შაბლონის ტიპის განმარტება, როგორც int - Type წყვილების ვექტორი. C++-ში ასე გამოიყურება:

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

ისე, alpha - საკვანძო სიტყვა! მაგრამ მხოლოდ C++-ში შეგიძლიათ დაწეროთ T, მაგრამ უნდა დაწეროთ ალფა, ბეტა... მაგრამ არაუმეტეს 8 პარამეტრისა, ფანტაზია დასრულდა თეტაზე. ასე რომ, როგორც ჩანს, ერთხელ პეტერბურგში იყო დაახლოებით ასეთი დიალოგები:

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

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

მაგრამ საუბარი იყო TL-ის „ზოგადად“ პირველ ასახულ განხორციელებაზე. მოდით გადავიდეთ Telegram-ის რეალურ კლიენტებში განხორციელების განხილვაზე.

ბასილის სიტყვა:

ვასილი, [09.10.18 17:07] ყველაზე მეტად, ტრაკი იმით აცხელებს, რომ აბსტრაქციების თაიგულები დაამტვრიეს, შემდეგ კი ჭანჭიკი დაარტყეს და კოდეგერატორი ყავარჯნებით გადააფარეს.
შედეგად, ჯერ დოკებიდან pilot.jpg
შემდეგ jekichan.webp კოდიდან

რა თქმა უნდა, ალგორითმებისა და მათემატიკის მცოდნე ადამიანებისგან შეგვიძლია ველოდოთ, რომ მათ წაიკითხეს Aho, Ullman და იცნობდნენ დე ფაქტო ინდუსტრიის სტანდარტულ ინსტრუმენტებს ათწლეულების განმავლობაში მათი DSL შემდგენელების დასაწერად, არა? ..

ავტორი telegram-cli არის ვიტალი ვალტმანი, როგორც შეიძლება გავიგოთ TLO ფორმატის გაჩენიდან მისი (cli) საზღვრებს გარეთ, გუნდის წევრი - ახლა გამოყოფილია ბიბლიოთეკა TL-ის გასაანალიზებლად ცალკერა შთაბეჭდილება რჩება მასზე TL პარსერი? ..

16.12 04:18 ვასილი: ჩემი აზრით, ვიღაცას არ დაეუფლა lex + yacc
16.12 04:18 ვასილი: თორემ ვერ ავხსნი
16.12 04:18 ვასილი: კარგი, ან გადაიხადეს VK-ში ხაზების რაოდენობა
16.12 04:19 ვასილი: სხვათა 3k+ სტრიქონი<censored> პარსერის ნაცვლად

იქნებ გამონაკლისი? ვნახოთ როგორ აკეთებს ეს არის ოფიციალური კლიენტი — Telegram Desktop:

    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 ჩეკზე ვისაუბრეთ? ასე რომ, Telegram Desktop კოდის გენერატორში არის გამონაკლისების სია იმ ტიპებისთვის, რომლებშიც გამოითვლება CRC32 არ შეესაბამება როგორც ნაჩვენებია დიაგრამაში!

ვასილი, [18.12 22:49] და აქ უნდა იფიქრო, საჭიროა თუ არა ასეთი TL
ალტერნატიული განხორციელებების არევა რომ მსურდა, დავიწყებდი ხაზების წყვეტების ჩასმას, პარსერების ნახევარი იშლება მრავალხაზოვან განმარტებებზე
tdesktop, თუმცა, ასევე

დაიმახსოვრეთ პუნქტი ერთი ლაინერების შესახებ, ჩვენ მას ცოტა მოგვიანებით დავუბრუნდებით.

კარგი, telegram-cli არაოფიციალურია, Telegram Desktop ოფიციალურია, მაგრამ რაც შეეხება დანარჩენებს? და ვინ იცის?.. ანდროიდის კლიენტის კოდში საერთოდ არ იყო სქემის პარსერი (რაც აჩენს კითხვებს ღია კოდის შესახებ, მაგრამ ეს არის მეორე ნაწილისთვის), მაგრამ იყო კიდევ რამდენიმე სასაცილო კოდი, მაგრამ მათ შესახებ ქვემოთ მოცემული ქვეგანყოფილება.

სხვა რა კითხვებს ბადებს პრაქტიკაში სერიალიზაცია? მაგალითად, მათ გააფუჭეს, რა თქმა უნდა, ბიტის ველებით და პირობითი ველებით:

vasily: flags.0? true
ნიშნავს, რომ ველი არსებობს და ჭეშმარიტია, თუ დროშა დაყენებულია

vasily: flags.1? int
ნიშნავს, რომ ველი არსებობს და საჭიროებს დესერიალიზაციას

ვასილი: ტრაკი, არ დაწვა, რას აკეთებ!
ვასილი: სადღაც დოკუმენტში არის ნახსენები, რომ true არის ნულოვანი სიგრძის შიშველი ტიპი, მაგრამ არარეალურია რაიმეს შეგროვება მათი დოკუმენტებიდან.
ვასილი: ღია განხორციელებებშიც არ არის მსგავსი, მაგრამ ბევრი ყავარჯნები და რეკვიზიტებია.

ტელემათონზე რას იტყვით? MTProto-ს თემას წინ ვუყურებ, მაგალითი - დოკუმენტაციაში არის ასეთი ნაწილები, მაგრამ ნიშანი % იგი მხოლოდ აღწერილია, როგორც "მოცემული შიშველი ტიპის შესაბამისი", ე.ი. ქვემოთ მოცემულ მაგალითებში ან შეცდომაა, ან რაიმე დაუსაბუთებელი:

ვასილი, [22.06.18/18/38 XNUMX:XNUMX] ერთ ადგილას:
msg_container#73f1f8dc messages:vector message = MessageContainer;
განსხვავებულში:
msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;
და ეს ორი დიდი განსხვავებაა, რეალურ ცხოვრებაში რაღაც შიშველი ვექტორი მოდის

მე არ მინახავს შიშველი ვექტორული განმარტებები და არ შემხვედრია

ტელეთონში ხელით დაწერილი ანალიზი

მისმა სქემამ გამოაქვეყნა განმარტება msg_container

ისევ და ისევ, კითხვა რჩება. არ არის აღწერილი.

ვადიმ გონჩაროვი, [22.06.18/19/22 XNUMX:XNUMX PM] და tdesktop-ში?

ვასილი, [22.06.18/19/23 XNUMX:XNUMX] მაგრამ მათი TL პარსერი რეგულატორებზე ალბათ არც შეჭამს

// parsed manually

TL მშვენიერი აბსტრაქციაა, მას სრულად არავინ ახორციელებს

და არ არის % სქემის მათ ვერსიაში

მაგრამ აქ დოკუმენტაცია ეწინააღმდეგება თავის თავს, ამიტომ xs

ის გრამატიკაში იქნა ნაპოვნი, მათ უბრალოდ შეეძლოთ დაევიწყებინათ სემანტიკის აღწერა

აბა, ტლ-ზე დოკი ნახე, ნახევარი ლიტრის გარეშე ვერ ხვდები

”კარგი, ვთქვათ,” იტყვის სხვა მკითხველი, ”თქვენ აკრიტიკებთ ყველაფერს, ასე რომ აჩვენეთ როგორც უნდა.”

ვასილი პასუხობს: „რაც შეეხება პარსერს, მე მჭირდება მსგავსი რამ

    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's გენერირებული კოდი), მათ შორის, აკრიფეთ სიკეთეები, აკრიფეთ ინფორმაცია ინტროსპექტივისთვის თითოეულ კლასში. თითოეული პოლიმორფული ტიპი გადაიქცევა ცარიელ აბსტრაქტულ საბაზისო კლასად და კონსტრუქტორები მისგან მემკვიდრეობით იღებენ და აქვთ სერიალიზაციისა და დესერიალიზაციის მეთოდები.

ტიპების ნაკლებობა ტიპის ენაში

ძლიერი აკრეფა კარგია, არა? არა, ეს არ არის ჰოლივარი (თუმცა მე მირჩევნია დინამიური ენები), არამედ პოსტულატი TL-ში. მასზე დაყრდნობით ენამ უნდა მოგვაწოდოს ყველანაირი შემოწმება. კარგი, კარგი, არა ის, არამედ განხორციელება, მაგრამ მან მაინც უნდა აღწეროს ისინი. და რა შესაძლებლობები გვინდა?

პირველ რიგში, შეზღუდვები. აქ ჩვენ ვხედავთ ფაილების ატვირთვის დოკუმენტაციაში:

შემდეგ ფაილის ორობითი შინაარსი იყოფა ნაწილებად. ყველა ნაწილს უნდა ჰქონდეს იგივე ზომა ( ნაწილი_ზომა ) და უნდა აკმაყოფილებდეს შემდეგი პირობები:

part_size % 1024 = 0 (იყოფა 1 კბ-ზე)

524288 % part_size = 0 (512 კბ თანაბრად იყოფა ნაწილის ზომაზე)

ბოლო ნაწილი არ უნდა აკმაყოფილებდეს ამ პირობებს, თუ მისი ზომა ნაკლებია part_size-ზე.

თითოეულ ნაწილს უნდა ჰქონდეს რიგითი ნომერი, ფაილის_ნაწილი, ღირებულებით 0-დან 2,999-მდე.

ფაილის დაყოფის შემდეგ თქვენ უნდა აირჩიოთ სერვერზე მისი შენახვის მეთოდი. გამოყენება upload.saveBigFilePart იმ შემთხვევაში, თუ ფაილის სრული ზომა 10 მბ-ზე მეტია და upload.saveFilePart პატარა ფაილებისთვის.
[…] შეიძლება დაბრუნდეს მონაცემთა შეყვანის ერთ-ერთი შემდეგი შეცდომა:

FILE_PARTS_INVALID - ნაწილების არასწორი რაოდენობა. ღირებულება არ არის შორის 1..3000

არის თუ არა რომელიმე მათგანი სქემაში? არის თუ არა ის რაღაცნაირად გამოხატული TL-ით? არა. მაგრამ მაპატიეთ, მოძველებულმა ტურბო პასკალმაც კი შეძლო მოცემული ტიპების აღწერა დიაპაზონები. და მას შეეძლო კიდევ ერთი რამის გაკეთება, ახლა უფრო ცნობილი როგორც enum - ტიპი, რომელიც შედგება მნიშვნელობების ფიქსირებული (მცირე) რაოდენობის ჩამოთვლისგან. ისეთ ენებზე, როგორიცაა C - რიცხვითი, გაითვალისწინეთ, აქამდე მხოლოდ ტიპებზე ვისაუბრეთ. რიცხვები. მაგრამ ასევე არის მასივები, სტრიქონები... მაგალითად, კარგი იქნება იმის აღწერა, რომ ეს სტრიქონი მხოლოდ ტელეფონის ნომერს შეიძლება შეიცავდეს, არა?

არცერთი ეს არ არის TL-ში. მაგრამ არის, მაგალითად, JSON სქემაში. და თუ ვინმეს შეუძლია გააპროტესტოს 512 KB-ის გაყოფის შესახებ, რომ ეს ჯერ კიდევ უნდა შემოწმდეს კოდში, მაშინ დარწმუნდით, რომ კლიენტი უბრალოდ ვერ შეძლო გაგზავნეთ ნომერი დიაპაზონის გარეთ 1..3000 (და შესაბამისი შეცდომა ვერ წარმოიშვა) შესაძლებელი იქნებოდა, არა? ..

სხვათა შორის, შეცდომებისა და დაბრუნების მნიშვნელობების შესახებ. თვალი ბუნდოვანია მათთვისაც კი, ვინც TL-ით მუშაობდა - ეს მაშინვე არ გაგვიჩნდა თითოეული ფუნქცია TL-ში რეალურად შეუძლია დააბრუნოს არა მხოლოდ აღწერილი დაბრუნების ტიპი, არამედ შეცდომა. მაგრამ ეს არ არის გამორიცხული თვით TL-ის საშუალებით. რა თქმა უნდა, გასაგებია და ნაფიგი არ არის აუცილებელი პრაქტიკაში (თუმცა, სინამდვილეში, RPC შეიძლება გაკეთდეს სხვადასხვა გზით, ჩვენ ამას დავუბრუნდებით) - მაგრამ რაც შეეხება ზეციური სამყაროდან აბსტრაქტული ტიპების მათემატიკის ცნებების სისუფთავეს? .. აიღო ბუქსირი - ასე ემთხვევა.

და ბოლოს, რაც შეეხება კითხვადობას? ისე, იქ, ზოგადად, მინდა აღწერა აქვს ის სწორად სქემაში (ისევ, ეს არის JSON სქემაში), მაგრამ თუ ის უკვე დაძაბულია, მაშინ რა შეიძლება ითქვას პრაქტიკულ მხარეზე - ყოველ შემთხვევაში, განახლებების დროს განსხვავებების ყურება ბანალურია? თავად ნახეთ აქ რეალური მაგალითები:

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

ან

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

ვიღაცას მოსწონს, მაგრამ GitHub, მაგალითად, უარს ამბობს ხაზს უსვამს ცვლილებებს ასეთ გრძელ ხაზებში. თამაში "იპოვე 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. Ან პირიქით. მაგრამ იმუშავა! ანუ სერვერს არ აინტერესებდა ტიპი. როგორ შეიძლება ეს? პასუხი, ალბათ, მოჰყვება კოდის ფრაგმენტებს telegram-cli-დან:

  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 მახასიათებლის შესახებ:

თუ კლიენტი მხარს უჭერს Layer 2-ს, მაშინ უნდა იქნას გამოყენებული შემდეგი კონსტრუქტორი:
invokeWithLayer2#289dd1f6 {X:Type} query:!X = X;
პრაქტიკაში, ეს ნიშნავს, რომ ყოველი API გამოძახების წინ არის int მნიშვნელობა 0x289dd1f6 მეთოდის ნომერამდე უნდა დაემატოს.

კარგად ჟღერს. მაგრამ რა მოხდა შემდეგ? მერე მოვიდა

invokeWithLayer3#b7475268 query:!X = X;

მაშ რა არის შემდეგი? როგორც ადვილი მისახვედრია

invokeWithLayer4#dea0d430 query:!X = X;

სასაცილო? არა, ჯერ ადრეა სიცილი, დაფიქრდი რა თითოეული სხვა ფენის მოთხოვნა უნდა იყოს შეფუთული ასეთ სპეციალურ ტიპში - თუ ისინი ყველა განსხვავებული გაქვთ, სხვაგვარად როგორ განვასხვავოთ ისინი? და წინ სულ რაღაც 4 ბაიტის დამატება საკმაოდ ეფექტური მეთოდია. Ისე

invokeWithLayer5#417a57ae query:!X = X;

მაგრამ აშკარაა, რომ ცოტა ხნის შემდეგ ეს რაღაც ბაქანალია გახდება. და გამოსავალი მოვიდა:

განახლება: დაწყებული Layer 9, დამხმარე მეთოდებით invokeWithLayerN შეიძლება გამოყენებულ იქნას ერთად initConnection

ჰოო! 9 ვერსიის შემდეგ, საბოლოოდ მივედით იმაზე, რაც გაკეთდა ინტერნეტ პროტოკოლებში ჯერ კიდევ 80-იან წლებში - ვერსიის მოლაპარაკება ერთხელ კავშირის დასაწყისში!

მერე რა არის შემდეგი?..

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

ახლა კი შეგიძლია იცინო. მხოლოდ კიდევ 9 ფენის შემდეგ, საბოლოოდ დაემატა უნივერსალური კონსტრუქტორი ვერსიის ნომრით, რომელსაც კავშირის დასაწყისში მხოლოდ ერთხელ უნდა გამოძახება და ფენებში მნიშვნელობა თითქოს გაქრა, ახლა ეს მხოლოდ პირობითი ვერსიაა, მაგ. ყველგან სხვაგან. პრობლემა მოგვარებულია.

არა?..

ვასილი, [16.07.18/14/01 XNUMX:XNUMX] პარასკევს ვიფიქრე:
ტელესერვერი აგზავნის მოვლენებს მოთხოვნის გარეშე. მოთხოვნები უნდა შეფუთული იყოს InvokeWithLayer-ში. სერვერი არ ახვევს განახლებებს, არ არსებობს პასუხებისა და განახლებების შეფუთვის სტრუქტურა.

იმათ. კლიენტს არ შეუძლია განსაზღვროს ის ფენა, რომელშიც მას სურს განახლებები

ვადიმ გონჩაროვი, [16.07.18/14/02 XNUMX:XNUMX PM] InvokeWithLayer პრინციპში ყავარჯენი არ არის?

ვასილი, [16.07.18/14/02 XNUMX:XNUMX] ეს ერთადერთი გზაა

ვადიმ გონჩაროვი, [16.07.18/14/02 XNUMX:XNUMX] რაც არსებითად უნდა ნიშნავდეს სესიის დასაწყისში ფენას.

სხვათა შორის, აქედან გამომდინარეობს, რომ კლიენტის დაქვეითება არ არის გათვალისწინებული

განახლებები, ე.ი. ტიპი Updates სქემაში, ეს არის ის, რასაც სერვერი უგზავნის კლიენტს არა API მოთხოვნის საპასუხოდ, არამედ დამოუკიდებლად, როდესაც ხდება მოვლენა. ეს კომპლექსური თემაა, რომელზეც განხილული იქნება სხვა პოსტში, მაგრამ ახლა მნიშვნელოვანია ვიცოდეთ, რომ სერვერი აგროვებს განახლებებს მაშინაც კი, როდესაც კლიენტი ოფლაინშია.

ამრიგად, შეფუთვაზე უარის თქმისას თითოეულ პაკეტი, რათა მიუთითოს მისი ვერსია, ამიტომ ლოგიკურად წარმოიქმნება შემდეგი შესაძლო პრობლემები:

სერვერი უგზავნის განახლებებს კლიენტს მანამ, სანამ კლიენტი არ ეტყვის, რომელ ვერსიას უჭერს მხარს
რა უნდა გაკეთდეს კლიენტის განახლების შემდეგ?
ვინც გარანტიებირომ სერვერის აზრი ფენის ნომერზე არ შეიცვლება პროცესში?

როგორ ფიქრობთ, ეს არის წმინდა თეორიული აზროვნება და პრაქტიკაში ეს არ შეიძლება მოხდეს, რადგან სერვერი სწორად არის დაწერილი (ყოველ შემთხვევაში, კარგად არის გამოცდილი)? ჰა! არ აქვს მნიშვნელობა როგორ!

ზუსტად ამას შევხვდით აგვისტოში. 14 აგვისტოს გაჩნდა შეტყობინებები, რომ რაღაც ახლდებოდა Telegram სერვერებზე ... და შემდეგ ჟურნალებში:

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

და შემდეგ რამდენიმე მეგაბაიტი სტეკის კვალი (კარგად, ამავე დროს, ხე დაფიქსირდა). ყოველივე ამის შემდეგ, თუ რაიმე არ იქნა აღიარებული თქვენს TL-ში - ის ორობითია ხელმოწერებით, შემდგომ ნაკადში ყველა მიდის, დეკოდირება შეუძლებელი გახდება. რა უნდა გააკეთოს ასეთ სიტუაციაში?

ისე, პირველი, რაც ვინმეს გონზე მოდის, არის გათიშვა და ხელახლა ცდა. არ უშველა. ჩვენ დავგუგლეთ CRC32 - ეს აღმოჩნდა ობიექტები 73-ე სქემიდან, თუმცა ჩვენ ვიმუშავეთ სქემა 82-ზე. ჩვენ ყურადღებით ვათვალიერებთ ჟურნალებს - არის იდენტიფიკატორები ორი განსხვავებული სქემიდან!

იქნებ პრობლემა მხოლოდ ჩვენს არაოფიციალურ კლიენტშია? არა, ჩვენ ვიყენებთ Telegram Desktop 1.2.17-ს (ვერსია მოწოდებული Linux-ის დისტრიბუციით), ის წერს გამონაკლისის ჟურნალში: MTP მოულოდნელი ტიპის id #b5223b0f წაკითხული MTPMessageMedia…

Google-მა აჩვენა, რომ მსგავსი პრობლემა უკვე შეექმნა ერთ-ერთ არაოფიციალურ კლიენტს, მაგრამ შემდეგ ვერსიის ნომრები და, შესაბამისად, ვარაუდები განსხვავებული იყო ...

ასე რომ, რა უნდა გააკეთოს? მე და ვასილი დავშორდით: მან სცადა სქემის განახლება 91-მდე, მე გადავწყვიტე დაველოდო რამდენიმე დღე და ვცადო 73-მდე. ორივე მეთოდი მუშაობდა, მაგრამ რადგან ისინი ემპირიულია, ვერ გავიგე, რამდენი ვერსია გჭირდებათ ზევით გადახტომა. ან დაბლა, არც რამდენ ხანს მოგიწევთ ლოდინი.

მოგვიანებით, მე მოვახერხე სიტუაციის რეპროდუცირება: ჩვენ ვიწყებთ კლიენტს, გამორთეთ იგი, გადავაწყვეთ სქემა სხვა ფენაზე, გადატვირთეთ, კვლავ დავიჭირეთ პრობლემა, დავბრუნდით წინაზე - ოჰ, სქემის გადართვა არ არის და კლიენტის გადატვირთვა რამდენიმე წუთი დაგეხმარებათ. თქვენ მიიღებთ მონაცემთა სტრუქტურების ნაზავს სხვადასხვა ფენებიდან.

ახსნა? როგორც სხვადასხვა არაპირდაპირი სიმპტომებიდან მიხვდებით, სერვერი შედგება სხვადასხვა ტიპის პროცესებისგან სხვადასხვა მანქანებზე. დიდი ალბათობით, ერთ-ერთმა სერვერმა, რომელიც პასუხისმგებელია „ბუფერირებაზე“, რიგში აყენებს იმას, რაც უფრო მაღალმა მისცა და მათ მისცეს ის სქემაში, რომელიც იყო გენერირების დროს. და სანამ ეს რიგი "დამპალი" იყო, ვერაფერს გააკეთებდა.

თუ... მაგრამ ეს საშინელი ყავარჯენია?!.. არა, გიჟურ იდეებზე ფიქრამდე, ოფიციალური კლიენტების კოდს გადავხედოთ. Android-ის ვერსიაში ჩვენ ვერ ვპოულობთ TL პარსერს, მაგრამ ვპოულობთ დიდ ფაილს (github უარს ამბობს მის შეღებვაზე) (დე)სერიალიზაციით. აქ არის კოდის ფრაგმენტები:

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

ან

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

ჰმ... გიჟურად გამოიყურება. მაგრამ, ალბათ, ეს არის გენერირებული კოდი, მაშინ კარგი? .. მაგრამ ის ნამდვილად მხარს უჭერს ყველა ვერსიას! მართალია, გაუგებარია, რატომ არის ყველაფერი ერთ გროვაში შერეული და საიდუმლო ჩეთები და ყველანაირი _old7 რატომღაც არ გავს მანქანების თაობას... თუმცა, ყველაზე მეტად გავგიჟდი

TL_message_layer104
TL_message_layer104_2
TL_message_layer104_3

ბიჭებო, ერთი ფენითაც ვერ გადაწყვიტეთ?! კარგი, კარგი, "ორი", ვთქვათ, გამოუშვეს შეცდომით, კარგი, ეს ხდება, მაგრამ სამი? .. მაშინვე ისევ იმავე საკომისიოზე? ეს რა პორნოგრაფიაა, უკაცრავად? ..

სხვათა შორის, მსგავსი რამ ხდება Telegram Desktop-ის წყაროებში - თუ ასეა, და სქემის ზედიზედ რამდენიმე ჩადენა არ ცვლის მის ფენის ნომერს, მაგრამ ასწორებს რაღაცას. იმ პირობებში, როდესაც არ არსებობს სქემის მონაცემების ოფიციალური წყარო, საიდან შემიძლია მისი მიღება, გარდა კლიენტის ოფიციალური წყაროებისა? და თქვენ იქიდან იღებთ, ვერ იქნებით დარწმუნებული, რომ სქემა მთლიანად სწორია, სანამ არ შეამოწმებთ ყველა მეთოდს.

როგორ შეიძლება ამის ტესტირება? ვიმედოვნებ, რომ ერთეულის, ფუნქციური და სხვა ტესტების მოყვარულები კომენტარებში გაიზიარებენ.

კარგი, მოდით გადავხედოთ კოდის სხვა ნაწილს:

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;

ეს „ხელით შექმნილი“ კომენტარი აქ ვარაუდობს, რომ ამ ფაილის მხოლოდ ნაწილი იწერება ხელით (წარმოგიდგენიათ ტექნიკური კოშმარი?), დანარჩენი კი მანქანით გენერირებულია. თუმცა, მაშინ ჩნდება სხვა კითხვა - რომ წყაროები ხელმისაწვდომია არა მთლიანად (a la blobs ქვეშ GPL Linux kernel-ში), მაგრამ ეს უკვე მეორე ნაწილის თემაა.

მაგრამ საკმარისია. მოდით გადავიდეთ პროტოკოლზე, რომლის თავზე მთელი ეს სერიალიზაცია მისდევს.

MT პროტო

ასე რომ გავხსნათ ზოგადი აღწერა и პროტოკოლის დეტალური აღწერა და პირველი, რაზეც ვბრუნდებით, არის ტერმინოლოგია. და ყველაფრის სიმრავლით. ზოგადად, როგორც ჩანს, ეს არის Telegram-ის სასაქონლო ნიშანი - რამის სხვადასხვა ადგილას დარეკვა სხვადასხვა გზით, ან სხვადასხვა ნივთების ერთი სიტყვით, ან პირიქით (მაგალითად, მაღალი დონის API-ში, თუ ხედავთ სტიკერების პაკეტს - ეს არ არის ის, რაც თქვენ ფიქრობდით).

მაგალითად, "მესიჯი" (მესიჯი) და "სესია" (სესია) - აქ ისინი ნიშნავს რაღაც განსხვავებულს, ვიდრე Telegram კლიენტის ჩვეულებრივ ინტერფეისში. ისე, ყველაფერი ნათელია გზავნილში, მისი ინტერპრეტაცია შეიძლება OOP-ის თვალსაზრისით, ან უბრალოდ ეწოდოს სიტყვას "პაკეტი" - ეს არის დაბალი, სატრანსპორტო დონე, არ არის იგივე შეტყობინებები, როგორც ინტერფეისში, ბევრია. სამსახურის პირობა. მაგრამ სხდომა ... მაგრამ პირველი რამ.

სატრანსპორტო ფენა

პირველი რაც არის ტრანსპორტი. გვეტყვიან 5 ვარიანტზე:

TCP
ვებსაკეტი
ვებსოკეტი HTTPS-ზე
HTTP
HTTPS

ვასილი, [15.06.18/15/04 XNUMX:XNUMX] და ასევე არის UDP ტრანსპორტი, მაგრამ ეს არ არის დოკუმენტირებული

და TCP სამ ვარიანტში

პირველი მსგავსია UDP-ს TCP-ზე, თითოეული პაკეტი შეიცავს მიმდევრობის ნომერს და crc-ს
რატომ არის ასე მტკივნეული ეტლზე დოკების კითხვა?

კარგი ახლა იქ TCP უკვე 4 ვარიანტში:

შემოკლებული
საშუალო
შეფუთული შუალედური
სრული

კარგი, შუალედური MTProxy-ისთვის დამატებული იყო, ეს მოგვიანებით დაემატა ცნობილი მოვლენების გამო. მაგრამ რატომ კიდევ ორი ვერსია (სულ სამი), როცა შეიძლება ამის გაკეთება? ოთხივე არსებითად განსხვავდება მხოლოდ იმით, თუ როგორ უნდა დააყენოთ მთავარი MTProto-ს სიგრძე და დატვირთვა, რაც შემდგომში იქნება განხილული:

შემოკლებულში ეს არის 1 ან 4 ბაიტი, მაგრამ არა 0xef შემდეგ body
შუალედში ეს არის 4 ბაიტის სიგრძე და ველი და პირველად კლიენტმა უნდა გაგზავნოს 0xeeeeeeee მიუთითოს, რომ ის არის შუალედური
სრულად, ყველაზე ნარკოტიკული, ქსელურის თვალსაზრისით: სიგრძე, მიმდევრობის ნომერი და არა ის, რაც ძირითადად არის MTProto, body, CRC32. დიახ, ეს ყველაფერი TCP-ის საშუალებით. რომელიც გვაწვდის საიმედო ტრანსპორტს ბაიტების სერიული ნაკადის სახით, არ არის საჭირო თანმიმდევრობა, განსაკუთრებით საკონტროლო ჯამები. კარგი, ახლა მე გავაპროტესტებ, რომ TCP-ს აქვს 16-ბიტიანი შემოწმების ჯამი, ამიტომ ხდება მონაცემთა კორუფცია. შესანიშნავია, გარდა იმისა, რომ ჩვენ რეალურად გვაქვს კრიპტოგრაფიული პროტოკოლი ჰეშებით 16 ბაიტზე მეტი, ყველა ეს შეცდომა - და კიდევ უფრო მეტი - იქნება დაფიქსირებული SHA შეუსაბამობაზე უფრო მაღალ დონეზე. CRC32-ში ამაზე აზრი არ აქვს.

შევადაროთ ABridged, სადაც შესაძლებელია ერთი ბაიტის სიგრძე, Intermediate-ს, რომელიც ამართლებს "იმ შემთხვევაში, თუ საჭიროა 4-ბაიტი მონაცემთა გასწორება", რაც საკმაოდ სისულელეა. რა, ითვლება, რომ Telegram-ის პროგრამისტები იმდენად მოუხერხებლები არიან, რომ მათ არ შეუძლიათ მონაცემების წაკითხვა სოკეტიდან გასწორებულ ბუფერში? თქვენ ჯერ კიდევ უნდა გააკეთოთ ეს, რადგან კითხვას შეუძლია დაგიბრუნოთ ნებისმიერი რაოდენობის ბაიტი (და ასევე არის პროქსი სერვერები, მაგალითად ...). ან, მეორეს მხრივ, რატომ უნდა შევიწუხოთ Abridged, თუ ჯერ კიდევ გვაქვს სოლიდური ბალიშები ზემოდან 16 ბაიტიდან - დაზოგეთ 3 ბაიტი ზოგჯერ ?

იქმნება შთაბეჭდილება, რომ ნიკოლაი დუროვს ძალიან უყვარს ველოსიპედების გამოგონება, მათ შორის ქსელის პროტოკოლები, რეალური პრაქტიკული საჭიროების გარეშე.

სხვა სატრანსპორტო ვარიანტები, მათ შორის. ვებ და MTProxy ახლა არ განვიხილავთ, იქნებ სხვა პოსტში თუ იქნება მოთხოვნა. ჩვენ მხოლოდ ახლა გავიხსენებთ სწორედ ამ MTProxy-ის შესახებ, რომ 2018 წელს მისი გამოშვებიდან მალევე, პროვაიდერებმა სწრაფად ისწავლეს მისი დაბლოკვა, რომელიც განკუთვნილი იყო ბლოკირების შემოვლითი გზამიერ პაკეტის ზომა! და ასევე ის ფაქტი, რომ MTProxy სერვერი დაწერილი (ისევ Waltman-ის მიერ) C-ზე ზედმეტად იყო მიბმული Linux-ის სპეციფიკასთან, თუმცა ეს საერთოდ არ იყო საჭირო (ფილ კულინი დაადასტურებს), და რომ მსგავსი სერვერი ან Go-ზე ან Node.js-ზე. შეესაბამება ასზე ნაკლებ ხაზს.

მაგრამ ამ ადამიანების ტექნიკური განათლების შესახებ დასკვნებს განყოფილების ბოლოს, სხვა საკითხების განხილვის შემდეგ გამოვიტანთ. ახლა გადავიდეთ მე-5 OSI ფენაზე, სესიაზე - რომელზეც მოათავსეს MTProto სესია.

გასაღებები, შეტყობინებები, სესიები, Diffie-Hellman

ისინი იქ არ წერენ მთლად სწორად... სესია არ არის იგივე სესია, რომელიც ჩანს ინტერფეისში აქტიური სესიების ქვეშ. მაგრამ იმისათვის.

აქ ჩვენ მივიღეთ ცნობილი სიგრძის ბაიტების სტრიქონი სატრანსპორტო ფენიდან. ეს არის ან დაშიფრული შეტყობინება ან ჩვეულებრივი ტექსტი - თუ ჩვენ ჯერ კიდევ საკვანძო მოლაპარაკების ეტაპზე ვართ და რეალურად ვაკეთებთ. რომელ ცნებებზე, რომლებსაც „გასაღები“ ჰქვია, ვსაუბრობთ? მოდით გავარკვიოთ ეს საკითხი თავად Telegram-ის გუნდისთვის (ბოდიშს ვიხდი, რომ ჩემი საკუთარი დოკუმენტაცია ინგლისურიდან დილის 4 საათზე გადავთარგმნე ან დაღლილ ტვინს, უფრო ადვილი იყო ზოგიერთი ფრაზის დატოვება ისე, როგორც არის):

ორი სუბიექტია ე.წ სესია - ერთი ოფიციალური კლიენტების ინტერფეისში „მიმდინარე სესიების“ ქვეშ, სადაც თითოეული სესია შეესაბამება მთელ მოწყობილობას/ოპერაციულ სისტემას.
მეორეა MTProto სესია, რომელსაც აქვს შეტყობინებების მიმდევრობის ნომერი (დაბალი დონის გაგებით) და რომელიც შეიძლება გაგრძელდეს სხვადასხვა TCP კავშირებს შორის. რამდენიმე MTProto სესიის დაყენება შესაძლებელია ერთდროულად, მაგალითად, ფაილის ჩამოტვირთვის დასაჩქარებლად.

ამ ორს შორის სხდომები არის კონცეფცია ავტორიზაციის. გადაგვარებულ შემთხვევაში შეიძლება ითქვას UI სესია იგივეა რაც ავტორიზაციისმაგრამ სამწუხაროდ, ეს რთულია. ჩვენ ვუყურებთ:

ახალი მოწყობილობის მომხმარებელი ჯერ ქმნის auth_key და აკავშირებს მას ანგარიშზე, მაგალითად, SMS-ით - ამიტომ ავტორიზაციის

ეს მოხდა პირველში MTProto სესია, რომელსაც აქვს session_id საკუთარ თავში.

ამ ეტაპზე კომბინაცია ავტორიზაციის и session_id შეიძლება ეწოდოს მაგალითად - ეს სიტყვა გვხვდება ზოგიერთი კლიენტის დოკუმენტაციასა და კოდში

შემდეგ კლიენტს შეუძლია გახსნა ზოგიერთი MTProto სესიები იმავეს ქვეშ auth_key - იმავე DC-ზე.

შემდეგ ერთ დღეს კლიენტმა უნდა მოითხოვოს ფაილი სხვა DC - და ამ DC-სთვის ახალი წარმოიქმნება auth_key !

ვუთხრა სისტემას, რომ ეს არ არის ახალი მომხმარებლის რეგისტრაცია, მაგრამ იგივე ავტორიზაციის (UI სესია), კლიენტი იყენებს API ზარებს auth.exportAuthorization სახლში DC auth.importAuthorization ახალ DC-ში.

ერთი და იგივე, შეიძლება რამდენიმე ღია იყოს MTProto სესიები (თითოეული თავისით session_id) ამ ახალ DC-ზე, ქვეშ მისი auth_key.

და ბოლოს, კლიენტს შეიძლება სურდეს Perfect Forward Secrecy. ყოველი auth_key იყო მუდმივი გასაღები - თითო DC - და კლიენტს შეუძლია დარეკოს auth.bindTempAuthKey გამოყენებისთვის დროებითი auth_key - და ისევ, მხოლოდ ერთი temp_auth_key თითო DC, საერთო ყველასთვის MTProto სესიები ამ DC-ს.

შენიშვნა მარილი (და მომავალი მარილები) ასევე ერთი auth_key იმათ. გაზიარებული ყველას შორის MTProto სესიები იმავე DC-ზე.

რას ნიშნავს "სხვადასხვა TCP კავშირებს შორის"? ეს ნიშნავს, რომ ეს რაღაც მსგავსი ავტორიზაციის ქუქი-ფაილები ვებსაიტზე - ის ნარჩუნდება (გადარჩენს) ბევრ TCP კავშირს ამ სერვერთან, მაგრამ ერთ დღეს ის გაუარესდება. მხოლოდ HTTP-ისგან განსხვავებით, MTProto-ში, სესიის შიგნით, შეტყობინებები თანმიმდევრულად ინომრება და დასტურდება, ისინი შევიდნენ გვირაბში, კავშირი გაწყდა - ახალი კავშირის დამყარების შემდეგ, სერვერი სიამოვნებით გამოგიგზავნით ამ სესიაზე ყველაფერს, რაც მან არ მიაწოდა წინა TCP კავშირი.

თუმცა, ზემოთ მოყვანილი ინფორმაცია შეკუმშვაა მრავალი თვის სასამართლო პროცესის შემდეგ. იმავდროულად, ვახორციელებთ თუ არა ჩვენს კლიენტს ნულიდან? - დავუბრუნდეთ საწყისს.

ასე რომ, ჩვენ ვაწარმოებთ auth_key on Diffie-Hellman-ის ვერსიები Telegram-იდან. შევეცადოთ გავიგოთ დოკუმენტაცია...

ვასილი, [19.06.18/20/05 1:255] data_with_hash := SHAXNUMX(მონაცემები) + მონაცემები + (ნებისმიერი შემთხვევითი ბაიტი); ისეთი, რომ სიგრძე უდრის XNUMX ბაიტს;
დაშიფრული_მონაცემები := RSA(მონაცემები_ჰაში, სერვერის_ საჯარო გასაღები); 255 ბაიტი სიგრძის რიცხვი (დიდი ენდიანი) ამაღლებულია საჭირო სიმძლავრემდე საჭირო მოდულზე და შედეგი ინახება 256 ბაიტიან რიცხვად.

მათ მიიღეს დოპი DH

არ ჰგავს ჯანმრთელი ადამიანის DH-ს
dx-ში ორი საჯარო გასაღები არ არის

ბოლოს და ბოლოს, ჩვენ გავარკვიეთ, მაგრამ ნალექი დარჩა - სამუშაოს დადასტურება ხდება კლიენტის მიერ, რომ მან შეძლო რიცხვის ფაქტორიზირება. დაცვის ტიპი DoS შეტევებისგან. და RSA გასაღები გამოიყენება მხოლოდ ერთხელ ერთი მიმართულებით, ძირითადად დაშიფვრისთვის new_nonce. მაგრამ მიუხედავად იმისა, რომ ეს ერთი შეხედვით მარტივი ოპერაცია წარმატებულია, რა მოგიწევთ წინაშე?

ვასილი, [20.06.18/00/26 XNUMX:XNUMX] ჯერ არ მიმიღწევია აპლიკანტურ მოთხოვნაზე

თხოვნა გავუგზავნე DH-ს

ხოლო, ტრანსპორტზე დოკში წერია, რომ მას შეუძლია პასუხის გაცემა 4 ბაიტით შეცდომის კოდით. და ეს არის ის

აბა, მითხრა -404, მერე რა?

აი მე მას: „დაიჭირე სერვერის გასაღებით დაშიფრული შენი efigna თითის ანაბეჭდით, მინდა DH“ და სულელურად პასუხობს 404

რას ფიქრობთ სერვერის ასეთ პასუხზე? Რა უნდა ვქნა? არავის ჰკითხავს (მაგრამ ამაზე მეტი მეორე ნაწილში).

აქ მთელი ინტერესი დოკის მიმართ არის გასაკეთებელი

სხვა საქმე არ მაქვს, მხოლოდ ნომრების წინ და უკან გადაყვანაზე ვოცნებობდი

ორი 32 ბიტიანი ნომერი. ჩავალაგე ისინი როგორც ყველა

მაგრამ არა, ეს ორი გჭირდებათ პირველ რიგში, როგორც BE

ვადიმ გონჩაროვი, [20.06.18/15/49 404:XNUMX PM] და ამის გამო XNUMX?

ვასილი, [20.06.18/15/49 XNUMX:XNUMX] დიახ!

ვადიმ გონჩაროვი, [20.06.18/15/50 XNUMX:XNUMX] ასე რომ, არ მესმის, რა შეიძლება "ვერ იპოვა"

ვასილი, [20.06.18 15:50] დაახლოებით

მე ვერ ვიპოვე ასეთი დაშლა მარტივ გამყოფებად%)

შეცდომის მოხსენებაც კი არ იქნა ათვისებული

ვასილი, [20.06.18/20/18 5:XNUMX] ოჰ, არის ასევე MDXNUMX. უკვე სამი განსხვავებული ჰეშია

გასაღების თითის ანაბეჭდი გამოითვლება შემდეგნაირად:
digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)
SHA1 და sha2

ასე რომ დავაყენოთ auth_key 2048 ბიტი ზომით მივიღეთ დიფი-ჰელმანის მიხედვით. Რა არის შემდეგი? შემდეგ აღმოვაჩენთ, რომ ამ კლავიშის ქვედა 1024 ბიტი არანაირად არ გამოიყენება... მაგრამ ახლა ამაზე ვიფიქროთ. ამ ეტაპზე ჩვენ გვაქვს საერთო საიდუმლო სერვერთან. შეიქმნა TLS სესიის ანალოგი, ძალიან ძვირი პროცედურა. მაგრამ სერვერმა ჯერ არაფერი იცის იმის შესახებ, თუ ვინ ვართ ჩვენ! ჯერ არა, რეალურად ავტორიზაცია. იმათ. თუ ფიქრობდით „შესვლა-პაროლზე“, როგორც ეს ადრე იყო ICQ-ში, ან თუნდაც „შესვლის გასაღები“, როგორც SSH-ში (მაგალითად, ზოგიერთ gitlab / github-ზე). ანონიმური გავხდით. და თუ სერვერი გვპასუხობს "ამ ტელეფონის ნომრებს სხვა DC ემსახურება"? ან თუნდაც "თქვენი ტელეფონის ნომერი აკრძალულია"? ყველაზე კარგი, რაც შეგვიძლია გავაკეთოთ, არის გასაღების შენახვა იმ იმედით, რომ ის მაინც იქნება გამოსადეგი და არა დამპალი.

სხვათა შორის, დათქმით „მივიღეთ“. მაგალითად, ვენდობით სერვერს? ის ყალბია? ჩვენ გვჭირდება კრიპტოგრაფიული შემოწმება:

ვასილი, [21.06.18/17/53 2:XNUMX PM] ისინი სთავაზობენ მობილურ კლიენტებს შეამოწმონ XNUMX კბიტიანი ნომერი სიმარტივისთვის%)

მაგრამ სულაც არ არის გასაგები, ნაფეიხოა

ვასილი, [21.06.18/18/02 XNUMX:XNUMX] დოკი არ ამბობს რა უნდა გააკეთოს, თუ აღმოჩნდა, რომ ეს არ არის მარტივი

არ უთქვამს. ვნახოთ, რას აკეთებს ამ შემთხვევაში ანდროიდის ოფიციალური კლიენტი? ა ეს რა (და დიახ, აქ მთელი ფაილი საინტერესოა) - როგორც იტყვიან, უბრალოდ აქ დავტოვებ:

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

არა, რა თქმა უნდა იქ ზოგი არის რიცხვის სიმარტივის შემოწმებები, მაგრამ პირადად მე მათემატიკაში საკმარისი ცოდნა აღარ მაქვს.

კარგი, ჩვენ მივიღეთ მთავარი გასაღები. შესვლა, ე.ი. გაგზავნეთ მოთხოვნები, აუცილებელია შემდგომი დაშიფვრის შესრულება, უკვე AES-ის გამოყენებით.

შეტყობინების გასაღები განისაზღვრება, როგორც წერილის ტექსტის SHA128-ის 256 შუა ბიტი (სესიის, შეტყობინების ID და ა.შ. ჩათვლით), დამტენის ბაიტების ჩათვლით, რომლებიც ასახულია ავტორიზაციის გასაღებიდან აღებული 32 ბაიტით.

ვასილი, [22.06.18/14/08 XNUMX:XNUMX PM] საშუალო ძუები

მივიღე auth_key. ყველა. შემდგომ მათ... ნავსადგომებიდან არ ჩანს. თავისუფლად შეისწავლეთ ღია კოდის კოდი.

გაითვალისწინეთ, რომ MTProto 2.0 მოითხოვს 12-დან 1024 ბაიტამდე ჩასხმას, იმ პირობით, რომ მიღებული შეტყობინების სიგრძე იყოფა 16 ბაიტზე.

მაშ, რამდენი ბალიშის ჩასმა?

დიახ, აქაც 404 შეცდომის შემთხვევაში

თუ ვინმემ ყურადღებით შეისწავლა დიაგრამა და დოკუმენტაციის ტექსტი, მან შენიშნა, რომ იქ MAC არ არის. და რომ AES გამოიყენება ზოგიერთ IGE რეჟიმში, რომელიც სხვაგან არ გამოიყენება. ისინი, რა თქმა უნდა, წერენ ამის შესახებ FAQ-ში... აქ, მაგალითად, შეტყობინების გასაღები არის ამავე დროს გაშიფრული მონაცემების SHA ჰეში, რომელიც გამოიყენება მთლიანობის შესამოწმებლად - და შეუსაბამობის შემთხვევაში, დოკუმენტაცია რატომღაც გირჩევთ მათ ჩუმად იგნორირებას (მაგრამ რაც შეეხება უსაფრთხოებას, მოულოდნელად დაგვატეხეთ?).

მე არ ვარ კრიპტოგრაფი, შესაძლოა ამ რეჟიმში ამ შემთხვევაში თეორიული თვალსაზრისით არაფერია ცუდი. მაგრამ მე ნამდვილად შემიძლია დავასახელო პრაქტიკული პრობლემა, Telegram Desktop-ის მაგალითის გამოყენებით. ის შიფრავს ლოკალურ ქეშს (ყველა ეს D877F783D5D3EF8C) ისევე, როგორც შეტყობინებები MTProto-ში (მხოლოდ ამ შემთხვევაში, ვერსია 1.0), ე.ი. ჯერ შეტყობინების გასაღები, შემდეგ თავად მონაცემები (და სადღაც განზე მთავარი დიდი auth_key 256 ბაიტი, რომლის გარეშეც msg_key უსარგებლო). ასე რომ, პრობლემა შესამჩნევი ხდება დიდ ფაილებზე. კერძოდ, თქვენ უნდა შეინახოთ მონაცემების ორი ასლი - დაშიფრული და გაშიფრული. და თუ არის მეგაბაიტები, ან სტრიმინგის ვიდეო, მაგალითად? .. კლასიკური სქემები MAC-ით შიფრული ტექსტის შემდეგ გაძლევს საშუალებას წაიკითხო ის ნაკადი, დაუყოვნებლივ გადაიტანო. და MTProto-სთან ერთად უნდა თავდაპირველად დაშიფვრეთ ან გაშიფრეთ მთელი შეტყობინება, მხოლოდ ამის შემდეგ გადაიტანეთ იგი ქსელში ან დისკზე. ამიტომ, Telegram Desktop-ის უახლეს ვერსიებში ქეშში user_data სხვა ფორმატი უკვე გამოიყენება - AES-ით CTR რეჟიმში.

ვასილი, [21.06.18/01/27 20:XNUMX AM] ოჰ, მე გავარკვიე რა არის IGE: IGE იყო პირველი მცდელობა "დაშიფვრის ავთენტიფიკაციის რეჟიმისთვის", თავდაპირველად Kerberos-ისთვის. ეს იყო წარუმატებელი მცდელობა (ის არ უზრუნველყოფს მთლიანობის დაცვას) და უნდა მოიხსნას. ეს იყო XNUMX წლიანი ძიების დასაწყისი დაშიფვრის ავტორიზაციის რეჟიმისთვის, რომელიც მუშაობს, რომელიც ცოტა ხნის წინ კულმინაციას მიაღწია ისეთ რეჟიმებში, როგორიცაა OCB და GCM.

ახლა კი არგუმენტები კალათის მხრიდან:

Telegram-ის უკან მყოფი გუნდი, რომელსაც ნიკოლაი დუროვი ხელმძღვანელობს, შედგება ACM-ის ექვსი ჩემპიონისგან, რომელთაგან ნახევარი მათემატიკის დოქტორია. მათ დაახლოებით ორი წელი დასჭირდათ MTProto-ს ამჟამინდელი ვერსიის გამოსაყენებლად.

Რა არის სასაცილო. ორი წელი დაბალ დონეზე

ან შეგვიძლია უბრალოდ ავიღოთ ტლ

კარგი, ვთქვათ, ჩვენ გავაკეთეთ დაშიფვრა და სხვა ნიუანსი. შეგვიძლია საბოლოოდ გავგზავნოთ TL სერიული მოთხოვნები და მივიღოთ პასუხების დესერიალიზება? რა უნდა გაიგზავნოს და როგორ? აქ არის მეთოდი initConnectionიქნებ ეს არის?

Vasily, [25.06.18/18/46 XNUMX:XNUMX PM] ახდენს კავშირის ინიცირებას და შეინახავს ინფორმაციას მომხმარებლის მოწყობილობასა და აპლიკაციაში.

ის იღებს app_id, device_model, system_version, app_version და lang_code.

და გარკვეული შეკითხვა

დოკუმენტაცია, როგორც ყოველთვის. თავისუფლად შეისწავლეთ ღია წყარო

თუ ყველაფერი უხეშად ნათელი იყო invokeWithLayer-ით, მაშინ რა არის ეს? გამოდის, რომ დავუშვათ, ჩვენ გვაქვს - კლიენტს უკვე ჰქონდა სერვერისთვის სათხოვარი - არის მოთხოვნა, რომლის გაგზავნაც გვინდოდა:

ვასილი, [25.06.18/19/13 XNUMX:XNUMX] კოდით თუ ვიმსჯელებთ, პირველი ზარი ამ ნაგავშია გახვეული და თავად ნაგავი არის invokewithlayer-ში.

რატომ არ შეიძლება initConnection იყოს ცალკე ზარი, მაგრამ უნდა იყოს შეფუთვა? დიახ, როგორც აღმოჩნდა, ეს უნდა გაკეთდეს ყოველ ჯერზე ყოველი სესიის დასაწყისში და არა ერთჯერადი, როგორც მთავარი გასაღებით. მაგრამ! მას არ შეუძლია დაურეკოს არაავტორიზებული მომხმარებელი! აქ ჩვენ მივედით იმ ეტაპამდე, რომელშიც ის გამოიყენება ეს ერთი დოკუმენტაციის გვერდი - და ის გვეუბნება, რომ ...

API მეთოდების მხოლოდ მცირე ნაწილია ხელმისაწვდომი არაავტორიზებული მომხმარებლებისთვის:

auth.sendCode
auth.resendCode
account.getPassword
auth.checkPassword
auth.checkPhone
auth.signUp
auth.signIn
ავტორიზაცია.import ავტორიზაცია
help.getConfig
help.getNearestDc
help.getAppUpdate
help.getCdnConfig
langpack.getLangPack
langpack.getStrings
langpack.getDifference
langpack.getLanguages
langpack.getLanguage

პირველი მათგანი auth.sendCode, და არის ის ძვირფასი პირველი მოთხოვნა, რომელშიც გამოგიგზავნით api_id და api_hash და რის შემდეგაც ვიღებთ SMS-ს კოდით. და თუ არასწორ DC-ზე მივედით (ამ ქვეყნის ტელეფონის ნომრებს ემსახურება სხვა, მაგალითად), მაშინ მივიღებთ შეცდომას სასურველი DC-ის ნომრით. იმის გასარკვევად, რომელ IP მისამართს უნდა დავუკავშირდეთ DC ნომრით, დაგვეხმარება help.getConfig. ერთხელ იყო მხოლოდ 5 ჩანაწერი, მაგრამ 2018 წლის ცნობილი მოვლენების შემდეგ რაოდენობა საგრძნობლად გაიზარდა.

ახლა გავიხსენოთ, რომ ამ ეტაპზე მივიღეთ ანონიმური სერვერი. ძალიან ძვირი არ არის მხოლოდ IP მისამართის მიღება? რატომ არ უნდა გააკეთოთ ეს და სხვა ოპერაციები MTProto-ს დაშიფრულ ნაწილში? მესმის პროტესტი: "როგორ შეგიძლიათ დარწმუნდეთ, რომ ეს არ არის RKN, რომელიც უპასუხებს ყალბი მისამართებით?". ამასთან, შეგახსენებთ, რომ, ფაქტობრივად, ოფიციალურ კლიენტებში ჩაშენებული RSA გასაღებები, ე.ი. შეგიძლია უბრალოდ ნიშანი ეს ინფორმაცია. სინამდვილეში, ეს უკვე კეთდება საკეტების გვერდის ავლით ინფორმაციისთვის, რომლებსაც კლიენტები იღებენ სხვა არხებით (ლოგიკურია, რომ ეს არ შეიძლება გაკეთდეს თავად MTProto-ში, რადგან თქვენ ჯერ კიდევ უნდა იცოდეთ სად დაუკავშირდეთ).

ᲙᲐᲠᲒᲘ. კლიენტის ავტორიზაციის ამ ეტაპზე ჩვენ ჯერ არ ვართ ავტორიზებული და არ დაგვირეგისტრირდა ჩვენი განაცხადი. ჩვენ მხოლოდ ახლა გვინდა ვნახოთ, რას პასუხობს სერვერი არაავტორიზებული მომხმარებლისთვის ხელმისაწვდომ მეთოდებზე. Და აქ…

ვასილი, [10.07.18 14:45] https://core.telegram.org/method/help.getConfig
config#7dae33e0 [...] = Config;
help.getConfig#c4f9186b = Config;
https://core.telegram.org/api/datacenter
config#232d5905 [...] = Config;
help.getConfig#c4f9186b = Config;
სქემაში მოდის პირველი, მეორე

tdesktop სქემაში მესამე მნიშვნელობა არის

დიახ, მას შემდეგ, რა თქმა უნდა, დოკუმენტაცია განახლდა. თუმცა მალე ის შეიძლება ისევ შეუსაბამო გახდეს. და როგორ უნდა იცოდეს ახალბედა დეველოპერმა? იქნებ განაცხადი რომ დარეგისტრირდე, შეგატყობინონ? ვასილიმ ეს გააკეთა, მაგრამ სამწუხაროდ, მას არაფერი გაუგზავნეს (კიდევ ერთხელ, ამაზე მეორე ნაწილში ვისაუბრებთ).

... თქვენ შენიშნეთ, რომ ჩვენ უკვე როგორღაც გადავედით API-ზე, ე.ი. შემდეგ დონეზე გადახვედით და რამე გამოგრჩათ MTProto თემაში? გასაკვირი არაფერია:

ვასილი, [28.06.18/02/04 2:XNUMX AM] მმ, ისინი ათვალიერებენ ზოგიერთ ალგორითმს eXNUMXe-ზე

Mtproto განსაზღვრავს დაშიფვრის ალგორითმებს და გასაღებებს ორივე დომენისთვის, ისევე როგორც ცოტა შეფუთვის სტრუქტურას

მაგრამ ისინი მუდმივად ურევენ სტეკის სხვადასხვა დონეებს, ამიტომ ყოველთვის არ არის ნათელი, სად დასრულდა mtproto და დაიწყო შემდეგი დონე.

როგორ არის შერეული? მაგალითად, აქ არის იგივე დროებითი გასაღები PFS-სთვის (სხვათა შორის, Telegram Desktop-მა არ იცის როგორ გააკეთოს ეს). ის შესრულებულია API მოთხოვნით auth.bindTempAuthKey, ე.ი. უმაღლესი დონიდან. მაგრამ ამავდროულად, ის ხელს უშლის დაშიფვრას ქვედა დონეზე - ამის შემდეგ, მაგალითად, თქვენ კვლავ უნდა გააკეთოთ ეს initConnection და ა.შ., ეს არ არის უბრალოდ ნორმალური მოთხოვნა. ცალკე, ის ასევე გვაწვდის იმას, რომ თქვენ შეგიძლიათ გქონდეთ მხოლოდ ერთი დროებითი გასაღები DC-ზე, თუმცა ველი auth_key_id თითოეულ შეტყობინებაში საშუალებას გაძლევთ შეცვალოთ გასაღები მინიმუმ ყველა შეტყობინებაში, და რომ სერვერს აქვს უფლება ნებისმიერ დროს „დაივიწყოს“ დროებითი გასაღები - რა უნდა გააკეთოს ამ შემთხვევაში, დოკუმენტაციაში არ არის ნათქვამი ... კარგი, რატომ შეუძლებელი იქნება რამდენიმე გასაღების ქონა, როგორც სამომავლო მარილების კომპლექტში, მაგრამ ?..

არის რამდენიმე სხვა რამ, რაც უნდა აღინიშნოს MTProto თემაში.

შეტყობინებების გაგზავნა, msg_id, msg_seqno, აღიარება, პინგები არასწორი მიმართულებით და სხვა თავისებურებები

რატომ უნდა იცოდე მათ შესახებ? იმის გამო, რომ ისინი "გაჟონავს" ერთი საფეხურით მაღლა და თქვენ უნდა იცოდეთ მათ შესახებ API-სთან მუშაობისას. დავუშვათ, ჩვენ არ გვაინტერესებს msg_key, ქვედა დონემ გაშიფრა ყველაფერი ჩვენთვის. მაგრამ გაშიფრული მონაცემების შიგნით, ჩვენ გვაქვს შემდეგი ველები (ასევე მონაცემების სიგრძე, რათა ვიცოდეთ სად არის ჩასმა, მაგრამ ეს არ არის მნიშვნელოვანი):

salt-int64
session_id - int64
message_id - int64
seq_no-int32

შეგახსენებთ, რომ მარილი არის ერთი მთელი DC. რატომ იცი ამის შესახებ? არა მხოლოდ იმიტომ, რომ არის მოთხოვნა get_future_salts, რომელიც გვეუბნება, რომელი ინტერვალები იქნება მართებული, არამედ იმიტომ, რომ თუ თქვენი მარილი „დამპალია“, მაშინ შეტყობინება (მოთხოვნა) უბრალოდ დაიკარგება. სერვერი, რა თქმა უნდა, მოახსენებს ახალ მარილს გაცემით new_session_created - ოღონდ ძველთან მოგიწევს როგორმე გადაგზავნა მაგ. და ეს კითხვა გავლენას ახდენს აპლიკაციის არქიტექტურაზე.

სერვერს უფლება აქვს, საერთოდ ჩამოაგდოს სესიები და უპასუხოს ამ გზით მრავალი მიზეზის გამო. სინამდვილეში, რა არის MTProto სესია კლიენტის მხრიდან? ეს ორი ციფრია session_id и seq_no შეტყობინებები ამ სესიის ფარგლებში. რა თქმა უნდა, და ძირითადი TCP კავშირი. ვთქვათ, ჩვენმა კლიენტმა ჯერ კიდევ არ იცის ბევრი რამის გაკეთება, გათიშული, ხელახლა დაკავშირება. თუ ეს მოხდა სწრაფად - ძველი სესია გაგრძელდა ახალ TCP კავშირში, გაზარდეთ seq_no უფრო. თუ ამას დიდი დრო დასჭირდა, სერვერმა შეიძლება წაშალოს იგი, რადგან მის მხარესაც არის რიგი, როგორც გავარკვიეთ.

რა უნდა იყოს seq_no? ოჰ, ეს რთული კითხვაა. შეეცადეთ გულწრფელად გაიგოთ რას გულისხმობდა:

შინაარსის შესახებ შეტყობინება

შეტყობინება, რომელიც მოითხოვს აშკარა აღიარებას. ეს მოიცავს მომხმარებლის ყველა და ბევრ სერვისულ შეტყობინებას, პრაქტიკულად ყველა კონტეინერებისა და მადლობის გარდა.

შეტყობინების თანმიმდევრობის ნომერი (msg_seqno)

32-ბიტიანი რიცხვი, რომელიც უდრის „შინაარსთან დაკავშირებული“ შეტყობინებების ორჯერ რაოდენობას (ისინი, რომლებიც საჭიროებენ აღიარებას, და განსაკუთრებით ის, რომელიც არ არის კონტეინერები), რომელიც შექმნილია გამგზავნის მიერ ამ შეტყობინებამდე და შემდგომ გაზრდილი ერთით, თუ მიმდინარე შეტყობინება არის შინაარსთან დაკავშირებული შეტყობინება. კონტეინერი ყოველთვის იქმნება მისი მთელი შიგთავსის შემდეგ; შესაბამისად, მისი რიგითი ნომერი მეტია ან ტოლია მასში შემავალი შეტყობინებების მიმდევრობით რიცხვებზე.

რა სახის ცირკია ეს 1-ის ნამატით და შემდეგ კიდევ 2-ით? .. მეეჭვება, რომ თავდაპირველი მნიშვნელობა იყო "დაბალი ბიტი ACK-ისთვის, დანარჩენი რიცხვია", მაგრამ შედეგი არ არის მთლად სწორი - კერძოდ, გამოდის, რომ მისი გაგზავნა შესაძლებელია ზოგიერთი დადასტურებები, რომლებსაც აქვთ იგივე seq_no! Როგორ? მაგალითად, სერვერი გვიგზავნის რაღაცას, გვიგზავნის და ჩვენ თვითონ ვჩუმდებით, მხოლოდ სერვისის დამადასტურებელი შეტყობინებებით ვპასუხობთ მისი შეტყობინებების მიღების შესახებ. ამ შემთხვევაში, ჩვენს გამავალ დადასტურებებს ექნება იგივე გამავალი ნომერი. თუ იცნობთ TCP-ს და ფიქრობთ, რომ ეს გიჟურად ჟღერს, მაგრამ, როგორც ჩანს, არც ისე ველურია, რადგან TCP-ში seq_no არ იცვლება და დადასტურება მიდის seq_no მეორე მხარე - მერე მეჩქარება გაბრაზება. დადასტურებები მოდის MTProto-ში არ on seq_no, როგორც TCP-ში, მაგრამ msg_id !

Ეს რა არის msg_id, ამ სფეროებიდან ყველაზე მნიშვნელოვანი? შეტყობინების უნიკალური ID, როგორც სახელი გულისხმობს. იგი განისაზღვრება, როგორც 64-ბიტიანი რიცხვი, რომელთაგან ყველაზე ნაკლებად მნიშვნელოვან ბიტებს კვლავ აქვს სერვერის არა სერვერის მაგია, ხოლო დანარჩენი არის Unix-ის დროის შტამპი, ფრაქციული ნაწილის ჩათვლით, გადატანილი 32 ბიტით მარცხნივ. იმათ. დროის შტამპი თავისთავად (და ძალიან განსხვავებული დროის შეტყობინებები უარყოფილი იქნება სერვერის მიერ). აქედან გამოდის, რომ ზოგადად, ეს არის კლიენტისთვის გლობალური იდენტიფიკატორი. ხოლო - გახსოვდეთ session_id - გარანტირებული გვაქვს: არავითარ შემთხვევაში არ შეიძლება ერთი სესიისთვის განკუთვნილი შეტყობინების გაგზავნა სხვა სესიაზე. ანუ გამოდის, რომ უკვე არსებობს სამ დონე — სესია, სესიის ნომერი, შეტყობინების ID. რატომ არის ასეთი ზედმეტი გართულება, ეს საიდუმლო ძალიან დიდია.

აქედან გამომდინარე, msg_id საჭიროა…

RPC: მოთხოვნები, პასუხები, შეცდომები. დადასტურებები.

როგორც თქვენ შენიშნეთ, სქემაში არსად არ არის სპეციალური ტიპი ან ფუნქცია "გააკეთე RPC მოთხოვნა", თუმცა არის პასუხები. ბოლოს და ბოლოს, ჩვენ გვაქვს შინაარსთან დაკავშირებული შეტყობინებები! ანუ ნებისმიერი შეტყობინება შეიძლება იყოს მოთხოვნა! ან არ იყოს. Ყველაფრის შემდეგ, თითოეულ არსებობს msg_id. და აი პასუხები:

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

ეს არის სადაც მითითებულია, რომელ შეტყობინებაზეა ეს პასუხი. ამიტომ, API-ს უმაღლეს დონეზე, მოგიწევთ გახსოვდეთ, რა ნომერი ჰქონდა თქვენს მოთხოვნას - ვფიქრობ, არ არის საჭირო იმის ახსნა, რომ სამუშაო ასინქრონულია და შეიძლება იყოს რამდენიმე მოთხოვნა ერთდროულად, რომლებზეც პასუხები შეიძლება დაბრუნდეს ნებისმიერი თანმიმდევრობით? პრინციპში, აქედან და შეცდომის შეტყობინებებიდან, როგორიცაა მუშა არ არის, ამის მიღმა არსებული არქიტექტურის კვალი შეიძლება გამოიკვეთოს: სერვერი, რომელიც ინარჩუნებს TCP კავშირს თქვენთან არის წინა ბალანსერი, ის მიმართავს მოთხოვნებს backend-ებზე და აგროვებს მათ უკან. message_id. აქ ყველაფერი ნათელია, ლოგიკური და კარგია.

კი?.. და თუ ფიქრობ? ყოველივე ამის შემდეგ, თავად RPC პასუხსაც აქვს ველი msg_id! უნდა ვუყვიროთ სერვერს „თქვენ არ პასუხობთ ჩემს პასუხს!“? დიახ, რა იყო დადასტურება? გვერდის შესახებ შეტყობინებები შეტყობინებების შესახებ გვეუბნება რა არის

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

და თითოეულმა მხარემ უნდა გააკეთოს ეს. მაგრამ არა ყოველთვის! თუ თქვენ მიიღებთ RpcResult-ს, ის თავისთავად ემსახურება როგორც აღიარებას. ანუ, სერვერს შეუძლია უპასუხოს თქვენს მოთხოვნას MsgsAck-ით - მაგალითად, "მე მივიღე". შეუძლია დაუყოვნებლივ უპასუხოს RpcResult-ს. ეს შეიძლება იყოს ორივე.

და დიახ, თქვენ ჯერ კიდევ უნდა უპასუხოთ პასუხს! Დადასტურება. წინააღმდეგ შემთხვევაში, სერვერი ჩათვლის მას მიუწოდებლად და კვლავ გადმოგდებს თქვენთან. ხელახალი დაკავშირების შემდეგაც კი. მაგრამ აქ, რასაკვირველია, დადგება თაიმაუტების საკითხი. მოდით შევხედოთ მათ ცოტა მოგვიანებით.

იმავდროულად, მოდით განვიხილოთ შესაძლო შეცდომები შეკითხვის შესრულებისას.

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

ოჰ, ვინმემ გაიძახოს, აი, უფრო ადამიანური ფორმატი - არის ხაზი! მიიღეთ დრო. Აქ შეცდომების სიამაგრამ რა თქმა უნდა არ არის სრული. მისგან ვიგებთ, რომ კოდი არის − რაღაც მსგავსი HTTP შეცდომები (კარგად, რა თქმა უნდა, პასუხების სემანტიკა არ არის დაცული, ზოგან ისინი ნაწილდება კოდებით შემთხვევით) და სტრიქონი ასე გამოიყურება CAPITAL_LETTERS_AND_NUMBERS. მაგალითად, PHONE_NUMBER_OCCUPIED ან FILE_PART_X_MISSING. ანუ, თქვენ ჯერ კიდევ გაქვთ ამ ხაზში გაანალიზება. მაგალითად, FLOOD_WAIT_3600 ნიშნავს, რომ ერთი საათი უნდა დაელოდო და PHONE_MIGRATE_5რომ ამ პრეფიქსით ტელეფონის ნომერი უნდა დარეგისტრირდეს მე-5 დკ. ჩვენ გვაქვს ტიპის ენა, არა? ჩვენ არ გვჭირდება არგუმენტი სტრიქონიდან, რეგულარული გამონათქვამები იქნება, cho.

კიდევ ერთხელ, ეს არ არის სერვისის შეტყობინებების გვერდზე, მაგრამ, როგორც ეს უკვე ჩვეულია ამ პროექტთან დაკავშირებით, შეგიძლიათ იპოვოთ ინფორმაცია სხვა დოკუმენტაციის გვერდზე. ან ეჭვს იწვევს. ჯერ ნახე, აკრეფის/ფენების დარღვევა - RpcError შეიძლება ინვესტიცია RpcResult. რატომ არა გარეთ? რა არ გავითვალისწინეთ?.. შესაბამისად სად არის იმის გარანტია RpcError არ შეიძლება ინვესტიცია RpcResult, მაგრამ პირდაპირ იყოს თუ სხვა ტიპში ჩასმული? აკლია req_msg_id ? ..

მაგრამ მოდით გავაგრძელოთ სერვისის შეტყობინებების შესახებ. კლიენტმა შეიძლება ჩათვალოს, რომ სერვერი დიდი ხნის განმავლობაში ფიქრობს და ასეთი მშვენიერი მოთხოვნა გააკეთოს:

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

მასზე სამი შესაძლო პასუხია, რომლებიც კვლავ იკვეთება დადასტურების მექანიზმთან, რათა შევეცადოთ გავიგოთ, რა უნდა იყოს ისინი (და რა არის იმ ტიპების სია, რომლებიც ზოგადად არ საჭიროებს დადასტურებას), მკითხველი რჩება საშინაო დავალებად (შენიშვნა: ინფორმაცია Telegram Desktop-ის წყაროებში არ არის სრული).

დამოკიდებულება: შეტყობინებების პოსტის სტატუსები

ზოგადად, TL, MTProto და ზოგადად Telegram-ში ბევრი ადგილი ტოვებს სიჯიუტის განცდას, მაგრამ ზრდილობის, ტაქტის და სხვა რბილი უნარები ჩვენ თავაზიანად ვდუმდით ამის შესახებ და დიალოგებში უხამსობა ცენზურას ახდენდა. თუმცა, ეს ადგილიОგვერდის უმეტესი ნაწილის შესახებ შეტყობინებები შეტყობინებების შესახებ შოკს იწვევს ჩემთვისაც კი, რომელიც დიდი ხანია ვმუშაობ ქსელის პროტოკოლებით და მინახავს სხვადასხვა ხარისხის გამრუდების ველოსიპედები.

იწყება უვნებლად, დადასტურებებით. შემდეგი, ჩვენ გვეუბნებიან

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

ისე, ყველას, ვინც იწყებს მუშაობას MTProto-სთან, მოუწევს მათთან შეხვედრა, "შესწორებული - ხელახლა შედგენილი - გაშვებული" ციკლში, რიცხვების შეცდომის მიღება ან რედაქტირების დროს დამპალი მარილის მიღება ჩვეულებრივი რამ არის. თუმცა, აქ არის ორი წერტილი:

აქედან გამომდინარეობს, რომ ორიგინალური შეტყობინება დაკარგულია. ჩვენ გვჭირდება რიგის შემოღობვა, ამას მოგვიანებით განვიხილავთ.
რა არის ეს უცნაური შეცდომის ნომრები? 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 64... სად არის დანარჩენი რიცხვები, ტომი?

დოკუმენტაციაში ნათქვამია:

მიზანია, რომ error_code მნიშვნელობები დაჯგუფდეს (error_code >> 4): მაგალითად, კოდები 0x40 - 0x4f შეესაბამება შეცდომებს კონტეინერის დაშლისას.

მაგრამ, ჯერ ერთი, ცვლა სხვა მიმართულებით და მეორეც, არ აქვს მნიშვნელობა სად არის დანარჩენი კოდები? ავტორის თავში?.. თუმცა ეს წვრილმანებია.

დამოკიდებულება იწყება პოსტის სტატუსის შეტყობინებებში და პოსტის ასლებში:

შეტყობინების სტატუსის ინფორმაციის მოთხოვნა
თუ რომელიმე მხარეს არ მიუღია ინფორმაცია მისი გამავალი შეტყობინებების სტატუსის შესახებ გარკვეული პერიოდის განმავლობაში, მას შეუძლია ცალსახად მოითხოვოს ეს მეორე მხარისგან:
msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;
საინფორმაციო შეტყობინება შეტყობინებების სტატუსის შესახებ
msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;
აქ, info არის სტრიქონი, რომელიც შეიცავს შეტყობინებების სტატუსს ზუსტად ერთ ბაიტს თითოეული შეტყობინებისთვის შემომავალი msg_ids სიიდან:
- 1 = არაფერია ცნობილი შეტყობინების შესახებ (msg_id ძალიან დაბალია, მეორე მხარეს შეიძლება დაავიწყდა)
- 2 = შეტყობინება არ არის მიღებული (msg_id შედის შენახული იდენტიფიკატორების დიაპაზონში; თუმცა, მეორე მხარეს ნამდვილად არ მიუღია მსგავსი შეტყობინება)
- 3 = შეტყობინება არ არის მიღებული (msg_id ძალიან მაღალია; თუმცა, მეორე მხარეს, რა თქმა უნდა, ჯერ არ მიუღია)
- 4 = მიღებული შეტყობინება (გაითვალისწინეთ, რომ ეს პასუხი ასევე არის ქვითრის დადასტურება)
- +8 = შეტყობინება უკვე აღიარებულია
- +16 = შეტყობინება, რომელიც არ საჭიროებს აღიარებას
- +32 = RPC მოთხოვნა, რომელიც შეიცავს შეტყობინებას, რომელიც დამუშავებულია ან დამუშავება უკვე დასრულებულია
- +64 = შინაარსთან დაკავშირებული პასუხი უკვე გენერირებულ შეტყობინებაზე
- +128 = მეორე მხარემ იცის, რომ შეტყობინება უკვე მიღებულია
  ეს პასუხი არ საჭიროებს აღიარებას. ეს არის შესაბამისი msgs_state_req, თავისთავად დადასტურება.
  გაითვალისწინეთ, რომ თუ მოულოდნელად აღმოჩნდება, რომ მეორე მხარეს არ აქვს შეტყობინება, თითქოს მას გაუგზავნა, შეტყობინება შეიძლება უბრალოდ ხელახლა გაიგზავნოს. მაშინაც კი, თუ მეორე მხარემ უნდა მიიღოს შეტყობინების ორი ასლი ერთდროულად, დუბლიკატი იგნორირებული იქნება. (თუ ძალიან დიდი დრო გავიდა და ორიგინალური msg_id აღარ არის მოქმედი, შეტყობინება უნდა შეიფუთოს msg_copy-ში).
შეტყობინებების სტატუსის ნებაყოფლობითი კომუნიკაცია
ნებისმიერ მხარეს შეუძლია ნებაყოფლობით აცნობოს მეორე მხარეს მეორე მხარის მიერ გადაცემული შეტყობინებების სტატუსის შესახებ.
msgs_all_info#8cc0d131 msg_ids:Vector long info:string = MsgsAllInfo
ერთი შეტყობინების სტატუსის გაფართოებული ნებაყოფლობითი კომუნიკაცია
...
msg_detailed_info#276d3ec6 msg_id:long answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
msg_new_detailed_info#809db6df answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
აშკარა მოთხოვნა შეტყობინებების ხელახლა გაგზავნის შესახებ
msg_resend_req#7d861a08 msg_ids:Vector long = MsgResendReq;
დისტანციური მხარე დაუყოვნებლივ პასუხობს მოთხოვნილი შეტყობინებების ხელახლა გაგზავნით […]
აშკარა მოთხოვნა პასუხების ხელახლა გაგზავნის შესახებ
msg_resend_ans_req#8610baeb msg_ids:Vector long = MsgResendReq;
დისტანციური მხარე დაუყოვნებლივ პასუხობს ხელახლა გაგზავნით პასუხი მოთხოვნილ შეტყობინებებზე […]
შეტყობინების ასლები
ზოგიერთ შემთხვევაში, ძველი შეტყობინება msg_id-ით, რომელიც აღარ არის მოქმედი, ხელახლა უნდა გაიგზავნოს. შემდეგ, იგი შეფუთულია ასლის კონტეინერში:
msg_copy#e06046b2 orig_message:Message = MessageCopy;
მიღების შემდეგ, შეტყობინება მუშავდება ისე, თითქოს შეფუთვა იქ არ იყოს. თუმცა, თუ დანამდვილებით ცნობილია, რომ შეტყობინება orig_message.msg_id იქნა მიღებული, მაშინ ახალი შეტყობინება არ მუშავდება (ამავდროულად, ის და orig_message.msg_id აღიარებულია). orig_message.msg_id-ის მნიშვნელობა კონტეინერის msg_id-ზე დაბალი უნდა იყოს.

მოდით გავჩუმდეთ კიდეც იმ ფაქტზე, რომ ქ msgs_state_info ისევ დაუმთავრებელი TL-ის ყურები გამოდის (დაგვჭირდა ბაიტების ვექტორი, ქვედა ორ ბიტში enum, ხოლო ძველ ბიტებში დროშები). საქმე სხვა რამეშია. ვინმეს ესმის რატომ არის ეს ყველაფერი პრაქტიკაში რეალურ კლიენტში აუცილებელია?.. გაჭირვებით, მაგრამ თქვენ წარმოიდგინეთ რაიმე სარგებელი, თუ ადამიანი დაკავებულია გამართვით და ინტერაქტიულ რეჟიმში - ჰკითხეთ სერვერს რა და როგორ. მაგრამ მოთხოვნები აქ არის აღწერილი ორმხრივი მგზავრობა.

აქედან გამომდინარეობს, რომ თითოეულმა მხარემ არა მხოლოდ უნდა დაშიფროს და გაგზავნოს შეტყობინებები, არამედ შეინახოს მონაცემები მათ შესახებ, მათზე პასუხების შესახებ და გაურკვეველი დროით. დოკუმენტაცია არ აღწერს ამ მახასიათებლების ვადებს ან პრაქტიკულ გამოყენებადობას. არავითარ შემთხვევაში არ. ყველაზე გასაკვირი ის არის, რომ ისინი რეალურად გამოიყენება ოფიციალური კლიენტების კოდში! როგორც ჩანს, მათ უთხრეს რაღაც, რაც არ იყო ღია დოკუმენტაციაში. გაიგე კოდიდან რატომ, აღარ არის ისეთი მარტივი, როგორც TL-ის შემთხვევაში - ეს არ არის (შედარებით) ლოგიკურად იზოლირებული ნაწილი, არამედ აპლიკაციის არქიტექტურასთან მიბმული ნაწილი, ე.ი. გაცილებით მეტი დრო დასჭირდება განაცხადის კოდის გასაგებად.

პინგები და ტაიმინგი. რიგები.

ყველაფრისგან, თუ თქვენ გახსოვთ ვარაუდები სერვერის არქიტექტურის შესახებ (მოთხოვნების განაწილება ბექენდებში), საკმაოდ მოსაწყენი რამ მოჰყვება - მიუხედავად მიწოდების ყველა გარანტიისა, რომელიც TCP-ში (ან მონაცემები მოწოდებულია, ან თქვენ შეგატყობინებთ შესვენება, მაგრამ მონაცემები გადაეცემა პრობლემის მომენტამდე), რომ დადასტურებები თავად MTProto-ში - არანაირი გარანტია. სერვერს შეუძლია ადვილად დაკარგოს ან გადააგდოს თქვენი მესიჯი და არაფრის გაკეთება არ შეიძლება, მხოლოდ სხვადასხვა ტიპის ყავარჯნების შემოღობვა.

და პირველ რიგში - შეტყობინებების რიგები. ჰოდა, ერთი რამ თავიდანვე აშკარა იყო ყველაფერი - დაუდასტურებელი შეტყობინება უნდა შენახულიყო და გააგზავნო. და რა დროის შემდეგ? და ჟინერი იცნობს მას. შესაძლოა, ამ ნარკომანთა სერვისის შეტყობინებებმა როგორმე გადაჭრას ეს პრობლემა ყავარჯნებით, ვთქვათ, Telegram Desktop-ში არის მათთან დაახლოებით 4 რიგი (შეიძლება მეტი, როგორც უკვე აღვნიშნეთ, ამისათვის საჭიროა უფრო სერიოზულად ჩახედოთ მის კოდს და არქიტექტურას; ამავდროულად. ჩვენ ვიცით, რომ მისი ნიმუშად აღება შეუძლებელია, MTProto სქემიდან გარკვეული რაოდენობის ტიპები მასში არ არის გამოყენებული).

Რატომ ხდება ეს? ალბათ, სერვერის პროგრამისტებმა ვერ უზრუნველყოფდნენ კლასტერში საიმედოობას, ან თუნდაც წინა ბალანსერზე ბუფერირებას და ეს პრობლემა კლიენტზე გადაიტანეს. სასოწარკვეთილების გამო, ვასილი ცდილობდა ალტერნატიული ვარიანტის განხორციელებას, მხოლოდ ორი რიგებით, TCP-დან ალგორითმების გამოყენებით - გაზომა RTT სერვერზე და შეცვალა "ფანჯრის" ზომა (შეტყობინებებში) დაუდასტურებელი მოთხოვნების რაოდენობის მიხედვით. ანუ ასეთი უხეში ევრისტიკა სერვერის დატვირთვის შესაფასებლად - რამდენი ჩვენი მოთხოვნა შეიძლება დაღეჭოს ერთდროულად და არ დაკარგოს.

ანუ, გესმის, არა? თუ კვლავ მოგიწევთ TCP დანერგვა პროტოკოლის თავზე, რომელიც მუშაობს TCP-ზე, ეს მიუთითებს ძალიან ცუდად შემუშავებულ პროტოკოლზე.

დიახ, რატომ არის საჭირო ერთზე მეტი რიგი და ზოგადად, რას ნიშნავს ეს მაღალი დონის API-ით მომუშავე ადამიანისთვის? აჰა, თხოვნას უყენებ, სერიულობ, მაგრამ მისი დაუყოვნებლივ გაგზავნა ხშირად შეუძლებელია. რატომ? რადგან პასუხი იქნება msg_id, რომელიც დროებითიაаმე ვარ ლეიბლი, რომლის დანიშვნა ჯობია რაც შეიძლება გვიან გადავდოთ - უცებ სერვერი უარს იტყვის მას შორის დროის შეუსაბამობის გამო (რა თქმა უნდა, ჩვენ შეგვიძლია გავაკეთოთ ყავარჯენი, რომელიც ჩვენს დროს აწმყოს გადააქვს. სერვერის დროს სერვერის პასუხებიდან გამოთვლილი დელტას დამატებით - ამას აკეთებენ ოფიციალური კლიენტები, მაგრამ ეს მეთოდი უხეში და არაზუსტია ბუფერირების გამო). ასე რომ, როდესაც თქვენ ითხოვთ ლოკალური ფუნქციის გამოძახებით ბიბლიოთეკიდან, შეტყობინება გადის შემდეგ ეტაპებს:

წევს იმავე რიგში და ელოდება დაშიფვრას.
დაინიშნა msg_id და შეტყობინება წავიდა სხვა რიგში - შესაძლო გადამისამართება; გაგზავნა სოკეტში.
ა) სერვერმა უპასუხა MsgsAck - შეტყობინება მიწოდებულია, ჩვენ მას ვშლით "სხვა რიგიდან".
ბ) ან პირიქით, რაღაც არ მოეწონა, უპასუხა badmsg - ჩვენ ხელახლა ვაგზავნით "სხვა რიგიდან"
გ) არაფერია ცნობილი, აუცილებელია შეტყობინების ხელახლა გაგზავნა სხვა რიგიდან - მაგრამ ზუსტად არ არის ცნობილი როდის.
ბოლოს უპასუხა სერვერმა RpcResult - ფაქტობრივი პასუხი (ან შეცდომა) - არა მხოლოდ მიწოდებული, არამედ დამუშავებული.

ალბათ, კონტეინერების გამოყენებამ შეიძლება ნაწილობრივ გადაჭრას პრობლემა. ეს ხდება მაშინ, როდესაც შეტყობინებების თაიგული იკვრება ერთში და სერვერმა უპასუხა ყველას ერთბაშად აღიარებით, ერთით. msg_id. მაგრამ ის ასევე უარს იტყვის ამ შეფუთვაზე, თუ რამე არასწორედ წარიმართა, ასევე მთლიანად.

და ამ ეტაპზე, არატექნიკური მოსაზრებები მოქმედებს. გამოცდილებიდან ბევრი ყავარჯნები გვინახავს და გარდა ამისა, ახლა კიდევ ვიხილავთ ცუდი რჩევისა და არქიტექტურის მაგალითებს - ასეთ პირობებში ღირს ნდობა და ასეთი გადაწყვეტილებების მიღება? კითხვა რიტორიკულია (რა თქმა უნდა არა).

რაზე ვსაუბრობთ? თუ თემაზე "დამოკიდებულების შეტყობინებები შეტყობინებების შესახებ" თქვენ მაინც შეგიძლიათ სპეკულირება გამოთქვათ წინააღმდეგობებით, როგორიცაა "შენ სულელი ხარ, შენ ვერ გაიგე ჩვენი ბრწყინვალე იდეა!" (ასე რომ ჯერ დაწერეთ დოკუმენტაცია, როგორც ნორმალურმა ადამიანებმა უნდა, დასაბუთებითა და პაკეტების გაცვლის მაგალითებით, მერე ვილაპარაკოთ), მერე ვადები/ტაიმაუტები წმინდა პრაქტიკული და კონკრეტული საკითხია, აქ ყველაფერი დიდი ხანია ცნობილია. მაგრამ რას გვეუბნება დოკუმენტაცია ტაიმაუტების შესახებ?

სერვერი ჩვეულებრივ ადასტურებს შეტყობინების მიღებას კლიენტისგან (ჩვეულებრივ, RPC მოთხოვნა) RPC პასუხის გამოყენებით. თუ პასუხი დიდი ხნის განმავლობაში მოდის, სერვერმა შეიძლება ჯერ გაგზავნოს ქვითრის დადასტურება, მოგვიანებით კი თავად RPC პასუხი.

კლიენტი ჩვეულებრივ ადასტურებს შეტყობინების მიღებას სერვერიდან (ჩვეულებრივ, RPC პასუხი) შემდეგ RPC მოთხოვნაზე დასტურის დამატებით, თუ ის ძალიან გვიან არ არის გადაცემული (თუ ის გენერირებულია, ვთქვათ, მიღებიდან 60-120 წამში. მესიჯი სერვერიდან). თუმცა, თუ დიდი ხნის განმავლობაში არ არსებობს მიზეზი, რომ გაგზავნოთ შეტყობინებები სერვერზე, ან თუ არის დიდი რაოდენობით არაღიარებული შეტყობინებები სერვერიდან (ვთქვათ, 16-ზე მეტი), კლიენტი გადასცემს დამოუკიდებელ აღიარებას.

... ვთარგმნი: ჩვენ თვითონ არ ვიცით რამდენი და როგორ არის საჭირო, აბა, შევაფასოთ, რომ ასე იყოს.

და პინგების შესახებ:

პინგ შეტყობინებები (PING/PONG)
ping#7abe77ec ping_id:long = Pong;
პასუხი ჩვეულებრივ უბრუნდება იმავე კავშირს:
pong#347773c5 msg_id:long ping_id:long = Pong;
ეს შეტყობინებები არ საჭიროებს აღიარებას. პონგი გადაიცემა მხოლოდ პინგის საპასუხოდ, ხოლო პინგის დაწყება შესაძლებელია ორივე მხარის მიერ.

გადადებული კავშირის დახურვა + PING
ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;
მუშაობს პინგის მსგავსად. გარდა ამისა, ამის მიღების შემდეგ, სერვერი იწყებს ტაიმერს, რომელიც დახურავს მიმდინარე კავშირს disconnect_delay წამებში, თუ არ მიიღებს იმავე ტიპის ახალ შეტყობინებას, რომელიც ავტომატურად აღადგენს ყველა წინა ტაიმერს. თუ კლიენტი აგზავნის ამ პინგებს ყოველ 60 წამში ერთხელ, მაგალითად, მან შეიძლება დააყენოს disconnect_delay ტოლი 75 წამი.

აზრზე ხარ?! 60 წამში მატარებელი შევა სადგურში, ჩამოვა და აიყვანს მგზავრებს და ისევ დაკარგავს კავშირი გვირაბში. 120 წამში, სანამ გარეთ ხართ, ის მოვა სხვასთან და კავშირი დიდი ალბათობით გაწყდება. კარგად, გასაგებია, საიდან იზრდება ფეხები - "მე გავიგე ზარის ხმა, მაგრამ არ ვიცი სად არის", არის ნაგლის ალგორითმი და TCP_NODELAY ვარიანტი, რომელიც განკუთვნილი იყო ინტერაქტიული მუშაობისთვის. მაგრამ, უკაცრავად, გადადეთ მისი ნაგულისხმევი მნიშვნელობა - 200 მილიწამი. თუ ნამდვილად გსურთ მსგავსი რამის გამოსახვა და შესაძლო წყვილი პაკეტზე დაზოგვა - კარგად, გადადეთ, სულ მცირე 5 წამით, ან როგორიც არ უნდა იყოს შეტყობინებების „მომხმარებლის კრეფს ...“ დრო უდრის. მაგრამ მეტი არა.

და ბოლოს, პინგები. ანუ TCP კავშირის სიცოცხლისუნარიანობის შემოწმება. სასაცილოა, მაგრამ დაახლოებით 10 წლის წინ დავწერე კრიტიკული ტექსტი ჩვენი ფაკულტეტის ჰოსტელის მესინჯერის შესახებ - იქ ავტორებმა სერვერი კლიენტისგანაც აიღეს და არა პირიქით. მაგრამ მესამე კურსის სტუდენტები ერთია და საერთაშორისო ოფისი მეორეა, არა? ..

პირველი, მცირე საგანმანათლებლო პროგრამა. TCP კავშირი, პაკეტების გაცვლის არარსებობის შემთხვევაში, შეიძლება არსებობდეს რამდენიმე კვირის განმავლობაში. ეს არის კარგიც და ცუდიც, მიზნიდან გამომდინარე. ისე, თუ სერვერთან SSH კავშირი გქონდა გახსნილი, ადექი კომპიუტერიდან, გადატვირთე დენის როუტერი, დაბრუნდი შენს ადგილას - ამ სერვერის მეშვეობით სესია არ დაირღვა (არაფერი დაგიწერია, პაკეტები არ იყო) მოსახერხებელი. ცუდია, თუ სერვერზე ათასობით კლიენტია, თითოეული იკავებს რესურსებს (გამარჯობა Postgres!) და კლიენტის ჰოსტი შეიძლება დიდი ხნის წინ გადაიტვირთა - მაგრამ ჩვენ ამის შესახებ არ ვიცით.

ჩატის/IM სისტემები მეორე შემთხვევას ეკუთვნის სხვა, დამატებითი მიზეზის გამო - ონლაინ სტატუსები. თუ მომხმარებელი „გავარდა“, აუცილებელია ამის შესახებ თანამოსაუბრეებს აცნობოს. წინააღმდეგ შემთხვევაში, იქნება შეცდომა, რომელიც Jabber-ის შემქმნელებმა დაუშვეს (და გამოასწორეს 20 წლის განმავლობაში) - მომხმარებელმა გათიშა, მაგრამ ისინი აგრძელებენ მისთვის შეტყობინებების წერას, მიაჩნიათ, რომ ის არის ონლაინ (რაც ასევე მთლიანად დაიკარგა ამ რამდენიმე წუთის წინ. შესვენება აღმოაჩინეს). არა, TCP_KEEPALIVE ვარიანტი, რომელიც ბევრ ადამიანს არ ესმის, თუ როგორ მუშაობს TCP ტაიმერი, ჩნდება სადმე (ველური მნიშვნელობების დაყენებით, როგორიცაა ათობით წამი), აქ არ დაგვეხმარება - თქვენ უნდა დარწმუნდეთ, რომ არა მხოლოდ OS ბირთვი მომხმარებლის აპარატი ცოცხალია, მაგრამ ასევე ნორმალურად ფუნქციონირებს, პასუხის გაცემას არ შეუძლია და თავად აპლიკაციაც (როგორ ფიქრობთ, ვერ გაიყინება? Telegram Desktop Ubuntu 18.04-ზე არაერთხელ დამიშალა).

ამიტომ უნდა პინგი სერვერზე კლიენტი, და არა პირიქით - თუ კლიენტი ამას აკეთებს, კავშირის გაწყვეტისას, პინგი არ იქნება მიწოდებული, მიზანი არ არის მიღწეული.

და რას ვხედავთ Telegram-ში? ყველაფერი ზუსტად პირიქითაა! ისე, ე.ი. ფორმალურად, რა თქმა უნდა, ორივე მხარეს შეუძლია ერთმანეთის პინგი. პრაქტიკაში კლიენტები ყავარჯენს იყენებენ ping_delay_disconnect, რომელიც სერვერზე ატარებს ტაიმერს. ბოდიში, კლიენტის საქმე არ არის, გადაწყვიტოს რამდენ ხანს სურს იქ იცხოვროს პინგის გარეშე. სერვერმა, მისი დატვირთვიდან გამომდინარე, უკეთ იცის. მაგრამ, რა თქმა უნდა, თუ არ გეცოდებათ რესურსები, მაშინ ისინი თავად არიან ბოროტი პინოქიო და ყავარჯენი ჩამოვარდება ...

როგორ უნდა ყოფილიყო დაპროექტებული?

მე მჯერა, რომ ზემოაღნიშნული ფაქტები საკმაოდ ნათლად მიუთითებს Telegram / VKontakte გუნდის არც თუ ისე მაღალ კომპეტენციაზე კომპიუტერული ქსელების სატრანსპორტო (და დაბალი) დონის სფეროში და მათ დაბალ კვალიფიკაციაზე შესაბამის საკითხებში.

რატომ აღმოჩნდა ეს ასე რთული და როგორ შეუძლიათ Telegram-ის არქიტექტორებს წინააღმდეგობის გაწევა? ის ფაქტი, რომ ისინი ცდილობდნენ სესიის გაკეთებას, რომელიც გადარჩება TCP კავშირს, წყვეტს, ანუ ის, რაც ახლა არ მოგვაწოდეს, მოგვიანებით მივაწოდებთ. ალბათ, UDP ტრანსპორტის გაკეთებაც სცადეს, თუმცა გაუჭირდათ და მიატოვეს (ამიტომ ცარიელია დოკუმენტაცია - სატრაბახო არაფერი იყო). მაგრამ იმის გამო, რომ არ გესმით, თუ როგორ მუშაობს ქსელები ზოგადად და TCP კონკრეტულად, სად შეგიძლიათ დაეყრდნოთ მას და სად უნდა გააკეთოთ ეს საკუთარ თავს (და როგორ), და მცდელობის გამო, ეს დააკავშიროთ კრიპტოგრაფიასთან ”ერთი კადრი ორიდან. ჩიტები ერთი ქვით“ - ასეთი გვამი აღმოჩნდა.

როგორ უნდა ყოფილიყო? გამომდინარე იქიდან, რომ msg_id არის დროის ანაბეჭდი, რომელიც კრიპტოგრაფიულად აუცილებელია განმეორებითი შეტევების თავიდან ასაცილებლად, მასზე უნიკალური იდენტიფიკატორის ფუნქციის მიმაგრება შეცდომაა. ამიტომ, მიმდინარე არქიტექტურის მკვეთრად შეცვლის გარეშე (როდესაც იქმნება განახლებების თემა, ეს არის მაღალი დონის API თემა პოსტების ამ სერიის სხვა ნაწილისთვის), უნდა:

სერვერი, რომელიც ფლობს TCP კავშირს კლიენტთან, იღებს პასუხისმგებლობას - თუ თქვენ გამოაკლებთ სოკეტს, გთხოვთ, დაადასტუროთ, დაამუშავოთ ან დააბრუნოთ შეცდომა, ზარალის გარეშე. მაშინ დადასტურება არ არის id-ების ვექტორი, არამედ უბრალოდ "ბოლო მიღებული seq_no" - უბრალოდ რიცხვი, როგორც TCP-ში (ორი ნომერი - თქვენი საკუთარი თანმიმდევრობა და დადასტურებული). ჩვენ ყოველთვის სხდომაზე ვართ, არა?
განმეორებითი შეტევების თავიდან აცილების დროის შტამპი ხდება ცალკე ველი, a la nonce. შემოწმებულია, მაგრამ სხვა არაფერი დაზარალდება. საკმარისია და uint32 - თუ ჩვენი მარილი ყოველ ნახევარ დღეში იცვლება, შეგვიძლია 16 ბიტი გავანაწილოთ მიმდინარე დროის მთელი ნაწილის ქვედა ბიტებზე, დანარჩენი - წამის წილად ნაწილზე (როგორც ახლაა).
უკუღმა msg_id საერთოდ - ბექენდებზე მოთხოვნების განმასხვავებელი თვალსაზრისით, არსებობს, პირველ რიგში, კლიენტის ID და მეორეც, სესიის 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' )
};

დიახ, სპეციალურად არა სპოილერის ქვეშ - თუ არ წაგიკითხავთ, წადით და გააკეთეთ!

ოჰ, ვაი~~... რას ჰგავს? რაღაც ძალიან ნაცნობი… იქნებ ეს არის ტიპიური Web API-ის მონაცემთა სტრუქტურა JSON-ში, გარდა იმისა, რომ კლასები იყო მიმაგრებული ობიექტებზე?..

ასე გამოდის... რა არის ეს, ამხანაგებო?.. ამდენი ძალისხმევა - და ჩვენ შევჩერდით, რომ დავისვენოთ, სადაც ვებ პროგრამისტები ახლახან იწყება?.. უბრალოდ JSON HTTPS-ზე ადვილი არ იქნება?! და რა მივიღეთ სანაცვლოდ? ღირდა თუ არა ეს ძალისხმევა?

მოდით შევაფასოთ რა მოგვცა TL+MTProto და რა ალტერნატივებია შესაძლებელი. ისე, HTTP მოთხოვნა-პასუხი ცუდია, მაგრამ მაინც რაღაც TLS-ზე მეტი?

კომპაქტური სერიალიზაცია. ამ მონაცემთა სტრუქტურის დანახვისას, JSON-ის მსგავსი, ახსოვს, რომ არსებობს მისი ორობითი ვარიანტები. მოდით აღვნიშნოთ MsgPack, როგორც არასაკმარისად გაფართოებადი, მაგრამ არსებობს, მაგალითად, CBOR - სხვათა შორის, სტანდარტი აღწერილია RFC 7049. აღსანიშნავია ის ფაქტი, რომ განსაზღვრავს ტეგები, როგორც გაფართოების მექანიზმი და მათ შორის უკვე სტანდარტიზებული არიან, იმყოფებიან:

25 + 256 - დუბლიკატი ხაზების შეცვლა ხაზის ნომრის მითითებით, ასეთი იაფი შეკუმშვის მეთოდი
26 - სერიული Perl ობიექტი კლასის სახელით და კონსტრუქტორის არგუმენტებით
27 - სერიული ენაზე დამოუკიდებელი ობიექტი ტიპის სახელით და კონსტრუქტორის არგუმენტებით

ისე, მე ვცადე იგივე მონაცემების სერიალიზაცია TL-ში და CBOR-ში, სტრიქონების და ობიექტების შეფუთვით ჩართული. შედეგი დაიწყო განსხვავებული CBOR-ის სასარგებლოდ სადღაც მეგაბაიტიდან:

cborlen=1039673 tl_len=1095092

აქედან გამომდინარე, დასკვნა: არსებობს არსებითად უფრო მარტივი ფორმატები, რომლებიც არ ექვემდებარება სინქრონიზაციის უკმარისობას ან უცნობი იდენტიფიკატორის პრობლემას, შედარებითი ეფექტურობით.

სწრაფი კავშირის დამყარება. ეს ნიშნავს ნულოვანი RTT ხელახლა დაკავშირების შემდეგ (როდესაც გასაღები უკვე გენერირებულია ერთხელ) - გამოიყენება პირველივე MTProto შეტყობინებიდან, მაგრამ გარკვეული დათქმებით - ისინი ერთსა და იმავე სალტში მოხვდნენ, სესია არ გაფუჭდა და ა.შ. რას გვთავაზობს TLS სანაცვლოდ? დაკავშირებული ციტატა:

TLS-ში PFS-ის გამოყენებისას, TLS სესიის ბილეთები (RFC 5077) დაშიფრული სესიის განახლება გასაღებების ხელახალი მოლაპარაკებისა და სერვერზე ძირითადი ინფორმაციის შენახვის გარეშე. პირველი კავშირის გახსნისა და გასაღებების გენერირებისას სერვერი შიფრავს კავშირის მდგომარეობას და უგზავნის კლიენტს (სესიის ბილეთის სახით). შესაბამისად, როდესაც კავშირი განახლდება, კლიენტი აგზავნის სესიის ბილეთს, რომელიც შეიცავს, სხვა საკითხებთან ერთად, სესიის კლავიშს უკან სერვერზე. თავად ბილეთი დაშიფრულია დროებითი გასაღებით (სესიის ბილეთის გასაღები), რომელიც ინახება სერვერზე და უნდა განაწილდეს ყველა წინა სერვერზე, რომლებიც ამუშავებენ SSL-ს კლასტერულ გადაწყვეტილებებში.[10]. ამრიგად, სესიის ბილეთის დანერგვამ შეიძლება დაარღვიოს PFS, თუ დროებითი სერვერის გასაღებები დაზიანებულია, მაგალითად, როდესაც ისინი ინახება დიდი ხნის განმავლობაში (OpenSSL, nginx, Apache ნაგულისხმევად ინახავს მათ პროგრამის გაშვების მთელი პერიოდის განმავლობაში; პოპულარული საიტები. გამოიყენეთ გასაღები რამდენიმე საათის განმავლობაში, დღემდე).

აქ RTT არ არის ნული, თქვენ უნდა გაცვალოთ მინიმუმ ClientHello და ServerHello, რის შემდეგაც Finished-თან ერთად კლიენტს უკვე შეუძლია მონაცემების გაგზავნა. მაგრამ აქ უნდა გვახსოვდეს, რომ ჩვენ არ გვაქვს ვებ, თავისი ახლად გახსნილი კავშირებით, არამედ მესინჯერი, რომლის დაკავშირება ხშირად არის ერთი და მეტ-ნაკლებად ხანგრძლივი, შედარებით მოკლე მოთხოვნა ვებ გვერდებზე - ყველაფერი არის მულტიპლექსირებული შიგნით. ანუ სავსებით მისაღებია, თუ მეტროს ძალიან ცუდი მონაკვეთი არ შეგვხვდა.

სხვა რამე დაგავიწყდა? დაწერეთ კომენტარებში.

Გაგრძელება იქნება!

ამ პოსტების სერიის მეორე ნაწილში განვიხილავთ ორგანიზაციულ საკითხებს და არა ტექნიკურს - მიდგომებს, იდეოლოგიას, ინტერფეისს, მომხმარებლისადმი დამოკიდებულებას და ა.შ. თუმცა, ტექნიკური ინფორმაციის საფუძველზე, რომელიც აქ იყო წარმოდგენილი.

მესამე ნაწილი გაგრძელდება ტექნიკური კომპონენტის/განვითარების გამოცდილების ანალიზს. თქვენ შეისწავლით კერძოდ:

პანდემონიის გაგრძელება TL-ტიპების მრავალფეროვნებით
უცნობი რამ არხებისა და სუპერჯგუფების შესახებ
ვიდრე დიალოგები სიაზე უარესია
აბსოლუტური და ფარდობითი შეტყობინების მიმართვის შესახებ
რა განსხვავებაა ფოტოსა და სურათს შორის
როგორ ერევა emoji დახრილ ტექსტს

და სხვა ხელჯოხები! Ადევნეთ თვალყური!

წყარო: www.habr.com