rnl

تحذير

لم يتم تدقيق RNL بما في ذلك رمز التشفير الخاص بها حتى الآن، وبالتالي فإن RNL مخصص فقط للألعاب وتطبيقات الوسائط المتعددة في الوقت الفعلي دون معالجة أي منها يحتوي على بيانات مهمة، ولكن ليس للتطبيقات الجادة التي تحتوي على بيانات مهمة!

وصف

RNL تعني "مكتبة الشبكة في الوقت الحقيقي"

RNL هي مكتبة شبكة قائمة على UDP للتطبيقات والألعاب في الوقت الفعلي، مستوحاة من ENet وyojimbo وlibgren وما إلى ذلك.

تم تصميم RNL حول الأنماط الشائعة المستخدمة في الألعاب في الوقت الفعلي، والتي تكون مرتبطة بالمحاكاة، وليست مرتبطة بالإدخال/الإخراج، وذات حالة كاملة، لذا فإن الإدخال/الإخراج غير المتزامن ليس له معنى كبير. وبالتالي فإن التصميم الأساسي لـ RNL هو ذو ترابط واحد، وليس متعدد الخيوط. ولكن يمكنك استخدام مثيلات TRNLHost متعددة داخل عدة سلاسل مختلفة (واحد إلى عدد قليل جدًا من المثيلات لكل سلسلة واحدة)، بحيث يمكنك استضافة العديد من مباريات ألعاب الشبكة على نفس الجهاز، طالما أن هذا الجهاز قوي وسريع بما يكفي لاستضافة عدة ألعاب مباريات لعبة الشبكة في نفس الوقت.

ومن جانب عميل اللعبة، يجب تشغيل عناصر الشبكة بالكامل، إن أمكن، في مؤشر ترابط خاص (أيضًا، إن أمكن، مثبت على وحدة المعالجة المركزية)، من أجل عدد قليل من التداخلات المحتملة والمشكلات المماثلة الأخرى. (offtopic: ينطبق الأمر نفسه أيضًا على سلسلة المحادثات الصوتية، ما لم يحب المرء حدوث مشكلات محتملة في تشغيل المخزن المؤقت للصوت وما إلى ذلك، عندما لا يحصل على وقت كافٍ لوحدة المعالجة المركزية في النقاط الزمنية المناسبة. :-))

وبالنسبة للألعاب الأكبر حجمًا التي تضم أعدادًا كبيرة من العملاء في عالم لعبة واحد، يجب عليك استخدام العديد من مثيلات TRNLHost المقسمة، بحيث يجب على كل TRNLHost التعامل مع عدد قليل فقط من العملاء المتصلين، في سلاسل عمليات متعددة، وذلك بدوره على خوادم فعلية مخصصة متعددة، والتي بدورها أيضًا قد يتواصلون مع بعضهم البعض لتقليد انطباع عالم لعبة واحد كبير جدًا. تم تصميم مثيل TRNLHost واحدًا على الأقل خصيصًا لأعداد العملاء المنخفضة النموذجية، حيث أن هذه هي الحالة النموذجية لألعاب التصويب على الذات وألعاب السباق وما إلى ذلك. أو بعبارة أخرى بالنسبة لعوالم الألعاب الكبيرة التي تضم أعدادًا كبيرة من العملاء: فرق تسد (على سبيل المثال مع قطاعات عالم اللعبة المتداخلة جزئيًا مع حدود القطاع كمثال لفكرة مفهوم فرق تسد)

ادعمني

ادعموني في باتريون

سمات

• في الغالب تصميم التعليمات البرمجية الموجهة للكائنات بالكامل
• دعم IPv6
• منصة متقاطعة
  • ويندوز (مع FreePascal ودلفي)
  • لينكس (مع فري باسكال)
  • *BSD (مع FreePascal)
  • أندرويد (مع فري باسكال ودلفي)
  • داروين (MacOS(X) وiOS) (مع FreePascal وDelphi)
• بروتوكول يستند إلى UDP
• التسلسل
• القنوات
  • مع ما يلي أنواع القنوات المجانية القابلة للتكوين:
    • أمر موثوق
    • موثوقة غير مرتبة
    • أمر غير موثوق بها
    • غير موثوق بها وغير مرتبة
• مصداقية
• التجزئة وإعادة التجميع
• تجميع
• القدرة على التكيف
• قابلية النقل
• إمكانية استخدام نموذج نظير إلى نظير أو حتى نموذج هجين مختلط من نظير إلى نظير والعميل/الخادم بدلاً من نموذج العميل/الخادم النقي فقط، وبالطبع أيضًا نموذج العميل/الخادم الكلاسيكي
• مولد أرقام عشوائية زائفة آمن تشفيريًا (CSPRNG)
  • استنادًا إلى arc4random ولكن مع ChaCha20 بدلاً من RC4 باعتباره لبنة البناء الأساسية
  • مصادر متعددة للإنتروبيا (لأنه لا يجب أن تثق أبدًا بمصدر واحد للإنتروبيا، لأنه قد يكون له باب خلفي)
    • بما في ذلك استخدام تعليمات rdseed/rdrand على معالجات x86 الأحدث كمصدر إنتروبيا إضافي اختياري قائم على شبه الأجهزة، إذا كانت هذه التعليمات مدعومة بواسطة المعالج الحالي قيد التشغيل
• المصادقة المتبادلة
  • استنادًا إلى بروتوكول يشبه محطة إلى محطة (STS)، والذي يفترض أن الأطراف لديها مفاتيح توقيع، والتي تُستخدم لتوقيع الرسائل، وبالتالي توفير أمان التصغير ضد هجمات رجل في الوسط، على عكس الصعوبة الأساسية البسيطة. طريقة هيلمان دون أي امتدادات من هذا القبيل.
  • المفاتيح الخاصة/العامة طويلة المدى هي مفاتيح ED25519 وتستخدم فقط لأغراض التوقيع
• السرية الأمامية باستخدام المنحنى الإهليلجي سريع الزوال Diffie-Hellman (منحنى 25519)
  • والنتيجة من ذلك إلى جانب الحقائق الأخرى هي أن كل اتصال يحتوي دائمًا على مفاتيح قصيرة المدى خاصة وعامة ومختلفة جديدة على كلا الجانبين، وبالتالي أيضًا مفاتيح قصيرة المدى سرية مشتركة جديدة
  • المفاتيح الخاصة/العامة قصيرة المدى هي مفاتيح X25519 ويتم استخدام المفتاح السري المشترك قصير المدى فقط لأغراض التشفير المستندة إلى AEAD
• التشفير المصدق مع تشفير حزم البيانات المرتبطة (AEAD).
  • استنادًا إلى ChaCha20 كتشفير وPoly1305 كرمز مصادقة للرسالة المشفرة
• إعادة تشغيل حماية بيانات حزمة التطبيق
  • استنادًا إلى آليات الحماية المختلفة في مرحلة إنشاء الاتصال وأرقام تسلسل الحزمة المشفرة
• آلية إنشاء الاتصال المؤجل كآلية إضافية لتصغير سطح الهجوم
• الرموز المميزة للاتصال والمصادقة (كخيار اختياري، حيث يجب أن يكون لديك قناة اتصال منفصلة خارج النطاق، على سبيل المثال واجهة خلفية رئيسية تعتمد على HTTPS لإنشاء هذه العناصر والتعامل معها) كآلية إضافية لتصغير سطح الهجوم ضد تضخيم DDoS الهجمات
  • يتم نقل رموز الاتصال بنص واضح، بحيث يتم فحصها بطريقة سريعة عند أول حزمة بيانات على الإطلاق من محاولة اتصال، دون الحاجة إلى فك تشفير رمز الاتصال أولاً قبل أن يكون من الممكن التحقق من الرمز المميز، وذلك من أجل توفير وقت وحدة المعالجة المركزية في هذه المرحلة. يُستخدم هذا الخيار في المقام الأول ضد هجمات تضخيم DDoS، مما يعني أن الخادم لن يستجيب على الفور إذا لم يتطابق رمز الاتصال مع أول حزمة بيانات على الإطلاق من محاولة الاتصال، وبالتالي فإن هجمات تضخيم DDoS ستنتقل ببساطة إلى لا شئ. وبالتالي، يجب أن تكون هذه الرموز صالحة لفترة زمنية قصيرة فقط، وهو ما ينطبق أيضًا على الجانب الخلفي الرئيسي للبنية الأساسية لديك.
  • يتم نقل رموز المصادقة المميزة بشكل مشفر، بعد معالجة تبادل المفاتيح الخاصة/العامة، وإنشاء المفتاح السري المشترك، وما إلى ذلك بنجاح. الرموز المميزة للمصادقة، على عكس رمز الاتصال، ليست إجراءً مضادًا ضد هجمات فئة DDoS، بل رموز المصادقة المميزة، كما يوحي الاسم، فقط لأغراض مصادقة قناة اتصال منفصلة خارج النطاق، وبعبارة أخرى، كأغراض إضافية الحماية ضد الاتصالات غير المصرح بها، حيث يمكنك التحقق من ذلك بمزيد من التفاصيل على الجانب الخلفي الرئيسي للبنية التحتية الخاصة بك، قبل أن يتمكن "العميل" من الاتصال بالخادم الحقيقي، حيث تحدث جميع الإجراءات الحقيقية.
• محدد معدل محاولة الاتصال
  • قابلة للتكوين باستخدام ثابتين، الاندفاع والفترة
• محدد معدل عرض النطاق الترددي القابل للتكوين
• ميزة الشبكة الافتراضية الاختيارية (على سبيل المثال لحل الاسترجاع المحلي السريع الذي لا يحتوي على واجهة برمجة تطبيقات للشبكة لمباريات ألعاب اللاعب الفردي، والتي يجب أن تظل قائمة على مفهوم الخادم/العميل)
• محاكي تداخل الشبكة (على سبيل المثال لحالات الاختبار وما إلى ذلك)
  • احتمالية فقدان الحزمة المحاكية القابلة للتكوين (لكل من الحزم الواردة والصادرة)
  • الكمون المحاكى القابل للتكوين (لكل من الحزم الواردة والصادرة)
  • محاكاة الارتعاش القابلة للتكوين (لكل من الحزم الواردة والصادرة)
  • احتمالية الحزم المكررة المحاكية القابلة للتكوين (لكل من الحزم الواردة والصادرة)
• آلية تعديل صعوبة الاستجابة لطلب تحدي الاتصال الديناميكي
  • شكلي مع قيمة العامل
  • استنادًا إلى آلية تحديد نمط سلاسة الإطارات في الثانية، ولكن بدلاً من ذلك فقط إطارات في الثانية، ومحاولات الاتصال في الثانية
• المزيد من خوارزميات الضغط كخيارات
  • تفريغ (LZ77 متوافق مع تدفق البتات zlib وهجين Huffman الكنسي، فقط هوفمان الثابت الثابت في هذا التنفيذ هنا على جانب الضاغط، ولكن جانب إلغاء الضغط كامل الميزات)
  • LZBRRC (ضاغط من طراز LZ77 مع واجهة خلفية لمشفر نطاق الإنتروبيا)
  • BRRC (مبرمج نطاق الإنتروبيا من الدرجة النقية 0)
• CRC32C بدلاً من CRC32 (بدون C في النهاية)
• والكثير من الأشياء. . .

الميزات المخططة (المعروفة أيضًا باسم Todo) بترتيب عشوائي للأولويات

• المهام

إرشادات عامة للمساهمين في الكود

إرشادات عامة للمساهمين في الكود

رخصة

رخصة زليب

قناة آي آر سي

قناة IRC #rnl على Freenode

شكرًا

• شكرًا لـ Lee Salzman على ENet كمصدر إلهام لأفكار تنفيذ تصميم واجهة برمجة التطبيقات الأساسية
• شكرًا لجلين فيدلر على الإلهام لأفكار التنفيذ الموجهة نحو الأمان
• شكرًا لسيرجي إجناتشينكو ("No Bugs" Hare) على الإلهام أيضًا لأفكار التنفيذ الموجهة نحو الأمان