تنزيل portunusd - تنزيل رمز مصدر portunusd

portunusd

فئات أخرى

Acuminatus

تنزيل

portunusd

قفص مستندات تويت خريطة الطريق

portunusd هو خادم تطبيقات شبكة مستوحى من relayd OpenBSD و Heirloom Unix inetd . يستمع لاتصال الشبكة الواردة ، وإعادة توجيه البيانات الواردة عبر باب Illumos إلى التطبيق المقصود ، وإعادة الاستجابة بطريقة مماثلة. يقوم portunusd بتعيين كل منفذ متصل بباب على نظام الملفات الذي يوفره التطبيق الهدف.

 Sequencediagram
    عميل المشارك
    المشارك portunusd
    باب المشارك
    تطبيق المشارك
    التطبيق->> الباب: إنشاء/var/run/app.door
    portunusd->> الباب: فتح
    portunusd->> portunusd: استمع على المنفذ 80
    طلبات مقبض الحلقة
        العميل->>+portunusd: أرسل طلب http
        Portunusd->>+التطبيق: طلب متصل عبر Door_Call
        التطبيق->>-portunusd: أرسل استجابة عبر Door_return
        portunusd->>-العميل: أرسل استجابة http
    نهاية

الهدف الرئيسي من portunusd هو تسهيل تحجيم التطبيقات المفردة. ضمن نموذج inetd ، يتم إنشاء عملية جديدة للتعامل مع كل طلب. من خلال الاستفادة من الأبواب ، لا يمكن portunusd إنشاء مؤشر ترابط جديد في عملية التطبيق إلا عند الوصول إلى علامة عالية من التزامن ؛ خلاف ذلك ، سيتم إعادة استخدام المواضيع الحالية للتعامل مع الطلبات اللاحقة.

بيان المشكلة

نريد تطبيقاتنا التي تواجه الشبكة على نطاق واسع وفقًا لطلب المستخدم. نريد تقليل تكلفة مورد تطبيقاتنا عندما تكون خاملاً ، ونريد الحفاظ على تكاليفنا خطية من حيث الطلب. نريد تقليل الدرجة التي يكون فيها مطور التطبيق مسؤولاً عن إدارة الموارد ، ونريد الاحتفاظ (حتى بأقصى قدر ممكن) بيئة التطوير المألوفة لأدوات خط الأوامر UNIX.

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

تتعامل بيئات مثل Node.js مع هذه المشكلة من خلال جعل عدم التزامن أكثر شفافية للمبرمج. على الرغم من أنه قد يكون من المفيد تبني الطبيعة غير المتزامنة لأجهزة الكمبيوتر ، إلا أنها قدمت أيضًا تغييرات على اللغات التي تدعمها ؛ هذا ليس مجرد تغيير في بناء الجملة ، ولكن أيضًا تغيير غير تافهة للنموذج العقلي الذي يستخدمه المرء لقراءة البرامج والكتابة وفهمها.

في الطرف الآخر من الطيف ، تتطلب تطبيقات CGI عملية ومساحة عنوان فريدة لكل طلب. يمكن أن تتوسع هذه التطبيقات خطيًا مع طلب المستخدم ، بما في ذلك التوسع في استخدام الذاكرة / وحدة المعالجة المركزية صفر عند الخمول ، ولكن تكلفة استدعاء execv(2) لكل طلب يمكن أن تعوق الإنتاجية.

يستوفي نهج ما بعد الحداثة "بدون خادم" هذه المعايير ، ولكن على حساب التخلي عن sytem التشغيلي . إنه نهج غير مألوف لتطوير البرامج ، ويرمي العديد من الأدوات التي يمكن استخدامها لمراقبة التطبيق وتصحيحه في وقت التشغيل.

أُطرُوحَة

تتيح الأبواب نموذجًا جديدًا (قديمًا؟) لتطوير تطبيقات الشبكة حيث يكون المطورين مسؤولين عن الحفاظ على مهمة خطية متزامنة وفهمها ، بينما يعمل نظام التشغيل + خادم الويب معًا على مشكلة التحجيم

عندما يكون التطبيق خاملاً ، هناك حاجة فقط إلى نسخة واحدة من الذاكرة.
عندما يدخل الطلب في النظام ، يمكن معالجته بواسطة مؤشر ترابط موجود.
يتم إنشاء المواضيع الجديدة فقط عند الوصول إلى ذروة جديدة من التزامن.

تتيح لنا هذه الصفات معالجة بيان مشكلتنا من خلال تطوير تطبيقات الشبكة التي تشعر بأنها أدوات سطر أوامر UNIX المفردة ، وتقدم الحد الأدنى من النفقات عند الخمول ، وتوسيع نطاقها خطيًا على التفاصيل لكل مسابقة.

بطبيعة الحال ، لن تتعامل الأبواب وحدها مع التحجيم عبر حدود مثيل نظام التشغيل الواحد ، ولكن التعاون على غرار Relayd مع جدار الحماية يمكن أن يسهل ذلك ، على افتراض أن نسخ التطبيق متوفرة على عدة مضيفين. هذا هو المكان الذي يأتي فيه portunusd .