לאחרונה החלו להופיע לעתים קרובות יותר ב-Habré פוסטים על כמה טובה טלגרם, עד כמה האחים דורוב מבריקים ומנוסים בבניית מערכות רשת וכו'. יחד עם זאת, מעט מאוד אנשים באמת שקעו במכשיר הטכני - לכל היותר, הם משתמשים ב-Bot API פשוט למדי (ודי שונה מ-MTProto) המבוסס על JSON, ובדרך כלל פשוט מקבלים על אמונה כל השבחים ויחסי הציבור שסובבים סביב השליח. לפני כמעט שנה וחצי, עמית שלי בעמותה אשלון ואסילי (לצערי, החשבון שלו ב-Habré נמחק יחד עם הטיוטה) החל לכתוב לקוח טלגרם משלו מאפס בפרל, ובהמשך הצטרף כותב שורות אלו. למה פרל, יש שישאלו מיד? מכיוון שפרויקטים כאלה כבר קיימים בשפות אחרות. למעשה, זו לא הנקודה, יכולה להיות כל שפה אחרת שבה אין ספרייה מוכנה, ובהתאם לכך על המחבר ללכת עד הסוף מאפס. יתר על כן, קריפטוגרפיה היא עניין של אמון, אבל ודא. עם מוצר המכוון לאבטחה, אתה לא יכול פשוט להסתמך על ספרייה מוכנה מהיצרן ולסמוך עליה באופן עיוור (עם זאת, זה נושא לחלק השני). כרגע, הספרייה עובדת די טוב ברמה ה"ממוצעת" (מאפשרת לך לבצע כל בקשות API).

עם זאת, לא תהיה הרבה קריפטוגרפיה או מתמטיקה בסדרת הפוסטים הזו. אבל יהיו עוד הרבה פרטים טכניים וקביים אדריכליים (שימושיים גם למי שלא יכתוב מאפס, אלא ישתמש בספרייה בכל שפה). לכן, המטרה העיקרית הייתה לנסות ליישם את הלקוח מאפס לפי תיעוד רשמי. כלומר, נניח שקוד המקור של לקוחות רשמיים סגור (שוב, בחלק השני נעסוק ביתר פירוט בנושא העובדה שזה נכון זה קורה כך), אבל, כמו בימים עברו, למשל, יש תקן כמו RFC - האם אפשר לכתוב לקוח לפי המפרט בלבד, "מבלי להסתכל" על קוד המקור, בין אם זה רשמי (Telegram Desktop, נייד), או Telethon לא רשמי?

אופציות:

תיעוד... זה קיים, נכון? האם זה נכון?..
איפה להתחיל כסופר צעיר?
סדרה בינארית: TL (שפת סוג) והסכימה שלה, והשכבות שלה, ועוד הרבה מילים מפחידות
MTProto
API?
המשך יבוא!

תיעוד... זה קיים, נכון? האם זה נכון?..

בקיץ האחרון החלו לאסוף שברי הערות למאמר זה. כל הזמן הזה באתר הרשמי https://core.telegram.org התיעוד היה נכון לשכבה 23, כלומר. תקוע אי שם ב-2014 (זוכרים, אפילו לא היו ערוצים אז?). כמובן, בתיאוריה, זה היה צריך לאפשר לנו ליישם לקוח עם פונקציונליות באותה תקופה ב-2014. אבל גם במצב זה, התיעוד היה, ראשית, חלקי, ושנית, במקומות שהוא סותר את עצמו. לפני קצת יותר מחודש, בספטמבר 2019, זה היה בטעות התגלה שיש עדכון גדול של התיעוד באתר, לשכבה 105 העדכנית לחלוטין, עם הערה שעכשיו צריך לקרוא הכל שוב. אכן, מאמרים רבים תוקנו, אך רבים נותרו ללא שינוי. לכן, כשקוראים את הביקורת למטה על התיעוד, כדאי לזכור שחלק מהדברים האלה כבר לא רלוונטיים, אבל חלק עדיין די. אחרי הכל, 5 שנים בעולם המודרני זה לא רק הרבה זמן, אלא מאוד הרבה. מאז אותם זמנים (במיוחד אם לא לוקחים בחשבון את אתרי הגיאוצ'אט שהושלכו והתחדשו מאז), מספר שיטות ה-API בתכנית גדל ממאה ליותר ממאתיים וחמישים!

איפה להתחיל כסופר צעיר?

זה לא משנה אם אתה כותב מאפס או משתמש, למשל, בספריות מוכנות כמו Telethon עבור Python או Madeline עבור PHP, בכל מקרה, תצטרך תחילה לרשום את הבקשה שלך - לקבל פרמטרים api_id и api_hash (אלה שעבדו עם ה-API של VKontakte מבינים מיד) לפיו השרת יזהה את האפליקציה. זֶה צריך לעשות זאת מסיבות משפטיות, אבל נדבר יותר על הסיבה לכך שסופרי ספרייה לא יכולים לפרסם את זה בחלק השני. יכול להיות שאתה מרוצה מערכי הבדיקה, למרות שהם מוגבלים מאוד - העובדה היא שעכשיו אתה יכול להירשם רק אחד אפליקציה, אז אל תמהרו אליה.

כעת, מבחינה טכנית, צריך להתעניין בעובדה שאחרי ההרשמה עלינו לקבל הודעות מטלגרם על עדכונים בתיעוד, פרוטוקול וכו'. כלומר, אפשר היה לשער שהאתר עם הרציפים פשוט נטוש והמשיך לעבוד במיוחד עם מי שהתחיל לעשות לקוחות, כי זה קל יותר. אבל לא, שום דבר כזה לא נצפה, שום מידע לא הגיע.

ואם אתה כותב מאפס, אז השימוש בפרמטרים שהתקבלו הוא למעשה עדיין רחוק. למרות ש https://core.telegram.org/ ומדבר עליהם בהתחלה קודם כל, למעשה, קודם כל תצטרך ליישם פרוטוקול MTProto - אבל אם האמנת פריסה לפי מודל OSI בסוף העמוד לתיאור כללי של הפרוטוקול, אז זה לגמרי לשווא.

למעשה, גם לפני וגם אחרי MTProto, בכמה רמות בו-זמנית (כפי שאומרים אנשי רשת זרים שעובדים בליבת מערכת ההפעלה, הפרת שכבות), נושא גדול, כואב ונורא יפריע...

סדרה בינארית: TL (שפת סוג) והסכימה שלה, והשכבות שלה, ועוד הרבה מילים מפחידות

נושא זה, למעשה, הוא המפתח לבעיות של טלגרם. ויהיו הרבה מילים איומות אם תנסו להתעמק בזה.

אז הנה התרשים. אם המילה הזאת עולה לך בראש, אמור, סכמת JSON, חשבת נכון. המטרה זהה: שפה כלשהי לתיאור קבוצה אפשרית של נתונים משודרים. כאן מסתיימים קווי הדמיון. אם מהדף פרוטוקול MTProto, או מעץ המקור של הלקוח הרשמי, ננסה לפתוח סכמה כלשהי, נראה משהו כמו:

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

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

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

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

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

---functions---

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

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

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

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

אדם שרואה זאת בפעם הראשונה יוכל באופן אינטואיטיבי לזהות רק חלק ממה שכתוב - ובכן, אלו כנראה מבנים (אם כי איפה השם, משמאל או מימין?), יש בהם שדות, שלאחריו סוג עוקב אחרי נקודתיים... כנראה. כאן בסוגריים זווית יש כנראה תבניות כמו ב-C++ (למעשה, לא ממש). ומה המשמעות של כל שאר הסמלים, סימני שאלה, סימני קריאה, אחוזים, סימני גיבוב (וברור שהם מתכוונים לדברים שונים במקומות שונים), לפעמים נוכחים ולפעמים לא, מספרים הקסדצימליים - והכי חשוב, איך מגיעים מזה נכון (שלא יידחה על ידי השרת) זרם בתים? תצטרך לקרוא את התיעוד (כן, יש קישורים לסכימה בגרסת JSON בקרבת מקום - אבל זה לא הופך את זה לבהיר יותר).

פתח את הדף סידור נתונים בינאריים וצלול לעולם הקסום של פטריות ומתמטיקה בדידה, משהו דומה למתן בשנה הרביעית. אלפבית, סוג, ערך, קומבינטור, קומבינטור פונקציונלי, צורה נורמלית, סוג מורכב, סוג פולימורפי... וזה הכל רק העמוד הראשון! הבא מחכה לך שפת TL, שלמרות שהוא כבר מכיל דוגמה לבקשה ותגובה טריוויאלית, לא נותן מענה כלל למקרים טיפוסיים יותר, מה שאומר שתצטרך לדשדש בשורה חוזרת של מתמטיקה שתורגמה מרוסית לאנגלית על עוד שמונה מוטמעות דפים!

קוראים שמכירים שפות פונקציונליות והסקת סוגים אוטומטית יראו, כמובן, את שפת התיאור בשפה הזו, אפילו מהדוגמה, כמוכרת הרבה יותר, ויכולים לומר שזה בעצם לא רע באופן עקרוני. ההתנגדויות לכך הן:

כן, מטרה נשמע טוב, אבל אבוי, היא לא הושג
השכלה באוניברסיטאות ברוסיה משתנה אפילו בין התמחויות IT - לא כולם למדו את הקורס המקביל
לבסוף, כפי שנראה, בפועל זה כך לא נדרש, שכן נעשה שימוש רק בתת-קבוצה מוגבלת אפילו של ה-TL שתואר

כמו שנאמר ליאונרד בערוץ #perl ברשת FreeNode IRC, שניסה ליישם שער מטלגרם למטריקס (תרגום הציטוט אינו מדויק מהזיכרון):

זה מרגיש כאילו מישהו התוודע לתורת הקלידים בפעם הראשונה, התלהב והתחיל לנסות לשחק איתה, לא ממש אכפת לו אם זה נחוץ בפועל.

תראה בעצמך אם הצורך בטיפוס חשוף (int, long וכו') כמשהו אלמנטרי לא מעלה שאלות - בסופו של דבר יש ליישם אותם באופן ידני - למשל, ניקח ניסיון להפיק מהם וקטור. כלומר, למעשה, מערך, אם אתה קורא לדברים המתקבלים בשמם הנכון.

אבל לפני

תיאור קצר של תת-קבוצה של תחביר 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. מכיוון שכאן רק מבני נתונים, אין שיטות (למרות שתיאור הפונקציות והשיטות עוד יותר מסוגל ליצור בלבול בראש שהם קיימים, אבל זה עניין אחר) - אפשר לחשוב על בנאי כערך מ- איזה נבנה הקלד בעת קריאת זרם בתים.

איך זה קורה? ה-deserializer, שתמיד קורא 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, כלומר "מספר טבעי". כלומר, למעשה, int unsigned הוא, אגב, המקרה היחיד כאשר מספרים חסרי סימן מתרחשים במעגלים אמיתיים. אז, הבא הוא בנייה עם סימן שאלה, כלומר השדה הזה - הוא יהיה קיים על החוט רק אם הסיבית המקבילה מוגדרת בשדה שאליו מתייחסים (בערך כמו אופרטור טרינרי). אז, בואו נניח שהביט הזה הוגדר, מה שאומר שעוד עלינו לקרוא שדה כמו Type, שבדוגמה שלנו יש 2 בנאים. אחד ריק (מורכב רק מהמזהה), לשני יש שדה ids עם סוג ids:Vector<long>.

אתה עשוי לחשוב שגם התבניות וגם הגנריות נמצאות במקצוענים או ב-Java. אבל לא. כִּמעַט. זֶה יחיד במקרה של שימוש בסוגריים זווית במעגלים אמיתיים, והוא משמש רק עבור וקטור. בזרם בתים, אלה יהיו 4 CRC32 בתים עבור סוג הוקטור עצמו, תמיד זהים, לאחר מכן 4 בתים - מספר רכיבי המערך, ולאחר מכן האלמנטים הללו עצמם.

תוסיפו לזה את העובדה שהסדרה תמיד מתרחשת במילים של 4 בתים, כל הסוגים הם כפולות שלו - גם הסוגים המובנים מתוארים bytes и string עם סדרה ידנית של האורך והיישור הזה ב-4 - ובכן, נראה שזה נשמע נורמלי ואפילו יעיל יחסית? למרות שלטענת TL הם סדרה בינארית יעילה, לעזאזל איתם, עם הרחבה של כמעט כל דבר, אפילו ערכים בוליאניים ומחרוזות של תו בודד ל-4 בתים, האם ה-JSON עדיין יהיה הרבה יותר עבה? תראה, אפילו שדות מיותרים אפשר לדלג עם דגלי ביט, הכל די טוב, ואפילו ניתן להרחבה לעתיד, אז למה לא להוסיף שדות אופציונליים חדשים לבנאי מאוחר יותר?..

אבל לא, אם אתה לא קורא את התיאור הקצר שלי, אלא את התיעוד המלא, וחושב על היישום. ראשית, ה-CRC32 של הבנאי מחושב לפי השורה המנורמלת של תיאור הטקסט של הסכימה (הסר רווח לבן נוסף וכו') - כך שאם יתווסף שדה חדש, שורת תיאור הסוג תשתנה, ומכאן שלה CRC32 ו- , כתוצאה מכך, סדרה. ומה יעשה הלקוח הוותיק אם יקבל שדה עם דגלים חדשים, והוא לא יודע מה לעשות איתם הלאה?...

שנית, בואו נזכור CRC32, המשמש כאן בעיקרו כ פונקציות חשיש כדי לקבוע באופן ייחודי איזה סוג מועבר (דה) בסידרה. כאן אנו מתמודדים עם בעיית ההתנגשויות - ולא, ההסתברות היא לא אחת ל-232, אלא הרבה יותר גדולה. מי זכר ש-CRC32 נועד לזהות (ולתקן) שגיאות בערוץ התקשורת, ובהתאם משפר את המאפיינים הללו לרעת אחרים? לדוגמה, לא אכפת לו מארגון מחדש של בתים: אם תחשב CRC32 משתי שורות, בשניה תחליף את 4 הבתים הראשונים עם 4 הבתים הבאים - זה יהיה זהה. כאשר הקלט שלנו הוא מחרוזות טקסט מהאלפבית הלטיני (ומעט סימני פיסוק), והשמות הללו אינם אקראיים במיוחד, הסבירות לסידור מחדש כזה עולה מאוד.

אגב, מי בדק מה יש? באמת CRC32? לאחד מקודי המקור המוקדמים (אפילו לפני וולטמן) הייתה פונקציית Hash שהכפילה כל תו במספר 239, כל כך אהובה על האנשים האלה, חה חה!

לבסוף, בסדר, הבנו שקונסטרוקטורים עם סוג שדה Vector<int> и Vector<PolymorType> יהיה CRC32 שונה. מה לגבי ביצועים מקוונים? ומנקודת מבט תיאורטית, האם זה הופך לחלק מהסוג? נניח שאנחנו עוברים מערך של עשרת אלפים מספרים, טוב עם Vector<int> הכל ברור, האורך ועוד 40000 בתים. מה אם זה Vector<Type2>, המורכב משדה אחד בלבד int וזה לבד בסוג - האם אנחנו צריכים לחזור על 10000xabcdef0 34 פעמים ואז 4 בתים int, או שהשפה מסוגלת לנתח אותה עבורנו מהקונסטרוקטור fixedVec ובמקום 80000 בתים, להעביר שוב רק 40000?

זו לא שאלה תיאורטית סרק בכלל - דמיינו שאתם מקבלים רשימה של משתמשים בקבוצה, שלכל אחד מהם יש תעודה מזהה, שם פרטי, שם משפחה - ההבדל בכמות הנתונים המועברים בחיבור סלולרי יכול להיות משמעותי. דווקא האפקטיביות של הסדרת טלגרם מתפרסמת לנו.

אז ...

וקטור, שמעולם לא שוחרר

אם תנסו לדפדף בין דפי התיאור של שילובים וכן הלאה, תראו שווקטור (ואפילו מטריצה) מנסה רשמית להיות פלט דרך טופלים של מספר גיליונות. אבל בסוף הם שוכחים, מדלגים על השלב האחרון, ופשוט ניתנת הגדרה של וקטור, שעדיין לא קשור לטיפוס. מה הבעיה? בשפות תכנות, במיוחד פונקציונליים, די אופייני לתאר את המבנה באופן רקורסיבי - המהדר עם ההערכה העצלה שלו יבין ויעשה הכל בעצמו. בשפה הסדרת נתונים מה שצריך זה יעילות: מספיק לתאר בפשטות список, כלומר מבנה של שני אלמנטים - הראשון הוא אלמנט נתונים, השני הוא אותו מבנה עצמו או חלל ריק עבור הזנב (חבילה (cons) בליספ). אבל זה כמובן ידרוש כל אלמנט מוציא 4 בתים נוספים (CRC32 במקרה ב-TL) כדי לתאר את הסוג שלו. ניתן גם לתאר מערך בקלות מידה קבועה, אבל במקרה של מערך באורך לא ידוע מראש, אנחנו מתנתקים.

לכן, מכיוון ש-TL אינו מאפשר להוציא וקטור, היה צורך להוסיף אותו בצד. בסופו של דבר התיעוד אומר:

סריאליזציה משתמשת תמיד באותו הבנאי "וקטור" (const 0x1cb5c415 = crc32("vector t:Type # [ t ] = Vector t") שאינו תלוי בערך הספציפי של המשתנה מסוג t.

הערך של הפרמטר האופציונלי t אינו מעורב בסריאליזציה מכיוון שהוא נגזר מסוג התוצאה (ידוע תמיד לפני הסידריאליזציה).

תסתכל מקרוב: vector {t:Type} # [ t ] = Vector t - אבל בשום מקום הגדרה זו עצמה לא אומרת שהמספר הראשון חייב להיות שווה לאורך הווקטור! וזה לא בא משום מקום. זה נתון שצריך לזכור וליישם עם הידיים. במקומות אחרים, התיעוד אפילו מזכיר בכנות שהטיפוס אינו אמיתי:

הפסאודוטייפ הפולימורפי של Vector t הוא "טיפוס" שערכו הוא רצף של ערכים מכל סוג t, בין אם מקופסת או חשופה.

... אבל לא מתמקד בזה. כשאתם, עייפים מלשתפשף במתיחות של המתמטיקה (אולי אפילו מוכר לכם מקורס באוניברסיטה), מחליטים לוותר ולמעשה בוחנים איך עובדים עם זה בפועל, הרושם שנותר בראשכם הוא שמדובר ברצינות מתמטיקה בבסיסה, ברור שהיא הומצאה על ידי Cool People (שני מתמטיקאים - זוכה ACM), ולא סתם מישהו. המטרה - להשוויץ - הושגה.

אגב, לגבי המספר. תן לנו להזכיר לך את זה # זו מילה נרדפת nat, מספר טבעי:

יש ביטויי סוג (type-expr) וביטויים מספריים (nat-expr). עם זאת, הם מוגדרים באותו אופן.
type-expr ::= expr
nat-expr ::= expr
אבל בדקדוק הם מתוארים באותו אופן, כלומר. יש לזכור שוב את ההבדל הזה ולהכניס אותו ליישום באופן ידני.

ובכן, כן, סוגי תבניות (vector<int>, vector<User>) בעלי מזהה משותף (#1cb5c415), כלומר. אם אתה יודע שהשיחה הוכרזה כ

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

אז אתה כבר לא מחכה רק לוקטור, אלא לוקטור של משתמשים. לייתר דיוק, צריך רגע - בקוד אמיתי, לכל אלמנט, אם לא סוג חשוף, יהיה בנאי, ובצורה טובה ביישום יהיה צורך לבדוק - אבל נשלחנו בדיוק בכל אלמנט של הווקטור הזה הסוג הזה? מה אם זה היה סוג של PHP, שבו מערך יכול להכיל סוגים שונים באלמנטים שונים?

בשלב זה אתה מתחיל לחשוב - האם TL כזה הכרחי? אולי עבור העגלה אפשר יהיה להשתמש בסריאלייזר אנושי, אותו פרוטובוף שכבר היה קיים אז? זו הייתה התיאוריה, בואו נסתכל על הפרקטיקה.

מימושי TL קיימים בקוד

TL נולדה במעמקי VKontakte עוד לפני האירועים המפורסמים עם מכירת חלקו של דורוב ו-(בוודאי), עוד לפני תחילת הפיתוח של טלגרם. ובקוד פתוח קוד המקור של היישום הראשון אתה יכול למצוא הרבה קביים מצחיקים. והשפה עצמה יושמה שם בצורה מלאה יותר ממה שהיא עכשיו בטלגרם. לדוגמה, הגיבוב אינו משמש כלל בסכימה (כלומר פסאודוטייפ מובנה (כמו וקטור) עם התנהגות סוטה). אוֹ

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

אבל הבה נשקול, למען השלמות, להתחקות, כביכול, אחר התפתחותו של ענק המחשבה.

#define ZHUKOV_BYTES_HACK

#ifdef ZHUKOV_BYTES_HACK

/* dirty hack for Zhukov request */

או היפה הזאת:

    static const char *reserved_words_polymorhic[] = {

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

      };

הפרגמנט הזה עוסק בתבניות כמו:

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

זוהי ההגדרה של סוג תבנית hashmap בתור וקטור של זוגות int - Type. ב-C++ זה ייראה בערך כך:

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

כך, alpha - מילת מפתח! אבל רק ב-C++ אפשר לכתוב T, אבל צריך לכתוב אלפא, בטא... אבל לא יותר מ-8 פרמטרים, שם מסתיימת הפנטזיה. נראה שפעם בסנט פטרסבורג התקיימו דיאלוגים כמו זה:

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

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

אבל זה היה בערך היישום הראשון שפורסם של TL "בכלל". בואו נעבור לשקול הטמעות בלקוחות הטלגרם עצמם.

מילה לווסילי:

וסילי, [09.10.18 17:07] יותר מכל, התחת לוהט כי הם יצרו חבורה של הפשטות, ולאחר מכן תקעו עליהם בורג וכיסו את מחולל הקוד בקביים
כתוצאה מכך, תחילה מ dock pilot.jpg
ואז מהקוד dzhekichan.webp

כמובן, מאנשים שמכירים אלגוריתמים ומתמטיקה, אנו יכולים לצפות שהם קראו את Aho, Ullmann, והם מכירים את הכלים שהפכו לסטנדרט דה פקטו בתעשייה במשך עשרות השנים לכתיבת מהדרי DSL שלהם, נכון?..

מְחַבֵּר טלגרם-קלי הוא ויטלי ולטמן, כפי שניתן להבין מהתרחשות פורמט TLO מחוץ לגבולות (cli) שלו, חבר בצוות - כעת הוקצתה ספרייה לניתוח TL בנפרד, מה הרושם ממנה מנתח TL? ..

16.12 04:18 וסילי: אני חושב שמישהו לא שלט בלקס+יאק
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+ שורות ב-Python, כמה ביטויים רגולריים + מקרים מיוחדים כמו וקטור, שכמובן מוצהר בסכמה כפי שהוא צריך להיות לפי תחביר TL, אבל הם הסתמכו על התחביר הזה כדי לנתח אותו... נשאלת השאלה, למה כל זה היה נס?иזה יותר מרובד אם אף אחד לא מתכוון לנתח את זה לפי התיעוד בכל מקרה?!

אגב... זוכרים שדיברנו על בדיקת CRC32? אז, במחולל הקוד של Telegram Desktop יש רשימה של חריגים עבור אותם סוגים שבהם CRC32 המחושב לא מתאים עם זה שמצוין בתרשים!

ואסילי, [18.12/22 כב:49] וכאן הייתי חושב אם צריך ת"ל כזה
אם הייתי רוצה להתעסק עם יישומים אלטרנטיביים, הייתי מתחיל להכניס מעברי שורות, חצי מהמנתחים ישברו בהגדרות מרובות שורות
עם זאת, גם tdesktop

זכרו את הנקודה בעניין וואן-ליינר, נחזור אליה מעט מאוחר יותר.

אוקיי, telegram-cli לא רשמי, Telegram Desktop רשמי, אבל מה עם האחרים? מי יודע?.. בקוד הלקוח של אנדרואיד לא היה מנתח סכמה בכלל (מה שמעלה שאלות לגבי קוד פתוח, אבל זה לחלק השני), אבל היו עוד כמה קטעי קוד מצחיקים, אבל עוד עליהם ב- סעיף קטן למטה.

אילו שאלות נוספות מעוררת בהמשכה בפועל? לדוגמה, הם עשו הרבה דברים, כמובן, עם שדות סיביות ושדות מותנים:

ואסילי: flags.0? true
פירושו שהשדה קיים ושווה אמת אם הדגל מוגדר

ואסילי: flags.1? int
פירושו שהשדה קיים וצריך להפוך אותו לסידריאליזציה

ואסילי: תחת, אל תדאג לגבי מה שאתה עושה!
ואסילי: יש אזכור איפשהו במסמך שאמנם הוא סוג חשוף באורך אפס, אבל אי אפשר להרכיב שום דבר מהמסמך שלהם
ואסילי: גם ביישומי קוד פתוח זה לא המקרה, אבל יש חבורה של קביים ותמיכות

מה עם טלטון? בהסתכלות קדימה לנושא של MTProto, דוגמה - בתיעוד יש קטעים כאלה, אבל הסימן % הוא מתואר רק כ"מתאים לסוג חשוף נתון", כלומר. בדוגמאות שלהלן יש שגיאה או משהו לא מתועד:

ואסילי, [22.06.18 18:38] במקום אחד:
msg_container#73f1f8dc messages:vector message = MessageContainer;
בשונה:
msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;
ואלה שני הבדלים גדולים, בחיים האמיתיים מגיע איזה וקטור עירום

לא ראיתי הגדרה וקטורית חשופה ולא נתקלתי בה

הניתוח נכתב ביד בטלטון

בתרשים שלו ההגדרה מוערת msg_container

שוב, השאלה נשארת בערך %. זה לא מתואר.

ואדים גונצ'רוב, [22.06.18 19:22] וב-tdesktop?

ואסילי, [22.06.18 19:23] אבל מנתח ה-TL שלהם במנועים רגילים סביר להניח שגם לא יאכל את זה

// parsed manually

TL הוא הפשטה יפה, אף אחד לא מיישם אותה לחלוטין

ו-% אינו בגרסה שלהם של התוכנית

אבל כאן התיעוד סותר את עצמו, אז איכשהו

זה נמצא בדקדוק, הם יכלו פשוט לשכוח לתאר את הסמנטיקה

ראית את המסמך ב-TL, אתה לא יכול להבין אותו בלי חצי ליטר

"טוב, נניח", יגיד קורא אחר, "אתה מבקר משהו, אז תראה לי איך זה צריך להיעשות."

ואסילי עונה: "לגבי המנתח, אני אוהב דברים כמו

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

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

איכשהו אוהב את זה יותר טוב מאשר

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

או

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

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

זה ה-WHOLE lexer:

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

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

הָהֵן. פשוט יותר הוא לנסח זאת בעדינות."

באופן כללי, כתוצאה מכך, המנתח ומחולל הקוד עבור תת-קבוצת המשנה בשימוש בפועל של TL משתלבים בכ-100 שורות דקדוק וכ-300 שורות של המחולל (ספירת כל printהקוד שנוצר), כולל לחמניות מידע על סוג עבור התבוננות פנימית בכל מחלקה. כל טיפוס פולימורפי הופך למחלקת בסיס מופשטת ריקה, ובנאים יורשים ממנה ויש להם שיטות לסריאליזציה ולדה-סריאליזציה.

חוסר טיפוסים בשפת הטיפוס

הקלדה חזקה היא דבר טוב, נכון? לא, זה לא הוליבר (למרות שאני מעדיף שפות דינמיות), אלא פוסטולציה במסגרת TL. על סמך זה, השפה צריכה לספק לנו כל מיני צ'קים. טוב, בסדר, אולי לא הוא עצמו, אלא היישום, אבל הוא צריך לפחות לתאר אותם. ואיזה סוג של הזדמנויות אנחנו רוצים?

קודם כל, אילוצים. כאן אנו רואים בתיעוד להעלאת קבצים:

התוכן הבינארי של הקובץ מחולק לחלקים. כל החלקים חייבים להיות באותו גודל ( חלק_גודל ) ויש לעמוד בתנאים הבאים:

part_size % 1024 = 0 (מתחלק ב-1KB)

524288 % part_size = 0 (512KB חייב להיות מתחלק באופן שווה ב-part_size)

החלק האחרון אינו חייב לעמוד בתנאים אלו, בתנאי שגודלו קטן מ-part_size.

לכל חלק צריך להיות מספר רצף, file_part, עם ערך שנע בין 0 ל-2,999.

לאחר חלוקת הקובץ, עליך לבחור שיטה לשמירתו בשרת. להשתמש upload.saveBigFilePart במקרה שהגודל המלא של הקובץ הוא יותר מ-10 מגה-בייט ו upload.saveFilePart עבור קבצים קטנים יותר.
[…] אחת משגיאות קלט הנתונים הבאות עשויה להיות מוחזרת:

FILE_PARTS_INVALID — מספר חלקים לא חוקי. הערך אינו בין 1..3000

האם משהו מכל זה בתרשים? האם ניתן להביע את זה איכשהו באמצעות TL? לא. אבל תסלחו לי, אפילו הטורבו פסקל של סבא הצליח לתאר את הסוגים שצוינו טווחים. והוא ידע עוד דבר אחד, שעכשיו ידוע יותר בשם enum - סוג המורכב מספירה של מספר קבוע (קטן) של ערכים. בשפות כמו C - מספרית, שימו לב שעד כה דיברנו רק על טיפוסים מספרים. אבל יש גם מערכים, מחרוזות... למשל, יהיה נחמד לתאר שהמחרוזת הזו יכולה להכיל רק מספר טלפון, נכון?

כל זה לא נמצא ב-TL. אבל יש, למשל, ב-JSON Schema. ואם מישהו אחר עשוי להתווכח על חלוקה של 512 KB, שעדיין צריך לבדוק זאת בקוד, ודא שהלקוח פשוט לא יכול היה לשלוח מספר מחוץ לטווח 1..3000 (והשגיאה המתאימה לא הייתה יכולה להתעורר) זה היה אפשרי, נכון?..

אגב, לגבי שגיאות וערכי החזרה. גם אלה שעבדו עם TL מטשטשים את עיניהם - זה לא התחוור לנו מיד כל אחד פונקציה ב-TL יכולה למעשה להחזיר לא רק את סוג ההחזר המתואר, אלא גם שגיאה. אבל לא ניתן להסיק זאת בשום אופן באמצעות ה-TL עצמו. כמובן, זה כבר ברור ואין צורך בשום דבר בפועל (אם כי למעשה, RPC יכול להתבצע בדרכים שונות, נחזור לזה בהמשך) - אבל מה לגבי טוהר המושגים של Mathematics of Abstract Types מהעולם השמימי?.. הרמתי את המשיכה - אז תתאים אותה.

ולבסוף, מה לגבי קריאות? ובכן, שם, באופן כללי, הייתי רוצה תיאור יש את זה נכון בסכימה (בסכימת 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. או להפך. אבל זה עבד! כלומר, לשרת לא היה אכפת מהסוג. איך זה יכול להיות? התשובה עשויה להינתן לנו על ידי קטעי קוד מ-telgram-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:

אם לקוח תומך בשכבה 2, יש להשתמש בבנאי הבא:
invokeWithLayer2#289dd1f6 {X:Type} query:!X = X;
בפועל, זה אומר שלפני כל קריאת API, int עם הערך 0x289dd1f6 יש להוסיף לפני מספר השיטה.

נשמע נורמלי. אבל מה קרה אחר כך? ואז הופיע

invokeWithLayer3#b7475268 query:!X = X;

אז מה הלאה? כפי שאתה יכול לנחש,

invokeWithLayer4#dea0d430 query:!X = X;

מצחיק? לא, זה מוקדם מדי לצחוק, תחשוב על זה כל אחד בקשה משכבה אחרת צריכה להיות עטופה בסוג כל כך מיוחד - אם יש לך את כולם שונים, איך עוד אתה יכול להבחין ביניהם? והוספת רק 4 בתים לפני היא שיטה די יעילה. כך,

invokeWithLayer5#417a57ae query:!X = X;

אבל ברור שאחרי זמן מה זה יהפוך לסוג של בכונליה. והפתרון הגיע:

עדכון: החל משכבה 9, שיטות עוזר invokeWithLayerN ניתן להשתמש רק יחד עם initConnection

הידד! אחרי 9 גרסאות, סוף סוף הגענו למה שנעשה בפרוטוקולי אינטרנט עוד בשנות ה-80 - הסכמה על הגרסה פעם אחת בתחילת החיבור!

אז מה הלאה?..

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

אבל עכשיו אתה עדיין יכול לצחוק. רק לאחר עוד 9 שכבות, סוף סוף נוסף בנאי אוניברסלי עם מספר גרסה, שצריך לקרוא לו רק פעם אחת בתחילת החיבור, ונראה היה שמשמעות השכבות נעלמה, עכשיו זו רק גרסה מותנית, כמו בכל מקום אחר. הבעיה נפתרה.

בְּדִיוּק?..

ואסילי, [16.07.18 14:01] אפילו ביום שישי חשבתי:
ה-Teleserver שולח אירועים ללא בקשה. יש לעטוף את הבקשות ב-InvokeWithLayer. השרת אינו עוטף עדכונים; אין מבנה לעטיפת תגובות ועדכונים.

הָהֵן. הלקוח לא יכול לציין את השכבה שבה הוא רוצה עדכונים

ואדים גונצ'רוב, [16.07.18 14:02] האם InvokeWithLayer הוא לא קב עקרוני?

ואסילי, [16.07.18 14:02] זו הדרך היחידה

ואדים גונצ'רוב, [16.07.18 14:02] שבעצם אמור להיות הסכמה על השכבה בתחילת הפגישה

אגב, מכאן נובע שלא ניתן שדרוג לאחור של הלקוח

עדכונים, כלומר. סוּג Updates בסכימה, זה מה שהשרת שולח ללקוח לא בתגובה לבקשת API, אלא באופן עצמאי כאשר מתרחש אירוע. זהו נושא מורכב שנדון בו בפוסט אחר, אך לעת עתה חשוב לדעת שהשרת שומר עדכונים גם כשהלקוח במצב לא מקוון.

לפיכך, אם אתה מסרב לעטוף כל חבילה כדי לציין את הגרסה שלה, זה מוביל באופן הגיוני לבעיות האפשריות הבאות:

השרת שולח עדכונים ללקוח עוד לפני שהלקוח הודיע באיזו גרסה הוא תומך
מה עלי לעשות לאחר שדרוג הלקוח?
מי ערבויותשדעת השרת לגבי מספר השכבה לא תשתנה במהלך התהליך?

האם לדעתך מדובר בספקולציה תיאורטית בלבד, ובפועל זה לא יכול לקרות, כי השרת כתוב נכון (לפחות, הוא נבדק היטב)? הא! לא משנה איך זה!

זה בדיוק מה שנתקלנו בו באוגוסט. ב-14 באוגוסט, היו הודעות שמשהו מתעדכן בשרתי הטלגרם... ואז ביומנים:

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

ולאחר מכן מספר מגה-בייט של עקבות מחסנית (טוב, באותו זמן רישום הרישום תוקן). אחרי הכל, אם משהו לא מזוהה ב-TL שלך, זה בינארי בחתימה, בהמשך השורה ALL הולך, פענוח יהפוך לבלתי אפשרי. מה כדאי לעשות במצב כזה?

ובכן, הדבר הראשון שעולה במוחו של מישהו הוא להתנתק ולנסות שוב. לא עזר. אנחנו מחפשים בגוגל CRC32 - התברר שהם אובייקטים מסכמה 73, למרות שעבדנו על 82. אנחנו מסתכלים היטב על היומנים - יש מזהים משתי סכמות שונות!

אולי הבעיה היא אך ורק בלקוח הלא רשמי שלנו? לא, אנו משיקים את Telegram Desktop 1.2.17 (גרסה מסופקת במספר הפצות לינוקס), הוא כותב ליומן החריגים: MTP Unexpected type id #b5223b0f read in MTPMessageMedia...

גוגל הראתה שכבר קרתה בעיה דומה לאחד הלקוחות הלא רשמיים, אבל אז מספרי הגרסאות ובהתאם לכך ההנחות היו שונות...

אז מה אנחנו צריכים לעשות? ואסילי ואני נפרדנו: הוא ניסה לעדכן את המעגל ל-91, החלטתי לחכות כמה ימים ולנסות ב-73. שתי השיטות עבדו, אבל מכיוון שהן אמפיריות, אין הבנה של כמה גרסאות למעלה או למטה אתה צריך לקפוץ, או כמה זמן אתה צריך לחכות .

מאוחר יותר הצלחתי לשחזר את המצב: אנו מפעילים את הלקוח, מכבים אותו, מקמפלים מחדש את המעגל לשכבה אחרת, מפעילים מחדש, תופסים שוב את הבעיה, חוזרים לקודמת - אופס, אין כמות של החלפת מעגלים והלקוח מפעיל מחדש למשך כמה דקות יעזרו. תקבל שילוב של מבני נתונים משכבות שונות.

הֶסבֵּר? כפי שניתן לנחש מסימפטומים עקיפים שונים, השרת מורכב מתהליכים רבים מסוגים שונים במכונות שונות. סביר להניח שהשרת שאחראי ל"חצץ" הכניס לתור את מה שהממונים עליו נתנו לו, והם נתנו את זה בתוכנית שהייתה קיימת בזמן היצירה. ועד שהתור הזה "רקוב", לא ניתן היה לעשות דבר בנידון.

אולי... אבל זה קב נורא?!.. לא, לפני שנחשוב על רעיונות מטורפים, בואו נסתכל על הקוד של הלקוחות הרשמיים. בגרסת האנדרואיד אנחנו לא מוצאים שום מנתח TL, אבל אנחנו כן מוצאים קובץ כבד (GitHub מסרב לגעת בו) עם (דה) סדרה. להלן קטעי הקוד:

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

או

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

הממ... נראה פראי. אבל, כנראה, זה נוצר קוד, אז בסדר?.. אבל זה בהחלט תומך בכל הגרסאות! נכון, לא ברור למה הכל מעורבב ביחד, צ'אטים סודיים ועוד כל מיני _old7 איכשהו לא נראים כמו דור מכונה... עם זאת, יותר מכל נדהמתי

TL_message_layer104
TL_message_layer104_2
TL_message_layer104_3

חבר'ה, אתם אפילו לא יכולים להחליט מה יש בתוך שכבה אחת?! ובכן, בסדר, נניח ש"שניים" שוחררו עם שגיאה, טוב, זה קורה, אבל שלוש?.. מיד, שוב אותו גריפה? איזה סוג של פורנוגרפיה זה, סליחה?

בקוד המקור של 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;

ההערה הזו "נוצרה באופן ידני" מרמזת שרק חלק מהקובץ הזה נכתב באופן ידני (האם אתה יכול לדמיין את כל סיוט התחזוקה?), והשאר נוצר על ידי מכונה. אולם אז מתעוררת שאלה נוספת - שהמקורות זמינים לא לגמרי (א la GPL blobs בקרנל של לינוקס), אבל זה כבר נושא לחלק השני.

אבל די. בוא נעבור לפרוטוקול שעליו מתנהלת כל ההסדרה הזו.

MTProto

אז בואו נפתח תיאור כללי и תיאור מפורט של הפרוטוקול והדבר הראשון שאנחנו נתקלים בו הוא הטרמינולוגיה. ועם שפע של הכל. באופן כללי, נראה שזו תכונה קניינית של טלגרם - לקרוא לדברים בצורה שונה במקומות שונים, או לדברים שונים במילה אחת, או להיפך (לדוגמה, ב-API ברמה גבוהה, אם אתה רואה חבילת מדבקות, זה לא מה שחשבת).

לדוגמה, "הודעה" ו-"Session" אומרות כאן משהו שונה מאשר בממשק הלקוח הרגיל של Telegram. ובכן, הכל ברור עם ההודעה, אפשר לפרש אותה במונחי OOP, או פשוט לקרוא למילה "מנות" - זו רמת תחבורה נמוכה, אין אותן הודעות כמו בממשק, יש הרבה הודעות שירות . אבל הפגישה... אבל קודם כל.

שכבת תחבורה

הדבר הראשון הוא תחבורה. הם יספרו לנו על 5 אפשרויות:

TCP
רשת אינטרנט
Websocket על HTTPS
HTTP
HTTPS

ואסילי, [15.06.18 15:04] יש גם תחבורה UDP, אבל זה לא מתועד

ו-TCP בשלוש גרסאות

הראשון דומה ל-UDP דרך TCP, כל חבילה כוללת מספר רצף ו-crc
מדוע קריאת מסמכים בעגלה כואבת כל כך?

ובכן, הנה זה עכשיו TCP כבר ב-4 גרסאות:

מקוצר
ביניים
ביניים מרופד
מלא

ובכן, בסדר, ביניים מרופד עבור MTProxy, זה נוסף מאוחר יותר עקב אירועים ידועים. אבל למה עוד שתי גרסאות (שלוש בסך הכל) כשאפשר להסתדר עם אחת? כל הארבעה נבדלים זה מזה רק כיצד להגדיר את האורך והמטען של ה-MTProto הראשי, אשר יידונו בהמשך:

ב-Abridged זה 1 או 4 בתים, אבל לא 0xef, ואז הגוף
ב-Intermediate זה 4 בתים של אורך ושדה, והפעם הראשונה שהלקוח חייב לשלוח 0xeeeeeeee כדי לציין שזה ביניים
באופן מלא הכי ממכר, מנקודת מבטו של רשת: אורך, מספר רצף, ולא THE ONE שהוא בעיקר MTProto, body, CRC32. כן, כל זה על גבי TCP. מה שמספק לנו תחבורה אמינה בצורה של זרם בתים רציף; אין צורך ברצפים, במיוחד סכומי ביקורת. אוקיי, עכשיו מישהו יתנגד לי של-TCP יש סכום ביקורת של 16 סיביות, אז מתרחשת שחיתות בנתונים. מצוין, אבל למעשה יש לנו פרוטוקול קריפטוגרפי עם גיבובים של יותר מ-16 בתים, כל השגיאות הללו - ואפילו יותר - ייתפסו על ידי אי התאמה של SHA ברמה גבוהה יותר. אין טעם ב-CRC32 נוסף על זה.

הבה נשווה את Abridged, שבה אפשר בית אחד באורך, עם Intermediate, שמצדיק "במקרה שיש צורך ביישור נתונים של 4 בתים", וזה די שטויות. מה, מאמינים שמתכנתי טלגרם הם כל כך לא מוכשרים שהם לא יכולים לקרוא נתונים משקע לתוך מאגר מיושר? אתה עדיין צריך לעשות זאת, כי קריאה יכולה להחזיר לך כל מספר של בתים (ויש גם שרתי פרוקסי, למשל...). או מצד שני, למה לחסום את Abridged אם עדיין יהיה לנו ריפוד כבד על גבי 16 בתים - חסוך 3 בתים לפעמים ?

מתקבל הרושם שניקולאי דורוב מאוד אוהב להמציא מחדש גלגלים, כולל פרוטוקולי רשת, ללא כל צורך מעשי של ממש.

אפשרויות תחבורה אחרות, כולל. אינטרנט ו-MTProxy, לא נשקול כעת, אולי בפוסט אחר, אם תהיה בקשה. לגבי אותו MTProxy, בואו נזכור רק עכשיו שזמן קצר לאחר שחרורו ב-2018, ספקים למדו במהירות לחסום אותה, המיועדת עבור עוקף חסימהעל ידי גודל החבילה! וגם העובדה ששרת ה-MTProxy שנכתב (שוב על ידי וולטמן) ב-C היה קשור יתר על המידה לפרטי לינוקס, למרות שזה לא היה נדרש כלל (Phil Kulin יאשר), וששרת דומה ב-Go או ב-Node.js יעשה זאת. מתאים בפחות ממאה שורות.

אבל נסיק מסקנות לגבי האוריינות הטכנית של האנשים האלה בסוף הסעיף, לאחר שנבחן נושאים אחרים. לעת עתה, נעבור לשכבה 5 של OSI, סשן - עליה הניחו את סשן MTProto.

מפתחות, הודעות, הפעלות, דיפי-הלמן

הם הציבו את זה שם לא לגמרי נכון... הפעלה היא לא אותה הפעלה שנראית בממשק תחת הפעלות פעילות. אבל לפי הסדר.

אז קיבלנו מחרוזת בתים באורך ידוע משכבת התחבורה. זו הודעה מוצפנת או טקסט רגיל - אם אנחנו עדיין בשלב הסכם המפתח ובעצם עושים את זה. על איזה מבין שלל המושגים שנקראים "מפתח" אנחנו מדברים? בואו נבהיר את הנושא הזה עבור צוות הטלגרם עצמו (אני מתנצל על תרגום התיעוד שלי מאנגלית עם מוח עייף בשעה 4 לפנות בוקר, היה קל יותר להשאיר כמה ביטויים כפי שהם):

יש שתי ישויות שנקראות מושב - אחד בממשק המשתמש של לקוחות רשמיים תחת "הפעלות נוכחיות", כאשר כל הפעלה תואמת למכשיר / מערכת הפעלה שלם.
שנית - מפגש MTProto, שיש בו את מספר הרצף של ההודעה (במובן ברמה נמוכה), ואיזה עשוי להימשך בין חיבורי TCP שונים. ניתן להתקין מספר הפעלות של MTProto בו-זמנית, למשל, כדי להאיץ את הורדת הקבצים.

בין שני אלה הפעלות יש מושג אישור. במקרה המנוון, אפשר לומר זאת הפעלה של ממשק משתמש זהה ל אישור, אבל אבוי, הכל מסובך. בואו נראה:

המשתמש במכשיר החדש יוצר לראשונה מפתח אימות ומגביל אותו לחשבון, למשל באמצעות SMS - זו הסיבה אישור

זה קרה בתוך הראשון מפגש MTProto, שיש session_id בתוך עצמך.

בשלב זה, השילוב אישור и session_id יכול להיקרא למשל - מילה זו מופיעה בתיעוד ובקוד של חלק מהלקוחות

לאחר מכן, הלקוח יכול לפתוח כמה הפעלות של MTProto תחת אותו הדבר מפתח אימות - לאותו DC.

ואז, יום אחד הלקוח יצטרך לבקש ממנו את הקובץ DC אחר - ועבור DC זה ייווצר אחד חדש מפתח אימות !

להודיע למערכת שלא משתמש חדש נרשם אלא אותו הדבר אישור (הפעלה של ממשק משתמש), הלקוח משתמש בקריאות API auth.exportAuthorization בבית DC auth.importAuthorization ב-DC החדש.

הכל אותו דבר, כמה עשויים להיות פתוחים הפעלות של MTProto (כל אחד משלו session_id) ל-DC החדש הזה, תחת שלו מפתח אימות.

לבסוף, ייתכן שהלקוח ירצה Perfect Forward Secrecy. כֹּל מפתח אימות היה קבוע מפתח - לכל DC - והלקוח יכול להתקשר auth.bindTempAuthKey לשימוש זמני מפתח אימות - ושוב, רק אחד temp_auth_key לכל DC, משותף לכולם הפעלות של MTProto ל-DC הזה.

שים לב ש מלח (ומלחים עתידיים) הוא גם אחד על מפתח אימות הָהֵן. משותף בין כולם הפעלות של MTProto לאותו DC.

מה המשמעות של "בין חיבורי TCP שונים"? אז זה אומר משהו כמו עוגיית הרשאה באתר - היא ממשיכה (שורדת) חיבורי TCP רבים לשרת נתון, אבל יום אחד היא מתקלקלת. רק בשונה מ-HTTP, ב-MTProto הודעות בתוך הפעלה ממוספרות ומאושרות ברצף; אם הן נכנסו למנהרה, החיבור נשבר - לאחר יצירת חיבור חדש, השרת ישלח בחביבות את כל מה שבסשן הזה שהוא לא העביר בקודם חיבור TCP.

עם זאת, המידע לעיל מסוכם לאחר חודשים רבים של חקירה. בינתיים, האם אנו מיישמים את הלקוח שלנו מאפס? - נחזור להתחלה.

אז בואו ניצור auth_key על גרסאות דיפי-הלמן מטלגרם. בואו ננסה להבין את התיעוד...

Vasily, [19.06.18 20:05] data_with_hash := SHA1(נתונים) + נתונים + (כל בתים אקראי); כך שהאורך שווה ל-255 בתים;
מוצפנים_נתונים := RSA(data_with_hash, server_public_key); מספר באורך 255 בתים (אנדיאן גדול) מועלה לעוצמה הנדרשת על המודולוס הדרוש, והתוצאה מאוחסנת כמספר של 256 בתים.

יש להם DH סמים

לא נראה כמו DH של אדם בריא
אין שני מפתחות ציבוריים ב-dx

ובכן, בסופו של דבר זה הוסדר, אבל נשארו שאריות - הוכחה לעבודה נעשית על ידי הלקוח שהוא הצליח לחשב את המספר. סוג הגנה מפני התקפות DoS. ומפתח RSA משמש רק פעם אחת בכיוון אחד, בעצם להצפנה new_nonce. אבל בעוד שהמבצע הפשוט לכאורה הזה יצליח, עם מה תצטרך להתמודד?

ואסילי, [20.06.18/00/26 XNUMX:XNUMX] עדיין לא הגעתי לבקשת האפליקציה

שלחתי בקשה זו ל-DH

ובמעגן התחבורה כתוב שהוא יכול להגיב עם 4 בתים של קוד שגיאה. זה הכל

ובכן, הוא אמר לי -404, אז מה?

אז אמרתי לו: "תפוס את השטויות שלך מוצפן עם מפתח שרת עם טביעת אצבע כזו, אני רוצה DH," וזה הגיב עם 404 טיפשי

מה הייתם חושבים על תגובת השרת הזו? מה לעשות? אין את מי לשאול (אבל עוד על כך בחלק השני).

כאן כל העניין נעשה על המזח

אין לי מה לעשות, פשוט חלמתי להמיר מספרים הלוך ושוב

שני מספרי 32 סיביות. ארזתי אותם כמו כולם

אבל לא, צריך להוסיף את שני אלה לשורה תחילה בתור BE

ואדים גונצ'רוב, [20.06.18 15:49] ובגלל זה 404?

ואסילי, [20.06.18 15:49] כן!

ואדים גונצ'רוב, [20.06.18 15:50] אז אני לא מבין מה הוא יכול "לא מצא"

וסילי, [20.06.18 15:50] כ

לא הצלחתי למצוא פירוק כזה לגורמים ראשוניים%)

אפילו לא ניהלנו דיווח על שגיאות

ואסילי, [20.06.18 20:18] אה, יש גם MD5. כבר שלושה חשישים שונים

טביעת האצבע של המפתח מחושבת באופן הבא:
digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)
SHA1 ו-sha2

אז בואו נניח את זה auth_key קיבלנו 2048 סיביות בגודל באמצעות דיפי-הלמן. מה הלאה? בשלב הבא אנו מגלים ש-1024 הסיביות התחתונות של המפתח הזה לא משמשות בשום צורה... אבל בואו נחשוב על זה לעת עתה. בשלב זה, יש לנו סוד משותף עם השרת. הוקם אנלוגי למפגש TLS, שהוא הליך יקר מאוד. אבל השרת עדיין לא יודע כלום על מי אנחנו! עדיין לא, בעצם. הרשאה. הָהֵן. אם חשבתם במונחים של "סיסמת כניסה", כמו שעשיתם פעם ב-ICQ, או לפחות "מפתח כניסה", כמו ב-SSH (לדוגמה, ב-gitlab/github כלשהו). קיבלנו אחד אנונימי. מה אם השרת אומר לנו "מספרי הטלפון האלה מטופלים על ידי DC אחר"? או אפילו "מספר הטלפון שלך אסור"? הכי טוב שאנחנו יכולים לעשות זה לשמור את המפתח בתקווה שהוא יהיה שימושי ולא ירקב עד אז.

אגב, "קיבלנו" אותו בהסתייגויות. לדוגמה, האם אנו סומכים על השרת? מה אם זה מזויף? יהיה צורך בבדיקות קריפטוגרפיות:

Vasily, [21.06.18 17:53] הם מציעים ללקוחות ניידים לבדוק מספר 2kbit עבור ראשוניות%

אבל זה לא ברור בכלל, nafeijoa

ואסילי, [21.06.18 18:02] המסמך לא אומר מה לעשות אם יתברר שזה לא פשוט

לא נאמר. בוא נראה מה לקוח אנדרואיד הרשמי עושה במקרה זה? א זה מה ש (וכן, כל הקובץ מעניין) - כמו שאומרים, אני פשוט אשאיר את זה כאן:

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

לא, כמובן שזה עדיין שם כמה יש מבחנים לראשוניות של מספר, אבל אישית כבר אין לי מספיק ידע במתמטיקה.

אוקיי, השגנו את המפתח הראשי. כדי להיכנס, כלומר. לשלוח בקשות, עליך לבצע הצפנה נוספת באמצעות AES.

מפתח ההודעה מוגדר כ-128 הסיביות האמצעיות של SHA256 של גוף ההודעה (כולל הפעלה, מזהה הודעה וכו'), כולל בתים של ריפוד, לפנים 32 בתים שנלקחו ממפתח ההרשאה.

וסילי, [22.06.18 14:08] ממוצע, כלבה, חתיכות

קיבלו auth_key. את כל. מעבר להם... לא ברור מהמסמך. אל תהסס ללמוד את קוד הקוד הפתוח.

שימו לב ש-MTProto 2.0 דורש ריפוד בין 12 ל-1024 בתים, עדיין בתנאי שאורך ההודעה המתקבלת יתחלק ב-16 בתים.

אז כמה ריפוד כדאי להוסיף?

וכן, יש גם 404 במקרה של שגיאה

אם מישהו למד היטב את התרשים והטקסט של התיעוד, הוא שם לב שאין שם MAC. וה-AES משמש במצב IGE מסוים שאינו בשימוש בשום מקום אחר. הם, כמובן, כותבים על זה בשאלות הנפוצות שלהם... כאן, למשל, מפתח ההודעה עצמו הוא גם ה-SHA hash של הנתונים המפוענחים, המשמש לבדיקת תקינות - ובמקרה של חוסר התאמה, התיעוד מסיבה כלשהי ממליץ להתעלם מהם בשקט (אבל מה לגבי אבטחה, מה אם ישברו אותנו?).

אני לא קריפטוגרף, אולי אין שום דבר רע במצב הזה במקרה הזה מנקודת מבט תיאורטית. אבל אני יכול לציין בבירור בעיה מעשית, באמצעות Telegram Desktop כדוגמה. הוא מצפין את המטמון המקומי (כל אלה D877F783D5D3EF8C) באותו אופן כמו הודעות ב-MTProto (רק במקרה זה גרסה 1.0), כלומר. קודם מפתח ההודעה, אחר כך הנתונים עצמם (ואיפשהו בצד הגדול העיקרי auth_key 256 בתים, בלעדיהם msg_key חֲסַר תוֹעֶלֶת). אז, הבעיה הופכת בולטת בקבצים גדולים. כלומר, אתה צריך לשמור שני עותקים של הנתונים - מוצפנים ומפוענחים. ואם יש מגה-בייט, או סטרימינג של וידאו, למשל?.. סכימות קלאסיות עם MAC אחרי טקסט ההצפנה מאפשרות לקרוא אותו בזרם, מיד לשדר אותו. אבל עם MTProto תצטרך בהתחלה להצפין או לפענח את כל ההודעה, רק לאחר מכן להעביר אותה לרשת או לדיסק. לכן, בגרסאות האחרונות של Telegram Desktop ב-cache in user_data נעשה שימוש גם בפורמט נוסף - עם AES במצב CTR.

Vasily, [21.06.18 01:27] הו, גיליתי מה זה IGE: IGE היה הניסיון הראשון של "מצב הצפנה אימות", במקור עבור Kerberos. זה היה ניסיון כושל (הוא לא מספק הגנת שלמות), והיה צריך להסירו. זו הייתה תחילתה של מסע של 20 שנה אחר מצב הצפנה אימות שעובד, שהגיע לשיאו לאחרונה במצבים כמו OCB ו- GCM.

ועכשיו הטיעונים מהצד של העגלה:

הצוות מאחורי טלגרם, בראשותו של ניקולאי דורוב, מורכב משישה אלופי ACM, מחציתם דוקטורנטים במתמטיקה. לקח להם כשנתיים להוציא את הגרסה הנוכחית של MTProto.

זה מצחיק. שנתיים ברמה נמוכה יותר

או שאתה יכול פשוט לקחת tls

אוקיי, נניח שביצענו את ההצפנה וניואנסים אחרים. האם סוף סוף אפשר לשלוח בקשות מסודרות ב-TL ולנטרל את התגובות? אז מה ואיך כדאי לשלוח? הנה, נניח, השיטה initConnection, אולי זה זה?

Vasily, [25.06.18 18:46] מאתחל חיבור ושמירת מידע במכשיר ובאפליקציה של המשתמש.

הוא מקבל app_id, device_model, system_version, app_version ו-lang_code.

וקצת שאילתה

תיעוד כמו תמיד. אתה מוזמן ללמוד את הקוד הפתוח

אם הכל היה ברור בערך עם invokeWithLayer, אז מה לא בסדר כאן? מסתבר, נניח שיש לנו - ללקוח כבר היה על מה לשאול את השרת - יש בקשה שרצינו לשלוח:

וסילי, [25.06.18 19:13] אם לשפוט לפי הקוד, השיחה הראשונה עטופה בזבל הזה, והשטות עצמה עטופה ב-invokewithlayer

למה initConnection לא יכולה להיות שיחה נפרדת, אבל חייבת להיות עטיפה? כן, כפי שהתברר, זה חייב להיעשות בכל פעם בתחילת כל פגישה, ולא פעם אחת, כמו עם המפתח הראשי. אבל! לא ניתן להתקשר אליו על ידי משתמש לא מורשה! עכשיו הגענו לשלב שבו זה ישים זֶה דף תיעוד - והוא אומר לנו ש...

רק חלק קטן משיטות ה-API זמינות למשתמשים לא מורשים:

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

הראשון שבהם, auth.sendCode, ויש את הבקשה הראשונה היקרה שבה אנחנו שולחים api_id ו-api_hash, ואחריה מקבלים SMS עם קוד. ואם אנחנו נמצאים ב-DC הלא נכון (מספרי טלפון במדינה זו משרתים על ידי אחר, למשל), אז נקבל שגיאה עם מספר ה-DC הרצוי. כדי לגלות לאיזו כתובת 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] ממ, הם מפשפשים בכמה מהאלגוריתמים ב-e2e

Mtproto מגדיר אלגוריתמי הצפנה ומפתחות לשני התחומים, כמו גם מבנה מעטפת

אבל הם כל הזמן מערבבים רמות שונות של הערימה, כך שלא תמיד ברור איפה mtproto נגמר והשלב הבא התחיל

איך הם מתערבבים? ובכן, הנה אותו מפתח זמני עבור PFS, למשל (אגב, Telegram Desktop לא יכול לעשות את זה). זה מבוצע על ידי בקשת API auth.bindTempAuthKey, כלומר מהרמה העליונה. אבל באותו זמן זה מפריע להצפנה ברמה הנמוכה יותר - אחרי זה, למשל, אתה צריך לעשות את זה שוב initConnection וכו', זה לא רק בקשה רגילה. מה שמיוחד הוא שאתה יכול לקבל רק מפתח זמני אחד לכל DC, למרות השדה auth_key_id בכל הודעה מאפשר לך לשנות את המפתח לפחות בכל הודעה, ולשרת יש את הזכות "לשכוח" את המפתח הזמני בכל עת - התיעוד לא אומר מה לעשות במקרה זה... ובכן, למה אפשר אין לך כמה מפתחות, כמו עם סט של מלחים עתידיים, ו?..

יש עוד כמה דברים שכדאי לשים לב לנושא MTProto.

הודעות הודעה, msg_id, msg_seqno, אישורים, פינגים בכיוון הלא נכון ועוד מוזרויות

למה אתה צריך לדעת עליהם? כי הם "דולפים" לרמה גבוהה יותר, ואתה צריך להיות מודע אליהם כשאתה עובד עם ה-API. בוא נניח שאנחנו לא מעוניינים ב-msg_key; הרמה הנמוכה פיענחה עבורנו הכל. אבל בתוך הנתונים המפוענחים יש לנו את השדות הבאים (גם את אורך הנתונים, אז אנחנו יודעים איפה הריפוד, אבל זה לא חשוב):

מלח - 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 לא על seq_no, כמו ב-TCP, אבל לפי msg_id !

מה זה msg_id, החשוב ביותר מבין התחומים הללו? מזהה הודעה ייחודי, כפי שהשם מרמז. הוא מוגדר כמספר של 64 סיביות, שבסיביות הנמוכות ביותר שבהן יש שוב את הקסם של "שרת-לא-שרת", והשאר הוא חותמת זמן של יוניקס, כולל החלק השברירי, המוזז 32 סיביות שמאלה. הָהֵן. חותמת זמן כשלעצמה (והודעות עם זמנים שונים מדי יידחו על ידי השרת). מכאן מסתבר שבאופן כללי מדובר על מזהה שהוא גלובלי עבור הלקוח. בהתחשב בכך - בואו נזכור session_id - מובטח לנו: בשום פנים ואופן לא ניתן לשלוח הודעה המיועדת להפעלה אחת להפעלה אחרת. כלומר, מסתבר שכבר יש שלוש רמה - הפעלה, מספר הפעלה, מזהה הודעה. מדוע סיבוך יתר כזה, המסתורין הזה גדול מאוד.

לפיכך, msg_id נחוץ ל...

RPC: בקשות, תגובות, שגיאות. אישורים.

כפי שאולי שמתם לב, אין סוג או פונקציה מיוחדת של "בצע בקשת RPC" בשום מקום בתרשים, למרות שיש תשובות. אחרי הכל, יש לנו הודעות הקשורות לתוכן! זה, כל ההודעה יכולה להיות בקשה! או לא להיות. אחרי הכל, כל יש msg_id. אבל יש תשובות:

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

כאן מצוין לאיזו הודעה מדובר בתגובה. לכן, ברמה העליונה של ה-API, תצטרכו לזכור מה היה מספר הבקשה שלכם - אני חושב שאין צורך להסביר שהעבודה היא אסינכרונית, ויכולות להיות מספר בקשות בעיצומן בו זמנית, את התשובות להן ניתן להחזיר בכל סדר? באופן עקרוני, מתוך זה והודעות שגיאה כמו אין עובדים, ניתן לעקוב אחר הארכיטקטורה מאחורי זה: השרת ששומר איתך על חיבור TCP הוא מאזן חזיתי, הוא מעביר בקשות ל-backends ואוסף אותן בחזרה באמצעות message_id. נראה שהכל כאן ברור, הגיוני וטוב.

כן?.. ואם חושבים על זה? הרי גם לתגובת ה-RPC עצמה יש שדה msg_id! האם אנחנו צריכים לצעוק לשרת "אתה לא עונה לי על התשובה!"? וכן, מה היה לגבי אישורים? עמוד אודות הודעות על הודעות אומר לנו מה זה

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

וזה חייב להיעשות על ידי כל צד. אבל לא תמיד! אם קיבלת RpcResult, זה עצמו משמש כאישור. כלומר, השרת יכול להגיב לבקשה שלך עם MsgsAck - כמו, "קיבלתי את זה." RpcResult יכול להגיב מיד. זה יכול להיות גם וגם.

וכן, אתה עדיין צריך לענות על התשובה! אִשׁוּר. אחרת, השרת יחשיב אותו כבלתי ניתן למסירה וישלח אותו אליך שוב. גם לאחר חיבור מחדש. אבל כאן, כמובן, עולה סוגיית פסקי הזמן. בואו נסתכל עליהם קצת מאוחר יותר.

בינתיים, בואו נסתכל על שגיאות אפשריות בביצוע שאילתה.

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

אה, מישהו יצעק, הנה פורמט יותר אנושי – יש בשורה! קח את הזמן. כאן רשימה של שגיאות, אבל כמובן לא שלם. ממנו אנו למדים שהקוד הוא משהו כמו שגיאות HTTP (טוב, כמובן, לא מכבדים את הסמנטיקה של התגובות, במקומות מסוימים הן מופצות באופן אקראי בין הקודים), והשורה נראית כך CAPITAL_LETTERS_AND_NUMBERS. לדוגמה, PHONE_NUMBER_OCCUPIED או FILE_PART_Х_MISSING. ובכן, כלומר, אתה עדיין צריך את הקו הזה לְנַתֵחַ. לדוגמה, FLOOD_WAIT_3600 זה אומר שאתה צריך לחכות שעה, ו PHONE_MIGRATE_5, שמספר טלפון עם קידומת זו חייב להיות רשום ב-5th DC. יש לנו שפת טיפוס, נכון? אנחנו לא צריכים ויכוח ממחרוזת, רגילים יעשו זאת, בסדר.

שוב, זה לא בעמוד הודעות השירות, אבל, כפי שכבר נהוג בפרויקט זה, ניתן למצוא את המידע בדף תיעוד אחר. או להטיל חשד. ראשית, תראה, הקלדה/הפרת שכבה - RpcError ניתן לקנן RpcResult. למה לא בחוץ? מה לא לקחנו בחשבון?.. בהתאם, היכן הערבות לכך RpcError לא יכול להיות מוטבע ב RpcResult, אבל להיות ישירות או מקונן בסוג אחר?.. ואם זה לא יכול, למה זה לא ברמה העליונה, כלומר. זה חסר req_msg_id ? ..

אבל בואו נמשיך לגבי הודעות שירות. הלקוח עשוי לחשוב שהשרת חושב הרבה זמן ולבקש את הבקשה הנפלאה הזו:

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

ישנן שלוש תשובות אפשריות לשאלה זו, שוב מצטלבות עם מנגנון האישור; הניסיון להבין מה הן צריכות להיות (ומה הרשימה הכללית של הסוגים שאינם דורשים אישור) נותר לקורא כשיעורי בית (שימו לב: המידע ב קוד המקור של Telegram Desktop אינו שלם).

התמכרות לסמים: סטטוסים של הודעות

באופן כללי, מקומות רבים ב-TL, MTProto ובטלגרם בכלל משאירים תחושת עקשנות, אך מתוך נימוס, טקט ואחרים מיומנויות רכות שתקנו על כך בנימוס, וצינזרנו את הגסויות בדיאלוגים. עם זאת, המקום הזהОרוב העמוד עוסק הודעות על הודעות זה מזעזע אפילו עבורי, שעובד עם פרוטוקולי רשת כבר הרבה זמן וראה אופניים בדרגות שונות של עקומה.

זה מתחיל בתמימות, עם אישורים. אחר כך הם מספרים לנו על

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 שניות, בזמן שאתה שומע אותו, הוא יגיע לעוד אחד, וסביר להניח שהחיבור יתקלקל. ובכן, ברור מאיפה הרגליים מגיעות - "שמעתי צלצול, אבל לא יודע איפה זה", יש את האלגוריתם של Nagl ואפשרות TCP_NODELAY המיועדת לעבודה אינטראקטיבית. אבל, תסלחו לי, תחזיקו בערך ברירת המחדל שלו - 200 אָלְפִּיתשניות אם אתה באמת רוצה לתאר משהו דומה ולשמור על כמה מנות אפשריות, אז דחה את זה ל-5 שניות, או מה שלא יהיה פסק הזמן של הודעת "המשתמש מקליד..." כעת. אבל לא יותר.

ולבסוף, פינג. כלומר, בדיקת החיים של חיבור ה-TCP. זה מצחיק, אבל לפני כעשר שנים כתבתי טקסט ביקורתי על השליח של המעונות של הפקולטה שלנו - המחברים שם גם פינג לשרת מהלקוח, ולא להיפך. אבל סטודנטים שנה ג' זה דבר אחד, ומשרד בינלאומי זה דבר אחר, נכון?..

ראשית, תוכנית חינוכית קטנה. חיבור TCP, בהיעדר החלפת מנות, יכול לחיות במשך שבועות. זה גם טוב וגם רע, תלוי במטרה. טוב אם היה לך חיבור SSH פתוח לשרת, קמת מהמחשב, אתחלת את הראוטר, חזרת למקום שלך - הסשן דרך השרת הזה לא נקרע (לא הקלדת כלום, לא היו מנות) , זה נוח. זה רע אם יש אלפי לקוחות בשרת, שכל אחד מהם תופס משאבים (שלום, Postgres!), והמארח של הלקוח אולי התאתחל מזמן - אבל לא נדע על כך.

מערכות צ'אט/IM נכנסות למקרה השני מסיבה אחת נוספת - סטטוסים מקוונים. אם המשתמש "נפל", עליך ליידע את בני שיחו על כך. אחרת תסתיים בטעות שעשו יוצרי ג'אבר (ותיקנו במשך 20 שנה) - המשתמש התנתק, אבל הם ממשיכים לכתוב לו הודעות, מתוך אמונה שהוא מקוון (שגם הלכו לאיבוד לגמרי באלה כמה דקות לפני גילוי הניתוק). לא, אפשרות ה-TCP_KEEPALIVE, שאנשים רבים שלא מבינים כיצד פועלים טיימרים של TCP זורקים באופן אקראי (על ידי הגדרת ערכי פרא כמו עשרות שניות), לא תעזור כאן - אתה צריך לוודא שלא רק ליבת מערכת ההפעלה של המחשב של המשתמש חי, אבל גם מתפקד כרגיל, מסוגל להגיב, והאפליקציה עצמה (אתה חושב שהיא לא יכולה להקפיא? Telegram Desktop באובונטו 18.04 קפא לי יותר מפעם אחת).

בגלל זה אתה צריך לעשות פינג שרת לקוח, ולא להיפך - אם הלקוח יעשה זאת, אם החיבור נשבר, הפינג לא יימסר, המטרה לא תושג.

מה אנחנו רואים בטלגרם? זה בדיוק ההפך! ובכן, כלומר. רשמית, כמובן, שני הצדדים יכולים לעשות פינג אחד לשני. בפועל, לקוחות משתמשים בקביים ping_delay_disconnect, שמגדיר את הטיימר בשרת. ובכן, תסלחו לי, זה לא תלוי בלקוח להחליט כמה זמן הוא רוצה לחיות שם בלי פינג. השרת, על סמך העומס שלו, יודע טוב יותר. אבל, כמובן, אם לא אכפת לך מהמשאבים, אז אתה תהיה פינוקיו הרשע של עצמך, וקב יעשה...

איך היה צריך לעצב אותו?

אני מאמין שהעובדות לעיל מצביעות בבירור על כך שצוות Telegram/VKontakte אינו מוכשר במיוחד בתחום התחבורה (והרמה הנמוכה יותר) של רשתות מחשבים וכישוריהם הנמוכים בעניינים רלוונטיים.

למה התברר שזה כל כך מסובך, ואיך אדריכלי טלגרם יכולים לנסות להתנגד? את העובדה שהם ניסו לעשות סשן ששורד הפסקות חיבור של TCP, כלומר, מה שלא נמסר עכשיו, נעביר בהמשך. הם כנראה גם ניסו לבצע טרנספורט UDP, אבל הם נתקלו בקשיים ונטשו אותו (בגלל זה התיעוד ריק - לא היה במה להתפאר). אבל בגלל חוסר הבנה של איך רשתות בכלל ו-TCP בפרט עובדות, איפה אפשר לסמוך על זה, ואיפה צריך לעשות את זה בעצמך (ואיך), וניסיון לשלב את זה עם קריפטוגרפיה "שתי ציפורים עם אבן אחת", זו התוצאה.

איך זה היה נחוץ? על סמך העובדה ש msg_id הוא חותמת זמן הנחוצה מנקודת מבט קריפטוגרפית כדי למנוע התקפות של משחק חוזר, זו טעות לצרף אליו פונקציית מזהה ייחודית. לכן, מבלי לשנות מהותית את הארכיטקטורה הנוכחית (כאשר זרם העדכונים נוצר, זה נושא API ברמה גבוהה עבור חלק אחר מסדרת הפוסטים הזו), יהיה צורך:

השרת המחזיק בחיבור ה-TCP ללקוח לוקח אחריות - אם הוא קרא מהשקע, נא לאשר, לעבד או להחזיר שגיאה, ללא הפסדים. אז האישור אינו וקטור של מזהים, אלא פשוט "האחרון שהתקבל seq_no" - רק מספר, כמו ב-TCP (שני מספרים - ההמשך שלך והמספר שאושר). אנחנו תמיד בתוך הפגישה, לא?
חותמת הזמן למניעת התקפות חוזרות הופכת לשדה נפרד, a la nonce. זה נבדק, אבל לא משפיע על שום דבר אחר. די ו uint32 - אם המלח שלנו משתנה לפחות כל חצי יום, נוכל להקצות 16 ביטים לסיביות מסדר נמוך של חלק שלם של הזמן הנוכחי, השאר - לשבריר של שנייה (כמו עכשיו).
הוסר msg_id בכלל - מנקודת המבט של הבקשות של הבקשות ב-backends, יש, ראשית, את מזהה הלקוח, ושנית, מזהה הפגישה, לשרשר אותם. בהתאם לכך, רק דבר אחד מספיק כמזהה בקשה 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 במקום זאת? ציטוט בנושא:

בעת שימוש ב-PFS ב-TLS, כרטיסי הפעלה של TLS (RFC 5077) כדי לחדש הפעלה מוצפנת ללא ניהול משא ומתן מחדש על מפתחות וללא אחסון מידע מפתח בשרת. בעת פתיחת החיבור הראשון ויצירת מפתחות, השרת מצפין את מצב החיבור ומשדר אותו ללקוח (בצורה של כרטיס הפעלה). בהתאם לכך, כאשר החיבור מתחדש, הלקוח שולח כרטיס הפעלה, כולל מפתח ההפעלה, בחזרה לשרת. הכרטיס עצמו מוצפן במפתח זמני (מפתח כרטיס הפעלה), אשר מאוחסן בשרת ויש להפיץ אותו בין כל שרתי החזית המעבדים SSL בפתרונות מקובצים.[10] לפיכך, הכנסת כרטיס הפעלה עלולה להפר את PFS אם מפתחות שרת זמניים נפגעים, למשל, כאשר הם מאוחסנים במשך זמן רב (OpenSSL, nginx, Apache מאחסנים אותם כברירת מחדל לכל משך התוכנית; אתרים פופולריים משתמשים המפתח למספר שעות, עד ימים).

כאן ה-RTT אינו אפס, אתה צריך להחליף לפחות ClientHello ו-ServerHello, ולאחר מכן הלקוח יכול לשלוח נתונים יחד עם Finished. אבל כאן עלינו לזכור שאין לנו את ה-Web, עם שלל החיבורים החדשים שנפתחו, אלא שליח, שהחיבור שלו הוא לרוב בקשות ארוכות יותר או פחות, קצרות יחסית לדפי אינטרנט - הכל מרובב. כְּלַפֵּי פְּנִים. כלומר, זה די מקובל אם לא נתקלנו בקטע ממש גרוע ברכבת התחתית.

שכחת עוד משהו? כתבו בתגובות.

המשך יבוא!

בחלק השני של סדרת פוסטים זו נשקול לא נושאים טכניים, אלא ארגוניים - גישות, אידיאולוגיה, ממשק, יחס למשתמשים וכו'. עם זאת, בהתבסס על המידע הטכני שהוצג כאן.

החלק השלישי ימשיך לנתח את הרכיב הטכני / חווית הפיתוח. תלמד, במיוחד:

המשך המגיפה עם מגוון סוגי ה-TL
דברים לא ידועים על ערוצים וקבוצות על
מדוע דיאלוגים גרועים מרוסטר
על התייחסות למסר מוחלט לעומת יחסי
מה ההבדל בין תמונה לתמונה
כיצד אמוג'י מפריעים לטקסט נטוי

וקביים אחרים! המשך לעקוב!

מקור: www.habr.com

ביקורת על הפרוטוקול והגישות הארגוניות של טלגרם. חלק 1, טכני: ניסיון בכתיבת לקוח מאפס - TL, MT