مرتضی عزیز لطف داره به من و منم ایشون رو با VPN و کانالی که توی یوتیوب دارن شناختم، ممنونم ازتون و خوش اومد میگم به دوستان جدیدی که عضو کانال شدن 🖖

روش پیاده سازی ACK پروتکل TCP توی کرنل

خب وقتی اسم TCP میاد وسط اولین چیزی که به ذهنمون خطور میکنه اینه که TCP برعکس UDP گارانتی میکنه که پکت ارسالی شما نهایت به مقصدش برسه. یکی از راه هایی که میاد میفهمه چیزی ارسال شده یا نه اینه که به ازای دریافت هر پکت داده به گیرنده بگه که این پکتی که فرستادی رو گرفتمش(ACK).

خب تا اینجای ماجرا ما یه فرستنده داریم که داده میفرسته و گیرنده به ازای هر دریافت پکت به فرستنده میگه که پکت ارسال شده رو گرفتم، اینو بزاریم کنار بریم توی کد سمت سرور:

من یه سوکت میسازم، بایند میکنمش به پورت ۸۰۸۰، شروع میکنم به گوش دادن و وقتی کانکشن جدید میاد اکسپتش میکنم و ارتباط بین کانکشن کلاینت و من برقرار میشه:

listener := net.Listen("tcp", "localhost:8080")

fmt.Printf("Server listening on %s\n", address)

conn := listener.Accept()

fmt.Printf("Accepted connection from %s\n", conn.RemoteAddr().String())

// اینجا کلاینت داره برای ما داده میفرسته ولی ما نمیخونیم. نخوندن ما به معنی ارسال نکردن ACK توسط کرنل نیست.

حالا کلاینت شروع میکنه برای ما دیتا میفرسته ولی ما هیچ دیتایی رو با سیستم کال read() نمیخونیم، سوالی که پیش میاد اینه که ایا کلاینت بدون اینکه من read انجام بدم ACK رو دریافت میکنه؟ جواب بله اس، بله دریافت میکنه!

هنگامی که یک بسته میرسه، استک TCP کرنل بلافاصله اون رو توی بافر دریافت مینویسه و یه ACK برای فرستنده میفرسته. این ACK تایید می کنه که بسته به کرنل رسیده و برای خوندن از سمت برنامه ی من که از طریق Go نوشتم آماده است. با این حال دیگه TCP منتظر نمیمونه تا برنامه قبل از تایید بیاد و داده ها رو پردازش کنه، این جدایی بین لایه های انتقال و برنامه دقیقا چیزیه که TCP رو بهینه و سریع و پاسخگو نگه میداره و تضمین میکنه که فرستنده میتونه بدون منتظر بودن پردازش داده توسط برنامه(کد ما که بالا نوشته شده) به ارسال داده ادامه بده.

- خب پس داده ها کجان؟
+ اینجا این بافر رو یادتونه؟ کرنل دقیقا وقتی دیتا رو میگیره اون رو داخل این بافر میریزه و به فرستنده که کلاینت باشه ACK رو میفرسته. و دیگه منتظر برنامه نمیمونه تا تایید بده

@knowpow

بدون هیچ فریمورکی از متد main شروع کردن همیشه سخت بوده، منم چندتا چندتا اشتباه بزرگ کردم توی این پروژه:

‏۱- لایه ها رو از هم جدا نکردم
‏۲- معماری روی کاغذ براش طراحی نکردم صرفا تو ذهنم بود و برای همین نقاط کور رو نمیدیذم
‏۳- مستقیم شروع کردم به کد زدن
‏۴- از بقیه ی پروژه ها ایده نگرفتم(خیلی کم گرفتم)

‏خلاصه که برگردیم به اول ماجرا و بورسیم که ما چی میخواییم و داریم چیکار میکنیم؟ یکم دیگه نتایج کارایی که برای حل مشکلات بالا انجام دادم میگم

@knowpow

خب، یه طراحی بسیار زیبا، چیزی که تو ذهنمه اینه که سه تا کامپوننت اصلی داریم که لاجیک برنامه توی اوناست:

‏1- Listener
‏2- Balancer(cluster of backends)
‏3- Health Checker

‏کامپوننت اول، Listener: این کامپوننت بر اساس کانفیگ میاد روی پورتی که هست ساخته میشه و شروع میکنه به اکسپت کردن کانکشن جدید، کانکشن هایی که اکسپت میشن رو به کامپوننت بعدی که بالانسر باشه میفرسته.

‏کامپوننت دوم، Balancer: این کامپوننت وظیفه داره تا سرور های بالادستی رو بهشون وصل بشه و یه استخری از کانکشن های سرورهای بالادستی داشته باشه، وضعیت سرورها رو از کامپوننت Health Checker بگیره و بر اساس اونا و کانفیگی که شده ترافیک رو روت کنه. لاجیک اصلی تصمیم گیری برای انتخاب سرور بالادستی اینجا پیاده سازی میشه.

‏کامپوننت سوم، Health Checker: این کامپوننت سوکت های خودش رو بر اساس کانفیگ روی سرور های بالادستی باز میکنه و مدام وضعیت سرورهای بالادست رو چک میکنه و اگه خبری بود به Balancer اطلاع میده تا توی انتخاب لحاظش کنه.

‏یک سری کامپوننت هم داریم که بیزینس سیستم توشون نیست و صرفا دارن کمک میکنند که سیستم به هدفش برسه و بین همه ی اینا مشترکه:
‏1- EventLoop(epoll, io uring)
‏2- Buffer Poll
‏3- Config
‏4- etc.

‏حالا دلیل زیبایی این مدل چیه؟

‏شما میتونید یه لیستی از لیسنرها داشته باشید و اون رو به یک کلاستر از بالانسر بفرستین، یعنی روی ۱۰ تا پورت گوش بدین و ترافیک اون رو فقط به یک بالانسر ارسال کنید، یا برعکسش، شما ممکنه یک لیسنر داشته باشید ولی بخوایید همزمان به چند تا سرور بفرستین.

‏دلیل اینم که health checker بیرون از کلاستره اینه که ممکنه سرورا بین کلاسترا مشترک باشه

@knowpow

🚀خب میخواستم TCP رو پیاده سازی کنم ولی آرین ایده ی بهتری داد، قرار شد با Rust بیام و یه جدول هش توزیع شده با الگوریتم Kademlia کادملیا رو پیاده سازی کنم، هم فاله هم تماشا،
هم rust یاد میگیرم هم با نتورکینگ e2e بازی میکنم. این الگوریتم توی IPFS و Ether هم استفاده شده.

داستان چیه؟ فرض کنید یه HashMap داریم و اون رو بین سرورهای مختلف توزیع میکنیم و از نتورک p2p استفاده میکنیم تا به دیتامون برسیم. کادملیا به یه روش بهینه میاد اینکارو میکنه(خودمم زیاد بلد نیستم و فقط یه ایده‌ی کلی ازش دارم). کادملیا از دو بخش استوریج و روتینگ تشکیل شده، بخش استوریج وظیفه‌ی اینو داره که بیاد داده هایی که ماژول روتینگ بهش میده رو put یا get کنه، جدا از این ماژول روتینگ وظیفه ی اینم داره که به بقیه ی نود ها به پیدا کردن نود مورد نظرشون کمک کنه، به ping ها جواب بده و بیاد شبکه رو برای تغییرات مانیتور کنه، ایده ای که این پیاده سازی رو متفاوت میکنه اینه که بیاییم روتینگ رو توی کرنل اسپیس پیاده سازی کنیم، اینجوری پرفورمنس بالاتری داریم و دیگه نیازی نیست تا لایه ی کاربر بریم بالا. ولی استوریج همونجا میمونه و به کارش ادامه میده.
برای شروع دوتا ماژول استوریج و روتینگ رو با Rust توی userspace مینویسم، بعد روتینگ رو به کرنل با C بازنویسی میکنم.
بزودی ادرس ریپو رو میزارم. پروژه ی vortex هم کنار همین ادامه پیدا میکنه.

#kdht

توضیحات آرین در مورد کادملیا:
https://ariyan-eghbal.github.io/posts/kademlia/

@knowpow

پیپر اصلی کادملیا که توی ۲۰۰۲ منتشر شده😎

@knowpow

همونطور که گفتم پروژه رو تبدیل به دوتا ماژول کردم، ماژول اول وظیفه‌ی پیاده سازی بخش روتینگ رو داره، و ماژول دوم استوریج. ایده ی اصلی کادملیا توی ماژول روتینگ پیاده سازی میشه.

باید اول بدونین که کادملیا ۴ تا پروسیجر اصلی داره: PING, FIND_NODE, STORE, FIND_VALUE که سیستم ما باید یا اینارو بفرسته یا وقتی اینارو میگیره باید یه کاری رو در قبالش انجام بده.

حالا قرار هست چیکار کنیم؟ ما اینجا ۴ تا لایه داریم که از بالا به ترتیب:

۱- لایه ی Routing که اصلی ترین بخش سیستمه اینجاست، باید بیاییم بر اساس پیام هایی که میگیریم با ماژول استوریج ارتباط بگیریم، باکت گره ها رو بروزرسانی کنیم، به بقیه ی گره ها با یه فاصله ی زمانی پیام پینگ رو بفرستیم و با توجه به جواب باکت رو بروزرسانی کنیم. درخواست های بالا رو کش کنیم و به پیام های پینگ هم جواب بدیم(شاید اینو به لایه ی rpc منتقل کردم مطمئن نیستم)

۲- لایه ی RPC وظیفه ی اینو داره که بیاد با توجه به پیامی که گرفته یا نتیجه رو برگردونه یا خطا بده و باید rate limit رو چک کنه.

۳- لایه ی Serialization/Deserialization وظیفه ی اینو داره که بیاد پیام های باینری یا جیسون رو به struct یا بلعکسش تبدیل کنه.

۴-لایه ی Communication وظیفه ی اینو داره که با توجه به پرتکلی که داره بیاد listen کنه و اماده‌ی دریافت پیام باشه، یا به یه نود وصل بشه و پیام بفرسته. توی طراحی که انجام دادم هم TCP رو ساپورت میکنم هم UDP رو، احتمالا برای نسخه ی اول فقط با UDP پیش بریم.

#kdht

@knowpow

معماری برای ماژول روتینگ
#kdht

@knowpow

“Failure is an option here. If things are not failing, you are not innovating enough.”

-Elon Musk

@knowpow

ریپو رو ساختم و کانکشن udp رو نوشتم، برای async از توکیو استفاده میکنم و نیازی به io uring نیست

https://github.com/aabolfazl/kdht

@knowpow

چیزی که توی rust اذیتم میکنه عجیب بودن سینتکسشه، اورده از هر زبون یه چیزی رو استفاده کرده یه لحظه به خودت میایی میبینی داری توی rust با سی++ جاوا مینویسی 😂 یعنی حواست نباشه به فنا میری.

البته این نظر برای امروزمه و ممکنه ماه بعد بیام بگم ای بابا چقدر ساده بودی اینم نمیدونستی؟!

@knowpow

البته سینتکس زبون ساده اس، مهم ایده ی پشته زبونه که باید یاد بگیریم،‌ یعنی باید ذهنیتمون رو راستی کنیم...

@knowpow

یه کتابخونه ی خوب از مجموعه‌ی توکیو توی راست پیدا کردم به اسم MIO که میاد پایینترین لایه ای که میشه روش ابسترکشن پیاده سازی کرد رو فراهم میکنه.
کتابخونه ی MIO روی مکانیزم‌های سیستم‌عامل(epoll توی لینوکس، kqueue توی macOS/BSD و IOCP توی ویندوز) تمرکز میکنه تا یه بدون درگیری با پیاده سازی notification system بیاییم و برنامه هامون رو بنویسیم.

حالا تفاوتش با async/await خود زبون چیه؟ اگه از رانتایم توکیو استفاده میکنید به احتمال زیاد داره از mio برای مدیریت io استفاده میکنه ولی بهتون یه اینترفیس تمیز بدون درگیری و پیاده سازی مدیریت ایونت ها رو به اسم async/await فراهم میکنه توی خود mio مستلزم پیاده سازی توسط خودتونه. mio کنترل بیشتری میده ولی پیچیدگی کدنویسی رو بالا میبره، شما باید همه چی رو دستی هندل کنید و ادامه ی ماجرا دیگه به نحوه ی پیاده سازی شما داره.

سورس کد پروژه برای ایده گرفتن:

https://github.com/tokio-rs/mio

@knowpow

I just added a YAML config loader using the cpp-yaml library to my load-balancing project. Let's implement the related cluster manager and listener manager.

✅ write accept new connection using io_uring dispatcher
✅ load listeners and clusters from the config

Next commit will be:
implement listener manager and open listener according to the listeners' config

https://github.com/aabolfazl/Vortex
#vortex #io_uring #loadbalancing #cpp

@knowpow

در باب io uring

حین اینکه Vortex رو توسعه میدادم دیدم که چقدر io_uring بزرگ و عمیقه، داکیومنت موال در موردش اونقدر غنی نبود و یا خیلی پراکنده بود، پس یه پروژه‌ی جدید رو شروع کردم به اسم io-uring-lab. تمرکزش روی بررسی و پیاده‌سازی مکانیزم io_uring توی لینوکسه، که یکی از جدیدترین و بهینه‌ترین راه‌ها برای مدیریت عملیات I/O تو سیستم‌عامله.

ایده‌ی اصلی اینه که از پایه مکانیزم io_uring رو درک کنیم و ببینیم چطوری میشه ازش برای ساخت سیستم‌های پرکاربرد استفاده کرد. برخلاف مدل‌های سنتی مثل epoll، اینجا کلی از بار سیستمی کم میشه و شما می‌تونید با یه مدل مدرن‌تر و منعطف‌تر کار کنید. چیزی که این مکانیزم رو خفن می‌کنه، کاهش overhead سیستمی و امکان اجرای عملیات async بدون نیاز به context switch های اضافیه.

فعلاً شروع کردم به ساختن یه سری example ساده برای io_uring تا بدون درگیر شدن با پیچیدگی‌های ‌لایه پایین، تا بتونم عملیات async I/O رو راحت‌تر هندل کنم. توی قدم های بعدی میرم سمت پیاده‌سازی مثال هایی از وب سرور و پولینگ سیستم ها

هر چی بگم که چقدر این مکانیزم آینده‌دار و البته عمیقه کم گفتم. میتونم به یکی از دیتابیسایی‌ که با زبون zig نوشته شده و از مکانیزم io_uring استفاده میکنه و اسمش TigerBeetle هست اشاره کنم، این سیستم برای مدیریت تراکنش‌های مالی با کارایی بالا طراحی شده اگه به این حوزه علاقه دارین یا تجربه‌ای دارید، خوشحال میشم نظر بدید یا تو پروژه مشارکت کنید.

لینک پروژه:
https://github.com/aabolfazl/io-uring-lab

#iouring

@knowpow

کدهایی که بین همه ی مثال ها مشترکه مثل logger و argument parser رو زدم و پوش کردم، تسک بعدی اینه که بریم سراغ اولین مثالمون:

لینک کامیت:
https://gtb/aabolfazl/last_commit

لینک ریپو:
https://github.com/aabolfazl/io-uring-lab

#iouring

@knowpow

راستی توی این پروژه دیشب به ۱۰۰ تا سرور توی کمتر از ۱۰۰ میلی ثانیه کانکشن async باز کردم.

میدونم اینجوری تایم نوشتن متریک خوبی برای سنجش پرفورمنس نیست ولی فعلا همینه وضعیت تا وقتی ورژن اول رو بزنم و بعد برم سراغ تست نوشتن و بنجمارکینگ درست حسابی

#vortex

@knowpow