نموذج الخادم والعميل

نموذج طلب الخدمة أو نموذج العميل/الخادم أو نموذج المُستخدم/المُخدّم (بالإنجليزية: Client/Server Model) هو نموذج بُنيوي لتطبيق مُوزّع حيث يجري توزيع المُهام أو الأعمال بين الطرف الذي يُقدّم الخدمات أو الموارد ويُسمّى المُخدّم والطرف الذي يطلب الخدمة ويُسمّى العميل أو مُستخدم الخدمة. غالباً ما يتّصل المُخدّم مع العميل عبر شبكة حواسب، حيث يعمل كل منهما على منصّة مُنفصلة، ولكن يُمكن أن يتواجد المُخدّم والعميل ضمن نفس النظام.
يُكمن للمُخدّم أن يُشغّل برنامجاً واحداً أو أكثر من البرامج الخاصة بطرف المُخدم لتقديم خدمة واحدة أو أكثر أو مُشاركة الموارد مع عميلٍ واحدٍ أو أكثر، أمّا العميل فلا يُشارك موارده مع أحد، ولكنّه يطلب الخدمة أو الموارد من المُخدّم. لذلك يبدأ العملاء بإنشاء قنوات اتصال مع المُخدّمات التي تنتظر مبادرتهم وتعمل على تقديم الخدمة المُناسبة لهم.
من الأمثلّة عن التطبيقات التي تعتمد هذا النموذج تطبيقات البريد الإلكترونيّ والطباعة عبر الشبكة وتطبيقات الويب.

نبذة تاريخيّة

ورد ذكر شكل بدائيّ من نموذج طلب الخدمة في الوثائق المرجعيّة الخاصة بنظام أو أس 360  المُطوّر من قبل شركة أي بي أم في منتصف الستينيات من القرن الماضي، وتحديداً في الوثيقة المعنونة: "مدخل لأداء الأعمال عن بعد"، حيث كان الهدف الأساسي هو إنجاز عمل ما عن بُعد. في نهاية الستينيات، كان العمل في معهد ستانفورد للأبحاث يجري على بناء شبكة الأربانت، وقد ورد ذكر بُنيّة بدائيّة لنموذج طلب الخدمة في أوائل وثائق التعليقات، حيث ورد في الوثيقة (RFC 4) المُعنونّة: "الجدول الزمني للشبكة"  استعمال لمصطلح المُضيف المُستخدم (بالإنجليزية: Using Host) والمُضيف المُخدّم (بالإنجليزية: Serving Host)، وهي تصف أشكال بدائيّة من العملاء والمُخدّمات.
ظهرت مُصطلحات مُشابهة في الوثيقة (RFC 5) المُعنونّة: " لغة الترميّز وفك الترميز" ، حيث كان الهدف الأساسي من هذه اللغة هو تطوير القدرة على إرسال أوامر والردّ عليها بشكل مُرمّز عبر الشبكة، وسميت أطراف العلاقة بمُضيف المستخدم (بالإنجليزية: User-Host) ومُضيف المُخدم (بالإنجليزية: Server-Host). أخيراً، في عام 1978م، نشر باحثون في شركة زيروكس ورقة بحثيّة بعنوان: "الفصل بين المُعطيات والوظائف في نظام توزيع الملفّات"، وقد حرص كاتبو البحث على التمييز بين المُستخدم والعميل، الذي عرّفوه بأنّه مُستخدم لعقدة في الشبكة. أمّا استعمال كلمة مُخدّم بمعناها الحالي فقد بدأ في العام 1992م.

دور العميل ودور المُخدّم

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

الاتصال بين العميل والمُخدّم

بشكلٍ عام، الخدمة هي شكل تجريديّ يُعبّر عن الموارد التي يمكن للمُخدم أن يقدّمها للعُملاء. إنّ نظام طلب الخدمة مُصمم بحيّث يكون العُملاء غير معنيين بالآليّة التي يقوم فيها المُخدّم بالاستجابة للطلبات، ويتوجب عليهم فقط أن يكونوا قادرين على فهم الردّ الوارد من المُخدّم، ويحصل ذلك عن طريق تشغيل العميل لأحد البروتوكولات الخاصّة بالخدمة المطلوبة.
يتبادل العميل والمُخدّم الرسائل ضمن نمط الطلب/الرد (Request/Response)، حيث يرسل العميل طلباً فيقوم المُخدّم بالردّ عليه، إنّ هذا النمط هو مثال عن عمليّة اتصال بين العمليات. لنجاح الاتصال يجب أن يدعم المُخدّم والعميل نفس بروتوكولات الاتصالات، حيث تحدد هذه البروتوكولات مجموعة القواعد الخاصّة بتنسيق وإعداد ونقل البيانات فيما بينهما بحيث تحصل العمليات السابقة بطريقة مفهومة لطرفي الاتصال.
تعمل كل بروتوكولات طلب الخدمة في أقرب طبقة للتطبيقات بحسب نموذج الاتصال المستعمل، على أيّ حال تسمى هذه الطبقة بطبقة التطبيق في نموذج الإنترنت وفي نموذج الاتصال المعياريّ أيضاً، ويُعرّف كل من هذه البروتوكولات أنماطاً مُميزة خاصّة به من رسائل الطلب/الرد، كنا يُمكن أن يدعم المُخدّم واجهة برمجة تطبيقات خاصّة به، وذلك بهدف تخصيص أنماط مُتبادلة، ويسهّل ذلك من عملية مُزامنة قواعد البيانات.
قد يستقبل |المُخدّم طلبات من العديد من العُملاء في فترة قصيرة، ويمكن أن يُشكل هذا ضغطاً على موارده، لذلك تعمد المُخدمات إلى الاعتماد على نظام جدولة لطلبات العُملاء، بحيث يتمّ تصنيف هذه الطلبات بحسب أهميتها. قد تُشكّل محدوديّة موارد المُخدّم ثغرة أمنيّة لهجوم إيقاف الخدمة، حيث يعمد المهاجمون إلى استغلال التزام المُخدّم بالرد على طلبات العُملاء فيقومون بإرسال الطلبات بمعدّلٍ مُفرط.

أمثلة عن عمل نموذج طلب الخدمة

فيما يلي أمثلة عن عمل نموذج طلب الخدمة، يُظهر المثال الأول كيفيّة عمل النموذج مع بروتوكول التهيئة الآليّة للمُضيفين (DHCP)، حيث يمكن أن يعمل البروتوكول بحسب النموذج بشكلين، إمّا وفق بنية ثنائية المُستويات، أو ثلاثيّة المستويات. أمّا المثال الثاني، فهو مُخصص لإظهار كيفيّة عمل النموذج عند تصفّح الإنترنت.

مقارنة مع نموذج القرناء

بالإضافة لنموذج طلب الخدمة، هناك نموذج عمل آخر هو نموذج القرناء (P2P)، ولهذا النموذج تطبيقات عديدة في مجال الحوسبة الموزّعة. يعتمد نموذج القرناء على آليّات عمل مُختلفة مقارنة بنموذج طلب الخدمة بالإضافة لامتلاكه بُنيّة معماريّة خاصّة.
في نموذج طلب الخدمة، تُصنّف الطرفيّات لتكون إمّا مُخدّمات أو عملاء، لا يتواصل العملاء مع بعضهم البعض بشكلٍ مُباشر، ولابد من وجود وسيط هو المُخدّم. أمّا في نموذج القرناء، فتُعتبر كل الطرفيات قرين، وهي تتواصل مع بعضها البعض بشكلٍ مُباشر بدون الحاجة لوجود وسيط.
إنّ أحد الأهداف الرئيسيّة الكامنة خلف تصميم نموذج طلب الخدمة هو خلق نقطة تحكّم مركزيّة في النظام لتُقدّم الخدمة للعُملاء ، تتجمع في هذه النقطة قُدرات الحوسبة والتخزين، ويجب أن يأخذ التصميم بالحسبان عدد العُملاء الأعظميّ المُتوقّع، وغالباً ما تُستخدم آليّات توزيع الحمل وأنظمة تجاوز الفشل (Failover) على نطاقٍ واسع. أمّا في الشبكات التي تعتمد نموذج القرناء، فيتشارك قرينان أو أكثر مواردهما ويتواصلان ضمن نظام غير مركزيّ. تكون القرناء مُتكافئة أي أنّها تملك أدواراً مُتساويّة ضمن شبكة ذات بنيّة غير هرميّة الامتيازات.
في نموذج طلب الخدمة، يجب أن تُحقق المُخدّمات توافريّة عاليّة، فقد يُسبب فشل المُخدّم فشلاً في كامل النموذج بسبب مركزيّة النظام. أمّا في نموذج القرناء، فإنّ التوافريّة العاليّة ليست مطلباً أساسيّاً بسبب وجود قرائن إضافيّة فائضة تُعوّض النقص الحاصل في الخدمة أو الموارد.

هوامش

1. العنوان الأصلي هو (بالإنجليزية: Remote Job Entry).
2. العنوان الأصلي هو (بالإنجليزية: Network Timetable).
3. العنوان الأصلي هو (بالإنجليزية: (The Decode-Encode Language (DEL).
5. العنوان الأصلي هو (بالإنجليزية: DHCP Relay Agent Information Option)
6. القرين لغةً هو المصاحب والملازم ويقابله (بالإنجليزية: Peer). جمعُه قرناء، مُؤنّثه قرينة وجمعها قرائِن وقرينات.