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

نموذج الخادم والعميل
نموذج طلب الخدمة أو نموذج العميل/الخادم أو نموذج المنتفع والخادم هو نموذج بُنيوي لتطبيق مُوزّع حيث يجري توزيع المُهام أو الأعمال بين الطرف الذي يُقدّم الخدمات أو الموارد ويُسمّى المُخدّم والطرف الذي يطلب الخدمة ويُسمّى العميل أو مُستخدم الخدمة. غالباً ما يتّصل المُخدّم مع العميل عبر شبكة حواسب، حيث يعمل كل منهما على منصّة مُنفصلة، ولكن يُمكن أن يتواجد المُخدّم والعميل ضمن نفس النظام.
يُكمن للمُخدّم أن يُشغّل برنامجاً واحداً أو أكثر من البرامج الخاصة بطرف المُخدم لتقديم خدمة واحدة أو أكثر أو مُشاركة الموارد مع عميلٍ واحدٍ أو أكثر، أمّا العميل فلا يُشارك موارده مع أحد، ولكنّه يطلب الخدمة أو الموارد من المُخدّم. لذلك يبدأ العملاء بإنشاء قنوات اتصال مع المُخدّمات التي تنتظر مبادرتهم وتعمل على تقديم الخدمة المُناسبة لهم.
من الأمثلّة عن التطبيقات التي تعتمد هذا النموذج تطبيقات البريد الإلكترونيّ والطباعة عبر الشبكة وتطبيقات الويب.
نبذة تاريخيّة
ورد ذكر شكل بدائيّ من نموذج طلب الخدمة في الوثائق المرجعيّة الخاصة بنظام المُطوّر من قبل شركة أي بي أم في منتصف الستينيات من القرن الماضي، وتحديداً في الوثيقة المعنونة: «مدخل لأداء الأعمال عن بعد»، حيث كان الهدف الأساسي هو إنجاز عمل ما عن بُعد. في نهاية الستينيات، كان العمل في معهد ستانفورد للأبحاث يجري على بناء شبكة الأربانت، وقد ورد ذكر بُنيّة بدائيّة لنموذج طلب الخدمة في أوائل وثائق التعليقات، حيث ورد في الوثيقة (RFC 4) المُعنونّة: «الجدول الزمني للشبكة» استعمال لمصطلح المُضيف المُستخدم والمُضيف المُخدّم ، وهي تصف أشكال بدائيّة من العملاء والمُخدّمات.
ظهرت مُصطلحات مُشابهة في الوثيقة (RFC 5) المُعنونّة: «لغة الترميّز وفك الترميز» ، حيث كان الهدف الأساسي من هذه اللغة هو تطوير القدرة على إرسال أوامر والردّ عليها بشكل مُرمّز عبر الشبكة، وسميت أطراف العلاقة بمُضيف المستخدم ومُضيف المُخدم . أخيراً، في عام 1978م، نشر باحثون في شركة زيروكس ورقة بحثيّة بعنوان: «الفصل بين المُعطيات والوظائف في نظام توزيع الملفّات»، وقد حرص كاتبو البحث على التمييز بين المُستخدم والعميل، الذي عرّفوه بأنّه مُستخدم لعقدة في الشبكة. أمّا استعمال كلمة مُخدّم بمعناها الحالي فقد بدأ في العام 1992م.
بُنية وآليّة عمل النموذج
يتألّف نموذج طلب الخدمة من مجموعة من العُملاء والمُخدّمات بالإضافة إلى الشبكة التي تصلّ فيما بينهم، ويُمكن تصنيف البُنى السابقة بحسب عدد المراحل اللازمة ليحصل العميل على الخدمة، والتي تُسمى مُستويات ، بالشكل التالي:
بُنيّة ثُنائيّة المُستويات : وهو أبسط بُنية لنموذج طلب الخدمة، وفيه يتوزّع العمل بين مُخدّم وعدد من العُملاء، يضمّ خادم المُخدّم قاعدة بيانات خاصّة بالخدمة التي يُقدمّها. بشكلٍ عام، يجب على كل عميل ينفذ إلى قاعدة البيانات. عبر طلب يُقدّم إلى المُخدّم الذي يُعالج الطلبات، من سلبيات هذه البُنية محدوديّة عدد العُملاء الذين يُمكن للمُخدم دعمُهم، بالإضافة لوجود إشكالات أمنيّة بسبب حاجة كل عميل للنفاذ بشكلٍ مُستقل إلى قاعدة البيانات.
بُنيّة ثُلاثيّة المُستويات : تم تطوير هذا النموذج لتجاوز محدوديّة البُنيّة ثنائيّة المستويات، في هذه البُنية يُضاف مُستوى ثالث، في الوسط بين المستويين السابقين بهدف فصل التعامل مع العميل عن إدارة قاعدة بيانات، يضمّ هذا المُستوى بالإضافة للعميل ومُخدّم قاعدة البيانات، مُخدّماّ خاصّاً بالتطبيقات. يُمكن أن يعمل مُخدّم التطبيقات على منصّة مُستقلة، أو أن يتواجد على نفس المنصة التي يعمل عليها مُخدّم قاعدة البيانات. في البنية ثُلاثية المُستويات، فقط مُخدّم التطبيقات هو من يملك صلاحيّات النفاذ إلى قاعدة البيانات الخاصّة بالخدمة عبر مُخدّم قاعدة البيانات، وذلك عوضاً عن منح هذه الصلاحيّات لكل عميل يتقدم بطلب الحصول على الخدمة كما هو الحال في البنيّة ثُنائية المستويات. إنّ البنية السابقة هي البُنية ثُلاثيّة المُستويات الأساسيّة، وتتنوع البُنى المُشتقة عنها باختلاف التطبيقات، ومن أهمها البُنى التي تحتوي على وسيط ، والبنى التي تحتوي على أكثر من قاعدة بيانات مُتزامنة.
بُنيّة مُتعددة المُستويات : إنّ تطوير هذا النموذج هو نتيجة للاعتماد المتزايد على شبكة الإنترنت، وهو يسمح للعميل بالنفاذ إلى الخدمة عبر مُتصفّخ ويب، أيّاً كانت الخدمة وأيّاً كان التطبيقات. في هذه البُنيّة، ونظراً إلى اعتماد العميل على مُتصفّخ ويب فإنّ طبقة جديدة تحتوي مُخدّم ويب سوف تضاف بين العُملاء ومُخدّم التطبيقات، ليصبح عدد الطبقات في هذه البنيّة أربعة، الأولى تضمّ العميل والمُتصفّح، والثانية تضم مُخدّم ويب، والثالثة تضمّ مُخدّم التطبيقات، أمّا الرابعة فتحتوي مُخدّم قاعدة البيانات وقاعدة البيانات الخاصّة خدمة بالخدمة. يُمكن تعميم هذا النموذج ليضم (N) مستوى.
دور العميل ودور المُخدّم
إنّ العلاقة بين العميل والمخدّم هي علاقة تعاون بين برنامجين ضمن نفس التطبيق، في هذه العلاقة يقوم المُخدّم بالوظيفة أو يُقدّم خدمة لعميل واحد أو أكثر ممن يطلبون ذلك. يجري تصنيف المُخدّمات بحسب الخدمات التي يقدمونها، فمثلاً مُخدّم الويب يُخدّم صفحات الويب، ومُخدّم الملفّات يقدم خدمته للملفّات. إنّ مشاركة الموارد تعتبر أيضاً شكلاً من أشكال الخدمة التي يُمكن أن تُقدّم، ويشمل ذلك البرامج والمُعطيات ومساحة التحزين وقدرات المعالجة.
يُمكن للحاسب أن يكون عميلاً لخدمة ما ومُخدّماً لخدمة أخرى أو كلاهما معّاً في نفس الوقت، كما يُمكن أن يكون عميلاً ومُخدّماً لنفس لخدمة بنفس الوقت، ويتعلق الأمر بالبرامج التي يتمّ تشغيلها فيه.
لا يتواصل العُملاء فيما بينهم من أجل الحصول على الخدمة، بل يقُومُون بإرسال طلباتهم إلى المُخدّمات. ينتظر المُخدّم استقبال طلبات العملاء، وهو قادر على تقديم الخدمة لأكثر من عميل بنفس الوقت، يمكن أن تتواصل المُخدّمات التي تقدّم نفس الخدمة مع بعضها البعض من أجل مُزامنة قواعد بياناتها وصُولاً إلى قاعدة بيانات مُشتركة، تسمّى هذه العملية الاتصال بين المُخدّمات .
الاتصال بين العميل والمُخدّم
بشكلٍ عام، الخدمة هي شكل تجريديّ يُعبّر عن الموارد التي يمكن للمُخدم أن يقدّمها للعُملاء. إنّ نظام طلب الخدمة مُصمم بحيّث يكون العُملاء غير معنيين بالآليّة التي يقوم فيها المُخدّم بالاستجابة للطلبات، ويتوجب عليهم فقط أن يكونوا قادرين على فهم الردّ الوارد من المُخدّم، ويحصل ذلك عن طريق تشغيل العميل لأحد البروتوكولات الخاصّة بالخدمة المطلوبة.
يتبادل العميل والمُخدّم الرسائل ضمن نمط الطلب/الرد (Request/Response)، حيث يرسل العميل طلباً فيقوم المُخدّم بالردّ عليه، إنّ هذا النمط هو مثال عن عمليّة اتصال بين العمليات. لنجاح الاتصال يجب أن يدعم المُخدّم والعميل نفس بروتوكولات الاتصالات، حيث تحدد هذه البروتوكولات مجموعة القواعد الخاصّة بتنسيق وإعداد ونقل البيانات فيما بينهما بحيث تحصل العمليات السابقة بطريقة مفهومة لطرفي الاتصال.
تعمل كل بروتوكولات طلب الخدمة في أقرب طبقة للتطبيقات بحسب نموذج الاتصال المستعمل، على أيّ حال تسمى هذه الطبقة بطبقة التطبيق في نموذج الإنترنت وفي نموذج الاتصال المعياريّ أيضاً، ويُعرّف كل من هذه البروتوكولات أنماطاً مُميزة خاصّة به من رسائل الطلب/الرد، كنا يُمكن أن يدعم المُخدّم واجهة برمجة تطبيقات خاصّة به، وذلك بهدف تخصيص أنماط مُتبادلة، ويسهّل ذلك من عملية مُزامنة قواعد البيانات.
قد يستقبل |المُخدّم طلبات من العديد من العُملاء في فترة قصيرة، ويمكن أن يُشكل هذا ضغطاً على موارده، لذلك تعمد المُخدمات إلى الاعتماد على نظام جدولة لطلبات العُملاء، بحيث يتمّ تصنيف هذه الطلبات بحسب أهميتها. قد تُشكّل محدوديّة موارد المُخدّم ثغرة أمنيّة لهجوم إيقاف الخدمة، حيث يعمد المهاجمون إلى استغلال التزام المُخدّم بالرد على طلبات العُملاء فيقومون بإرسال الطلبات بمعدّلٍ مُفرط.
أمثلة عن عمل نموذج طلب الخدمة
فيما يلي أمثلة عن عمل نموذج طلب الخدمة، يُظهر المثال الأول كيفيّة عمل النموذج مع بروتوكول التهيئة الآليّة للمُضيفين (DHCP)، حيث يمكن أن يعمل البروتوكول بحسب النموذج بشكلين، إمّا وفق بنية ثنائية المُستويات، أو ثلاثيّة المستويات. أمّا المثال الثاني، فهو مُخصص لإظهار كيفيّة عمل النموذج عند تصفّح الإنترنت.
مثال عن عمل النموذج في بروتوكول التهيئة الآليّة للمُضيفين
يعمل بروتوكول التهيئة الآلية للمُضيفين على تزويد المُضيفين بالإعدادات اللازمة لنجاح اتصالهم بالشبكة أو قيامهم بوظائفهم. بشكلٍ أساسيّ، يقوم البروتوكول بتزويد المُضيف بعنوان بروتوكول إنترنت وقناع الشبكة (Network mask) وعنوان . هناك إمكانيّة لتزويد المُضيف بعدد كبير من الخيارات الأخرى. يعمل بروتوكول التهيئة الآلية للمُضيفين وفق نموذج طلب الخدمة، حيث تُعرّف مُحددات البروتوكول عميلَ البروتوكول بأنّه مُضيف إنترنت يستخدم البروتوكول من أجل الحصول على إعدادات التهيئة، ومُخدّم البروتوكول بأنّه مُضيف إنترنت يُقدّم إعدادات التهيئة لعملاء البروتوكول.
يُمكن أن يعمل البروتوكول بشكلين، الأول هو النموذج المُباشر، وهو نموذج طلب خدمة ثنائيّ المُستويات، حيث يملك المُخدّم والعميل عناوين إنترنت من نفس الشبكة، أيّ أنّهما يتواجدان ضمن نفس نطاق البث العام، أمّا النموذج الثاني، فهو نموذج الوسيط، وهو نموذج طلب خدمة ثُلاثي المُستويات، وفيه يكون العميل والمُخدّم في |نطاقي بث عام مُختلفين، أيّ في شبكتين مُختلفتين، ويُوجد في شبكة العميل وسيط للمُخدّم يقوم بنقل الرسائل بين العميل والمُخدّم.
عمل البروتوكول وفق النموذج المباشر
يعتمد بروتوكول التهيئة الآلية للمُضيفين على بروتوكول حزم بيانات المُستخدم كبروتوكول طبقة نقل، يقوم هذا البروتوكول بإنشاء قنوات اتصال لا تتطلب تهيئة يستخدمها بروتوكول التهيئة الآلية للمُضيفين لتبادل أربع أنواع من الرسائل بين العميل والمُخدّم، وتكون هذه الرسائل رسائل بث عام، وهي:
رسالة الاكتشاف (DHCP Discovery): وتُرسل من العميل إلى المُخدّم، وتكون موجّهة إلى أي مُخدّم للبروتوكول موجود في نطاق البث العام، كما يُمكن أن تُستخدم هذه الرسالة لطلب مُحددات سابقة، مثل العنوان القديم الذي استضافه المُضيف.
رسالة العرض (DHCP Offer): وهي ردّ على رسالة الاكتشاف، وتُرسل من المُخدّم إلى العميل، وتتضمن معلومات عن المُخدّم الذي يقدّم عرض التهيئة ومعلومات عن العرض نفسه.
رسالة الطلب (DHCP request): وتُرسل من العميل إلى المُخدّم، وتتضمن طلباً بالتزويد بمعلومات التهيئة بحسب العرض الذي تمّ تقديمه في الرسالة السابقة.
إشعار التأكيد (DHCP Acknowledgement): ويُرسل من المُخدّم إلى العميل، وهو آخر مرحلة من مراحل التهيئة، ويتضمّن الإشعار معلُومات التهيئة الخاصّة بالعميل، ويمكن للعميل استعمال هذه المعلومات بعد تلقيه إشعار التأكيد.
يعمل بروتوكول التهيئة الآلية للمضيفين (DHCP) وفق النموذج المباشر، أي نموذج طلب الخدمة ثنائي المُستويات، حيث يجري تبادل الرسائل بين العميل والمُخدّم الموجودين ضمن نفس نطاق البثّ العامّ وفق التسلسل التالي:
يُرسل عميل البروتوكول رسالة اكتشاف بحثّاً عن أي مُخدّم للبروتكول موجود في نطاق بثّه العامّ.
تصل رسالة الاكتشاف إلى مُخدّم واحد أو أكثر، فيقوم كل مُخدّم استقبل رسالة الاكتشاف بإرسال رسالة عرض إلى العميل، يعرض فيها تزويده بمُحددات التهيئة.
تصل رسالة العرض إلى العميل، فيقوم بطلب معلومات التهيئة من المُخدّم عن طريق رسالة طلب.
يستقبل المُخدّم رسالة الطلب ويردّ على العميل بإشعار التأكيد الذي يحتوي معلومات التهيئة المطلُوبة.
يستقبل العميل إشعار الردّ ويستخدم المُحددات الواردة فيه لتهيئة منفذه المُتصل مع الشبكة.
عمل البروتكول وفق نموذج الوسيط
تصفّ الوثيقة (RFC 3046) المعنونّة: «معلومات عن خيار وسيط النقل الخاصّ ببروتوكول التهيئة الآليّة للمُضيفين» كيفيّة استخدام أحد خيارات البروتوكول من أجل توسيع مجال عمل البروتوكول وتمكينُه من تقديم خدمة التهيئة الآلية لمُضيفين لا يتواجدون ضمن نطاق بثّه العامّ.
لينجح المُخدّم في تقديم خدمته في شبكة بعيدة، لابدّ من وجود وسيطٍ له في تلك الشبكة، يقوم هذا الوسيط بنقل الرسائل بين العميل والمُخدّم. يجب تهيئة الوسيط وتزويده بعنوان بروتوكول الإنترنت الخاصّ بالمخدّم. بعد التهيئة يقوم الوسيط بانتظار رسائل الاكتشاف التي يُرسلها العملاء، ثُمّ يقوم بتوليد رسائل طلب مُكافئة نحو المُخدّم. لا يكون العملاء مُدركين لوجود الوسيط الذي غالباً ما يكون أحد منافذ المُوجّهات المُتصلة مع الشبكة البعيدة.
في المثال المدروس هنا، يوجد المُخدّم والعميل في شبكتين مختلفتين، يتصل الموجه (R1) مع شبكة العميل، ويلعب منفذ الموجّه دور وسيط المُخدّم، يُمكن الاطلاع على طوبولوجيا الشبكة من الشكل المُرفق جانباً، إنّ الرسائل المتبادلة بين العميل والمُخدّم مشابه من حيث النوع والترتيب للرسائل في المثال السابق، ولكنّ المسار الذي تسلكه يكون مُختلفّاً.
تكون الرسائل المتبادلة بين العميل والوسيط رسائل بثّ عام، أما تلك المُتبادلة بين الوسيط والمُخدّم فتكون رسائل فريدة، ويكون مسار الرسائل بالشكل التالي:
يُرسل العميل رسائله على شكل رسائل بثّ عام في شبكته المحليّة (LAN)، تصل هذه الرسائل إلى الوسيط الموجُود في تلك الشبكة.
ينقل الوسيط رسالة العميل إلى المُخدّم على شكل رسالة فريدة، تعبر هذه الرسالة المسار الواصل بين الوسيط والمُخدّم.
بعد معالجة الرسالة، يقوم المُخدّم بإرسال رسالته إلى الوسيط على شكل رسالة فريدة.
بعد وصول الرسالة الفريدة إلى الوسيط، يقوم بنقل هذه الرسالة إلى الشبكة المحلية ويرسلها على شكل رسالة بثّ عام.
تسلك جميع الرسائل المُتبادلة بين المُخدّم والعميل المسار السابق مُروراً بالوسيط.
مثال عن عمل النموذج عند تصفّح الإنترنت
يقوم مُستخدم باستعمال متصفّح للحصول على خدمة التصفّح من مُخدّم ويب بعيد، ولنجاح هذا لا بد من استعمال نظام تسمية النطاقات للحصول على عنوان موقع الويب. تعتمد خدمة تصفح الويب على بروتوكول نقل النصّ التشعبي وفق نموذج طلب الخدمة ببُنية ثنائية المستويّات، أمّا بخدمة تبديل الأسماء بالعناوين فتعتمد نفس النموذج ولكن وفق بُنية ثلاثيّة المُستويّات.
في هذا المثال يوجد ثلاث طرفيات، الأولى هي حاسب المُستخدم، والثانيّة هي مُخدّم الويب البعيد (Web Server)، والثالثة هي مُخدّم نظام تسميّة النطاقات البعيد (Remote DNS Server)، يضمّ حاسب المستخدم مُتصفّح ويب ومُخدّم محلّيّ لنظام تسمية النطاقات (Local DNS Client). يلعب مُتصفّح الويب دور عميل الويب (Web Client) وعميل نظام تسميّة النطاقات (DNS Client).
تبدأ العملية عندما يقوم المُستخدم بإدخال اسم موقع ويب لأول مرة في المُتصفّح من أجل تصفّحه، وتتابع مراحل العمل بالشكل التالي:
يحصل عميل نظام أسماء النطاقات على اسم الموقع، ويُرسل طلباً لمُخدّم نظام أسماء النطاقات المحلّيّ طالباً منه خدمة تبديل الاسم بالعنوان الموافق.
يستقبل مُخدّم نظام تسميّة النطاقات الطلب، وبما أنّ تصفّح الموقع يجري للمرة الأولى، فلا وجود لسجلّات خاصّة به في قاعدة البيانات المحلّيّة، فيقوم مُخدّم نظام أسماء النطاقات المحلّيّ بإرسال الطلب إلى مُخدّم نظام أسماء النطاقات البعيد.
يصلّ الطلب إلى نظام أسماء النطاقات البعيد، يُعالج المُخدّم البعيد الطلب ويُرسل ردّاً بالعنوان المُوافق إلى مُخدّم نظام أسماء النطاقات المحلّيّ.
يصلّ الردّ إلى نظام أسماء النطاقات المحلّيّ، فيُسجّل العنوان المُوافق للاسم في قاعدة بياناته المحليّة، ثُمّ يُرسل الردّ إلى عميل نظام أسماء النطاقات، ونتيجة للعملية يحصل المُتصفّح على عنوان موقع الويب.
يطلب عميل الويب خدمة تصفّح موقع الويب المُحدد بالعنوان من مُخدّم الويب البعيد.
يُعالج مُخدّم الويب البعيد الطلب، ويردّ عليه برسالة تتضمّن الملفّات الخاصّة بصفحة الويب المطلُوبة.
يستقبل عميل الويب رسالة الردّ التي تحتوي صفحة الويب المطلوبة، وبات بإمكان المُتصفّح عرض الصفحة للمُستخدم.
مقارنة مع نموذج القرناء
بالإضافة لنموذج طلب الخدمة، هناك نموذج عمل آخر هو نموذج القرناء (P2P)، ولهذا النموذج تطبيقات عديدة في مجال الحوسبة الموزّعة. يعتمد نموذج القرناء على آليّات عمل مُختلفة مقارنة بنموذج طلب الخدمة بالإضافة لامتلاكه بُنيّة معماريّة خاصّة.
في نموذج طلب الخدمة، تُصنّف الطرفيّات لتكون إمّا مُخدّمات أو عملاء، لا يتواصل العملاء مع بعضهم البعض بشكلٍ مُباشر، ولابد من وجود وسيط هو المُخدّم. أمّا في نموذج القرناء، فتُعتبر كل الطرفيات قرين، وهي تتواصل مع بعضها البعض بشكلٍ مُباشر بدون الحاجة لوجود وسيط.
إنّ أحد الأهداف الرئيسيّة الكامنة خلف تصميم نموذج طلب الخدمة هو خلق نقطة تحكّم مركزيّة في النظام لتُقدّم الخدمة للعُملاء، تتجمع في هذه النقطة قُدرات الحوسبة والتخزين، ويجب أن يأخذ التصميم بالحسبان عدد العُملاء الأعظميّ المُتوقّع، وغالباً ما تُستخدم آليّات توزيع الحمل وأنظمة تجاوز الفشل (Failover) على نطاقٍ واسع. أمّا في الشبكات التي تعتمد نموذج القرناء، فيتشارك قرينان أو أكثر مواردهما ويتواصلان ضمن نظام غير مركزيّ. تكون القرناء مُتكافئة أي أنّها تملك أدواراً مُتساويّة ضمن شبكة ذات بنيّة غير هرميّة الامتيازات.
في نموذج طلب الخدمة، يجب أن تُحقق المُخدّمات توافريّة عاليّة، فقد يُسبب فشل المُخدّم فشلاً في كامل النموذج بسبب مركزيّة النظام. أمّا في نموذج القرناء، فإنّ التوافريّة العاليّة ليست مطلباً أساسيّاً بسبب وجود قرائن إضافيّة فائضة تُعوّض النقص الحاصل في الخدمة أو الموارد.
هوامش
. العنوان الأصلي هو .
. العنوان الأصلي هو .
. العنوان الأصلي هو .
. العنوان الأصلي هو
. القرين لغةً هو المصاحب والملازم ويقابله . جمعُه قرناء، مُؤنّثه قرينة وجمعها قرائِن وقرينات.
انظر أيضاً
نموذج الإنترنت (TCP/IP).
نموذج الاتصال المعياري(OSI).
البنية متعددة االمستويات.
نموذج القرناء (P2P).
المُخدّم.
العميل.
مراجع
وصلات خارجية
مُقدّمة إلى الشبكات العاملة بنموذج طلب الخدمة مقالة على موقع لايف واير بقلم برادلي ميتشل (Bradley Mitchell).
القواعد الإرشادية للتطبيقات مُتعددة المُستويات، الفصل الخامس من دليل بُنيّة التطبيقات، مُقدّم من مايكروسوفت.
بنية نموذج طلب الخدمة ثلاثيّة المستويات، العدد 75 من مجلة لينوكس.
تشريح نموذج طلب الخدمة، مقالة مقدّمة من شركة بي أيه أي (BEA).
وثيقة طلب التعليقات رقم: 1856، الإصدار التشغيليّ من أوبستات (Opstat)، بروتوكول الحصول على البيانات العامل بنموذج طلب الخدمة، وثيقة تعليقات على بروتوكول عامل بنموذج طلب الخدمة.
اتصال بين العمليات
بروتوكولات طبقة التطبيق
بنية الشبكة
خوادم
عملاء (حوسبة)