پس تا اینجا متوجه شدیم تلگرام یک تعدادی خطوط ارتباطی با سرور ایجاد می کند و از طریق آنها دستورات را ارسال و دریافت می کند.

به عنوان نمونه در تصویر می بینید در صورت نیاز به دانلود و یا upload خط ارتباطی مجزا و با datacenterهای خاص برقرار می شود.

یعنی خط ارتباطی که با آن داده ارسال و دریافت می کنید با خط ارتباطی ارسال و دریافت فایل کاملا متفاوت است

#telegram #yum_12

نکته دیگر آنچه در اینجا مطرح میشود مربوط به اندروید است و مثلا برای وب داستان کاملا متفاوت است و تکنیک های دیگری بکار می برند

پ.ن. با موضوع کارایی اصلا شوخی نکردند و همه چیز به بهترین نحوه ممکن بوده است :)

#telegram #yum_13

خلاصه تا اینجا:
در موبایل، برای کارهای با نوع مختلف (ارسال و دریافت فایل و متن و apiهای سیستمی) خطوط/connection مختلف دارند که توسط thread پیاده سازی شده در زبان سی مدیریت می شوند و با استفاده از multiplexing امکان near real time در ارتباط را بوجود آورده اند. در موبایل تلگرام یک connection برای دریافت درخواست ها ایجاد می شود که شما از طریق ها درخواست/apiهای تلگرام را فراخوانی می کنید. یک connection برای push و دریافت پاسخ درخواست نیز ایجاد میشود. این connection دوم و یا همان push بنا به شرایطی (سرعت و یا بهتر است بگویم کیفیت ارتباط) ممکن است ایجاد نشود و از همان یک connection برای هر دو منظور استفاده شود.

#telegram #yum_14

این همه connection مدیریتش سخت نمی شود؟
تلگرام از تکنیک multi-datacenter استفاده می کند. مثلا اغلب کاربران ایرانی در dc شماره ۴ هستند و بدین ترتیب می توان متناسب با افزایش scale مدیریت لازم را اعمال کند. مثلا فرض کنید شما به dc شماره ۲ درخواست connection ارسال می کنید. درخواست شما با جابه جایی کد diffie-hellman امن میشود و پذیرفته می شود ولی به محض اینکه اولین api را فراخوانی می کنید به شما پیغام migrate to 4 را می دهند. client با دریافت این خطا connection را می بندد و سپس در preference می نوسد که زین پس باید به dc شماره ۴ متصل شود. به عبارت ساده تر در زمان طراحی پیش بینی شده است که کاربران به یک dc جدید migrate کنند.

این تکنیک با تکنیک federation در ایمیل سرورها و یا پروتکل ejabber متفاوت است.

یک نکته جالب بخشی از فرایند تصمیم گیری برای اتصال به dc به کلاینت منتقل شده و بار از روی دوش سرور برداشته شده است. این کار معمولا پیاده سازی clientها را سخت تر می کند ولی به بهبود کارایی در سمت سرور از طریق کاهش حجم کارها کمک می کند.
به عنوان یک تجربه تا انجا که می شود و مخاطره امنیتی ایجاد نمی کند کارها را بین کلاینت ها توزیع کنید :)


پیاده سازی session سمت سرور آن واقعا سخت و جذاب است 😂 شما باید لیستی از ‌connectionهای کاربر را در session کاربر نگاه دارید البته اگر در طراحی بخواهید همواره کاربر را به یک session سرور هدایت کنید (از طریق الگوریتمهای consistent hashing)

#telegram #yum_15

نکته دیگر : epoll یک روش non-blocking I/O است که با فایل معمولی کار نمی کند
#telegram #yum_16

برای ادامه (فردا شب) می خواهیم یک سرور ساده درست کنیم و با پیاده سازی مبتنی بر epoll به آن متصل شویم. بعد بر می گردیم و کد تلگرام را نگاه می کنیم

اگر تمایل داشتید این کار را به صورت قدم به قدم جلو ببریم می توانید در گروه پیغام بگذارید تا فردا شب راس یک ساعت مشخص با هم شروع کنیم :)

https://github.com/cpp-taskflow/cpp-taskflow

#cpp #C++ #thread

به عنوان یک نمونه از کاربرد:

https://github.com/noahlevenson/wasmface

سپاس از @Alihyd1 برای اشتراک این مطلب زیر

تجربه:انچه در ادامه امده بر اساس تلاش من در چند روز گذشته است.
یکی از چالشهای جدی که در wasm# با آن مواجه شدم عدم پشتیبانی از محاسبات برای داده های ۸ بایتی است!
unsigned long int
unsigned long long int

داده های ۴ بایتی هستند!
البته احتمالا در آینده نزدیک این مهم پشتیبانی می شود

یک احتمال دیگر هم هست که من نتواستم به درستی تنظیمات را انجام دهد (پارامترهای کامپایلر). از این رو اگر فردی این مهم را حل کرد لطفا به اشتراک بگذارد.

به عنوان نمونه تابع زیر فقط ۴ بایت را پر می کند!

uint64_t llui()
{
    uint64_t what = 0;
    for (int i = 0; i < 8; i++)
    {
        what += 255 << (i * 8);
    }
    return what;
}
‍

در لینک بالا یک شرایط که در اعتراض های کره در تلگرام مورد توجه کاربران فرار گرفته شده است توضیح داده شده است