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

من أرابيكا، الموسوعة الحرة
اذهب إلى التنقل اذهب إلى البحث
بُنية نموذج طلب الخدمة (Client/Server).

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

يُكمن للمُخدّم أن يُشغّل برنامجاً واحداً أو أكثر من البرامج الخاصة بطرف المُخدم لتقديم خدمة واحدة أو أكثر أو مُشاركة الموارد مع عميلٍ واحدٍ أو أكثر، أمّا العميل فلا يُشارك موارده مع أحد، ولكنّه يطلب الخدمة أو الموارد من المُخدّم.[5] لذلك يبدأ العملاء بإنشاء قنوات اتصال مع المُخدّمات التي تنتظر مبادرتهم وتعمل على تقديم الخدمة المُناسبة لهم.

من الأمثلّة عن التطبيقات التي تعتمد هذا النموذج تطبيقات البريد الإلكترونيّ والطباعة عبر الشبكة وتطبيقات الويب.[6]

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

ورد ذكر شكل بدائيّ من نموذج طلب الخدمة في الوثائق المرجعيّة الخاصة بنظام أو أس 360 [English] المُطوّر من قبل شركة أي بي أم في منتصف الستينيات من القرن الماضي، وتحديداً في الوثيقة المعنونة:[7] «مدخل لأداء الأعمال عن بعد»،(1) حيث كان الهدف الأساسي هو إنجاز عمل ما عن بُعد. في نهاية الستينيات، كان العمل في معهد ستانفورد للأبحاث يجري على بناء شبكة الأربانت، وقد ورد ذكر بُنيّة بدائيّة لنموذج طلب الخدمة في أوائل وثائق التعليقات، حيث ورد في الوثيقة (RFC 4) المُعنونّة:[8] «الجدول الزمني للشبكة» (2) استعمال لمصطلح المُضيف المُستخدم (بالإنجليزية: Using Host)‏ والمُضيف المُخدّم (بالإنجليزية: Serving Host)‏، وهي تصف أشكال بدائيّة من العملاء والمُخدّمات.

ظهرت مُصطلحات مُشابهة في الوثيقة (RFC 5) المُعنونّة:[9] «لغة الترميّز وفك الترميز» (3)، حيث كان الهدف الأساسي من هذه اللغة هو تطوير القدرة على إرسال أوامر والردّ عليها بشكل مُرمّز عبر الشبكة، وسميت أطراف العلاقة بمُضيف المستخدم (بالإنجليزية: User-Host)‏ ومُضيف المُخدم (بالإنجليزية: Server-Host)‏. أخيراً، في عام 1978م، نشر باحثون في شركة زيروكس ورقة بحثيّة بعنوان:[10] «الفصل بين المُعطيات والوظائف في نظام توزيع الملفّات»،(4) وقد حرص كاتبو البحث على التمييز بين المُستخدم والعميل، الذي عرّفوه بأنّه مُستخدم لعقدة في الشبكة. أمّا استعمال كلمة مُخدّم بمعناها الحالي فقد بدأ في العام 1992م.[11]

بُنية وآليّة عمل النموذج

يتألّف نموذج طلب الخدمة من مجموعة من العُملاء والمُخدّمات بالإضافة إلى الشبكة التي تصلّ فيما بينهم، ويُمكن تصنيف البُنى السابقة بحسب عدد المراحل اللازمة ليحصل العميل على الخدمة، والتي تُسمى مُستويات (بالإنجليزية: Tier)‏، بالشكل التالي:[12]

بُنيّة نموذج طلب الخدمة ثنائي المُستويات.
بُنيّة نموذج طلب الخدمة ثلاثي المُستويات.
بنيّة نموذج طلب الخدمة مُتعدد المُستويات.
  • بُنيّة ثُنائيّة المُستويات (بالإنجليزية: Two-Tiers Architecture)‏: وهو أبسط بُنية لنموذج طلب الخدمة، وفيه يتوزّع العمل بين مُخدّم وعدد من العُملاء، يضمّ خادم المُخدّم قاعدة بيانات خاصّة بالخدمة التي يُقدمّها. بشكلٍ عام، يجب على كل عميل ينفذ إلى قاعدة البيانات. عبر طلب يُقدّم إلى المُخدّم الذي يُعالج الطلبات، من سلبيات هذه البُنية محدوديّة عدد العُملاء الذين يُمكن للمُخدم دعمُهم، بالإضافة لوجود إشكالات أمنيّة بسبب حاجة كل عميل للنفاذ بشكلٍ مُستقل إلى قاعدة البيانات.[13]
  • بُنيّة ثُلاثيّة المُستويات (بالإنجليزية: Three-Tiers Architecture)‏: تم تطوير هذا النموذج لتجاوز محدوديّة البُنيّة ثنائيّة المستويات،[14] في هذه البُنية يُضاف مُستوى ثالث، في الوسط بين المستويين السابقين بهدف فصل التعامل مع العميل عن إدارة قاعدة بيانات،[15] يضمّ هذا المُستوى بالإضافة للعميل ومُخدّم قاعدة البيانات، مُخدّماّ خاصّاً بالتطبيقات. يُمكن أن يعمل مُخدّم التطبيقات على منصّة مُستقلة، أو أن يتواجد على نفس المنصة التي يعمل عليها مُخدّم قاعدة البيانات. في البنية ثُلاثية المُستويات، فقط مُخدّم التطبيقات هو من يملك صلاحيّات النفاذ إلى قاعدة البيانات الخاصّة بالخدمة عبر مُخدّم قاعدة البيانات، وذلك عوضاً عن منح هذه الصلاحيّات لكل عميل يتقدم بطلب الحصول على الخدمة كما هو الحال في البنيّة ثُنائية المستويات. إنّ البنية السابقة هي البُنية ثُلاثيّة المُستويات الأساسيّة، وتتنوع البُنى المُشتقة عنها باختلاف التطبيقات، ومن أهمها البُنى التي تحتوي على وسيط (بالإنجليزية: Broker)‏،[16] والبنى التي تحتوي على أكثر من قاعدة بيانات مُتزامنة.
  • بُنيّة مُتعددة المُستويات (بالإنجليزية: N-Tiers Architecture)‏: إنّ تطوير هذا النموذج هو نتيجة للاعتماد المتزايد على شبكة الإنترنت، وهو يسمح للعميل بالنفاذ إلى الخدمة عبر مُتصفّخ ويب، أيّاً كانت الخدمة وأيّاً كان التطبيقات. في هذه البُنيّة، ونظراً إلى اعتماد العميل على مُتصفّخ ويب فإنّ طبقة جديدة تحتوي مُخدّم ويب سوف تضاف بين العُملاء ومُخدّم التطبيقات، ليصبح عدد الطبقات في هذه البنيّة أربعة، الأولى تضمّ العميل والمُتصفّح، والثانية تضم مُخدّم ويب، والثالثة تضمّ مُخدّم التطبيقات، أمّا الرابعة فتحتوي مُخدّم قاعدة البيانات وقاعدة البيانات الخاصّة خدمة بالخدمة. يُمكن تعميم هذا النموذج ليضم (N) مستوى.

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

إنّ العلاقة بين العميل والمخدّم هي علاقة تعاون بين برنامجين ضمن نفس التطبيق، في هذه العلاقة يقوم المُخدّم بالوظيفة أو يُقدّم خدمة لعميل واحد أو أكثر ممن يطلبون ذلك. يجري تصنيف المُخدّمات بحسب الخدمات التي يقدمونها، فمثلاً مُخدّم الويب يُخدّم صفحات الويب، ومُخدّم الملفّات يقدم خدمته للملفّات. إنّ مشاركة الموارد تعتبر أيضاً شكلاً من أشكال الخدمة التي يُمكن أن تُقدّم، ويشمل ذلك البرامج والمُعطيات ومساحة التحزين وقدرات المعالجة.[17]

يُمكن للحاسب أن يكون عميلاً لخدمة ما ومُخدّماً لخدمة أخرى أو كلاهما معّاً في نفس الوقت، كما يُمكن أن يكون عميلاً ومُخدّماً لنفس لخدمة بنفس الوقت، ويتعلق الأمر بالبرامج التي يتمّ تشغيلها فيه.

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

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

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

يتبادل العميل والمُخدّم الرسائل ضمن نمط الطلب/الرد (Request/Response)، حيث يرسل العميل طلباً فيقوم المُخدّم بالردّ عليه، إنّ هذا النمط هو مثال عن عمليّة اتصال بين العمليات. لنجاح الاتصال يجب أن يدعم المُخدّم والعميل نفس بروتوكولات الاتصالات، حيث تحدد هذه البروتوكولات مجموعة القواعد الخاصّة بتنسيق وإعداد ونقل البيانات فيما بينهما بحيث تحصل العمليات السابقة بطريقة مفهومة لطرفي الاتصال.[18]

تعمل كل بروتوكولات طلب الخدمة في أقرب طبقة للتطبيقات بحسب نموذج الاتصال المستعمل، على أيّ حال تسمى هذه الطبقة بطبقة التطبيق في نموذج الإنترنت[19] وفي نموذج الاتصال المعياريّ[20] أيضاً، ويُعرّف كل من هذه البروتوكولات أنماطاً مُميزة خاصّة به من رسائل الطلب/الرد، كنا يُمكن أن يدعم المُخدّم واجهة برمجة تطبيقات خاصّة به،[21] وذلك بهدف تخصيص أنماط مُتبادلة، ويسهّل ذلك من عملية مُزامنة قواعد البيانات.[22]

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

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

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

مثال عن عمل النموذج في بروتوكول التهيئة الآليّة للمُضيفين

المقالة الرئيسية: بروتوكول التهيئة الآلية للمضيفين

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

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

عمل البروتوكول وفق النموذج المباشر

الرسائل المُتبادلة بين مُخدّم وعميل بروتوكول التهيئة الآلية للمضيفين.

يعتمد بروتوكول التهيئة الآلية للمُضيفين على بروتوكول حزم بيانات المُستخدم[25] كبروتوكول طبقة نقل، يقوم هذا البروتوكول بإنشاء قنوات اتصال لا تتطلب تهيئة يستخدمها بروتوكول التهيئة الآلية للمُضيفين لتبادل أربع أنواع من الرسائل بين العميل والمُخدّم، وتكون هذه الرسائل رسائل بث عام، وهي:[24]

  • رسالة الاكتشاف (DHCP Discovery): وتُرسل من العميل إلى المُخدّم، وتكون موجّهة إلى أي مُخدّم للبروتوكول موجود في نطاق البث العام، كما يُمكن أن تُستخدم هذه الرسالة لطلب مُحددات سابقة، مثل العنوان القديم الذي استضافه المُضيف.
  • رسالة العرض (DHCP Offer): وهي ردّ على رسالة الاكتشاف، وتُرسل من المُخدّم إلى العميل، وتتضمن معلومات عن المُخدّم الذي يقدّم عرض التهيئة ومعلومات عن العرض نفسه.
  • رسالة الطلب (DHCP request): وتُرسل من العميل إلى المُخدّم، وتتضمن طلباً بالتزويد بمعلومات التهيئة بحسب العرض الذي تمّ تقديمه في الرسالة السابقة.
  • إشعار التأكيد (DHCP Acknowledgement): ويُرسل من المُخدّم إلى العميل، وهو آخر مرحلة من مراحل التهيئة، ويتضمّن الإشعار معلُومات التهيئة الخاصّة بالعميل، ويمكن للعميل استعمال هذه المعلومات بعد تلقيه إشعار التأكيد.

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

  1. يُرسل عميل البروتوكول رسالة اكتشاف بحثّاً عن أي مُخدّم للبروتكول موجود في نطاق بثّه العامّ.
  2. تصل رسالة الاكتشاف إلى مُخدّم واحد أو أكثر، فيقوم كل مُخدّم استقبل رسالة الاكتشاف بإرسال رسالة عرض إلى العميل، يعرض فيها تزويده بمُحددات التهيئة.
  3. تصل رسالة العرض إلى العميل، فيقوم بطلب معلومات التهيئة من المُخدّم عن طريق رسالة طلب.
  4. يستقبل المُخدّم رسالة الطلب ويردّ على العميل بإشعار التأكيد الذي يحتوي معلومات التهيئة المطلُوبة.
  5. يستقبل العميل إشعار الردّ ويستخدم المُحددات الواردة فيه لتهيئة منفذه المُتصل مع الشبكة.

عمل البروتكول وفق نموذج الوسيط

مسار رسائل بروتوكول التهيئة الآليّة للمُضيفين (DHCP) عند استخدام خيار الوسيط.

تصفّ الوثيقة (RFC 3046) المعنونّة:[26] «معلومات عن خيار وسيط النقل الخاصّ ببروتوكول التهيئة الآليّة للمُضيفين»(5) كيفيّة استخدام أحد خيارات البروتوكول من أجل توسيع مجال عمل البروتوكول وتمكينُه من تقديم خدمة التهيئة الآلية لمُضيفين لا يتواجدون ضمن نطاق بثّه العامّ.

لينجح المُخدّم في تقديم خدمته في شبكة بعيدة، لابدّ من وجود وسيطٍ له في تلك الشبكة، يقوم هذا الوسيط بنقل الرسائل بين العميل والمُخدّم. يجب تهيئة الوسيط وتزويده بعنوان بروتوكول الإنترنت الخاصّ بالمخدّم. بعد التهيئة يقوم الوسيط بانتظار رسائل الاكتشاف التي يُرسلها العملاء،[27] ثُمّ يقوم بتوليد رسائل طلب مُكافئة نحو المُخدّم. لا يكون العملاء مُدركين لوجود الوسيط الذي غالباً ما يكون أحد منافذ المُوجّهات المُتصلة مع الشبكة البعيدة.

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

تكون الرسائل المتبادلة بين العميل والوسيط رسائل بثّ عام، أما تلك المُتبادلة بين الوسيط والمُخدّم فتكون رسائل فريدة، ويكون مسار الرسائل بالشكل التالي:

  1. يُرسل العميل رسائله على شكل رسائل بثّ عام في شبكته المحليّة (LAN)، تصل هذه الرسائل إلى الوسيط الموجُود في تلك الشبكة.
  2. ينقل الوسيط رسالة العميل إلى المُخدّم على شكل رسالة فريدة، تعبر هذه الرسالة المسار الواصل بين الوسيط والمُخدّم.
  3. بعد معالجة الرسالة، يقوم المُخدّم بإرسال رسالته إلى الوسيط على شكل رسالة فريدة.
  4. بعد وصول الرسالة الفريدة إلى الوسيط، يقوم بنقل هذه الرسالة إلى الشبكة المحلية ويرسلها على شكل رسالة بثّ عام.

تسلك جميع الرسائل المُتبادلة بين المُخدّم والعميل المسار السابق مُروراً بالوسيط.

مثال عن عمل النموذج عند تصفّح الإنترنت

مثال عن نموذج طلب الخدمة (Client/ Server)، مُخطط تسلسل العمليات لتصفّح الويب، يُمكن ملاحظة البنيّة ثُلاثيّة المستويات للنموذج الخاص بخدمة تبديل الأسماء بالعناوين.

يقوم مُستخدم باستعمال متصفّح للحصول على خدمة التصفّح من مُخدّم ويب بعيد، ولنجاح هذا لا بد من استعمال نظام تسمية النطاقات[28] للحصول على عنوان موقع الويب. تعتمد خدمة تصفح الويب على بروتوكول نقل النصّ التشعبي[29] وفق نموذج طلب الخدمة ببُنية ثنائية المستويّات، أمّا بخدمة تبديل الأسماء بالعناوين فتعتمد نفس النموذج ولكن وفق بُنية ثلاثيّة المُستويّات.

في هذا المثال[30] يوجد ثلاث طرفيات، الأولى هي حاسب المُستخدم، والثانيّة هي مُخدّم الويب البعيد (Web Server)، والثالثة هي مُخدّم نظام تسميّة النطاقات البعيد (Remote DNS Server)، يضمّ حاسب المستخدم مُتصفّح ويب ومُخدّم محلّيّ لنظام تسمية النطاقات (Local DNS Client). يلعب مُتصفّح الويب دور عميل الويب (Web Client) وعميل نظام تسميّة النطاقات (DNS Client).

تبدأ العملية عندما يقوم المُستخدم بإدخال اسم موقع ويب لأول مرة في المُتصفّح من أجل تصفّحه، وتتابع مراحل العمل بالشكل التالي:

  1. يحصل عميل نظام أسماء النطاقات على اسم الموقع، ويُرسل طلباً لمُخدّم نظام أسماء النطاقات المحلّيّ طالباً منه خدمة تبديل الاسم بالعنوان الموافق.
  2. يستقبل مُخدّم نظام تسميّة النطاقات الطلب، وبما أنّ تصفّح الموقع يجري للمرة الأولى، فلا وجود لسجلّات خاصّة به في قاعدة البيانات المحلّيّة، فيقوم مُخدّم نظام أسماء النطاقات المحلّيّ بإرسال الطلب إلى مُخدّم نظام أسماء النطاقات البعيد.
  3. يصلّ الطلب إلى نظام أسماء النطاقات البعيد، يُعالج المُخدّم البعيد الطلب ويُرسل ردّاً بالعنوان المُوافق إلى مُخدّم نظام أسماء النطاقات المحلّيّ.
  4. يصلّ الردّ إلى نظام أسماء النطاقات المحلّيّ، فيُسجّل العنوان المُوافق للاسم في قاعدة بياناته المحليّة، ثُمّ يُرسل الردّ إلى عميل نظام أسماء النطاقات، ونتيجة للعملية يحصل المُتصفّح على عنوان موقع الويب.
  5. يطلب عميل الويب خدمة تصفّح موقع الويب المُحدد بالعنوان من مُخدّم الويب البعيد.
  6. يُعالج مُخدّم الويب البعيد الطلب، ويردّ عليه برسالة تتضمّن الملفّات الخاصّة بصفحة الويب المطلُوبة.
  7. يستقبل عميل الويب رسالة الردّ التي تحتوي صفحة الويب المطلوبة، وبات بإمكان المُتصفّح عرض الصفحة للمُستخدم.

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

مقارنة بين نموذج القرناء (P2P) ونموذج طلب الخدمة (Client/Server).

بالإضافة لنموذج طلب الخدمة، هناك نموذج عمل آخر هو نموذج القرناء (P2P)،[31] ولهذا النموذج تطبيقات عديدة في مجال الحوسبة الموزّعة. يعتمد نموذج القرناء على آليّات عمل مُختلفة مقارنة بنموذج طلب الخدمة بالإضافة لامتلاكه بُنيّة معماريّة خاصّة.

في نموذج طلب الخدمة، تُصنّف الطرفيّات لتكون إمّا مُخدّمات أو عملاء، لا يتواصل العملاء مع بعضهم البعض بشكلٍ مُباشر، ولابد من وجود وسيط هو المُخدّم. أمّا في نموذج القرناء، فتُعتبر كل الطرفيات قرين،(6) وهي تتواصل مع بعضها البعض بشكلٍ مُباشر بدون الحاجة لوجود وسيط.[22]

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

في نموذج طلب الخدمة، يجب أن تُحقق المُخدّمات توافريّة عاليّة، فقد يُسبب فشل المُخدّم فشلاً في كامل النموذج بسبب مركزيّة النظام. أمّا في نموذج القرناء، فإنّ التوافريّة العاليّة ليست مطلباً أساسيّاً بسبب وجود قرائن إضافيّة فائضة تُعوّض النقص الحاصل في الخدمة أو الموارد.[32]

هوامش

1. العنوان الأصلي هو (بالإنجليزية: Remote Job Entry)‏.

2. العنوان الأصلي هو (بالإنجليزية: Network Timetable)‏.

3. العنوان الأصلي هو (بالإنجليزية: (The Decode-Encode Language (DEL)‏.

5. العنوان الأصلي هو (بالإنجليزية: DHCP Relay Agent Information Option)‏

6. القرين لغةً هو المصاحب والملازم ويقابله (بالإنجليزية: Peer)‏. جمعُه قرناء، مُؤنّثه قرينة وجمعها قرائِن وقرينات.

انظر أيضاً

مراجع

  1. ^ Q111284802، ص. 342، QID:Q111284802
  2. ^ Q113638576، ص. 59، QID:Q113638576
  3. ^ "Client/Server Definition". The Linux Information Project (بEnglish). Nov 2005. Archived from the original on 2007-01-07. Retrieved 2017-08-05.
  4. ^ "Server Service". Microsoft (بEnglish). Archived from the original on 2017-08-01. Retrieved 2017-08-05.
  5. ^ "The client/server model". International Business Machines Corporation (IBM) (بEnglish). Archived from the original on 2017-08-04. Retrieved 2017-08-05.
  6. ^ Server Management (بEnglish) (الأولى ed.). Auerbach Publications. 2000. p. 5. ISBN:0849398231.
  7. ^ IBM System/360 Operating System, Remote Job Entry (بEnglish) (الثالثة ed.). International Business Machines Corporation (IBM). 1968.
  8. ^ Shapiro, Elmer B. (Mar 1969). "RFC 4, Network TimetableProtocol". The Internet Society (بEnglish). Archived from the original on 2016-03-08. Retrieved 2017-08-02.
  9. ^ Rulifson, Jeff (Jun 1969). "RFC 5, The Decode-Encode Language (DEL)". The Internet Society (بEnglish). Archived from the original on 2016-03-08. Retrieved 2017-08-05.
  10. ^ Israel، Jay E.؛ Mitchell، James G.؛ Sturgis، Rahner (1978). "Separating Data from Function in a Distributed File System". Xerox Palo Alto Research Center Computer Science Laboratory. Xerox Palo Alto Research Center,. ج. 78. {{استشهاد بدورية محكمة}}: line feed character في |صحيفة= في مكان 32 (مساعدة)صيانة الاستشهاد: علامات ترقيم زائدة (link)
  11. ^ "معنى كلمة Server في قاموس Online Etymology Dictionary". International Organization for Standardization (ISO) (بEnglish). Archived from the original on 2017-03-22. Retrieved 2017-08-05.
  12. ^ Oluwatosin، Haroon Shakirat (فبراير 2014). "Client-Server Model". IOSR Journal of Computer Engineering (IOSR-JCE). ج. 16 ع. 1: 67-71. ISSN:2278-8727.
  13. ^ Kramek, Andy (Sep 2008). "Introduction to Client Server Architecture". Foxite.COM Community Weblog (بEnglish). Archived from the original on 2017-08-02. Retrieved 2017-08-05.
  14. ^ Gallaugher، John M.؛ Ramanathan، Suresh C. (1996). "Choosing a Client/Server Architecture". Information Systems Management. Taylor & Francis. ج. 7 ع. 13: 7-13.
  15. ^ "Anatomy of the Client/Server". BEA Systems, Inc. (بEnglish). 2000. Archived from the original on 2017-08-02. Retrieved 2017-08-05.{{استشهاد ويب}}: صيانة الاستشهاد: التاريخ والسنة (link)
  16. ^ Aarsten، Amund؛ Brugali، Davide (1996). "Patterns for three-tier client/server applications". Proceedings of Pattern Languages of Programs (PLoP’96). ج. 4 ع. 6.
  17. ^ Douglas E Comer (1997). Internetworking With TCP/IP Volume 3 (بEnglish). Pearson Ptr. p. 11. ISBN:0-13-474222-2.
  18. ^ "معنى كلمة Protocol في الموسوعة البريطانيّة". الموسوعة البريطانية (بEnglish). Archived from the original on 2019-05-27. Retrieved 2017-08-05.
  19. ^ Socolofsky, T.; Kale, C. (يناير1991). "RFC 1180, A TCP/IP Tutorial". The Internet Society (بEnglish). Archived from the original on 28 مارس 2019. Retrieved 5 أغسطس 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (help)
  20. ^ "ISO/IEC 7498-1:1994, Information technology -- Open Systems Interconnection -- Basic Reference Model: The Basic Model". International Organization for Standardization (ISO) (بEnglish). 1994. Archived from the original on 2018-12-30. Retrieved 2017-08-05.{{استشهاد ويب}}: صيانة الاستشهاد: التاريخ والسنة (link)
  21. ^ Adkr، Richard M. (أبريل 1995). "Distributed coordination models for client/server computing". Computer. IEEE. ج. 28 ع. 4: 14-22. ISSN:0018-9162.
  22. ^ أ ب Yongsheng، Huang؛ Xiaoyu، Tian؛ Zhongbin، Tang (يونيو 2013). "An Optimization Model for the Interconnection among Peers of the P2P Network". Journal of Applied Sciences. ج. 13 ع. 5: 700-707.
  23. ^ McDowell, Mindi (2009). "Security Tip (ST04-015), Understanding Denial-of-Service Attacks". United States Coomputer Emergency Readiness Team (US-CERT) (بEnglish). Archived from the original on 2019-05-22. Retrieved 2017-07-31.{{استشهاد ويب}}: صيانة الاستشهاد: التاريخ والسنة (link)
  24. ^ أ ب Droms, R. (Mar 1997). "RFC 2131, Dynamic Host Configuration Protocol". The Internet Society (بEnglish). Archived from the original on 2018-11-15. Retrieved 2017-08-05.
  25. ^ Postal, J. (Aug 1980). "RFC 768, User Datagram Protocol". The Internet Society (بEnglish). Archived from the original on 2019-09-17. Retrieved 2017-08-05.
  26. ^ Patrick, M. (Jan 2001). "RFC 3046, DHCP Relay Agent Information Option". The Internet Society (بEnglish). Archived from the original on 2020-01-10. Retrieved 2017-08-05.
  27. ^ "IP Addressing: DHCP Configuration Guide, Cisco IOS Release 15SY, Configuring the Cisco IOS DHCP Relay Agent". Cisco Systems, Inc (بEnglish). 2015. Archived from the original on 2017-08-03. Retrieved 2017-08-05.{{استشهاد ويب}}: صيانة الاستشهاد: التاريخ والسنة (link)
  28. ^ Mockapetris, P. (Nov 1987). "RFC 1035, Domain names - implementation and specification". The Internet Society (بEnglish). Archived from the original on 2017-07-01. Retrieved 2017-08-05.
  29. ^ Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P.; Berners-Lee, T. (Jun 1999). "Hypertext Transfer Protocol -- HTTP/1.1". The Internet Society (بEnglish). Archived from the original on 2019-09-22. Retrieved 2017-08-05.
  30. ^ Murray, Peter (Jul 2008). "On the Internet, How Do You Know If You Are Talking to a Dog?". Disruptive Library Technology Jester (بEnglish). Archived from the original on 2016-03-13. Retrieved 2017-08-05.
  31. ^ Schollmeier, R. (2001). 1st International Conference on Peer-To-Peer Computing:A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications (بEnglish). IEEE. ISBN:0-7695-1503-7.
  32. ^ Wu، BangYu؛ Chi، Chi-Hung؛ Liu، Cong؛ Xie، ZhiHeng؛ Ding، Chen (ديسمبر 2010). "High Availability Data Model for P2P Storage Network". Web Information Systems Engineering – WISE. springer.: 322-327.

وصلات خارجية

مجلوبة من «https://3rabica.org/index.php?title=نموذج_الخادم_والعميل&oldid=2230538»