بدون هیچ فریمورکی از متد 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

این مدتی که vortex رو دارم مینویسم فهمیدم یکم تو سی++ عقب موندم و چیزای جدید زیادی بهش اضافه شدن که من اپدیت نیستم، یادگیری Rust الان برام اولویت نداره، پس این پروژه رو فعلا متوقف میکنم و تمرکزم رو میبرم روی سی++ و سیستم های با تاخیر کم، تا ببینم چی میشه و کی Rust رو دوباره میارم تو برنامه، تصمیمم رو توی پست بعدی توضیح میدم

🚀 هدف اینه که یاد بگیریم چطور یه سیستم با تاخیر کم طراحی کنیم و برنامه مون رو متناسب با اون بنویسیم یا سیستمی که داریم رو پرفورمنسش رو بهتر کنیم.

پس میام به دوتا بخش تقسیم میکنم، نوشتن یه اپلیکیشن که low latency باشه، و بخش دوم اجرای اون اپلیکیشن روی کرنلی هست که بهینه‌سازی شده.

- نوشتن سیستم با تاخیر کم (low latency system design):
طبیعتا زبون مورد استفاده مون C++ خواهد بود و برای Low Latency میاییم Memory Model، Lock-free programming، Zero-Copy design، SIMD/Vectorization، Modern C++ features (17/20) رو کار میکنیم.

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

- بهینه‌سازی سیستمی:
اینجا بهینه‌سازی سطح سیستم رو انجام میدیم که شامل CPU Architecture & Cache، Kernel tuning، Network stack optimization و IO_uring & async I/O هست.

جدای از اون پروتکل TCP/IP رو تحلیل میکنیم و با تغییرات هدفمند و حذف overhead های غیرضروری، latency رو بهبود میدیم.

پروژه‌های عملی:

- لودبالانسر لایه ۴ با io_uring که در حال توسعه‌اش هستم و هر بخش رو با بنچمارک‌های دقیق بررسی می‌کنیم #vortex
- یک market data handler کم‌تاخیر که از ابتدا با هم طراحی و پیاده‌سازی می‌کنیم #market_data_handler

هر مدت یه بار آپدیت پیشرفت و چالش‌ها رو اینجا به اشتراک میذارم.

#LowLatency #SystemProgramming
#CPlusPlus

@knowpow

فعلا یه نتیجه از کدی که توی هر ثانیه نزدیک ۵۰۰ تا ایونت رو هندل میکنه رو ببینید تا ببینیم دنیا دست کیه 😃

تک هسته، تک کانکشن

آیا این کد low latency محسوب مبشه؟ نه حتی بهش نزدیکم نیست، چرا؟ چون هر ایونت به صورت میانگین داره توی ۱~۲ میلی ثانیه هندل میشه که باید برسه به ۱۰۰~میکرو ثانیه! بله همینقدر کم 🤷‍♂️

آیا همه چی به نرم افزار وابسته اس؟ نه قطعا، اینجا سخت‌افزاره که حرف اول رو میزنه بعد میرسیم به نرم‌افزار…

@knowpow