ثلاثيّ المكاتب، هذا الشيء فعلًا إذا بتسويه من الصفر، الصعوبة أصلًا مش في «كتابة مُمرِّر (forwarder)»، بل في «تحمّل كومة الشغل الوسخ والمتعب كله».
تقريبًا في هالكُتل:
-
تصميم البروتوكول
المصافحة كيف تنعمل
المصادقة كيف تنعمل
هل نحتاج تعدد الإرسال (multiplexing) ولا لا
كيف نوحّد التعامل مع UDP وTCP وDNS
في البداية بتوفّر على نفسك، وبعدين غالبًا بتعيد كتابة كل شيء بسبب قابلية التوسّع -
مكدّس شبكة متعدد المنصات
سلوك Windows / Linux / macOS / Android / iOS كله مختلف
TUN/TAP، البروكسي على مستوى النظام، التوجيه (routing)، وطرق الاستحواذ على DNS كلها مختلفة
المقرف فعليًا هو التوافق بين المنصات، مو أسطر socket القليلة -
الأداء
إذا كثر عدد الاتصالات بتظهر المشاكل
buffer، copy، تنافس الأقفال (lock contention)، جدولة الـcoroutines، تجزئة الذاكرة، تكلفة syscalls
إنك تقدر تشغّل اتصال واحد ما يعني إنك تقدر «تضرب» في الواقع -
الاستقرارية
إعادة الاتصال بعد الانقطاع
تبديل الشبكة
السكون ثم الاستيقاظ
NAT / IPv6 / MTU / التجزئة (fragmentation)
مع كثرة الحوادث الاستثنائية، اللوجات ممكن تخلي الواحد يطلع منها بـ PTSD -
التشفير والأمان
تبادل المفاتيح
حماية من إعادة التشغيل (replay)
الأمان الأمامي (forward secrecy)
استعادة الجلسة
أمان توزيع الإعدادات
أكثر شيء يخوّف هنا «اختراع علم التشفير بنفسك»، هذا كأنه تصعّبها على نفسك -
استراتيجية التدفّق والتغليف
كيف تقطع الحِزم
كيف تخبّي الـheader
كيف تتجنب بصمة ثابتة زيادة عن اللزوم
هالأشياء مو «إذا اشتغل الاتصال خلاص»، بل «لازم ما ينفجر على المدى الطويل» -
معالجة DNS
تحليل محلي ولا تحليل بعيد
DoH / DoT / UDP خام
تلويث (pollution)، كاش، اتساق، تسرّب
كثير من مشاكل «متصل بس غريب» سببها DNS -
التوجيه والتقسيم (routing & split)
كامل، قواعد، حسب الدومين، حسب IP، حسب العملية (process)
GeoIP / GeoSite / قواعد مخصصة
نظام القواعد كلما كتبته يزيد ويصير مثل نص مُفسِّر (interpreter) نصّه -
القابلية للرصد (observability)
سجلات (logs)
tracing
حالة الاتصالات
لوحة إحصاءات
بدونها تصير الديباغينغ: طلاسم وإيمان -
نظام الإعدادات (config)
تحديث ساخن (hot update)
توافق الإعدادات
ترحيل الإصدارات (version migration)
تحقق schema
المستخدم أكثر شيء يحبه يكتب الإعدادات بشكل زبالة ثم يسبّ «النواة» إنها غير مستقرة -
منظومة العميل (client ecosystem)
GUI
اشتراكات
استيراد/تصدير الإعدادات
تكامل مع النظام
وقت تصير «منتج»، حجم كود النواة مو لازم يكون الأكبر؛ الأطراف هي اللي تبلعك -
مطبّات البرمجة بمساعدة AI نفسها
الـAI شاطر يكتب كود شبكات «يبان صح»
لكن في التزامن، الحالات الحدّية، وآلة حالات البروتوكول (protocol state machine) بسهولة يدفن ألغام
يساعدك تبني الهيكل، تكمّل boilerplate، وتكتب اختبارات
ما يقدر يبدّل عنك التحقق من صحة البروتوكول
بالنهاية غالبًا تصير: AI يطلع كود بـ5 دقايق، وأنت 5 ساعات تلتقط packets وتدور وين الغلط
إذا بتسوي نواة بسيطة بس، أصعب شيء واقعيًا هندسيًا هو:
عرّف الهدف الأدنى من البداية
لا تبدأ مباشرة متعدد المنصات
لا تبدأ مباشرة باختراع بروتوكول
لا تبدأ مباشرة بمحرك قواعد
لا تبدأ مباشرة بـ«معمارية عالية الأداء شاملة لكل شيء»
وإلا بسهولة تصير:
الأسبوع الأول: بسوي نواة الجيل القادم
الأسبوع الثاني: خلّني أول شي أشغّل تحويل TCP
الأسبوع الثالث: ليش DNS انفجر مرة ثانية
الأسبوع الرابع: خلّني أروح أعدّل على مشروع موجود أحسن
تقييم لاذع بجملة واحدة:
الكتابة من الصفر لشيء «يمشي» مو صعبة كثير، الصعب تكتب شيء «قابل للصيانة طويلًا، متعدد المنصات، مستقر، قابل للتوسع، وأداءه مو سيّئ».
إذا أنت تقيم «صعوبة MVP من الصفر بمساعدة AI» أقدر أكمل بنفس المعيار وأفككها لك إلى:
نموذج أولي خلال أسبوعين
شهر لتستخدمه بنفسك
3 أشهر بحيث ما تنسجن بالصيانة
مثل هالنسخ.