Ola Abbas

يقدّم هذا المقال أساسيات الألوان في برنامج سكريبوس Scribus ويوضّح كيفية: معرفة الفرق بين نمطي الألوان الرئيسيين RGB وCMYK. التنقل ضمن نافذة الألوان والتعبئة Colours. إنشاء ألوانك الخاصة. استرجاع لون من لوحة ألوان موجودة مسبقًا. نسخ أو استيراد الألوان من مستند موجود مسبقًا. إنشاء لوحاتك اللونية المخصّصة. أساسيات الألوان يمنحك سكريبوس خيار إنشاء الألوان باستخدام نمطين مختلفين من الألوان هما: RGB وCMYK، فنمط الألوان هو مجرد طريقة لاختيار هذه الألوان. نمط الألوان RGB RGB هو اختصار للألوان "الأحمر Red والأخضر Green والأزرق Blue"، وهو المعيار المستخدَم في العروض المرئية، لهذا فإن كنت غير راغبٍ في طباعة مستندك، فسيكون استخدام ألوان RBG جيدًا. نمط الألوان CMYK CMYK هو اختصار للكلمات "Cyan وMagenta وYellow وKey أو Black"، وهو المعيار المستخدم في صناعة الطباعة، فإذا أردت طباعة مستندك باحترافية، فيجب أن تحاول استخدام ألوان CMYK، حيث يجب أن تفكر في استخدام ألوان CYMK حتى إذا أردت الطباعة باستخدام طابعة منزلية أو مكتبية (انظر إلى عبوة أو عبوات الألوان في طابعتك، فإذا كانت إحداها زرقاء فاتحة، وأخرى أرجوانيةً أو زرقاء داكنة، وأخرى صفراء؛ فلا بد أنك تستخدم ألوان CMYK). إذا اعتقدت أنك قد تحتاج إلى استخدام إدارة الألوان كما ذكرنا سابقًا، فعليك استخدام ألوان CMYK من البداية، فهذا سيجعل الأمر أسهل عند الطباعة. قد تكون قادرًا على استخدام ألوان RGB، ولكن يُحتمَل أن تعمل المطبعة مع ألوان CMYK افتراضيًا، وبالتالي ستظهر مشاكل إن استخدمت ألوان RGB. اختيار نمط الألوان الذي تستخدمه هو أمر متروك لك تمامًا، ولكن إذا كنت مرتبكًا، فاستخدم هذه الإرشادات العامة الآتية: إذا أردت طباعة المستند فاستخدم ألوان CMYK. إذا كان مستندك للاستخدام على الشاشة فقط، فلا مانع من استخدام ألوان RGB. هذه الإرشادات الأساسية مبسطة للغاية ولكنها جيدة لمعظم الأغراض، فالشيء المهم الذي يجب فعله هو التمسّك بنمط ألوان واحد في المستند بأكمله دون المزج بينها، وذا كان لديك أي تساؤل، فتحقق من المطبعة أولًا، إذ سيكون الأشخاص هناك قادرين على تقديم النصح لك. الألوان الموضعية Spot Colours يتيح لك سكريبوس أيضًا إمكانية تحويل لون إلى "لون موضعي". تُعَد الألوان الموضعية أكثر تعقيدًا مما تبدو عليه، ولكن يمكنك التفكير فيها على أنها تعليمات للمطبعة لاستخدام حبر خاص، فإذا أردت طباعة لون معين باستخدام حبر معدني ليكون مثل ذهب لامع على سبيل المثال؛ فعليك أن تجعل هذا اللون لونًا موضعيًا Spot Colour. ويجب أن تكون مستعدًا أيضًا لتشرح للمطبعة ما تريده بالضبط. لكن لا تنشئ ألوانًا موضعيةً خاصةً بك إلا إذا عرفت ما تفعله. نافذة الألوان نافذة الألوان والتعبئة Colours هي المكان الذي ستدير فيه جميع الألوان المستخدَمة في مستندك. يمكن فتح نافذة الألوان باتباع الخطوات التالية: افتح برنامج سكريبوس وأنشئ مستندًا جديدًا (إن لم يكن لديك المستند مفتوحًا بالفعل). اختر قائمة تحرير Edit ثم الألوان والتعبئة Colours. ثم ستظهر نافذة كما يلي: تعرض القائمة الموجودة على الجانب الأيمن الألوان الموجودة فعليًا في مستندك، حيث يجب تحديد اللون في هذه القائمة قبل تنفيذ إجراءٍ ما عليه. وتعمل الأزرار الموجودة على اليسار بالعمليات التالية: يتيح لك زر استيراد Import نسخ كل الألوان من مستند آخر. يتيح لك زر إضافة New إنشاء لون جديد. يتيح لك زر تحرير Edit تغيير لون موجود مسبقًا. يتيح لك زر نسخ مطابق Duplicate نسخ لون موجود وتعديل هذه النسخة. يتيح لك زر حذف Delete إزالة لون من المستند (أو استبداله بلون آخر موجود). يحذف الزر "احذف غير المستخدم Remove Unused" كل الألوان التي لا يستخدمها أي شيء في المستند. يقبل الزر "موافق OK" أي تغييرات أجريتها، ويتراجع الزر "إلغاء Cancel" عنها. محرر الألوان Colour Editor إذا ضغطت على أي من أزرار تحرير أو إضافة أو نسخ مطابق، فستظهر نافذة تحرير الألوان Edit Colour كما في الشكل التالي: سترى اسم اللون الذي تعمل عليه في الجزء العلوي الأيمن من المحرر، حيث يمكنك استخدام أي اسم تريده -بما في ذلك المسافات- طالما لم يستخدمه لون آخر. يوجد تحت الاسم قائمة نمط الألوان Color Model لاختيار نمط الألوان CMYK أو RGB كما ذكرنا سابقًا. يوجد أيضًا مربعان، حيث يُظهر المربع الموجود على اليمين اللون القديم (الأصلي)، واللون الموجود على اليسار هو اللون الجديد (المتغيّر)، ويكون اللون القديم دائمًا هو اللون الأبيض عند إنشاء لون جديد. وإذا حرّرت لونًا، فإن اللون القديم هو اللون قبل إجراء أي تغييرات؛ أما إذا نسخت لونًا، فإن اللون القديم هو اللون الأصلي الذي تنسخه. اللون الجديد هو دائمًا اللون الذي سينشأ عند الضغط على زر "موافق". توجد قائمة "محدد لوحة الألوان Palette Selector" في أعلى يسار نافذة محرّر الألوان، حيث تكون مضبوطةً افتراضيًا على الخيار "خريطة الألوان HSV Color Map". يمنحك تحديد الخيار خريطة ألوان مستطيلًا متعدد الألوان مثل الشكل التالي، حيث يمكنك النقر على لونٍ ما لتحديده. توجد أسفل خريطة الألوان بعض المنزلقات Sliders التي يمكنك استخدامها لتغيير اللون الذي تعمل عليه حاليًا، كما يوجد بجوار كل منزلق حقلٌ نصي، حيث يمكنك إدخال قيمة مباشرةً. ويوجد على يمين كل حقل مجموعة من الأسهم المتحركة التي تسمح لك بزيادة أو إنقاص هذه القيمة بسرعة. إنشاء لون جديد من الصفر افتح نافذة الألوان والتعبئة -إن لم تكن مفتوحةً بالفعل- من قائمة تحرير ثم الألوان والتعبئة Colours، ثم اضغط على الزر إضافة أو جديد New. ثم ستظهر لك نافذة تحرير الألوان Edit Colour. تأكّد من ضبط نمط الألوان Color Model على CMYK لإنشاء لون CMYK جديد، وعلى القيمة RGB لإنشاء لون RGB جديد. يوصَى بإعطاء اللون اسمًا مرتبطًا بغرض استخدامه، أي إذا أردت استخدام لون أزرق داكن لخلفيّة لافتة، فيجب تسمية اللون مثل الاسم "خلفية اللافتة Banner Background" مثلًا، حيث ؤدي تسمية الألوان بهذه الطريقة إلى تجنّب الالتباس إذا قررت تغيير اللون لاحقًا، فإذا سمّيت اللون في الأصل بالاسم "أزرق داكن" على سبيل المثال ولكنك أردت تغيير خلفية اللافتة إلى اللون الأحمرعوضًا عن الأزرق الداكن، فيجب إعادة تسمية اللون مع تغييره (وقد تغير رأيك مرةً أخرى). انقر في أي مكان على خريطة الألوان لتحديد اللون الموجود أسفل المؤشر (اسحب المؤشر على الخريطة لترى تغير اللون). سيتغيّر مربع اللون "الجديد" الموجود على اليسار ليظهر لك الشكل الذي سيبدو عليه اللون الجديد، أثناء تحديد لون من خريطة الألوان. استخدم المنزلقات الموجودة أسفل خريطة الألوان لضبط اللون كما تريد، واسحب المنزلق لتغيير أحد مكونات اللون، إذ سيغيّر سحب المنزلق "C" مثلًا مقدار السماوي Cyan في اللون إذا استخدمت نمط ألوان CMYK. ويمكنك أيضًا ضبط قيم محدَّدة لكل مكون من مكونات اللون باستخدام حقول إدخال النص على يسار كل منزلق. يمكنك الضغط على زر "موافق" لإنشاء اللون الجديد إن أعجبك، أو اضغط على زر "إلغاء" إن لم تَعُد تريده. انقر على محدد لوحة الألوان، وانتقل لأسفل حتى تصل إلى لوحة الألوان "CrayonTM" مثلًا، واضغط عليها. سترى أن خريطة الألوان قد استبدِلت بقائمة من الألوان التي لها أسماء، حيث سيؤدي النقر على لونٍ من هذه القائمة -اللون "Aquamarine" الأزرق الفاتح مثلًا- إلى تغيير اللون الذي تحرّره لتظهر قيم اللون Aquamarine المخزَّنة، وقد تلاحظ أيضًا تغيّر نمط الألوان، لأن بعض اللوحات اللونية عبارة عن لوحات RGB وبعضها الآخر عبارة عن لوحات CMYK. إذا غيّرت قيم اللون الآن، فلن تغيّره في اللوحة اللونية المعيارية، إذ تتغيّر فقط نسختك الخاصة من هذا اللون. يعيد برنامج سكريبوس تسمية اللون بنفس اسم اللون في اللوحة اللونية تلقائيًا عندما تختار لونًا من إحدى اللوحات المعيارية، لذلك فقد ترغب في إعادة تسميته بنفسك إلى شيء مفيد لك. يمكن أن يؤدي انتقاء الألوان من لوحة معيارية أحيانًا إلى تسهيل الحصول على الألوان التي تتناسب مع بعضها البعض، فهناك العشرات من اللوحات اللونية الجاهزة في سكريبوس التي يمكنها أن تفيدك في تصميماتك، لذلك نوصيك بإلقاء نظرة عليها. تحرير لون موجود مسبقا حدّد لونًا من القائمة الموجودة على يمين نافذة الألوان والتعبئة Colours واضغط على زر تحرير Edit. ستظهر لك نافذة تحرير الألوان كما كانت من قبل ولكنك ستحرّر اللون الذي حدّدته. يمكنك تغيير نمط الألوان والقيم إلى أي شيء تريده، كما تفعل عند إنشاء لون جديد. يؤدّي الضغط على زر "موافق" إلى إجراء التغييرات على اللون، بينما يلغيها الزر "إلغاء". نسخ لون حدّد لونًا من القائمة الموجودة على يمين نافذة الألوان والتعبئة Colours، واضغط على زر نسخ مطابق Duplicate. ستظهر لك نافذة تحرير الألوان كما كانت من قبل ولكنك ستحرّر نسخة من اللون الذي حدّدته. لاحظ تغيُّر اسم اللون مؤقتًا إلى "نسخ من <اللون> أو Copy of <colour>‎" حيث أن <اللون> هو اسم اللون الذي حددته في الأصل، لذلك يجب تغيير هذا الاسم إلى اسم أفضل. لن يتغير اللون الأصلي الذي حدّدته، إذ سيكون أيّ تغيير تجريه هنا على النسخة الجديدة فقط. يمكنك أيضًا تعديل نمط الألوان و / أو القيم كما تريد. سينشأ لونك الجديد بمجرد الضغط على زر "موافق"، أو اضغط على زر "إلغاء" إن لم تَعُد تريده. حذف لون حدّد لونًا من القائمة الموجودة على يمين نافذة الألوان والتعبئة Colours واضغط على زر حذف Delete. ستظهر لك نافذة حذف اللون Delete Colour كما في الشكل التالي (لكن انتبه، حيث سيؤدي الضغط على زر حذف في الإصدار 1.5.7 من برنامج سكريبوس إلى حذف اللون مباشرةً دون ظهور هذه النافذة): يجب الآن تحديد اللون الموجود الآخر الذي سيُستبدَل اللون المحذوف به من القائمة، حيث سيُستبدَل لون أيّ كائن (نص أو مخطط تفصيلي أو تعبئة أو غير ذلك) له اللون الذي تحذفه بهذا باللون الذي ستختاره، فإذا حذفت اللون "الأحمر" واستبدلته باللون "الأزرق" على سبيل المثال، فسيُلوَّن أي شيء كان لونه "أحمر" باللون "الأزرق". سيؤدي تحديد الخيار "لا شيء None" على أنه اللون البديل إلى عدم وجود أي لون على الإطلاق لكل شيء ملوَّنٍ باللون الذي تحذفه. اضغط على زر "موافق" لحذف اللون، أو اضغط على زر "إلغاء" لإلغاء الحذف. حذف الألوان غير المستخدمة يمكن أن تصبح قائمة الألوان الخاصة بك فوضويةً مع الكثير من الألوان التي أنشأتها لأي سبب من الأسباب ولكنك لم تَعُد تريدها، حيث يمكنك تصفح قائمة الألوان، وتحديد كل لون تعرف أنك لا تستخدمه ثم حذفه لوحده، ولكنها قد تكون عمليةً طويلةً جدًا، وقد تحذف لونًا لا تريد حذفه عن طريق الخطأ، لهذا السبب يحتوي برنامج سكريبوس على عملية "حذف الألوان غير المستخدَمة". اضغط على الزر "احذف غير المستخدَم Remove Unused" في نافذة الألوان والتعبئة Colours. سينظر برنامج سكريبوس إلى كل لونٍ في القائمة ويتحقق لمعرفة ما إذا كان هناك أي شيء يستخدم هذا اللون بمجرد الضغط على الزر "احذف غير المستخدَم"، فإذا استخدم أي شيء في المستند لونًا ما، فسيتجاهله سكريبوس وينتقل إلى اللون التالي؛ أما إن لم يستخدم أي شيء هذا اللون، فسيحذفه سكريبوس مباشرةً دون التحقق منك أولًا، ثم سيحدّث سكريبوس القائمة لإظهار الألوان التي تستخدمها الكائنات في مستندك فقط. استيراد الألوان من مستند آخر قد يكون لديك في بعض الأحيان لون محدَّد في مستند آخر وترغب في استخدامه في المستند الحالي، كما يمكنك إعادة إنشاء هذا اللون يدويًا، ولكن عملية استيراد اللون من المستند الآخر أسرع. اضغط على الزر "استيراد Import" في نافذة الألوان والتعبئة. ستظهر لك الآن نافذة افتح ملفًا Open File (أو استورد ألوانًا)، حيث يمكنك اختيار المستند - ملف سكريبوس SLA - الذي تريد استيراد اللون منه، بعدها حدّد مستندًا واضغط على موافق لاستيراد كل الألوان من المستند المحدد، أو اضغط على "إلغاء" لإلغاء الاستيراد. يحصل الاستيراد على كل الألوان من المستند المحدّد وتُضاف إلى مستندك المفتوح، حيث يمكنك استخدام عملية "حذف الألوان غير المستخدَمة" بعد استخدام اللون الذي تريده على كائنٍ ما لإزالة الألوان الأخرى المستوردة إن أردت ذلك. اللوحات اللونية المخصصة يمكنك إنشاء لوحاتك اللونية المخصصة باستخدام العمليات المذكورة أعلاه، إذ يمكنك استخدام هذه اللوحات في أي مستند آخر على النحو الآتي: أنشئ مستندًا جديدًا. اضبط الألوان على النحو المطلوب وتأكّد منها لأنك ستستخدمها مرات متعددة. احفظ المستند باسم مناسب. أغلق المستند ثم أنشئ مستندًا جديدًا. استخدم الزر "استيراد" في نافذة الألوان والتعبئة Colours لنسخ الألوان من مستند "لوحة الألوان" الذي حفظته للتو إلى مستندك الجديد. تذكّر أن أي تغييرات تجريها على الألوان التي استوردتها لن تُطبَّق على مستند "لوحة الألوان"، وإذا غيّرت ألوان مستند "لوحة الألوان"، فستحتاج إلى إعادة استيرادها لمشاهدة التغييرات. عجلة الألوان Colour Wheel هناك طريقة أخرى يمكنك من خلالها إنشاء الألوان في برنامج سكريبوس، وهي استخدام عجلة الألوان التي تتيح لك تحديد الألوان التي تتلاءم مع بعضها البعض بسهولة على النحو الآتي: أغلق نافذة الألوان والتعبئة إذا كانت مفتوحة. اختر قائمة إضافي Extras ثم عجلة الألوان Colour Wheel. يجب أن تشاهد الآن نافذة عجلة الألوان كالشكل التالي: تنقسم هذه النافذة إلى خمسة أقسام هي: توجد عجلة الألوان في أعلى اليمين، حيث يمكنك اختيار اللون الأساسي Base Colour. يوجد تحتها قسم تحديد الطريقة Method، حيث تختار طريقة تحديد سكريبوس للألوان الأخرى. يوجد تحته قسم المعاينة Preview، حيث يمكنك أن ترى كيف ستبدو الألوان المختارة مع بعضها البعض في ظروف مختلفة. الجزء العلوي الأيسر هو القسم الذي تغيّر من خلاله قيم اللون الأساسي اللونية بدقة. وتوجد تحته قائمة بالألوان التي اخترتها أو التي اختارها برنامج سكريبوس. اللون الأساسي Base Colour ستتعامل دائمًا مع اللون الأساسي عندما تستخدم عجلة الألوان، إذ يخبر هذا اللون الأساسي برنامجَ سكريبوس باللون الذي يجب استخدامه عند اختيار ألوان أخرى، ويظهَر اللون الأساسي دائمًا في دائرة عجلة الألوان المركزية. انقر على لونٍ من عجلة الألوان لاختياره على أنه اللون الأساسي، أو اسحب المؤشر حوله مع الاستمرار في الضغط على زر الفأرة الأيسر لرؤية تغيّر اللون الأساسي. هناك عدد من الدوائر الصغيرة حول عجلة الألوان تُظهِر الأماكن التي يختار سكريبوس الألوان منها، حيث توضّح الدائرة الحمراء مكان وجود اللون الأساسي على العجلة، كما توضّح الدائرة (أو الدوائر) السوداء مكان الألوان الأخرى. طريقة مخطط الألوان Colour Scheme Method يستخدم برنامج سكريبوس مجموعةً متنوعةً من الطرق لاختيار الألوان وهي: تدرج لوني أحادي Monochromatic: يتكون من ثلاثة ألوان هي اللون الأساسي ونسخة أفتح منه ونسخة أغمق. لون متماثل Analogous: يتكون من ثلاثة ألوان هي اللون الأساسي ولونان آخران عند زاويةٍ ما من اللون الأساسي، إذ يمكنك تحديد قيمة هذه الزاوية من الحقل الموجود تحت قائمة الطرق. لون مكمّل Complementary: يتكون من لونين هما اللون الأساسي ولون آخر متباين معه. التكامل المنقسم Split Complementary: يتكون من خمسة ألوان هي مزيج من لون متماثل ولون مكمّل. التكامل الثلاثي Triadic: يتكون من ثلاثة ألوان هي اللون الأساسي ولونان آخران عند الزاوية 120 درجة منه. ثانوي (تكاملي مزودج) Tetradic: يتكون من أربعة ألوان هي اللون الأساسي ولون متماثل ولونان مكمّلان. لست بحاجة إلى أن تعرف الأسلوب الذي تختار به هذه الطرق ألوانها أو ما تعنيه هذه الطرق، فكل ما عليك فعله هو تجربة هذه الطرق واختيار الأنسب لتصميمك. الزوايا Angles يمكنك اختيار "الزاوية" من الحقل الموجود تحت قائمة الطرق لبعض منها، حيث تحدّد هذه الزاوية فقط مدى دوران العجلة - بعيدًا عن اللون الأساسي - لتحديد الألوان الأخرى عند هذه الزاوية. قسم المعاينة Preview يوجد قسم المعاينة أسفل قسم طريقة مخطط الألوان، حيث يوضح الجزء الرئيسي من هذا القسم عيّنات الألوان التي اخترتها والألوان التي اختارها برنامج سكريبوس مع نص فاتح وداكن فوقها لتتمكّن من رؤية كيفية ظهورها في المستند. وتوجد فوق هذه المعاينة قائمةٌ تمثّل نوع خلل الطيف Vision Defect Type التي تمكّنك من تغيير نوع المعاينة التي ستراها، حيث سيظهِر الخيار "بصر طبيعي Normal Vision" كيف ستبدو الألوان لشخص يتمتع ببصر طبيعي، وتُظهر الأنواع الأخرى كيف ستبدو الألوان لشخص لديه مشكلة معينة في بصره، حيث يمكنك تحديد نوع العيب من القائمة لتغيير المعاينة. اختيار اللون الأساسي يمكنك تحديد قيم اللون الأساسي بدقة من القسم الموجود في الجزء العلوي الأيسر عن طريق الكتابة في حقول النص أو استخدام أزرار التحرك لزيادة أو إنقاص القيم. الغرض من علامات التبويب CMYK وRGB وHSV واضح، ويتيح لك التبويب مستند Document اختيار أحد ألوان مستندٍ موجود مسبقًا مثل لون أساسي. الألوان الناتجة Result Colours يُظهِر قسم الألوان الناتجة Result Colors الموجود في أسفل يسار النافذة الألوان كما ستكون إذا أُضيفت إلى المستند، كما أنه يظهِر أسماءها. ولا يمكنك إجراء أي تغييرات هنا، فهي مجرد معلومات، ولكن يمكن إعادة تسمية الألوان من خلال نافذة الألوان والتعبئة Colours -كما وضّحنا سابقًا- إن أردت ذلك. انقر على لونٍ من هذه القائمة لمعرفة المزيد من المعلومات حول هذا اللون في الجدول الذي تحته. الدمج Merging والاستبدال Replacing يمكنك استخدام إما الزر "دمج Merge" أو الزر "استبدال Replace" عندما تكون جاهزًا لإضافة الألوان المحدَّدة إلى المستند الخاص بك، حيث يؤدي الضغط على الزر "إلغاء" إلى إغلاق النافذة دون إجراء أية تغييرات. إذا اخترت دمج الألوان، فسيضيف سكريبوس الألوان الجديدة إلى قائمة الألوان في المستند؛ أما إذا كان اللون موجودًا بالفعل بنفس الاسم فستتلقى تحذيرًا وستُنقَل إلى نافذة الألوان والتعبئة Colours لإعادة تسمية اللون الحالي قبل المتابعة. إذا اخترت استبدال الألوان فسيضيف سكريبوس الألوان الجديدة كما هو الحال عند اختيار دمج الألوان، ولكن سيحل هذا اللون مكان أي لون موجود مسبقًا بالاسم نفسه. يمكن أن تكون هذه الخاصية مفيدةً إذا أردت تجربة مخططات ألوان مختلفة، حيث يمكنك على سبيل المثال: إنشاء مخطط ألوان أولي باستخدام عجلة الألوان. ثم إعداد المستند الخاص بك كما تريد. ثم الرجوع إلى عجلة الألوان واختيار مخطط ألون مختلف. ثم استبدال الألوان لترى التغييرات. إرشادات مهمة إذا أردت إنشاء لون RGB جديد اسمه "Violet" له القيم 146 و110 و174، فاتبع الخطوات التالية: اختر قائمة تحرير Edit ثم الألوان والتعبئة Colours. اضغط على زر إضافة أو جديد New. غيّر اسم اللون إلى "Violet" (بدون علامات الاقتباس). تأكد من ضبط نمط الألوان Color Model على الخيار RGB. استخدم المنزلقات أو حقول الإدخال لضبط "R" على القيمة 146، ثم اضبط "G" على القيمة 110، ثم "B" على القيمة 174. اضغط على زر موافق لإنشاء اللون الجديد. اضغط على "موافق" في نافذة الألوان والتعبئة Colours للعودة إلى المستند، إلّا إذا أردت إنشاء مزيد من الألوان. أما إذا أردت إنشاء لون CMYK جديد اسمه "Goldenrod" له القيم 4% و14% و62% و 1%، فاتبع الخطوات التالية: اختر قائمة تحرير ثم الألوان والتعبئة. اضغط على زر إضافة أو جديد. غيّر اسم اللون إلى "Goldenrod" (بدون علامات الاقتباس). تأكّد من ضبط نمط الألوان على الخيار CMYK. استخدم المنزلقات أو حقول الإدخال لضبط "C" على 4%، ثم اضبط "M" على 14%، ثم "Y" على 62%، ثم "K" على 1%. اضغط على زر موافق لإنشاء اللون الجديد. اضغط على "موافق" في نافذة الألوان والتعبئة للعودة إلى المستند إلّا إذا أردت إنشاء مزيد من الألوان. حيث تُعطَى دائمًا قيم اللون بالترتيب R ثم G ثم B لألوان RGB، أو C ثم M ثم Y ثم K لألوان CMYK. ترجمة -وبتصرّف- للمقال How to create your own colours. اقرأ أيضًا كيفية إنشاء الظلال في برنامج سكريبوس Scribus كيفية إنشاء التأثير Distressing Mask في برنامج سكريبوس لإنتاج تأثيرات تعبئة جذابة كيفية إنشاء لافتة نيون Neon Sign في برنامج سكريبوس Scribus كيفية إنشاء تأثير نص مخيف في برنامج سكريبوس Scribus

سنوضّح كيفية إنشاء تأثير مخيف Spooky على نص مثل الشكل التالي لوضعه فوق صورة خلفية باستخدام مجموعة من تقنيات برنامجَي جيمب GIMP وسكريبوس Scribus المختلفة. يجب معرفة كيفية تنفيذ الأشياء التالية على وجه الخصوص: إنشاء وتحرير الألوان. إنشاء إطار صورة ووضع صورة فيه. إنشاء طبقات وإعادة تسميتها. إنشاء إطار نص، وإدخال النص، وتغيير التنسيق. تحويل النص إلى مخططات تفصيلية Outlines. فك تجميع الكائنات. دمج المضلعات. تغيير ألوان التعبئة / الحدّ وأحجام الخطوط. تحويل المضلعات إلى إطارات صور. إنشاء مسارات من الخطوط Strokes. تغيير خصائص الطبقة. إن لم تعرف كيفية تنفيذ هذه الأشياء، فمن المحتمل أن تجد صعوبةً في تمكُّنك من اتباع الخطوات أدناه، إذ سنقدّم بعض التلميحات خلال الشرح ولكن يجب عليك معرفة ما تفعله، فقد شرحنا جميع التقنيات المستخدمة في مقالات أخرى سابقًا، ويُفترَض أيضًا معرفة كيفية استخدام أساسيات برنامج جيمب. الإعداد نزّل صورة الخلفية الموضَّحة في الشكل التالي، وتأكّد من تنزيل النسخة الصغيرة بحجم 640x426 بكسل: نزّل الخط Harrington الموضّح في الشكل التالي -إن لم يكن لديك-: الخطوات التي نحتاجها على برنامج جيمب GIMP افتح برنامج جيمب واضبط لون الخلفية على اللون الأسود. أنشئ صورةً جديدةً بحجم 640x400 مليئةً بلون الخلفية. استخدم قائمة المرشّحات Filters، ثم اختر Noise ثم Hurl، واقبل الإعدادات الافتراضية. استخدم قائمة ألوان Colours ثم اختر عدم التشبّع Desaturate، واقبل الإعدادات الافتراضية. استخدم قائمة طبقات Layer ثم شفافية Transparency، ثم Colour to Alpha، واختر اللون الأسود ثم اضغط موافق. صدّر الصورة بتنسيق PNG (للحفاظ على الشفافية) وسمَِ الملف بالاسم "sparkle.png". يجب الحصول الآن على صورة شبه شفّافة تتكون من الكثير من النقاط ذات التدرج الرمادي، حيث يوضّح الشكل التالي الزاوية العلوية اليسرى منها: الخطوات التي نحتاجها على برنامج سكريبوس الخلفية افتح برنامج سكريبوس وأنشئ مستندًا جديدًا بالقياس A4، أو رسالةً ويكون الاتجاه أفقيًا Landscape، (إن استخدمت القياس Portrait، فيجب عليك تنفيذ المزيد من الخطوات لاحقًا). أنشئ إطار صورة بأي حجم. ضع صورة الخلفية التي نزّلتها في إطار الصورة. انقر بزر الفأرة الأيمن واختر ضبط الإطار إلى صورة Resize Frame to Image. أنقل إطار الصورة إلى الموضع X وY لهما القيمة 50 نقطة (دوّن هذه القيم، إذ ستحتاج إليها لاحقًا). الألوان أنشئ لونًا جديدًا R,G,B = 0,255,133، حيث ستحتاج هذا اللون الجديد لاحقًا. الطبقات أنشئ 4 طبقات جديدة. أعِد تسمية هذه الطبقات من الأعلى إلى الأسفل "top" و"5" و"9" و"15" (بدون علامات الاقتباس). حدّد الطبقة "top". ستساعدك تسمية الطبقات بهذه الطريقة على التأكد من وضع الشيء الصحيح على الطبقة الصحيحة وبالترتيب الصحيح أيضًا. النص الأولي أنشئ إطار نص بنفس حجم إطار صورة الخلفية (لست بحاجة إلى الدقة، فكل ما عليك فعله هو التأكد من النص الذي تكتبه إذا كان مناسبًا للصورة). أدخِل النص "Spectre" (ربما لا يمكنك رؤيته بعد). غيّر نوع الخط إلى الخط "Harrington" وحجمه إلى 160 نقطة، حيث يجب أن تكون قادرًا على رؤيته الآن. حوّل النص إلى مخططات تفصيلية Outlines من قائمة عنصر Item ثم تحويل لـ Convert To، ثم مخططات تفصيلية Outlines. فُكّ تجميع المخططات التفصيلية من قائمة عنصر، ثم اختر التجميع ثم فَك التجميع Ungroup. ادمج المضلعات من قائمة عنصر ثم أدوات المسار، ثم ادمج المضلعات Combine Polygons. انقل النص المحدّد على الصورة إلى المكان الذي يبدو فيه أفضل، حيث يمكنك استخدام المخطط التفصيلي لمعرفة مكان وضعه. تأكد من قيم الموضع X وY لهذا "النص المحدّد" هي أعداد صحيحة، لأن هذا سيساعدك لاحقًا (دوّن قيم X وY هذه، حيث ستحتاج إليها لاحقًا). إنشاء التوهج Sparkles تأكد من أنك في الطبقة "top". حدّد النص. أنشئ نسخًا مكرَّرةً Multiple Duplicate من النص واقبل الإعدادات الافتراضية لإنشائها مباشرةً فوق النص الأصلي. حدّد النسخة الجديدة وأرسلها إلى الطبقة "5". حدّد الطبقة "5"، ثم حدد نسخة النص المكرَّرة. اضبط عرض الخط على القيمة 5 بلون أسود للخط. أنشئ مسارًا من خط Stroke من قائمة عنصر ثم أدوات المسار Path Tools ثم اختر "أنشئ مسار من خط Create "Path from Stroke. اضبط لون التعبئة والحد على "لا شيء None" (لا تنسَ ذلك وإلا فلن يعمل التأثير بصورة صحيحة، حيث ستفقد شفافية الصورة إذا احتفظت بالخلفية المملوءة). حوّل الكائن إلى إطار صورة من قائمة عنصر ثم تحويل لـ ثم إطار صورة. ضع الصورة "Sparkle" في إطار الصورة الجديد. وبهذا يكون قد بدأ التوهّج بالظهور الآن. كرّر نفس الخطوات السابقة ولكن استخدم الطبقة "9" بعرض خط 9 نقاط. ثم افعل الشيء نفسه بالنسبة للطبقة "15" بعرض خط 15 نقطة. يجب أن يبدو النص الآن مثل الشكل التالي: إنشاء التراكب Overlay حدّد الطبقة "top". حدّد النص الأصلي المحدّد. حوّله إلى إطار صورة. ضع صورة الخلفية في هذا الإطار. يبدو هذا خاطئًا ولكن عليك إجراء بعض العمليات الحسابية: اطرح الموضع X "للصورة التي تحتوي النص" من الموضع X لصورة الخلفية (105-50 = 55 مثلًا). اضبط الصورة على "تحجيم حر Free Scaling" من تبويب صورة Image في نافذة خصائص Properties، أو من نافذة خصائص الصورة في الإصدار 1.5.7 من برنامج سكريبوس التي يمكنك الوصول إليها من قائمة نوافذ ثم خصائص المحتوى. بعد ذلك أدخِل القيمة السلبية لعملية الطرح التي أجريتها للتو (‎-55 مثلًا). افعل الشيء نفسه بالنسبة للموضع Y. وبهذا تكون قد تمكّنت من إجراء هذه الحسابات المحدَّدة للمواضع من جعل الخلفية "تمر من خلال" الجزء الأوسط من "التوهّج Sparkles"، وذلك من خلال إنشاء صورة على شكل نص في الأمام، حيث يجب ظهوره وكأن هناك فراغ داخل الحروف، وانظر مكان مرور الأشجار والأرض عبر النص لترى التأثير بصورة أفضل. اللمسات الأخيرة ابقَ في الطبقة "top" وحدّد "صورة النص"، ثم أعطها لون المخطط التفصيلي الذي أنشأته مسبقًا بعرض خط يبلغ 1 نقطة. حدد الطبقة "15" واضبط التعتيم Opacity على القيمة 60%. حدّد الطبقة "9" واضبط التعتيم على القيمة 80%. حدد الطبقة "5" واضبط نمط الدمج Blend Mode على "تباين Difference" (لاحظ كيف يؤدي استخدام نمط الدمج "التباين"- في هذه الحالة - إلى زيادة الضوء بين الأشجار). فعّل "وضع المعاينة Preview Mode" لرؤية التأثير في أفضل حالاته دون إضافة برنامج سكريبوس أي مخططات. النهاية غيّر التعتيم وأنماط الدمج للطبقات الوسطى المختلفة - "5" و"9" و"15" - لتغيير التأثير واختيار ما تراه الأفضل. جرّب أيضًا استخدام صورة مختلفة ولاحظ الفرق الذي يحدث، حيث لا تحتاج إلى البدء من جديد، إذ يمكنك تغيير صورة الخلفية فقط، ثم "صورة النص" في الأمام، مع التأكد من تغيير إزاحة X وY مرةً أخرى. ترجمة -وبتصرّف- للمقال How to create some spooky text. اقرأ أيضًا كيفية إنشاء رمز RSS Feed في برنامج سكريبوس Scribus كيفية التعامل مع محرر القصص Story Editor في برنامج سكريبوس Scribus تصميم تأثير النصوص على الصور في جيمب كيفية إنشاء الظلال في برنامج سكريبوس Scribus كيفية إنشاء التأثير Distressing Mask في برنامج سكريبوس لإنتاج تأثيرات تعبئة جذابة كيفية إنشاء لافتة نيون Neon Sign في برنامج سكريبوس Scribus

سنوضّح كيفية إنشاء رمز RSS Feed باستخدام الأدوات الموجودة في برنامج سكريبوس Scribus فقط، وقد لا تستخدم سكريبوس لتنفيذ ذلك نظرًا لوجود العديد من الصور الأفضل المتوفرة مجانًا للاستخدام، ولكن هذا المقال يتعلّق بشرح استخدام أدوات سكريبوس بصورة أساسية. الألوان افتح برنامج سكريبوس وأنشئ مستندًا جديدًا، حيث سيكون القياس A4 / Letter وأي اتجاه سيكون جيدًا. ستحتاج إلى لونين هما: برتقالي فاتح Light Orange بقيم CMYK التي هي: 0% و50% و100% و0%. برتقالي غامق Dark Orange بقيم CMYK التي هي: 5% و60% و90% و10%. استخدم نافذة محرّر الألوان Color Editor، من قائمة تحرير Edit، ثم الألوان والتعبئة Colors لإضافة الألوان إلى المستند. إن لم تعرف كيفية إضافة الألوان إلى المستند، فراجع دليل تعليمات سكريبوس عبر قائمة مساعدة Help ثم اختر Scribus Help، واطّلع على القسم "Documentation / Editing Colors"، ثم راجع قسم "الألوان" في مقال كيفية إنشاء لافتة نيون في برنامج سكريبوس. الخلفية ستحتاج الآن إلى إنشاء شكل مربع ذي زوايا مستديرة للخلفية كما في الشكل التالي: أنشئ مربعًا واجعل العرض والارتفاع 100 نقطة. اضبط نصف القطر لتدوير الزاوية على القيمة 16 نقطة مثلًا من تبويب شكل Shape في نافذة خصائص Properties. اضبط لون الحد Line Colour على "لا شيء None". اضبط نمط التعبئة على "متدرج خطي Diagonal Gradient". اضبط نقطة توقف التدرج اللوني في أقصى اليسار على اللون Dark Orange في الموضع 0%. اضبط نقطة توقف التدرج اللوني في أقصى اليمين على اللون Dark Orange في الموضع 100%. أنشئ نقطة توقف متدرجة جديدة عند الموضع 50%، واضبطها على اللون Light Orange. حدد المربع المستدير واختر قائمة عنصر Item، ثم مضاعفة/تحويل ثم تحويل Transform. اضغط على زر إضافة Add واختر "تحجيم Scaling" من القائمة. اضبط التحجيم الأفقي والرأسي على القيمة 90%. حدد مركز الكائن مثل نقطة أساسية Origin. اضبط عدد النسخ على القيمة "1" واضغط على موافق OK. حدد المستطيل الأصغر الجديد واضبط نمط التعبئة على "خالص Normal" ولون التعبئة على "لا شيء". اضبط لون الحد على اللون Light Orange، واضبط عرض الخط على 3 نقاط من تبويب خط في نافذة خصائص. يجب الحصول الآن على شكل مشابه للشكل السابق. الدوائر أنشئ دائرةً لتكون خارج المربع الأكبر -استخدمنا دائرة بعرض وارتفاع 140 نقطة-. اختر قائمة عنصر ثم مضاعفة/تحويل ثم تحويل. اضغط على زر إضافة Add واختر "تحجيم Scaling" من القائمة. اضبط التحجيم الأفقي والرأسي على 80%. حدد مركز الكائن ليكون نقطةً أساسية. اضبط عدد النسخ على القيمة "1" واضغط على موافق OK. حدد الدائرة الأصغر الجديدة واتبع الخطوات السابقة نفسها من اختيار القائمة عنصر إلى ضبط عدد النسخ ولكن استخدم نسبة تحجيم 76%. حدد الدائرة الأحدث الأصغر واتبع الخطوات السابقة نفسها من اختيار القائمة عنصر إلى ضبط عدد النسخ ولكن استخدم نسبة تحجيم 66%. استخدام هذه النسب المئوية يمنحك شيئًا يشبه الشكل التالي: الأشكال الحلقية يجب الآن تحويل الدوائر الأربع إلى شكلين حلقيين كما يلي: حدد أصغر دائرة داخلية ثم اضغط Shift وحدّد الدائرة التالية الأكبر. اختر قائمة عنصر، ثم أدوات المسار Path Tools، تليها عمليات المسار Path Operations. حدّد عملية "طرح Subtracts"، وبدّل الأشكال إن أردت رؤية الشكل الحلقي في مربع المعاينة العلوي الأيسر. اضغط موافق. حدد الدائرة الأكبر الخارجية ثم اضغط Shift وحدد الدائرة الأصغر التالية. كرّر الخطوات السابقة نفسها من اختيار قائمة عنصر إلى الضغط على موافق. يجب الحصول الآن على شكلان حلقيان بدلًا من أربع دوائر، بحيث يكون الشكل التالي ملوّنًا لتتمكّن من رؤية النتيجة بصورة أفضل، ولكن إن فعلت ذلك تذكّر وجوب التراجع عن التلوين قبل المتابعة. أرباع الأنابيب اختر قائمة إدراج Insert ثم منحنى بيزية Insert Bezier Curve. انقر أعلى منتصف الجزء العلوي من الحلقة الكبيرة، ثم انقر على أسفل منتصف الجزء السفلي، وانقر بزر الفأرة الأيمن لإغلاق المنحنى. يجب الانتباه ليكون الخط مستقيمًا عموديًا ولكن يمكنك استخدام نافذة حاذِ ووزّع Align & Distribute للمحاذاة مركزيًا، ولا يمكنك استخدام أداة الخط العادية لأن الخطوط العادية لا يمكنها قطع المضلعات. اختر قائمة عنصر ثم مضاعفة/تحويل ثم نسخ مطابق Multiple Duplicate، واضغط على زر موافق لإنشاء نسخة أعلى النسخة الأصلية. حدّد أحد الخطوط المستقيمة ثم اضغط Shift، وحدّد الحلقة الصغيرة. اختر قائمة عنصر ثم أدوات المسار Path Tools، ثم قصّ المضلع Cut Polygon. بهذا يكون قد اختفى خط بيزية الآن -على الرغم من وجود الخط الآخر- وانقسمت الحلقة إلى قسمين، بحيث قد تتمكن من رؤية المكان الذي انقسمت فيه الخطوط الأسمك في أماكن معينة. حدد خط بيزية الآخر، ثم اضغط على Shift وحدد الحلقة الأكبر، بعد ذلك اختر قائمة عنصر، ثم أدوات المسار، ثم قصّ المضلع مرةً أخرى. وبهذا تكون قد قُسِّمت الحلقتان إلى "أنصاف أنابيب"، حيث نقلناها قليلًا في الشكل التالي لتتمكن من رؤيتها، ولكن لا تفعل ذلك. يجب الآن تقسيمها مرةً أخرى: ارسم خط بيزية آخر كما فعلت سابقًا ولكن اجعله أفقيًا ويمر من منتصف أنصاف الأنابيب. اختر قائمة عنصر ثم مضاعفة/تحويل ثم نسخ مطابقة مرةً أخرى للحصول على خط آخر. حدّد أحد خطوط بيزية وأحد أنصاف الأنابيب اليمنى واستخدم عملية قص المضلع مرةً أخرى. افعل الشيء نفسه مع خط بيزية الآخر ونصف الأنبوب الأيمن الآخر. يمكنك محاولة إجراء عملية "القص" سريعًا عن طريق رسم شكل "L" بدلًا من استخدام خطين مستقيمين، ولكن قد تجد مع هذه الطريقة أن الحصول على محاذاة مركزية صحيحة أمر صعب، لكن يمكنك المحاولة رغم ذلك. يجب الحصول الآن على نصف أنبوب على اليسار وربع أنبوب على اليمين، حيث نقلناهم قليلًا في الشكل التالي لتتمكّن من رؤيتهم. تجميع الأجزاء مع بعضها البعض يمكنك الآن حذف أنصاف الأنابيب اليسرى والمجموعة السفلية من أرباع الأنابيب لأنها ليست ضرورية. ارسم دائرةً صغيرةً بعرض وارتفاع 16 نقطة مثلًا. حدّد الدائرة وكلًا من ربعي الأنبوب، واستخدم نافذة Align & Distribute لمحاذاتهم إلى الجانب الأيسر والأسفل. أعطِ الدائرة والأرباع لون خط "لا شيء" ولون تعبئة أبيض. اجمعهم مع بعضهم البعض ليسهل تحريكهم. حرِّك الأشكال البيضاء إلى فوق المربعات المستديرة الأصلية. يمكنك استخدام نافذة Align & Distribute للحصول على تموضع سريع أو قد ترغب في وضعها يدويًا. الخلاصة يجب الآن الحصول على الشكل التالي، وبذلك نكون قد أنهينا العمل. صحيح أن هذا قد كان ذلك عملًا كثيرًا لشيء بسيط جدًا ولكن نأمل تكوين فكرةً جيدةً لك الآن عن كيفية عمل بعض وظائف برنامج سكريبوس، وهذا هو الشيء الرئيسي. ترجمة -وبتصرّف- للمقال How to create an RSS Feed Symbol. اقرأ أيضًا كيفية بدء استخدام برنامج سكريبوس Scribus كيفية إنشاء شارة تقليدية ذات شريط في برنامج سكريبوس Scribus خطوات تطوير شعار باستخدام برنامج سكريبوس Scribus كيفية إنشاء الظلال في برنامج سكريبوس Scribus الطريقة الأساسية لترقيم العناصر تسلسليا في برنامج سكريبوس Scribus

كانت معظم التطبيقات معنيّةً بنقل الملفات في الأيام الأولى من تقنيات تبديل الرزم، على الرغم من أنه في وقت مبكر من عام 1981، كانت التجارب جاريةً لنقل حركة المرور في الوقت الحقيقي، مثل عينات الصوت الرقمية. نطلق على التطبيق صفة "الوقت الحقيقي" عندما يكون لديه متطلبات قوية لتسليم المعلومات في الوقت المناسب. يُعَد بروتوكول Voice over IP أو اختصارًا VoIP مثالًا كلاسيكيًا لتطبيق الوقت الحقيقي لأنه لا يمكنك إجراء محادثة بسهولة مع شخص إذا استغرق الأمر أكثر من جزء من الثانية للحصول على رد. تفرُض تطبيقات الوقت الحقيقي بعض المتطلبات المحدَّدة على بروتوكول النقل التي لم تلبيها جيدًا البروتوكولات التي ناقشناها سابقًا. تُقسم تطبيقات الوسائط المتعددة، التي تتضمن الفيديو والصوت والبيانات، إلى فئتين: التطبيقات التفاعلية interactive applications وتطبيقات التدفق streaming applications. يظهر الشكل السابق مؤلفَي السلسلة اللذين يستخدمان نموذجًا لأداة مؤتمرات نموذجية للصف التفاعلي. هذه هي أنواع التطبيقات الأكثر صرامة في الوقت الحقيقي إلى جانب بروتوكول VoIP. تقدم تطبيقات التدفق عادةً تدفقًا صوتيًا أو تدفق فيديو من خادمٍ إلى عميل وتتميز بمُنتجات تجارية مثل Spotify. أصبح تدفق الفيديو، مثل YouTube و Netflix، أحد الأشكال السائدة لحركة المرور على الإنترنت. تضع تطبيقات التدفق متطلباتٍ في الوقت الحقيقي أقل صرامةً إلى حدٍ ما على البروتوكولات الأساسية نظرًا لأنها تفتقر إلى التفاعل بين البشر. لا يزال التوقيت مهمًا على الرغم من ذلك، فقد تريد على سبيل المثال أن يبدأ تشغيل مقطع فيديو بعد الضغط على "تشغيل play"، وبمجرد أن يبدأ التشغيل، فإن الرزم المتأخرة إما ستؤدي إلى تباطئه أو إنشاء نوع من التدهور البصري visual degradation. لذلك وعلى الرغم من أن تطبيقات التدفق ليست تمامًا في الوقت الحقيقي، ولكن لا يزال لديها ما يكفي من القواسم المشتركة مع تطبيقات الوسائط المتعددة التفاعلية لضمان النظر في بروتوكولٍ مشترك لكلا النوعين من التطبيقات. يجب أن يكون واضحًا الآن أن مصممي بروتوكول النقل لتطبيقات الوقت الحقيقي والوسائط المتعددة يواجهون تحديًا حقيقيًا في تحديد المتطلبات على نطاق واسع بما يكفي لتلبية احتياجات التطبيقات المختلفة للغاية. يجب عليهم أيضًا الانتباه إلى التفاعلات بين التطبيقات المختلفة، مثل مزامنة تدفقات الصوت والفيديو. سنرى أدناه كيف أثرت هذه المخاوف على تصميم بروتوكول النقل الأساسي في الوقت الحقيقي المُستخدم اليوم وهو: بروتوكول النقل في الوقت الحقيقي Real-time Transport Protocol أو اختصارًا RTP. يُستمد الكثير من RTP في الواقع من وظائف البروتوكول التي كانت مضمَّنةً في الأصل في التطبيق نفسه. كان اثنان من أوائل هذه التطبيقات هما تطبيقَي VIC و VAT، حيث يدعم الأول الفيديو في الوقت الحقيقي ويدعم الآخر الصوت في الوقت الحقيقي. شُغِّل كلا التطبيقين في الأصل مباشرة عبر بروتوكول UDP، بينما اكتشف المصممون الميزات اللازمة للتعامل مع طبيعة الاتصال في الوقت الحقيقي، وأدركوا لاحقًا أن هذه الميزات يمكن أن تكون مفيدة للعديد من التطبيقات الأخرى وعرّفوا بروتوكولًا بهذه الميزات، ثم جرى توحيد هذا البروتوكول في النهاية كبروتوكول RTP. يمكن تشغيل RTP عبر العديد من بروتوكولات الطبقة الدنيا، ولكنه لا يزال يعمل بشكل شائع عبر بروتوكول UDP. وهذا يؤدي إلى مكدس البروتوكول الموضح في الشكل التالي، حيث نلاحظ تشغيل بروتوكول نقل فوق بروتوكول نقل. لا توجد قاعدة مخالفة لذلك، نظرًا لأن بروتوكول UDP يوفّر مثل هذا المستوى الأدنى من الوظائف، كما أن فك تعدد الإرسال الأساسي المستند إلى أرقام المنافذ هو بالضبط ما يحتاجه بروتوكول RTP كنقطة بداية. لذلك يستعين RTP بمصادر خارجية لوظيفة فك تعدد الإرسال demultiplexing إلى UDP بدلًا من إعادة إنشاء أرقام المنافذ في RTP. متطلبات بروتوكول RTP إن أكثر المتطلبات الأساسية لبروتوكول الوسائط المتعددة للأغراض العامة هو أنه يسمح للتطبيقات المتماثلة بالتفاعل مع بعضها بعضًا. ينبغي أن يكون من الممكن لتطبيقين لعقد المؤتمرات الصوتية مطبَّقَين بصورة مستقلة التحدثَ مع بعضهما البعض على سبيل المثال. يشير هذا على الفور إلى أنه كان من الأفضل للتطبيقات استخدام نفس طريقة تشفير وضغط الصوت، وإلا فإن البيانات المرسلة من طرفٍ واحد ستكون غير مفهومة للطرف المستقبل. سيكون استخدام مخططٍ واحد فقط فكرة سيئة نظرًا لوجود عددٍ كبير من أنظمة تشفير الصوت المختلفة، ولكلٍ منها مقايضاتٌ خاصة بها بين الجودة ومتطلبات حيز النطاق التراسلي bandwidth والتكلفة الحسابية، ويجب بدلًا من ذلك أن يوفر بروتوكولنا طريقةً تمكّن المرسل من إخبار جهاز الاستقبال بنظام التشفير الذي يريد استخدامه، وربما التفاوض إلى أن يتم تحديد مخطط متاح لكلا الطرفين. هناك العديد من أنظمة ترميز الفيديو المختلفة كما هو الحال مع الصوت أيضًا، وبالتالي نرى أن الوظيفة المشتركة الأولى التي يمكن أن يوفرها RTP هي القدرة على التواصل لاختيار مخطط التشفير هذا. كما يعمل أيضًا على تحديد نوع التطبيق (الصوت أو الفيديو على سبيل المثال)، فبمجرد أن نعرف ما هي خوارزمية التشفير المستخدَمة، فإننا نعرف نوع البيانات المُشفَّرة أيضًا. تمكين مستقبل تدفق البيانات من تحديد علاقة التوقيت بين البيانات المستلمة مطلبٌ مهم آخر. حيث تحتاج تطبيقات الوقت الحقيقي إلى وضع البيانات المستلمة في مخزن تشغيلٍ مؤقت playback buffer لتخفيف الاضطراب jitter الذي قد يكون أُدخِل في تدفق البيانات أثناء النقل عبر الشبكة. وبالتالي سيكون من الضروري وجود نوعٍ من استخدام العلامات الزمنية timestamping للبيانات لتمكين المستقبل من إعادة تشغيلها في الوقت المناسب. تتعلق مسألة توقيت تدفق وسائطٍ واحد بمزامنة الوسائط المتعددة في مؤتمر، والمثال الواضح على ذلك هو مزامنة تدفق الصوت والفيديو الذي ينشأ من نفس المرسل، وهذه مشكلة أعقد قليلًا من تحديد وقت تشغيل تدفقٍ واحد كما سنرى أدناه. يجب توفير وظيفة أخرى وهي الإشارة إلى فقدان رزمة. لاحظ أن التطبيق الذي له حدود وقت استجابةٍ ضيقة لا يمكنه عمومًا استخدام وسيلة نقل موثوقة مثل TCP لأن إعادة إرسال البيانات لتصحيح الخسارة قد يتسبب في وصول الرزمة بعد فوات الأوان لتكون مفيدة. وبالتالي يجب أن يكون التطبيق قادرًا على التعامل مع الرزم المفقودة، والخطوة الأولى في التعامل معها هي ملاحظة أنها مفقودة بالفعل. قد يتخذ تطبيق الفيديو الذي يستخدم تشفير MPEG إجراءاتٍ مختلفة عند فقدان رزمة، اعتمادًا على ما إذا كانت الحزمة تأتي من إطار I أو من إطار B أو من إطار P على سبيل المثال. يُعَد فقدان الرزم أيضًا مؤشرًا محتملًا للازدحام. تفوّت تطبيقات الوسائط المتعددة أيضًا ميزات تجنب الازدحام في TCP نظرًا لأنها لا تعمل عبر TCP. ولكن العديد من تطبيقات الوسائط المتعددة قادرةٌ على الاستجابة للازدحام، مثل تغيير معاملات خوارزمية التشفير لتقليل حيز نطاق التراسلي المُستهلك. يحتاج المستقبِل، لإنجاز هذا العمل، إلى إعلام المرسل بحدوث فقدانٍ في الرزم حتى يتمكن المرسل من ضبط معاملات التشفير الخاصة به. وظيفةٌ أخرى مشتركة بين تطبيقات الوسائط المتعددة هي مفهوم بيان حدود الإطار، والإطار في هذا السياق خاصٌ بالتطبيق. فقد يكون من المفيد إعلام تطبيق فيديو أن مجموعةً معينة من الرزم تتوافق مع إطار واحد على سبيل المثال. من المفيد في تطبيقٍ صوتي تحديد بداية مجموعة من الأصوات أو الكلمات المتبوعة بالصمت والتي تُعرَف بـ "talkspurt". يمكن للمتلقي بعد ذلك تحديد فترات الصمت بين talkspurt واستخدامها كفرص لتحريك نقطة التشغيل. يتبع ذلك ملاحظة أن الاختصار الطفيف أو إطالة الفراغات بين الكلمات أمرٌ غير محسوس للمستخدمين، في حين أن تقصير أو إطالة الكلمات نفسها أمرٌ محسوس ومزعج. الوظيفة النهائية التي قد نرغب في وضعها في البروتوكول هي طريقةٌ ما لتحديد المرسلين أسهل استخدامًا من عنوان IP. فيمكن أن تعرض تطبيقات المؤتمرات الصوتية والمرئية سلاسلًا مثل تلك الموجودة على لوحات التحكم الخاصة بها، وبالتالي يجب أن يدعم بروتوكول التطبيق ارتباط هذه السلسلة بتدفق البيانات. ونلاحظ متطلبًا إضافيًا ألا وهو: يجب استخدام حيز النطاق التراسلي بكفاءة معقولة. أي لا نريد تقديم الكثير من البتات الإضافية الواجب إرسالها مع كل رزمة في هيئة ترويسةٍ طويلة، والسبب في ذلك هو أن الرزم الصوتية، والتي تعَد واحدةً من أكثر أنواع بيانات الوسائط المتعددة شيوعًا، تميل إلى أن تكون صغيرة، وذلك لتقليل الوقت المستغرق لملء هذه الرزم الصوتية بالعينات. قد تعني رزم الصوت الطويلة زمن استجابةٍ مرتفع بسبب عملية الحزم packetization، مما يؤثر سلبًا على جودة المحادثات المحسوسة (كان هذا أحد العوامل في اختيار طول خلايا ATM). تعني الترويسة الكبيرة استخدام قدرٍ كبير نسبيًا من حيز نطاق الرابط التراسلي بواسطة الترويسات نظرًا لأن رزم البيانات نفسها قصيرة، وبالتالي تقليل السعة المتاحة للبيانات المفيدة. سنرى العديد من جوانب تصميم RTP التي تأثرت بضرورة إبقاء الترويسة قصيرةً. يمكنك أن تناقش فيما إذا كانت كل ميزة وُصِفت للتو تحتاج حقًا إلى أن تكون في بروتوكول نقلٍ في الوقت الحقيقي، وربما تجد بعض الميزات الأخرى الممكن إضافتها. الفكرة الأساسية هنا هي تسهيل الحياة لمطوّري التطبيقات من خلال منحهم مجموعة مفيدة من الأفكار المجردة وتوفير لبِنات بناء تطبيقاتهم، حيث نوفّر على كل مطور تطبيق في الوقت الحقيقي من اختراع تطبيقه الخاص من خلال وضع آلية علامة زمنية في بروتوكول RTP على سبيل المثال، ونزيد أيضًا من فرص تشغيل تطبيقين مختلفين في الوقت الحقيقي. تصميم بروتوكول RTP الآن وقد رأينا القائمة الطويلة إلى حدٍ ما من متطلبات بروتوكول النقل للوسائط المتعددة، ننتقل إلى تفاصيل البروتوكول الذي حُدِّد لتلبية هذه المتطلبات. طُوِّر بروتوكول RTP في منظمة IETF وهو قيد الاستخدام على نطاق واسع. يحدد معيار RTP بالفعل زوجًا من البروتوكولات، بروتوكول RTP وبروتوكول التحكم في النقل في الوقت الحقيقي Real-time Transport Control Protocol أو اختصارًا RTCP. يُستخدَم البروتوكول الأول لتبادل بيانات الوسائط المتعددة، بينما يُستخدَم البروتوكول الأخير لإرسال معلومات التحكم المرتبطة بتدفق بياناتٍ معين دوريًا. يستخدم تدفق بيانات RTP وتدفق تحكم RTCP المرتبط منافذ طبقة النقل المتتالية عند التشغيل عبر بروتوكول UDP. تستخدم بيانات RTP رقم منفذٍ زوجي وتستخدم معلومات تحكم RTCP رقم المنفذ التالي الأعلى الفردي. إن بروتوكول RTP مصمَّمٌ لدعم مجموعةٍ متنوعة من التطبيقات، فهو يوفّر آليةً مرنة يمكن من خلالها تطوير تطبيقاتٍ جديدة دون إجراء مراجعة متكررة لبروتوكول RTP نفسه. يحدد بروتوكول RTP لكل صنفٍ من أصناف التطبيقات (الصوت مثلًا) ملفَّ تعريفٍ profile وتنسيقًا واحدًا format أو أكثر. يوفّر ملف التعريف مجموعة من المعلومات تضمن فهمًا مشتركًا للحقول الموجودة في ترويسة RTP لصنف التطبيق هذا، كما سيتضح عندما نفحص الترويسة بالتفصيل. تشرح مواصفات التنسيق كيفية تفسير البيانات التي تتبع ترويسة RTP. قد يتبع ترويسة RTP سلسلةٌ من البايتات على سبيل المثال، ويمثل كلٌّ منها عينةً صوتية واحدة مأخوذة بفاصل زمني محدد بعد الفاصل الزمني السابق. قد يكون تنسيق البيانات أعقد من ذلك، حيث يحتاج تدفق الفيديو المشفر بتنسيق MPEG، على سبيل المثال، إلى بنية كبيرة لتمثيل جميع أنواع المعلومات المختلفة. يجسّد تصميم RTP مبدأً معماريًا يُعرف باسم تأطير مستوى التطبيق Application Level Framing أو اختصارًا ALF. طرح هذا المبدأ كلٌّ من كلارك Clark وتنينهاوس Tennenhouse في عام 1990 كطريقة جديدة لتصميم بروتوكولات لتطبيقات الوسائط المتعددة الناشئة. وقد أدركا أنه من غير المرجح تقديم هذه التطبيقات الجديدة جيدًا من خلال البروتوكولات الحالية مثل بروتوكول TCP، وأنها قد لا تقدَّم جيدًا من خلال أي بروتوكول من النوع "مقاس واحد يناسب الجميع". يكمن في قلب هذا المبدأ الاعتقاد بأن التطبيق يفهم احتياجاته الخاصة بصورةٍ أفضل، حيث يعرف تطبيق فيديو MPEG على سبيل المثال أفضل السبل لاستعادة الإطارات المفقودة وكيفية الاستجابة بصورةٍ مختلفة في حالة فقدان إطار I أو إطار B. يفهم نفس التطبيق أيضًا أفضل طريقة لتقسيم البيانات من أجل إرسالها، فمن الأفضل على سبيل المثال إرسال البيانات من إطارات مختلفة في مخططات بيانات مختلفة، بحيث لا تؤدي الرزمة المفقودة إلا إلى إتلاف إطارٍ واحد، وليس إطارَين، لذلك يترك بروتوكول RTP الكثير من تفاصيل البروتوكول لملف التعريف ووثائق التنسيق الخاصة بالتطبيق. صيغة الترويسة يوضح الشكل التالي صيغة الترويسة التي يستخدمها بروتوكول RTP. تكون أول 12 بايتًا موجودةً دائمًا، بينما تُستخدَم معرّفاتُ المصدرِ المشاركة في حالات معينة فقط. قد يكون هناك ترويسات لإضافات اختيارية بعد هذه الترويسة، كما هو موضح أدناه. أخيرًا، يتبع الترويسةَ حمولةُ RTP، والتي يحدّد التطبيق صيغتها. القصد من هذه الترويسة هو أن تحتوي فقط على الحقول المحتمل أن تستخدمها عدّة تطبيقات مختلفة، نظرًا لأن أي شيء خاص جدًا بتطبيقٍ معين سيُنقَل بكفاءة أكبر في حمولة RTP لهذا التطبيق فقط. يشير أول بتين إلى معرّف الإصدار version identifier، والذي يحتوي على القيمة 2 في إصدار RTP المنشور وقت كتابة هذه السلسلة بنسختها الإنجليزية. قد تعتقد أن مصممي البروتوكول كانوا جريئين إلى حد ما للاعتقاد بأن 2 بت ستكون كافية لاحتواء جميع الإصدارات المستقبلية من RTP، لكن تذكر أن هذه البتات موجودةٌ في أعلى ترويسة RTP. إن استخدام ملفات تعريف التطبيقات المختلفة يجعل من غير المرجح أن تكون هناك حاجة إلى العديد من المراجعات لبروتوكول RTP الأساسي، ولكن إذا اتضح أن هناك حاجة إلى إصدار آخر من RTP بخلاف الإصدار 2، فمن الممكن التفكير في تغيير صيغة الترويسة بحيث يكون من الممكن وجود أكثر من إصدارٍ مستقبلي. يمكن أن تحتوي ترويسة RTP الجديدة ذات القيمة 3 في حقل الإصدار على حقل "التخريب subversion" في مكان آخر في الترويسة على سبيل المثال. البت التالي هو بت الحاشية padding أو P، والتي تُضبَط في ظروفٍ تكون فيها حمولة RTP محشوَّةً لسببٍ ما. قد تكون بيانات RTP محشوَّةً لملء كتلة بحجم معين كما هو مطلوب بواسطة خوارزمية تشفير على سبيل المثال. ففي مثل هذه الحالة، سيُنقَل الطول الكامل لترويسة RTP والبيانات والحاشية بواسطة ترويسة بروتوكول الطبقة الدنيا (ترويسة UDP مثلًا)، وسيحتوي البايت الأخير من الحاشية على عدد البايتات التي يجب تجاهلها، وهذا موضح في الشكل الآتي. لاحظ أن طريقة الحشو هذه تزيل أي حاجةٍ إلى حقل طولٍ في ترويسة RTP، وبالتالي يخدم هدف إبقاء الترويسة قصيرةً، حيث يُستنتَج الطول من بروتوكول الطبقة الدنيا في الحالة الشائعة لعدم وجود حاشية. يُستخدم بت التوسّع extension أو X للإشارة إلى وجود ترويسة توسّع، والذي سيُحدَّد لتطبيقٍ معين ويتبع الترويسة الرئيسية. نادرًا ما تُستخدم هذه الترويسات، نظرًا لأنه من الممكن عمومًا تحديد ترويسةٍ خاصة بالحمولة كجزءٍ من تعريف صيغة حمولة تطبيقٍ معين. يتبع البت X حقلٌ مؤلفٌ من 4 بتات يحسب عدد المصادر المشاركة contributing sources، إن وجدت في الترويسة. لاحظنا أعلاه الحاجة المتكررة لنوع من تحديد الإطار، حيث يُوفَّر ذلك من خلال بت العلامة، الذي له استخدامٌ خاص بالملف التعريفي، ويمكن ضبط هذا البت في بداية talkpurt بالنسبة للتطبيق الصوتي على سبيل المثال. ثم حقل نوع الحمولة المؤلف من 7 بتات، حيث يشير إلى نوع بيانات الوسائط المتعددة التي تحملها هذه الرزمة. ويتمثل أحد الاستخدامات المحتملة لهذا الحقل في تمكين التطبيق من التبديل من مخطط تشفيرٍ إلى آخر بناءً على معلوماتٍ حول توفُّر الموارد في الشبكة أو ردًا على جودة التطبيق. يُحدَّد الاستخدام الدقيق لنوع الحمولة أيضًا بواسطة ملف تعريف التطبيق. لاحظ عدم استخدام نوع الحمولة النافعة عمومُا مثل مفتاح لإزالة تعدد الإرسال لتوجيه البيانات إلى تطبيقات مختلفة، أو إلى تدفقات مختلفة داخل تطبيق واحد مثل دفق الصوت والفيديو لمؤتمرات فيديو، ويعود السبب بذلك إلى أن إزالة تعدد الإرسال تُوفَّر عادةً في طبقة سفلية بواسطة بروتوكول UDP على سبيل المثال كما هو موضح سابقًا، وبالتالي فإن دفقين للوسائط باستخدام RTP يستخدمان عادةً أرقام منافذ UDP مختلفة. يُستخدَم الرقم التسلسلي لتمكين مستقبل تدفق RTP من اكتشاف الرزم المفقودة وغير المرتبة، حيث يزيد المرسل ببساطة القيمة بمقدار واحد لكل رزمةٍ مرسلة. لاحظ أن RTP لا يفعل أي شيء عندما يكتشف رزمةً مفقودة على عكس بروتوكول TCP الذي يصحح الفقدان عن طريق إعادة الإرسال، ويفسر هذا الفقدان على أنه مؤشر ازدحام مما قد يؤدي إلى تقليل حجم النافذة، وهنا يُترك للتطبيق بدلًا من ذلك أن يقرر ما يجب فعله عند فقد الرزمة لأن هذا القرار من المرجح أن يعتمد بصورةٍ كبيرة على التطبيق، فقد يقرر تطبيق الفيديو أن أفضل ما يمكن فعله عند فقدان رزمة هو إعادة تشغيل آخر إطار اُستلِم بصورةٍ صحيحة على سبيل المثال. قد تقرر بعض التطبيقات أيضًا تعديل خوارزميات التشفير الخاصة بها لتقليل احتياجات حيز النطاق التراسلي استجابةً لهذه الخسارة، ولكن هذه ليست وظيفة بروتوكول RTP. لن يكون من المعقول أن يقرر RTP بتوجُّب تخفيض معدل الإرسال، لأن هذا قد يجعل التطبيق عديم الفائدة. تتمثل وظيفة حقل الطابع الزمني في تمكين جهاز الاستقبال من تشغيل العينات على فترات زمنية مناسبة وتمكين تزامن تدفقات الوسائط المختلفة. نظرًا لأن التطبيقات المختلفة قد تتطلب مستويات مختلفة من دقة التوقيت، فإن RTP نفسها لا تحدد الوحدات التي يُقاس فيها الوقت. بدلاً من ذلك، فإن الطابع الزمني هو مجرد عداد "لحظات الساعة ticks"، حيث يعتمد الوقت بين هذه اللحظات على الترميز المستخدم. على سبيل المثال ، يمكن لتطبيق صوتي يأخذ عينات البيانات مرة واحدة كل 125 ميكرو ثانية استخدام هذه القيمة كدِقة ساعة. دقة الساعة هي أحد التفاصيل المحددة في ملف تعريف RTP أو تنسيق الحمولة لتطبيق ما. قيمة العلامة الزمنية في الرزمة هي رقمٌ يمثل الوقت الذي جرى فيه إنشاء العينة الأولى في الرزمة. لا تمثِّل العلامة الزمنية انعكاسًا لوقت اليوم، حيث أن الاختلافات بين العلامات الزمنية ذات صلة فقط. إذا كان الفاصل الزمني لأخذ العينات هو 125 ميكرو ثانية على سبيل المثال وأُنشئَت العينة الأولى في الرزمة رقم n + 1 بعد 10 ميلي ثانية من العينة الأولى في الرزمة رقم n، فإن عدد لحظات أخذ العينات بين هاتين العينتين هو: TimeBetweenPackets الوقت بين الرزم / TimePerSample وقت كل عينة = (10 × 10-3) / (125 × 10-6) = 80 بافتراض دقة الساعة هي نفس الفاصل الزمني لأخذ العينات، فإن العلامة الزمنية في الرزمة n + 1 ستكون أكبر من تلك في الرزمة n بمقدار 80. لاحظ إمكانية إرسال أقل من 80 عينة بسبب تقنيات الضغط مثل اكتشاف فترات الصمت، ولكن العلامة الزمنية تسمح للمستقبل بإعادة تشغيل العينات بالعلاقة الزمنية الصحيحة. مصدر المزامنة synchronization source أو اختصارًا SSRC هو رقمٌ مؤلف من 32 بتًا يحدد بشكل فريد مصدرًا واحدًا لتدفق RTP. يختار كل مرسلٍ مصدر مزامنة عشوائيًا في مؤتمر وسائط متعددة معين ويتوقع منه حل التعارضات في الحدث غير المحتمل الذي يختار فيه مصدران نفس القيمة. يضمن بروتوكول RTP الاستقلال عن بروتوكول الطبقة الدنيا من خلال جعل معرّف المصدر شيئًا آخر مختلفًا عن عنوان الشبكة أو عنوان النقل الخاص بالمصدر. كما أنه يمكّن عقدةً واحدة ذات مصادر متعددة (عدة كاميرات مثلًا) من التمييز بين تلك المصادر. ليس مطلوبًا استخدام نفس SSRC في كل تدفق عندما تولد عقدة واحدة تدفقات وسائط مختلفة (الصوت والفيديو على سبيل المثال)، إذ توجد آليات في RTCP (الموضحة أدناه) للسماح بمزامنة الوسائط. يُستخدَم المصدر المشارك contributing source أو CSRC فقط عند مرور عدد من تدفقات RTP عبر مازجٍ mixer. يمكن استخدام المازج لتقليل متطلبات حيز النطاق التراسلي لمؤتمرٍ من خلال استقبال البيانات من عدة مصادر وإرسالها كتدفقٍ واحد. يمكن فك تشفير تدفقات الصوت من عدة مكبرات صوت متزامنة وإعادة تشفيرها على أنها تدفق صوتي واحد على سبيل المثال، وفي هذه الحالة، يحدّد المازج نفسه كمصدر للتزامن ولكنه يحدد أيضًا المصادر المشاركة أي قيم SSRC للمتحدثين الذين شاركوا في الرزمة المعنية. بروتوكول التحكم Control Protocol يوفر بروتوكول RTCP تدفق تحكم مرتبط بتدفق بيانات تطبيق وسائط متعددة. يوفر تدفق التحكم هذا ثلاث وظائف رئيسية: ملاحظاتٍ على أداء التطبيق والشبكة. طريقةً لربط ومزامنة تدفقات الوسائط المختلفة التي تأتي من نفس المرسل. طريقةً لنقل هوية المرسل لعرضها على واجهة المستخدم. قد تكون الوظيفة الأولى مفيدة في اكتشاف الازدحام والاستجابة له. بعض التطبيقات قادرة على العمل بمعدلات مختلفة وقد تستخدم بيانات الأداء لاتخاذ قرار باستخدام نظام ضغط أقوى لتقليل الازدحام على سبيل المثال، أو لإرسال تدفق عالي الجودة عندما يكون هناك ازدحام ضئيل. يمكن أن تكون ملاحظات الأداء مفيدة أيضًا في تشخيص مشاكل الشبكة. قد تعتقد أن الوظيفة الثانية يتم يوفّرها بالفعل معرّف مصدر المزامنة SSRC الخاص ببروتوكول RTP، ولكنها في الحقيقة ليست كذلك. قد تحتوي الكاميرات المتعددة من عقدة واحدة على قيم SSRC مختلفة، ولا يوجد شرطٌ بأن يستخدم تدفق الصوت والفيديو من نفس العقدة نفس SSRC، فقد يكون من الضروري تغيير قيمة SSRC للتدفق نظرًا لاحتمال حدوث تضارب في قيم SSRC. للتعامل مع هذه المشكلة، يستخدم بروتوكول RTCP مفهوم الاسم المتعارف عليه canonical name أو اختصارًا CNAME الذي يُسنَد لمرسل، والذي يرتبط بعد ذلك بقيم SSRC المختلفة التي يمكن أن يستخدمها هذا المرسل باتّباع آليات RTCP. ربط تدفقين هو ببساطة جزءٌ من مشكلة مزامنة الوسائط فقط. يجب أن تكون هناك طريقةٌ لمزامنة التدفقات بدقة مع بعضها بعضًا نظرًا لأن التدفقات المختلفة قد تحتوي على ساعات مختلفة تمامًا وبدّقات granularities وجودة مختلفة وحتى بمقادير مختلفة من عدم الدقة inaccuracy أو الانزياح drift. يعالج بروتوكول RTCP هذه المشكلة عن طريق نقل معلومات التوقيت التي تربط الوقت الحقيقي من اليوم بالعلامات الزمنية المعتمدة على معدل الساعة والتي تُحمَل في رزم بيانات RTP. يحدد بروتوكول RTCP عددًا من أنواع الرزم المختلفة مثل: تقارير المرسل، والتي تمكّن المرسلين النشطين في جلسة من الإبلاغ عن إحصائيات الإرسال والاستقبال. تقارير المستقبِل، والتي يستخدمها المستقبلون الذين ليسوا مرسلين للإبلاغ عن إحصائيات الاستقبال. أوصاف المصدر، والتي تتضمن ملفات CNAME ومعلومات وصف المرسل الأخرى. رزم التحكم الخاصة بالتطبيق. تُرسَل أنواع رزم RTCP المختلفة هذه عبر بروتوكول الطبقة الدنيا، والذي، كما لاحظنا، عادةً ما يكون بروتوكول UDP. يمكن وضع العديد من رزم RTCP في PDU واحد لبروتوكول المستوى الأدنى. يجب إرسال رزمتَي RTCP على الأقل في كل PDU بمستوى أدنى: رزمةٌ هي رزمة تقرير، والأخرى هي رزمة وصف المصدر. قد تُضمَّن رزمٌ أخرى حتى الوصول إلى حدود الحجم المفروضة من قِبل بروتوكولات الطبقة الدنيا. نلاحظ أن هناك مشكلة محتملة مع كل عضو في مجموعة الإرسال المتعدد الذي يرسل حركة مرور تحكمٍ دورية. إذا لم نتخذ بعض الخطوات للحد من ذلك، فمن المحتمل أن تكون حركة مرور التحكم هذه مستهلكًا مهمًا لحيز النطاق التراسلي. لا يُحتمل أن يرسل أكثر من مرسلَين أو ثلاثة بياناتٍ صوتية في أي لحظة في مؤتمر صوتي على سبيل المثال، حيث لا فائدة من تحدث الجميع في آنٍ واحد، ولكن لا يوجد مثل هذا الحد الاجتماعي على كل شخصٍ يرسل حركة مرور تحكمٍ، وقد تكون هذه مشكلة خطيرة في مؤتمر يحضره الآلاف من المشاركين. فللتعامل مع هذه المشكلة، يكون لدى بروتوكول RTCP مجموعة من الآليات التي يقلّل المشاركون من خلالها من تكرار تقاريرهم مع زيادة عدد المشاركين. هذه القواعد معقدةٌ إلى حدٍ ما، لكن الهدف الأساسي هو: حدُّ كمية حركة RTCP الإجمالية إلى نسبةٍ صغيرة (عادةً 5%) من حركة بيانات RTP. لتحقيق هذا الهدف، يجب أن يعرف المشاركون مقدار حيز نطاق البيانات التراسلي المُحتمَل استخدامه (مقدار إرسال ثلاثة تدفقات صوتية على سبيل المثال) مع معرفة عدد المشاركين. يتعلّم المشاركون حيز نطاق البيانات التراسلي المُحتمَل استخدامه من وسائل خارج RTP، والمعروفة باسم إدارة الجلسة session management التي سنناقشها لاحقًا، ويتعلمون عدد المشاركين من تقارير RTCP للمشاركين الآخرين. قد يكون من الممكن فقط الحصول على عدد تقريبي للعدد الحالي للمستقبلين نظرًا لأنه قد تُرسَل تقارير RTCP بمعدلٍ منخفض جدًا، ولكن هذا عادةً يكون كافيًا. يوصَى أيضًا بتخصيص المزيد من حيز نطاق RTCP التراسلي للمرسلين النشطين، على افتراض أن معظم المشاركين يرغبون في رؤية تقارير منهم، لمعرفة مَن يتحدث على سبيل المثال. بمجرد أن يحدّد المشارك مقدار حيز النطاق التراسلي الممكن استهلاكه مع حركة مرور RTCP، يبدأ في إرسال تقارير دورية بالمعدل المناسب. تختلف تقارير المرسل وتقارير المستقبل فقط من حيث أن الأولى تتضمن بعض المعلومات الإضافية حول المرسل. يحتوي كلا النوعين من التقارير على معلومات حول البيانات المُستقبلة من جميع المصادر في أحدث فترة إبلاغ. تتكون المعلومات الإضافية في تقرير المرسل من: علامة زمنية تحتوي على الوقت الحقيقي من اليوم الذي أُنشئ فيه هذا التقرير. علامة RTP الزمنية المقابلة للوقت الذي أُنشئ فيه هذا التقرير. الأعداد التراكمية للرزم والبايتات التي أرسلها هذا المرسل منذ أن بدأ الإرسال. نلاحظ إمكانية استخدام الكميتين الأوليتين لِتفعيل مزامنة تدفقات الوسائط المختلفة من نفس المصدر، حتى إذا كانت تلك التدفقات تستخدم مستويات مختلفة من دقة الساعة في تدفقات بيانات RTP الخاصة بها، حيث أنها تعطي المفتاح لتحويل الوقت من اليوم إلى علامات RTP الزمنية. تحتوي كلٌّ من تقارير المرسل والمستقبل على كتلة واحدة من البيانات لكل مصدرٍ سُمِع منه منذ التقرير الأخير. تحتوي كل كتلة على الإحصائيات التالية للمصدر المعني: SSRC الخاص به. جزء رزم البيانات من هذا المصدر التي فُقِدت منذ إرسال التقرير الأخير (يُحسَب بموازنة عدد الرزم المستقبَلة مع عدد الرزم المتوقعة، ويمكن تحديد هذه القيمة الأخيرة من أرقام RTP التسلسلية). إجمالي عدد الرزم المفقودة من هذا المصدر منذ أول مرة سُمِع من هذا المصدر. أعلى رقم تسلسلي اُستلِم من هذا المصدر (يتوسّع إلى 32 بتًا لحساب التفاف الرقم التسلسلي). الاضطراب jitter الداخلي التقديري للمصدر (محسوب بموازنة التباعد بين الرزم المستقبَلة مع التباعد المتوقَّع في وقت الإرسال). آخر علامة زمنية فعلية مستلمة عبر بروتوكول RTCP لهذا المصدر. التأخير منذ استقبال آخر تقرير مرسل عبر بروتوكول RTCP لهذا المصدر. يمكن لمستقبِلي هذه المعلومات أن يتعلّموا كل أنواع حالة الجلسة. فيمكنهم معرفة ما إذا كان المستقبلون الآخرون يحصلون على جودة أفضل بكثير من الجودة التي يحصلون عليها من بعض المرسلين، مما قد يكون مؤشرًا على ضرورة إجراء حجزٍ للموارد، أو أن هناك مشكلة في الشبكة تحتاج إلى الاهتمام بها. إذا لاحظ المرسل معاناة العديد من المستقبلين من خسارةٍ كبيرة في رِزمهم، فقد يقرر بوجوب تقليل معدل الإرسال أو استخدام مخطط تشفير أكثر مقاومةً للخسارة. الجانب الأخير من بروتوكول RTCP الذي سننظر فيه هو رزمة وصف المصدر. تحتوي هذه الرزمة، على الأقل، على SSRC الخاص بالمرسل وCNAME الخاص بالمرسل. يُشتق الاسم المتعارف عليه canonical name بطريقةٍ تجعل جميع التطبيقات، التي تنشئ تدفقات وسائط والممكن أن تكون بحاجةٍ إلى مزامنة (مثل تدفقات الصوت والفيديو التي أُنشئتمنفصلةً من نفس المستخدم)، تختار نفس CNAME على الرغم من أنها قد تختار قيم SSRC مختلفة، ويتيح ذلك لجهاز الاستقبال تحديدَ تدفق الوسائط الذي يأتي من نفس المرسل. صيغة CNAME الأكثر شيوعًا هي user@host، حيث يكون المضيف host هو اسم النطاق المؤهَّل الكامل لجهاز الإرسال. وبالتالي يعمل التطبيق، الذي يشغّله المستخدم الذي يكون اسم المستخدم user name الخاص به هو jdoe، على الجهاز cicada.cs.princeton.edu، ويستخدم السلسلة jdoe@cicada.cs.princeton.edu باعتبارها CNAME الخاص به. إن العدد الكبير والمتغير من البايتات المُستخدمة في هذا التمثيل سيجعل منه اختيارًا سيئًا لصيغة SSRC، حيث يُرسَل SSRC مع كل رزمة بيانات ويجب معالجتها في الوقت الحقيقي. يمكّن السماح لأسماء CNAME بالالتزام بقيم SSRC في رسائل RTCP الدورية بصيغة SSRC مضغوطة وفعالة. قد تُضمَّن عناصرٌ أخرى في رزمة وصف المصدر، مثل الاسم الحقيقي وعنوان البريد الإلكتروني للمستخدم، حيث تُستخدم في عرض واجهة المستخدم وللتواصل بالمشاركين، ولكنها أقل أهمية لتشغيل بروتوكول RTP من CNAME. RTP و RTCP هما زوجٌ معقد من البروتوكولات مثل بروتوكول TCP. يأتي هذا التعقيد في جزءٍ كبير منه من الرغبة في جعل الأمور أسهل لمصممي التطبيقات. إن التحدي في تصميم بروتوكول النقل هو جعله عامًا بما يكفي لتلبية الاحتياجات المتنوعة على نطاق واسع للعديد من التطبيقات المختلفة دون جعل البروتوكول نفسه مستحيل التطبيق نظرًا لوجود عدد لا حصر له من التطبيقات الممكنة. لقد أثبت بروتوكول RTP نجاحًا كبيرًا في هذا الصدد، حيث شكّل الأساس للعديد من تطبيقات الوسائط المتعددة في الوقت الحقيقي التي يجري تشغيلها عبر الإنترنت اليوم. يُعَد بروتوكول HTTP هو الوسط الضيق الجديد وُصِف الإنترنت على أنه ذو معماريةٍ ضيقة الوسط narrow waist، ببروتوكولٍ عالمي واحد في المنتصف IP، يتسع لدعم العديد من بروتوكولات النقل والتطبيق فوقه، مثل TCP وUDP وRTP وSunRPC وDCE-RPC وgRPC وSMTP وHTTP وSNMP، ويستطيع العمل على العديد من تقنيات الشبكة تحته، مثل شبكات Ethernet وPPP وWiFi وSONET وATM. لقد كانت هذه البنية العامة مفتاحًا لانتشار الإنترنت في كل مكان: من خلال الحفاظ على طبقة IP التي يجب على الجميع الموافقة على الحد الأدنى الملائم لها. هذه الاستراتيجية الآن مفهومة على نطاق واسع لأي منصة تحاول تحقيق التكيُّف العالمي. ولكن حدث شيء آخر خلال الثلاثين عامًا الماضية. أصبح من الضروري إدخال سلسلة من الميزات الإضافية في معمارية الإنترنت، من خلال عدم معالجة جميع المشكلات الممكن أن يواجهها الإنترنت في نهاية المطاف مع نموه، مثل الأمان والازدحام والتنقل والاستجابة في الوقت الحقيقي، وما إلى ذلك. كان وجود عناوين IP العالمية ونموذج خدمة أفضل جهد best-effort شرطًا ضروريًا للتكيف، ولكنه لم يكن أساسًا كافيًا لجميع التطبيقات التي أراد الناس إنشاءها. لم نرَ بعد بعض هذه الحلول، لكن من المفيد اغتنام هذه الفرصة للتوفيق بين قيمة الوسط أو الخصر waist الضيق العالمي والتطور الذي يحدث حتمًا في أي نظام طويل العمر: انتقلت "النقطة الثابتة" التي تتطور حولها بقية المعمارية إلى مكانٍ جديد في مكدس البرمجيات، حيث أصبح بروتوكول HTTP هو الخصر الضيق الجديد، وهو القطعة المشتركة / المفترضة من البنية التحتية العالمية التي تجعل كل شيء آخر ممكنًا. لم يحدث هذا بين عشية وضحاها، رغم أن البعض توقع حدوثه. انجرف الخصر الضيق ببطء إلى قمة مكدس البروتوكول كنتيجة للتطور (لمزج علوم الأرض والاستعارات البيولوجية). وُضعت علامة الوسط الضيق على بروتوكول HTTP للتبسيط. وهو في الواقع جهدٌ جماعي، حيث تعمل تركيبة HTTP / TLS / TCP / IP الآن مثل نظام أساسي مشتركٍ للإنترنت، حيث: يوفر بروتوكول HTTP معرفات الكائنات العالمية (مثل معرّفات URI) وواجهة GET / PUT بسيطة. يوفر بروتوكول TLS أمان اتصالات من طرفٍ إلى طرف. يوفر بروتوكول TCP إدارة الاتصال، والنقل الموثوق، والتحكم في الازدحام. يوفر بروتوكول IP عناوين مضيف عالمية وطبقة تجريد للشبكة. لكن على الرغم من أنك حر في اختراع خوارزمية التحكم في الازدحام الخاصة بك، فإن بروتوكول TCP يحل هذه المشكلة جيدًا، لذلك من المنطقي إعادة استخدام هذا الحل. وعلى الرغم من أنك حر في اختراع بروتوكول RPC خاص بك، فإن HTTP يوفر بروتوكولًا صالحًا للخدمة تمامًا (لأنه يأتي مزوَّدًا بأمان مثبَت، ولديه ميزةٌ إضافية تتمثل في عدم حظره بواسطة جدران حماية خاصة بمؤسسة)، لذا فمن المنطقي مرة أخرى إعادة استخدامه بدلًا من إعادة اختراع شيء جديد. يوفر بروتوكول HTTP أيضًا أساسًا جيدًا للتعامل مع التنقل mobility. إذا نُقل المورد الذي تريد الوصول إليه، فيستطيع HTTP أن يرجع استجابة إعادة توجيه redirect response والتي توجّه العميل إلى موقعٍ جديد. ويتيح بروتوكول HTTP حقن وكلاء التخزين المؤقت caching proxies بين العميل والخادم، مما يجعل من الممكن نسخ المحتوى الشائع في مواقع متعددة وتوفير تأخير وصول العملاء عبر الإنترنت لاسترداد بعض المعلومات. أخيرًا، اُستخدم HTTP لتوصيل الوسائط المتعددة في الوقت الحقيقي، في نهج يُعرف باسم التدفق التكيفي adaptive streaming. ترجمة -وبتصرّف- للقسم Transport for Real-Time من فصل End-to-End Protocols من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: استدعاء إجراء عن بعد Remote Procedure Call في الشبكات الحاسوبية التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية النقل الموثوق Reliable Transmission في الشبكات الحاسوبية

سنوضّح من خلال هذا المقال كيفية إنشاء شارة تقليدية بشريط مشابه للشكل الآتي، وذلك باستخدام الأدوات المتوفرة في برنامج سكريبوس Scribus فقط، حيث سنشرح الخطوات بالتفصيل، ولكن يجب على المبتدئين التأكد من معرفتهم الجيدة أساسيات سكريبوس قبل تجربتها، فإن كنت لم تستخدم سكريبوس من قبل، فقد تجد الأمر مربكًا بعض الشيء. التقنيات المحددة المستخدمة التقنيات التي سنستعملها هي: إنشاء المضلعات. محاذاة الكائنات. تحويل الكائنات عن طريق التحجيم Scaling والتدوير والترجمة. إضافة نص إلى مسار. دمج الأشكال. تنفيذ عمليات المسار أو الشكل. تغيير التعقب اليدوي Manual Tracking على النص. وضع مخطط Outline للنص. تحرير عقد الشكل. إنشاء عمود من الأشكال. دفع Nudging الكائنات باستخدام لوحة المفاتيح. الخط Font ستحتاج إلى تنزيل الخط Fundamental Brigade، حيث يتكون ملف التنزيل من عدة ملفات، ولكنك ستحتاج فقط الملف "Fundamental Brigade.ttf"، لهذا ثبّت الخط قبل فتح سكريبوس. الألوان افتح سكريبوس وأنشئ مستندًا جديدًا، وسيكون القياس A4 / Letter جيدًا، كما سنحتاج إلى أربعة ألوان هي: Badge لون الشارة: R 55 وG 69 وB 72. Stars لون النجوم: R 166 وG 166 وB 166. Badge Text لون نص الشارة: R 204 وG 204 وB 204. Ribbon لون الشريط: R 55 وG 200 وB 171. استخدم نافذة محرّر الألوان Color Editor، والتي يمكن الوصول إليها من قائمة تحرير Edit ثم ألوان Colors، وذلك لإضافة الألوان إلى المستند. إذا لم تعرف كيفية إضافة الألوان إلى المستند، فراجع دليل تعليمات سكريبوس عبر قائمة مساعدة Help، ثم اختر Scribus Help، واطّلع على القسم "Documentation / Editing Colors". إن لم يكن هذا الدليل مثبتًا لديك، فراجع قسم "الألوان" في مقال كيفية إنشاء لافتة نيون في برنامج سكريبوس، واستبدل CMYK بنمط الألوان RGB. خلفية الشارة سننشئ أولًا خلفية الشارة، وذلك باتباع الخطوات الآتية: اختر قائمة إدراج Insert، ثم مضلع Insert Polygon، ثم خصائص Properties لفتح نافذة خصائص المضلع Polygon Properties. اضبط "الزوايا" على القيمة 13. اترك "التدوير" على القيمة 0. حدّد مربع "طبّق المعامل Apply Factor". غيّر "المعامل" ليكون ‎-10% (سالب 10%). اضغط على موافق. انقر بالقرب من الجزء العلوي الأيسر من المستند. أدخل العرض والارتفاع 200 نقطة. تأكد من تحديد مربع "تذكر الحجم Remember Size". اضغط موافق، حيث يمكنك تعديل العرض والارتفاع في تبويب X وY وZ من نافذة الخصائص. بذلك تكون قد أنشأت الشكل الأول، والآن ستكون بحاجة إلى مثيله، لهذا كرّر الخطوات السابقة المذكورة مع التغييرات الآتية: اضبط "التدوير" على القيمة 13 في مربع حوار خصائص المضلع. انقر على يمين الشكل الأول عند النقر لرسم المضلع الثاني لتسهيل التعامل معه. يجب الآن تلوين المضلعين ونقلهما إلى موضع معين. حدّد المضلع الأول اليساري، وانتقل إلى نافذة خصائص Properties، ثم اختر تبويب ألوان Colours. اضغط على "لون الحد Line Color" وحدّد "لا شيء None" من قائمة الألوان. اضغط على "لون التعبئة Fill Color" وحدد اللون "Badge" من قائمة الألوان. حدّد المضلع الثاني اليميني، وانتقل إلى خصائص، ثم اختر ألوان مرةً أخرى. اضغط على "لون الحد" وحدّد "لا شيء" من قائمة الألوان. اضغط على "لون التعبئة" وحدّد اللون "Ribbon" من قائمة الألوان. اختر قائمة نوافذ Windows ثم الخيار "حاذِ وزّع Align & Distribute"، وذلك لفتح نافذة حاذِ ووزّع A&DP. اسحب وحدد المضلعَين، ثم اضغط على أيقونة "مَركِز على المحور الرأسي Center on Vertical"، ثم أيقونة "مَركِز على المحور الأفقي Center on Horizontal" في نافذة A&DP. ألغِ تحديد المضلعين ثم أعِد تحديد المضلع العلوي. استخدم مفاتيح المؤشرات من لوحة المفاتيح حتى تصبح محاذاة المضلعين بالشكل الذي يرضيك. حدّد المضلع العلوي وانقر بزر الفأرة الأيمن واختر المستوى Level، ثم الخيار للأسفل Lower to Bottom من القائمة. وبهذا يكون قد تشكّل شكل الشارة الأساسي كما يلي: خطوط ونص الشارة اسحب وحدّد المضلعات الخاصة بك. انقر بزر الفأرة الأيمن واختر مجموعة Group من القائمة. اسحب المجموعة إلى الجزء العلوي الأيسر من المستند لتوفير بعض المساحة. اختر قائمة إدراج Insert، ثم شكل Insert Shape، ثم أشكال افتراضية Default Shapes، ثم دائرة Circle. انقر ضمن المستند الخاص بك على يمين الشارة. أدخل عرضًا وارتفاعًا بمقدار 140 نقطة ثم اضغط موافق. انتقل إلى تبويب ألوان من نافذة خصائص، واضغط على لون الحد Line Color، وحدّد اللون "Badge Text". اختر قائمة عنصر Item، ثم "مضاعفة/تحويل"، ثم تحويل Transform. اضغط على زر إضافة Add وحدد "تحجيم Scaling" من القائمة. غيّر كل عوامل التحجيم إلى 90%. حدّد الدائرة المركزية في مربع "نقطة أساسية Origin". غيّر قيمة "النسخ" إلى 1. اضغط على موافق. حدد الدائرة الأصغر الجديدة وانتقل إلى تبويب خط Line من نافذة خصائص. حدّد نوع الخط المنقّط الثامن في قائمة "نوع الخط Type of Line". يجب أن يكون لديك الآن شيء يشبه الشكل التالي: انقر على الدائرة الداخلية التي أنشأتها للتو. اختر قائمة عنصر، ثم مضاعفة/تحويل، ثم تحويل. اضغط على زر إضافة وحدد "تحجيم Scaling" من القائمة. غيّر كلًا من عوامل التحجيم إلى القيمة 70%. حدد الدائرة المركزية في مربع "نقطة أساسية". غيّر قيمة "النسخ" إلى 1. اضغط على موافق. أنشئ إطار نص أسفل الدوائر بنفس عرض الدائرة الأكبر. أضف النص "‎100% MADE WITH" (بدون علامات الاقتباس) إلى إطار النص. انتقل إلى تبويب نص Text في نافذة خصائص، أو انتقل إلى نافذة خصائص النص من قائمة نوافذ، ثم اختر خصائص المحتوى في الإصدار 1.5.7 من برنامج سكريبوس. غيّر الخط إلى "Fundamental Brigade" وحجم الخط إلى 16 نقطة. غيّر لون الخط إلى اللون "Badge Text". اضغط على Shift من لوحة المفاتيح وحدّد الدائرة الأصغر. اختر قائمة عنصر، ثم أدوات المسار، ثم اختر "اربط النص بالمسار Attach Text to Path". يجب أن يكون لديك الآن شيء يشبه الشكل التالي، حيث يمكنك ملاحظة أن النص موجود في مكان خاطئ، ولذلك ستحتاج إلى إصلاح الأمر: حدّد كائن النص، ثم انتقل إلى نافذة خصائص النص وافتح تبويب "خصائص نص المسار Path Text Properties". قد تضطر إلى التمرير للأسفل لرؤيتها. أدخل القيمة 152 نقطة في حقل الإدخال "ابدأ الإزاحة Start Offset". يجب أن يكون النص الآن في الموضع الصحيح، لكن إذا لم يكن كذلك، فغيّر القيمة. اسحب وحدّد الدوائر والنص. انقر بزر الفأرة الأيمن واختر مجموعةً من القائمة. اضغط Shift وحدّد مجموعة المضلعات. تأكد من ضبط "متصل بـ Relative To" على القيمة "الاختيار الأخير Last Selected" في نافذة حاذِ ووزّع A&DP. اضغط على كل من الأيقونتين "مَركِز على المحور الرأسي Center on Vertical" و"مَركِز على المحور الأفقي Center on Horizontal". يجب أن يكون لديك الآن شيء يشبه الشكل التالي: إنشاء النجوم لننشئ النجوم لإضافتها إلى الشارة، وذلك باتباع ما يلي: اختر قائمة إدراج، ثم مضلع، ثم خصائص لفتح نافذة خصائص المضلع. اضبط عدد "الزوايا" على القيمة 5. اضبط "التدوير" على القيمة 0. اضبط "المعامل" على القيمة ‎-52% (ناقص 52%). اضغط موافق. انقر في مكان ما على يمين شارتك. أدخل القيمة 30 نقطة لكل من العرض والارتفاع. اضغط موافق. انتقل إلى نافذة خصائص ثم تبويب ألوان. اضغط على "لون الحدّ" وحدّد "لا شيء" من قائمة الألوان. اضغط على "لون التعبئة" وحدّد اللون "Stars" من قائمة الألوان. بهذا يكون قد تشكّلت لديك الآن النجمة الأساسية الأولى، إذًا لنشكّل نجمتين أيضًا. حدّد النجمة ثم اختر قائمة عنصر، ثم مضاعفة/تحويل، ثم تحويل. اضغط على زر إضافة وحدّد "تحجيم" من القائمة. غيّر كلًا من عوامل التحجيم إلى القيمة 70%. اضغط على زر إضافة مرةً أخرى، وحدّد "تدوير Rotation" من القائمة. غيّر "الزاوية" إلى 10 درجات. غيّر قيمة "النسخ" إلى 1. اضغط على موافق. بهذا تكون قد أنشأت الآن النجمة الصغيرة الأولى. ألغِ تحديد كل شيء ثم اسحب النجمة الأصغر الجديدة إلى يمين النجمة الأصل حتى تتمكن من رؤيتها بصورة صحيحة، وذلك باتباع ما يلي: حدّد النجمة الأصغر، ثم اختر قائمة عنصر ثم مضاعفة/تحويل، ثم نسخ مطابق Duplicate. اضغط على أيقونة "اقلب أفقيًا Flip Horizontal" في تبويب X وY وZ من نافذة خصائص. بهذا نكون قد أنشأنا الآن النجمة الأخرى الصغيرة. اسحبها إلى يسار النجمة الأكبر كما في الشكل التالي، لكن لا تقلق بشأن المحاذاة الصحيحة الآن، إذ سنفعل ذلك لاحقًا. الشريط الأمامي سننشئ جسم الشريط الرئيسي أولًا. اختر قائمة إدراج، ثم شكل، ثم أشكال افتراضية، ثم دائرة. انقر أسفل الجهة اليسرى السفلية للشارة. أدخل عرض 400 نقطة وارتفاع 100 نقطة. اضغط موافق. حدّد الدائرة المسطحة، ثم اختر قائمة عنصر، ثم مضاعفة/تحويل، ثم تحويل. اضغط على زر إضافة وحدّد "ترجمة Translation" من القائمة. غيّر قيمة رأسي Vertical إلى 50 نقطة. غيّر قيمة "النسخ" إلى 1. اضغط موافق. يجب أن يكون لديك الآن شيء يشبه الشكل التالي: اسحب وحدد الدائرتين. اختر قائمة عنصر، ثم أدوات المسار، ثم ادمج المضلعات Combine Polygons. بهذا ستكون قد أنشأت مضلعًا واحدًا من المضلعين السابقين، كما ستنشئ أيضًا شيئًا للتلاعب بهذا المضلع الجديد، باعتماد الخطوات الآتية: اختر قائمة إدراج، ثم "شكل"، ثم أشكال افتراضية، بعد ذلك اختر مثلث يشير للأسفل، والمتواجدة بالقرب من أسفل القائمة. انقر على منتصف الشارة. أدخل عرض 200 نقطة وارتفاع 600 نقطة. اضغط موافق. ألغِ تحديد كل شيء وأعد تحديد المثلث الطويل. انقر على Shift وحدّد الدوائر المدمَجة. تأكد من ضبط "متصل بـ Relative To" على القيمة "الاختيار الأخير Last Selected" في نافذة A&DP. اضغط على أيقونة "مَركِز على المحور الرأسي". اضغط على أيقونة "حاذِ الجوانب العليا Align Tops". يجب أن يكون لديك الآن شيء يشبه الشكل التالي: ألغِ تحديد كل شيء وأعِد تحديد المثلث الطويل. اضغط على Shift وحدّد الدوائر المدمَجة. اختر قائمة عنصر، ثم أدوات المسار Path Tools، ثم عمليات المسار Path Operations. اضغط على أيقونة "تقاطع الأشكال "Intersection of the Shapes" في مربع "عملية Operation". يجب أن تبدو النتيجة مثل الشكل التالي، لكن إذا لم يكن كذلك، فحدّد مربع "تبديل الأشكال Swap Shapes". اضغط موافق. حدد "المنحني المزدوج" الجديد واختر قائمة عنصر ثم أدوات المسار ثم اختر "افصل المضلعات Split Polygons". ألغِ تحديد كل شيء وأعِد تحديد المنحني السفلي. انقر بزر الفأرة الأيمن واختر حذف Delete من القائمة، لأنك لست بحاجة إليه. حدد المنحني العلوي المتبقي، واختر قائمة عنصر، ثم مضاعفة/تحويل، ثم نسخ مطابق Duplicate. اسحب النسخة المكرّرة إلى الجانب لاستخدامها لاحقًا. أنشئ إطار نص أسفل الشريط الأصلي وبعرضه تقريبًا. أضف النص "SCRIBUS" (بدون علامات الاقتباس) إلى إطار النص. انتقل إلى نافذة خصائص النص. غيّر الخط إلى Fundamental Brigade وحجم الخط إلى 40 نقطة. غيّر التتبع اليدوي Manual Tracking إلى 8% في تبويب الإعدادات المتقدمة Advanced Setting من نافذة خصائص النص. حدّد إطار النص، ثم اضغط Shift وحدّد الشريط الأصلي. اختر قائمة عنصر ثم أدوات المسار ثم اختر "اربط النص بالمسار". سيبدو النص كما في الشكل التالي، أي خاطئًا تمامًا، ولكن يمكن إصلاحه بسهولة باتباع الخطوات التالية: حدّد النص ثم انتقل إلى نافذة خصائص النص وافتح التبويب "خصائص نص المسار". أدخِل القيمة 295 نقطة في حقل الإدخال "ابدأ الإزاحة". أدخل القيمة ‎-39 نقطة (ناقص 39 نقطة) في حقل الإدخال "المسافة من المنحنى Distance from Curve". حدد مربع "أظهر المنحنى Show Curve" لمعرفة ما حدث. يجب أن يكون لديك الآن شيء يشبه الشكل التالي لكنك لم تنتهِ بعد، وإذا لم يظهر لديك الشكل نفسه، فحاول تغيير قيم "أظهر المنحنى" و"المسافة من المنحنى"). ألغِ تحديد مربع "أظهر المنحنى"، فلست بحاجة إلى رؤيته بعد الآن لأنه سيفسد التأثير. غيّر لون النص إلى "اللون الأبيض" من تبويب الألوان، والمؤثرات في نافذة خصائص النص. انقر على رمز "مخطط Outline" تحت خيارات الألوان. انقر على رمز "مخطط Outline" تحت خيارات الألوان مرةً أخرى، ولكن اضغط مطوَّلًا حتى تظهر نافذة صغيرة. غيّر "عرض الخط Linewidth" إلى 2%. حدّد الشريط المكرّر. انتقل إلى تبويب ألوان في نافذة خصائص. اضغط على "لون الحد" وحدّد اللون "Badge" من قائمة الألوان. اضغط على "لون التعبئة" وحدّد اللون "Ribbon" من قائمة الألوان. اسحب وحدّد كلًا من الشريط والنص. اضغط على كل من "مَركِز على المحور الرأسي"، و"مَركِز على المحور الأفقي" في نافذة A&DP. إذا اختفى النص فألغِ تحديد كل شيء، ثم حدّد الشريط، وانقر بزر الفأرة الأيمن، ثم اختر المستوى Level، بعد ذلك اختر الخيار للأسفل Lower to Bottom للحصول على النص أعلى الشريط. يجب أن يكون لديك الآن شيء مثل الشكل التالي: اسحب وحدّد الشريط والنص. انقر بزر الفأرة الأيمن واختر مجموعةً من القائمة. نهايات الشريط يجب الآن إنشاء نهايات الشريط،-وهذا هو الجزء الصعب بالعملية-، وذلك باتباع الخطوات الآتية: اختر قائمة إدراج، ثم شكل، ثم أشكال افتراضية، ثم مستطيل. انقر في أي مكان أسفل الشريط. أدخل عرض 40 نقطة وارتفاع 50 نقطة. اضغط موافق. انقر نقرًا مزدوجًا على المستطيل لفتح نافذة محرّر العقد Node Editor. اضغط على أيقونة "أضِف عُقد Add Nodes" في نافذة محرّر العقد. انقر على المستطيل الذي رسمته في منتصف الحافة العمودية اليمنى. اضغط على أيقونة "حرّك عقدًا Move Nodes" في نافذة محرر العقد. ارجع إلى المستطيل واسحب العقدة التي أضفتها للتو إلى اليسار، بحيث تقرأ قيم X-Pos وY-Pos في نافذة محرر العقد، بحيث تكون X مساويةً لـ 25 نقطة، وY مساوية لـ 25 نقطة كما في الشكل التالي، أو يمكنك تغيير القيم مباشرةً في حقول الإدخال. اضغط على زر إنهاء التحرير أو موافق عند الانتهاء. انتقل إلى تبويب ألوان Colors في نافذة خصائص. اضغط على "لون الحد" وحدّد اللون "Badge" من قائمة الألوان. اضغط على "لون التعبئة" وحدد اللون "Ribbon" من قائمة الألوان. لننشئ الآن بعض الرتوش، وذلك باتباع الخطوات الآتية: اختر قائمة إدراج، ثم شكل، ثم أشكال افتراضية، ثم مثلث يشير إلى اليمين. انقر في أي مكان أسفل الشكل الذي رسمته للتو. أدخل عرضًا 20 نقطة وارتفاعًا 2.5 نقطة. اضغط موافق. انتقل إلى تبويب ألوان في نافذة خصائص. اضغط على "لون الحد"، وحدد "لا شيء" من قائمة الألوان. اضغط على "لون التعبئة" وحدد اللون "Badge" من قائمة الألوان. حدّد المثلث ثم اختر قائمة عنصر، ثم مضاعفة/تحويل، ثم نسخ مطابقة Multiple Duplicate. انتقل إلى تبويب "بعدد الصفوف والأعمدة By Rows and Columns". غيّر قيمة "عدد الصفوف Number of Rows" إلى 20. اضغط على موافق. اسحب وحدد كل المثلثات. انقر بزر الفأرة الأيمن واختر مجموعةً من القائمة. انقر مع الضغط على مفتاح Shift على الشكل السابق الذي يحتوي على "ثنية" فيه. اضغط على كل من "حاذِ الجوانب اليسرى Align left sides"، و"مَركِز على المحور الأفقي Center on Horizontal" في نافذة A&DP. بهذا يكون الشريط قد أوشك على الانتهاء، بحيث لم تتبقى سوى بضع خطوات تتمثل في التالي: اختر قائمة إدراج، ثم شكل، ثم أشكال افتراضية، ثم مثلث قائم الزاوية. انقر في أي مكان أسفل المجموعة التي أنشأتها للتو. أدخل عرض 15 نقطة وارتفاع 10 نقاط. اضغط موافق. اذهب إلى تبويب X وY وZ من نافذة خصائص. اضغط على أيقونة "اقلب أفقيًا Flip Vertical". انتقل إلى تبويب ألوان من نافذة خصائص. اضغط على "لون الحد"، وحدد "لا شيء" من قائمة الألوان. اضغط على "لون التعبئة"، وحدّد اللون "Badge" من قائمة الألوان. انقر مع الضغط على مفتاح Shift على مجموعة الأشكال بما في ذلك "الرتوش". اضغط على "حاذِ الجوانب اليسرى"، و"حاذِ الجوانب السفلى Align bottoms" في نافذة A&DP. اسحب وحدّد كل الأشكال التي أنشأتها للتو. انقر بزر الفأرة الأيمن واختر مجموعةً من القائمة. اذهب إلى تبويب X وY وZ من نافذة خصائص. غيّر "التدوير" إلى 350 درجة. يجب أن يكون لديك الآن شكل مماثل للتالي: حدّد المجموعة، ثم انقر بزر الفأرة الأيمن واختر مستوى Level، ثم "للأسفل Lower to Bottom" من القائمة. اختر قائمة عنصر ثم مضاعفة/تحويل، ثم نسخ مطابق Duplicate. حدّد النسخة المكرَّرة، ثم انتقل إلى تبويب X وY وZ من نافذة خصائص. اضغط على أيقونة "اقلب أفقيًا". انقر بزر الفأرة الأيمن واختر مستوى Level ثم للأسفل Lower to Bottom من القائمة. تجميع الأجزاء مع بعضها البعض يجب الآن إنهاء الشريط ومحاذاة الشارة، ثم تحريك النجوم إلى مكانها الصحيح، فقم بسحب إحدى نهايتي الشريط إلى زاوية أحد طرفي الشريط. لا توجد طريقة لمحاذاة هذه الأشكال تلقائيًا، فكل ما عليك فعله هو تنفيذ ذلك بالنظر، ولكن عليك وضع زاوية المثلث الرمادي الداكن الصغير أسفل زاوية الشريط السفلية كما في الشكل التالي، حيث يشير السهم الأحمر: كرّر الشيء نفسه بالنسبة لنهاية الشريط الآخر في الطرف الآخر من الشريط، وذلك كما في الشكل التالي: اسحب وحدّد جميع أجزاء الشريط وانقر بزر الفأرة الأيمن على مجموعة من القائمة. انقر بزر الفأرة الأيمن على المجموعة، واختر المستوى Level، ثم أحضره للأعلى Raise to Top من القائمة. سنحاذي الآن الشريط مع الشارة. حدّد الشريط. اضغط على مفتاح Shift، وحدّد مركز الشارة، حيث ستحدد إحدى الدوائر في الحقيقة ولكن لا بأس بذلك). اضغط على كل من "مَركِز على المحور الرأسي Center on Vertical" و"مَركِز على المحور الأفقي Center on Horizontal" في نافذة A&DP. سيكون الشريط مرتفعًا جدًا عن الشارة ولكن يمكنك إصلاح ذلك بسهولة، لهذا استمر بالضغط على السهم للأسفل من لوحة المفاتيح حتى يصبح الشريط في المكان المناسب. نقترح وضع الجزء العلوي من الشريط حول مركز الدوائر أو أسفله مباشرةً، لكن الأمر متروك لك. يجب الآن وضع النجوم في مكانها الصحيح، لهذا اتبع الخطوات الموالية: اسحب وحدّد كل النجوم. انتقل إلى تبويب توزيع Distribute في نافذة A&DP. انقر على أيقونة "أنشئ فجوات أفقية بين العناصر مساوية للقيمة المحددة Make Horizontal Gaps between items equal to the value specified". ألغِ تحديد كل شيء وحدّد النجمة المركزية الكبرى. استخدم السهم للأعلى من لوحة المفاتيح لتحريك النجمة الكبيرة للأعلى، وذلك حتى تصبح في المكان الذي تريده، وسيبدو الارتفاع بحوالي 15 نقطة جيدًا. اسحب وحدّد كل النجوم. انقر بزر الفأرة الأيمن واختر مجموعةً من القائمة. انقر بزر الفأرة الأيمن فوق المجموعة واختر المستوى Level، ثم للأعلى Raise to Top من القائمة. اضغط Shift وحدّد دائرة في الشارة. ارجع إلى تبويب حاذِ Align في نافذة A&DP. تأكد من ضبط "متصل بـ Relative to" على القيمة "الاختيار الأخير Last Selected"، وإلا فستحدث فوضى. اضغط على كلٍ من أيقونات "مَركِز على المحور الرأسي" و"مَركِز على المحور الأفقي" في نافذة A&DP. بهذا تكون النجوم قد أصبحت منخفضةً جدًا، ولكن يمكنك إصلاح ذلك بسهولة أيضًا. ألغِ تحديد كل شيء وحدّد النجوم. استخدم السهم للأعلى من لوحة المفاتيح لتحريك النجوم إلى مكان تجده مناسبًا، واجعل الفجوة الموجودة بين أعلى النجمة الكبيرة وأسفل النص، مثل الفجوة الموجودة بين أسفل النجوم الصغيرة والشريط. وبهذا نكون قد أنهينا تصميم الشارة التقليدية. ترجمة -وبتصرّف- للمقال How to create a retro ribbon badge. اقرأ أيضًا كيفية إنشاء رسوم من النمط Pop Art Explosion في برنامج سكريبوس Scribus خطوات تطوير شعار باستخدام برنامج سكريبوس Scribus كيفية إنشاء التأثير Distressing Mask في برنامج سكريبوس لإنتاج تأثيرات تعبئة جذابة كيفية إنشاء الظلال في برنامج سكريبوس Scribus

النمط الشائع للاتصال الذي تستخدمه برامج التطبيقات المُهيكَلة كزوج عميل / خادم client/server هو اتفاق رسائل الطلب / الرد request/reply message: يرسل العميل رسالة طلبٍ إلى الخادم، ويستجيب الخادم برسالة رد، مع تعطيل العميل (تعليق التنفيذ) انتظارًا للرد. يوضح الشكل التالي التفاعل الأساسي بين العميل والخادم في مثل هذا التبادل. إنّ بروتوكول النقل الذي يدعم نموذج الطلب / الرد أكثر بكثير من رسالة UDP تسير في اتجاه واحد متبوعةً برسالة UDP تذهب في الاتجاه الآخر، فهو يحتاج إلى التعامل مع تحديد العمليات بصورةٍ صحيحة على المضيفين البعيدين وربط الطلبات بالاستجابات. قد يحتاج أيضًا إلى التغلب على بعض أو كل قيود الشبكة الأساسية الموضحة في بيان المشكلة في بداية هذا المقال. يتغلب بروتوكول TCP على هذه القيود من خلال توفير خدمة تدفق بايتات موثوقة، ولكنه لا يتطابق تمامًا مع نموذج الطلب / الرد. يصف هذا القسم فئةً ثالثةً من بروتوكول النقل، تُسمى استدعاء الإجراء عن بُعد Remote Procedure Call أو اختصارًا RPC، والتي تتطابق بشكل وثيق مع احتياجات التطبيق المُضمَّنة في تبادل رسائل الطلب / الرد. أساسيات الإجراء عن بعد RPC بروتوكول RPC ليس بروتوكولًا تقنيًا، فمن الأفضل التفكير به كآلية عامة لبناء الأنظمة الموزعة. يُعَد RPC شائعًا لأنه يعتمد على دلالات استدعاء الإجراء المحلي، حيث يستدعي برنامج التطبيق إجراءً دون تحديد ما إذا كان محليًا أو بعيدًا ويتوقف حتى يعيد الإجراء قيمة. يمكن أن يكون مطور التطبيق غير مدرك إلى حد كبير ما إذا كان الإجراء محليًا أم بعيدًا، مما يبسط مهمته إلى حدٍ كبير. يُعرف RPC باسم استدعاء الطرائق عن بُعد remote method invocation أو اختصارًا RMI عندما تكون الإجراءات التي يتم استدعاؤها هي في الواقع طرائق methods لكائناتٍ بعيدة في لغة موجّهة بالكائنات. على الرغم من أن مفهوم RPC بسيط، إلا أن هناك مشكلتين رئيسيتين تجعله أعقد من استدعاءات الإجراءات المحلية: تملك الشبكة بين العملية المستدعية calling process والعملية المُستدعاة called process خصائصًا أعقد من اللوحة الأم المعززة backplane للحاسوب، فمن المحتمل أن تحد من أحجام الرسائل وتميل إلى فقدان الرسائل وإعادة ترتيبها على سبيل المثال. قد تحتوي الحواسيب التي تعمل عليها العمليات المستدعية والمُستدعاة على معماريات وتنسيقات تمثيل بيانات مختلفة. وبالتالي تتضمن آلية RPC الكاملة في الواقع مكونين رئيسيين: بروتوكول يدير الرسائل المرسلة بين عمليات العميل وعمليات الخادم ويتعامل مع الخصائص غير المرغوب فيها المحتملة للشبكة الأساسية. دعم لغة برمجة ومصرّف compiler لحزم الوسطاء arguments في رسالة طلب على جهاز العميل ثم ترجمة هذه الرسالة مرة أخرى إلى الوسطاء على جهاز الخادم، وبالمثل مع القيمة المُعادة. يُطلق على هذه القطعة من آلية RPC عادةً اسم مصرّف جذعي stub compiler. يوضح الشكل الآتي ما يحدث عندما يستدعي العميل إجراءً عن بُعد. أولًا، يستدعي العميل جذعًا stub محليًا للإجراء، ويمرر إليه الوسطاء التي يتطلبها هذا الإجراء. يخفي هذا الجذع حقيقة أن الإجراء بعيد عن طريق ترجمة الوسطاء إلى رسالة طلب ثم استدعاء بروتوكول RPC لإرسال رسالة الطلب إلى جهاز الخادم. يسلّم بروتوكول RPC رسالة الطلب في الخادم إلى جذع الخادم، والذي يترجمه إلى وسطاء لهذا الإجراء ثم يستدعي الإجراء المحلي. يعود إجراء الخادم بعد اكتماله في رسالة رد تُفيد بأنه يسلّم بروتوكول RPC لإرساله مرة أخرى إلى العميل. يمرر بروتوكول RPC الموجود على العميل هذه الرسالة إلى جذع العميل، والذي يترجمه إلى قيمة معادة إلى برنامج العميل. يتناول هذا القسم الجوانب المتعلقة بالبروتوكول فقط لآلية RPC، أي أنه يتجاهل الأجزاء الجذعية stubs ويركز بدلًا من ذلك على بروتوكول RPC، الذي يشار إليه أحيانًا باسم بروتوكول الطلب / الرد، الذي ينقل الرسائل بين العميل والخادم. من المهم أيضًا أن تضع في حساباتك أن برامج العميل والخادم مكتوبة في بعض لغات البرمجة، مما يعني أن آلية RPC المعينة قد تدعم Python stubs وJava stubs وGoLang stubs وما إلى ذلك، يتضمن كل منها مصطلحات خاصة باللغة عن كيفية استدعاء الإجراءات. يشير مصطلح RPC إلى نوعٍ من البروتوكولات بدلًا من معيارٍ معين مثل TCP، لذلك تختلف بروتوكولات RPC المحددة في الوظائف التي تؤديها. ولا يوجد بروتوكول RPC مهيمن واحد على عكس بروتوكول TCP، وهو بروتوكول تدفق البايتات الموثوق. وبالتالي سنتحدث في هذا القسم أكثر عن خيارات التصميم البديلة أكثر من السابق. المعرفات Identifiers في RPC يجب تأدية وظيفتين بواسطة أي بروتوكول RPC هما: وفّر مساحة اسم name space لتعريف الإجراء الذي سيُستدعى بشكل فريد. طابق كل رسالة رد برسالة الطلب المقابلة. المشكلة الأولى لها بعض أوجه التشابه مع مشكلة تحديد العقد في الشبكة، وهو شيء تفعله عناوين IP على سبيل المثال. أحد خيارات التصميم عند تحديد الأشياء هو جعل مساحة الاسم مسطحة flat أو هرمية hierarchical. تسند مساحة الاسم المسطحة ببساطة معرّفًا فريدَا غير منظم (عددًا صحيحًا مثلًا) لكل إجراء، وسيُنقَل هذا الرقم في حقلٍ واحد في رسالة طلب RPC. قد يتطلب ذلك نوعًا من التنسيق المركزي لتجنب إسناد رقم الإجراء نفسه لاثنين من الإجراءات المختلفة. ويمكن للبروتوكول تطبيق مساحة أسماء هرمية، مماثلة لتلك المستخدمة لأسماء مسار الملف، والتي تتطلب فقط أن يكون "الاسم الأساسي basename" لملفٍ ما فريدًا داخل مجلده، ومن المحتمل أن يبسط هذا النهج مهمة ضمان تفرد أسماء الإجراءات. يمكن تطبيق مساحة أسماء هرمية لآلية RPC عن طريق تحديد مجموعة من الحقول في صيغة رسالة الطلب، حقلٌ لكل مستوى من مستويات التسمية في مساحة اسماءٍ هرمية من مستويين أو ثلاثة مستويات على سبيل المثال. المفتاح لمطابقة رسالة الرد برسالة الطلب المقابلة هو تحديد أزواج الطلبات والردود بشكل فريد باستخدام حقل معرّف الرسالة. حيث يُضبَط حقل معرّف رسالة الرد على نفس قيمة رسالة الطلب. تستخدم وحدة RPC في العميل التي تتلقى الرد معرّفَ الرسالة للبحث عن الطلب المعلّق المقابل. يُوقَف المستدعي حتى استلام رسالة الرد لجعل اتفاق RPC يظهر مثل استدعاء إجراء محلي للمستدعي caller. يُحدَّد المستدعي الذي جرى وقفه عند تلقي الرد بناءً على رقم الطلب في الرد، ويتم الحصول على القيمة المعادة من الإجراء البعيد من خلال الرد reply، ويُلغى وقف المستدعي حتى يتمكن من إعادة هذه القيمة المعادة. أحد التحديات المتكررة في RPC هو التعامل مع الاستجابات غير المتوقعة، ونرى ذلك مع معرّفات الرسائل. افترض الحالة المرضيّة (ولكن الواقعية) التالية على سبيل المثال: يرسل جهاز العميل رسالة طلب بمعرف رسالة 0، ثم يتعطل ويعيد التشغيل، ثم يرسل رسالة طلب ليست ذات صلة، وأيضًا بمعرّف رسالة 0. ربما لم يكن الخادم على علم بأن العميل قد تعطل وأعيد تشغيله، عند رؤية رسالة طلب بمعرف رسالة 0، فيُقِر بها ثم يتجاهلها كونها مكررة، ولا يتلقى العميل أبدًا ردًا على الطلب. يوجد طريقةٌ واحدة للتخلص من هذه المشكلة هي استخدام معرّف إقلاع boot ID. معرف إقلاع الجهاز هو رقم يُزاد في كل مرة يعاد تشغيل الجهاز. يُقرَأ هذا الرقم من وحدة تخزين غير متطايرة (محرك أقراص أو محرك أقراص محمول)، فيُزاد ويعاد كتابته إلى جهاز التخزين أثناء إجراء بدء تشغيل الجهاز، ثم يُوضَع هذا الرقم في كل رسالة يرسلها ذلك المضيف. إذا استُلِمت رسالةٌ بمعرّف رسالة قديم ولكن مع معرف إقلاع جديد، سيجري التعرف عليها كرسالة جديدة. يتحد معرّف الرسالة ومعرّف الإقلاع لتشكيل معرّفٍ فريد لكل اتفاق. التغلب على قيود الشبكة تؤدي بروتوكولات RPC غالبًا وظائفًا إضافية للتعامل مع حقيقة أن الشبكات ليست قنوات مثالية. اثنان من هذه الوظائف هي: توفير توصيل موثوق للرسائل. دعم أحجام الرسائل الكبيرة من خلال التجزئة fragmentation وإعادة التجميع reassembly. قد يعرّف بروتوكول RPC "هذه المشكلة بعيدًا" عن طريق اختيار التشغيل فوق بروتوكول موثوق مثل بروتوكول TCP، ولكن يطبّق بروتوكول RCP في كثير من الحالات طبقة تسليم الرسائل الموثوقة الخاصة به فوق ركيزة غير موثوقة مثل UDP / IP، وبالتالي من المحتمل أن يطبّق بروتوكول RPC هذا الوثوقيةَ باستخدام الإشعارات acknowledgments والمهل الزمنية timeouts، على غرار بروتوكول TCP. الخوارزمية الأساسية واضحة ومباشرة، كما هو موضح في الجدول الزمني الوارد في الشكل التالي. حيث يرسل العميل رسالة طلب ويرسل الخادم إشعارًا بها، ثم يرسل الخادم رسالة رد ويرسل العميل إشعارًا بالرد بعد تنفيذ الإجراء. قد تضيع في الشبكة، تلك الرسالة التي تحمل بيانات (رسالة طلب أو رسالة رد) أو إشعار ACK مُرسَل للإقرار بوصول الرسالة، لذلك يحفظ كلٌّ من العميل والخادم نسخةً من كل رسالة يرسلانها حتى وصول إشعار ACK لها. يضبط كل جانب أيضًا مؤقت إعادة إرسال RETRANSMIT أي يعيد إرسال الرسالة في حالة انتهاء صلاحية هذا المؤقت، ويعيد كلا الجانبين ضبط هذا المؤقت ويحاولان مرة أخرى عددًا من المرات متفقًا عليه قبل التخلي عن الرسالة وتحريرها. إذا تلقى عميل RPC رسالةَ رد، فمن الواضح أنه يجب أن يكون الخادم قد استلم رسالة الطلب المقابلة، حيث أن رسالة الرد نفسها هي إشعارٌ ضمني implicit acknowledgment، ولن يكون أيُّ إشعارٍ إضافي من الخادم ضروريًا منطقيًا. يمكن لرسالة الطلب إرسال إشعارًا ضمنيًا لرسالة الرد السابقة على افتراض أن البروتوكول يجعل اتفاقات الطلب والرد متسلسلة، بحيث يجب إكمال اتفاقٍ واحد قبل أن يبدأ الاتفاق التالي، ولكن سيحد هذا التسلسل بشدة من أداء RPC. طريقة الخروج من هذا المأزق هي أن يطبّق بروتوكول RPC تجريد القناة channel abstraction. تكون اتفاقات الطلب / الرد متسلسلة داخل قناةٍ معينة، حيث يمكن أن يكون هناك اتفاقٌ واحد فقط نشط على قناة معينة في أي وقت معين، ولكن يمكن أن تكون هناك قنوات متعددة. يتيح تجريد القناة إمكانية تعدد اتفاقات طلب / رد RPC بين زوج العميل / الخادم. تتضمن كلُّ رسالةٍ حقلَ معرّف القناة للإشارة إلى القناة التي تنتمي إليها الرسالة. ستُقِر رسالة طلب في قناة معينة ضمنيًا بالرد السابق في تلك القناة، إذا لم يكن قد أُقِر بها بالفعل. يمكن لبرنامج التطبيق فتح قنوات متعددة إلى الخادم إذا كان يريد الحصول على أكثر من اتفاق طلب / رد بينها في نفس الوقت، ويحتاج التطبيق عندئذٍ إلى خيوطٍ threads متعددة. تُقِر رسالة الرد برسالة الطلب، ويُقِر الطلب اللاحق بالرد السابق كما هو موضح في الشكل التالي. لاحظ أننا رأينا طريقة مشابهة جدًا، تسمى القنوات المنطقية المتزامنة concurrent logical channels، في قسم سابق كطريقة لتحسين أداء آلية موثوقية التوقف والانتظار. من التعقيدات الأخرى الواجب على RPC معالجتها أن الخادم قد يستغرق وقتًا طويلًا بصورة كيفية لتحقيق النتيجة، والأسوأ من ذلك، أنه قد يتعطل قبل توليد الرد. ضع في بالك أننا نتحدث عن الفترة الزمنية بعد موافقة الخادم على الطلب ولكن قبل إرسال الرد. يمكن لعميل RPC إرسال رسالة دورية "هل أنت على قيد الحياة؟ ?Are you alive" إلى الخادم لمساعدة العميل على التمييز بين الخادم البطيء والخادم المعطَّل، ويستجيب جانب الخادم بإشعار ACK. ويمكن للخادم إرسال رسائل "ما زلت على قيد الحياة I am still alive" إلى العميل دون أن يطلبها العميل أولًا. هذا النهج أكثر قابلية للتوسع لأنه يضع المزيد من العبء (أي إدارة مؤقت المهلة الزمنية) على العملاء. قد تتضمن وثوقية RPC الخاصيةَ المعروفة باسم دلالاتٌ لمرة واحدة على الأكثر at-most-once semantics. هذا يعني أنه بالنسبة لكل رسالة طلب يرسلها العميل، تُسلَّم نسخةٌ واحدة على الأكثر من تلك الرسالة إلى الخادم. في كل مرةٍ يستدعي فيها العميلُ إجراءً بعيدًا، يُستدعى هذا الإجراء مرة واحدة على الأكثر على جهاز الخادم. نقول "مرة واحدة على الأكثر" بدلًا من "مرة واحدة تمامًا" لأنه من الممكن دائمًا فشل الشبكة أو جهاز الخادم، مما يجعل من المستحيل تسليم نسخةٍ واحدة من رسالة الطلب. يجب أن يتعّرف RPC في جانب الخادم على الطلبات المكررة ويتجاهلها لتنفيذ الدلالات مرة واحدة على الأكثر، حتى إذا كان قد استجاب بالفعل للطلب الأصلي بنجاح، ويجب أن يحتفظ ببعض معلومات الحالة التي تحدد الطلبات السابقة. تتمثل إحدى الطرق في تحديد الطلبات باستخدام الأرقام التسلسلية، لذلك يحتاج الخادم فقط إلى تذكر الرقم التسلسلي الأحدث، ولكن قد يحد ذلك من RPC وبالتالي يقتصر على طلبٍ معلق واحد إلى خادم معين في كل مرة، حيث يجب إكمال طلب واحد قبل إرسال الطلب بالرقم التسلسلي التالي. توفر القنوات الحل، فيمكن للخادم التعرّفَ على الطلبات المكررة من خلال تذكر الرقم التسلسلي الحالي لكل قناة، دون حدِّ العميل بطلب واحد في كل مرة. لا تدعم كل بروتوكولات RPC هذا السلوك، حيث يدعم البعض دلالاتٍ semantics تسمى دلالات الصفر أو أكثر zero-or-more semantics، أي أن كل استدعاء للعميل يؤدي إلى استدعاء الإجراء البعيد صفر مرةً أو أكثر. ليس من الصعب فهم كيف يمكن أن يتسبب ذلك في حدوث مشكلاتٍ لإجراءٍ بعيد قام بتغيير بعض متغيرات الحالة المحلية (زيادة عدّاد مثلًا) أو كان له بعض الآثار الجانبية المرئية خارجيًا (إطلاق صاروخ على سبيل المثال) في كل مرة يُستدعَى فيها. إذا كان الإجراء البعيد المُستدعى عديم الفعالية، سيكون للاستدعاءات المتعددة نفس تأثير استدعاءٍ واحد فقط، إذًا لا تحتاج آلية RPC إلى دعم دلالات مرة واحدة على الأكثر، ويكفي تطبيق أبسط قد يكون أسرع. يكمن السببان وراء تطبيق بروتوكول RPC تجزئة الرسالة وإعادة تجميعها كما كان الحال مع الوثوقية بعدم توفير مكدس البروتوكول الأساسي لذلك أو أنه يمكن تطبيقه بصورة أكثر كفاءة بواسطة بروتوكول RPC. ضع في اعتبارك الحالة التي يُطبَّق RPC أعلى UDP / IP ويعتمد على IP للتجزئة وإعادة التجميع. إذا فشل جزءٌ واحد فقط من الرسالة في الوصول خلال فترة زمنية معينة، فإن بروتوكول IP يتجاهل الأجزاء التي وصلت بالفعل وستضيع الرسالة فعليًا. ستنتهي مهلة بروتوكول RPC (بافتراض أنه يطبّق الوثوقية) ويعيد إرسال الرسالة. في المقابل، ضع في اعتبارك بروتوكول RPC الذي يطبّق التجزئة وإعادة التجميع الخاصة به ويرسل ACK أو NACK (إشعارًا سلبيًا) بالأجزاء الفردية. ستُكتشَف الأجزاء المفقودة ويُعاد إرسالها بسرعةٍ أكبر، وسيعاد إرسال الأجزاء المفقودة فقط، وليس الرسالة بأكملها. البروتوكولات المتزامنة مقابل البروتوكولات غير المتزامنة تتمثل إحدى طرق وصف البروتوكول في كونه متزامنًا synchronous أو غير متزامن asynchronous. يعتمد المعنى الدقيق لهذه المصطلحات على مكان استخدامها في تسلسل البروتوكول الهرمي. من الأدق في طبقة النقل التفكير فيهما على أنهما يعينان الحدود القصوى للطيف بدلًا من عدّهما بديلين متعارضين. الخاصية الرئيسية لأي نقطة على طول الطيف هي مقدار ما تعرفه عملية الإرسال بعد جواب عملية إرسال الرسالة. أي إذا افترضنا أن أحد برامج التطبيق يستدعي العملية send على بروتوكول نقل، فما الذي يعرفه التطبيق بالضبط عن نجاح العملية عند رد أو جواب العملية send؟ لا يعرف التطبيق شيئًا على الإطلاق عند عودة العملية send في الطرف غير المتزامن من الطيف، فهو لا يعرف فقط ما إذا كانت الرسالة قد استقبلها نظيرها، ولكنه لا يعرف أيضًا على وجه اليقين فيما إذا غادرت الرسالة الجهاز المحلي بنجاح أم لا. تعيد عملية send عادةً رسالةَ رد في الطرف المتزامن من الطيف، أي أن التطبيق لا يعرف فقط أن الرسالة التي أرسلها قد استلمها نظيره، ولكنه يعرف أيضًا أن النظير قد أعاد إجابة. وبالتالي تطبّق البروتوكولات المتزامنة تجريد الطلب / الرد، بينما تُستخدَم البروتوكولات غير المتزامنة إذا أراد المرسل أن يكون قادرًا على إرسال العديد من الرسائل دون الحاجة إلى انتظار الرد. تكون بروتوكولات RPC عادة بروتوكولات متزامنة باستخدام التعريف السابق. على الرغم من أننا لم نناقشها في هذا المقال، إلا أن هناك نقاطًا مثيرة للاهتمام بين هذين النقيضين. قد يطبّق بروتوكول النقل العملية send بحيث تُوقَف (أي لا تعيد قيمة) حتى تُستلَم الرسالة بنجاح على الجهاز البعيد، ولكنها تعيد قيمةً قبل أن يعالجها نظير المرسل على هذا الجهاز البعيد ويستجيب لها بالفعل. يسمى هذا أحيانًا بروتوكول مخطط بيانات موثوق reliable datagram protocol. تطبيقات وهي SunRPC وDCE وgRP لـ RPC ننتقل الآن إلى مناقشتنا لبعض أمثلة تطبيقات بروتوكولات RPC. حيث ستُبرز هذه المناقشة بعض قرارات التصميم المختلفة التي اتخذها مصممو البروتوكول. مثالنا الأول هو SunRPC، وهو بروتوكول RPC واسع الاستخدام يُعرف أيضًا باسم Open Network Computing RPC أو اختصارًا ONC RPC. المثال الثاني، الذي سنشير إليه باسم DCE-RPC، هو جزء من بيئة الحوسبة الموزعة Distributed Computing Environment أو اختصارًا DCE. بيئة DCE عبارة عن مجموعة من المعايير والبرمجيات لبناء الأنظمة الموزعة التي حددتها منظمة البرمجيات المفتوحة Open Software Foundation أو اختصارًا OSF، وهي اتحاد من شركات الحاسوب التي تضم في الأصل شركات IBM وDigital Equipment Corporation وHewlett-Packar، ويطلق على OSF اليوم اسم المجموعة المفتوحة Open Group. مثالنا الثالث هو gRPC، وهي آلية RPC شائعة جعلتها شركة Google مفتوحة المصدر، استنادًا إلى آلية RPC التي تستخدمها داخليًا لتطبيق الخدمات السحابية في مراكز البيانات الخاصة بها. تمثل هذه الأمثلة الثلاثة خيارات تصميم بديلة مثيرة للاهتمام في مساحة حلول RPC، وأقل ما قد تعتقده أنها الخيارات الوحيدة، سنشرح ثلاث آليات أخرى شبيهة بآلية RPC هي WSDL وSOAP وREST في سياق خدمات الويب لاحقًا. آلية SunRPC أصبحت آلية SunRPC معيارًا واقعيًا بفضل توزيعها الواسع مع محطات عمل Sun والدور المركزي الذي تلعبه في نظام ملفات الشبكة Network File System أو اختصارًا NFS الشهير في Sun. تبنتها منظمة IETF لاحقًا كَبروتوكول إنترنت قياسي تحت اسم ONC RPC. يمكن تطبيق آلية SunRPC عبر عدة بروتوكولات نقل مختلفة. ويوضح الشكل التالي الرسم البياني للبروتوكول عند تطبيق SunRPC على UDP. قد يستهجن أحد خبراء الطبقات الصارم فكرة تشغيل بروتوكول نقل عبر بروتوكول نقل، أو يجادل بأن RPC يجب أن يكون شيئًا آخر غير بروتوكول نقل لأنه يظهر "فوق" طبقة النقل. يُعد عمليًا قرار التصميم الخاص بتشغيل RPC على طبقة نقل حالية ذو فحوى ودلالة كبيرين، كما سيتضح في المناقشة التالية: تستخدم آلية SunRPC معرّفات من مستويين لتحديد الإجراءات البعيدة: رقم برنامج ذو 32 بت ورقم إجراء ذو 32 بت (يوجد أيضًا رقم إصدار ذو 32 بت، لكننا نتجاهل ذلك في المناقشة التالية). إذا أُسنِد رقم برنامج x00100003 على سبيل المثال لخادم NFS، ويوجد داخل هذا البرنامج الإجراء getattr هو الإجراء 1، والإجراء setattr هو الإجراء 2، والإجراء read هو الإجراء 6، والإجراء write هو الإجراء 8، وما إلى ذلك. يُرسَل رقم البرنامج ورقم الإجراء في ترويسة رسالة طلب SunRPC، والموضحة حقولها في الشكل التالي. الخادم، الذي قد يدعم عدة أرقام برامج، مسؤولٌ عن استدعاء الإجراء المحدد للبرنامج المحدد. يمثل طلب SunRPC حقًا طلبًا لاستدعاء البرنامج والإجراءات المحددة على الجهاز المعين الذي أُرسِل الطلب إليه، على الرغم من إمكانية تطبيق نفس رقم البرنامج على أجهزةٍ أخرى في نفس الشبكة. وبالتالي فإن عنوان جهاز الخادم (عنوان IP على سبيل المثال) هو طبقة ثالثة ضمنية من عنوان RPC. قد تنتمي أرقام البرامج المختلفة إلى خوادم مختلفة على نفس الجهاز. تحتوي هذه الخوادم المختلفة على مفاتيح فك تعدد إرسال demux مختلفة لطبقة النقل مثل منافذ UDP، ومعظمها أرقام غير معروفة ولكنها تُسنَد ديناميكيًا، وتسمى مفاتيح تعدد الإرسال هذه محدّدات النقل transport selectors. كيف يمكن لعميل SunRPC الذي يريد التحدث إلى برنامج معين تحديد محدّد النقل الواجب استخدامه للوصول إلى الخادم المقابل؟ الحل هو إسناد عنوانٍ معروف لبرنامجٍ واحد فقط على الجهاز البعيد والسماح لهذا البرنامج بالتعامل مع مهمة إخبار العملاء باستخدام محدّد نقل معين للوصول إلى أي برنامجٍ آخر على الجهاز. يُطلق على الإصدار الأصلي من برنامج SunRPC اسم Port Mapper، وهو يدعم فقط UDP وTCP كبروتوكولات أساسية. رقم هذا البرنامج هو x00100000، ومنفذه المعروف هو 111. يدعم برنامج RPCBIND، المُطوَّر من برنامج Port Mapper، بروتوكولات النقل الأساسية الكيفية. يستدعي كلُّ خادم SunRPC في البداية إجراءَ تسجيل RPCBIND على الجهاز الرئيسي للخادم، لتسجيل محدد النقل وأرقام البرامج التي يدعمها. يمكن للعميل البعيد استدعاء إجراء بحث RPCBIND للبحث lookup عن محدد النقل لرقم برنامجٍ معين. لجعل هذا أكثر واقعية، نفترض مثالًا باستخدام برنامج Port Mapper مع بروتوكول UDP. لإرسال رسالة طلب إلى إجراء read الخاص ببرنامج NFS، يرسل العميل أولًا رسالة طلب إلى Port Mapper على منفذ UDP المعروف 111، ويطلب العميل هذا الإجراء 3 لربط رقم البرنامج x00100003 مع منفذ UDP حيث يوجد برنامج NFS حاليًا. يرسل العميل بعد ذلك رسالة طلب SunRPC برقم البرنامج x00100003 والإجراء رقم 6 إلى منفذ UDP هذا، وتستدعي وحدة SunRPC عند ذلك المنفذ إجراء read الخاص ببرنامج NFS. يخزّن العميل أيضًا ربط رقم البرنامج إلى المنفذ تخزينًا مؤقتًا بحيث لا يحتاج للرجوع إلى Port Mapper في كل مرة يريد فيها التحدث إلى برنامج NFS. يُعَد NFS، من الناحية العملية، برنامجًا مهمًا لدرجة أنه أُعطي منفذ UDP الخاص به، ولكن نتظاهر بأن الأمر ليس كذلك لأغراض التوضيح. تشتمل ترويسات رسائل الطلب والرد على حقل XID "معرّف الاتفاق transaction ID"، كما في الشكل السابق، لمطابقة رسالة رد مع الطلب المقابل، بحيث يمكن إرجاع نتيجة استدعاء الإجراء البعيد إلى المستدعي الصحيح. XID هو معرّف الاتفاق الفريد الذي يستخدمه فقط طلبٌ واحد والرد المقابل له. لا يتذكر الخادم المعرّف XID بعد أن نجح في الرد على طلب معين. لا يستطيع SunRPC ضمان دلالات مرة واحدة على الأكثر at-most-once semantics. تعتمد تفاصيل دلالات SunRPC على بروتوكول النقل الأساسي. لا يطبق SunRPC موثوقيته الخاصة، لذلك لا يمكن الاعتماد عليه إلا إذا كان بروتوكول النقل الأساسي موثوقًا (قد يختار أي تطبيق مُشغَّل عبر SunRPC أيضًا تطبيق آليات الوثوقية الخاصة به فوق مستوى SunRPC). تعتمد القدرة على إرسال رسائل الطلب والرد التي تكون أكبر من وحدة الإرسال القصوى MTU للشبكة على النقل الأساسي. أي لا يحاول SunRPC تحسينَ النقل الأساسي عندما يتعلق الأمر بالموثوقية وحجم الرسالة. بما أن SunRPC يمكن تشغيله عبر العديد من بروتوكولات النقل المختلفة، فإن هذا يمنحه قدرًا كبيرًا من المرونة دون تعقيد تصميم بروتوكول RPC نفسه. بالعودة إلى صيغة ترويسة SunRPC بالشكل السابق، حيث تحتوي رسالة الطلب على حقول Credentials وVerifier ذات الطول المتغير، وكلاهما يستخدمه العميل بهدف استيثاق authenticate نفسه على الخادم، أي لتقديم دليل على أن العميل لديه الحق في استدعاء الخادم. تُعَد كيفية استيثاق العميل لنفسه على الخادم مشكلة عامة يجب معالجتها بواسطة أي بروتوكول يريد توفير مستوى معقول من الأمن. آلية DCE-RPC DCE-RPC هو بروتوكول RPC وهو صميم نظام DCE وكان أساس آلية RPC التي تقوم عليها Microsoft DCOM وActiveX. يمكن استخدامه مع المصرّف الجذعي stub compiler لتمثيل بيانات الشبكة Network Data Representation أو اختصارًا NDR، ولكنه يعمل أيضًا كبروتوكول RPC الأساسي لمعيار Common Object Request Broker Architecture أو اختصارًا CORBA، وهو معيار على مستوى الصناعة لبناء الأنظمة الموزعة والموجَّهة بالكائنات. يمكن تطبيق DCE-RPC، مثل SunRPC، فوق العديد من بروتوكولات النقل بما في ذلك UDP وTCP. وهو مشابه أيضًا لبروتوكول SunRPC من حيث أنه يحدد مخطط عنونة من مستويين: فك تعدد إرسال بروتوكول النقل إلى الخادم الصحيح، وإرسال DCE-RPC إلى إجراءٍ معين يصدّره هذا الخادم، ويستشير العملاء "خدمة ربط نقاط النهاية endpoint mapping service" (مماثلة لبرنامج Port Mapper الخاص ببروتوكول SunRPC) لمعرفة كيفية الوصول إلى خادمٍ معين. لكن ينفذ DCE-RPC دلالات استدعاء مرة واحدة على الأكثر at-most-once على عكس SunRPC. (يدعم DCE-RPC دلالات استدعاء متعددة، بما في ذلك الدلالات الراسخة المماثلة لدلالات SunRPC، ولكن دلالات at-most-once في معظم الأحيان هو السلوك الافتراضي). هناك بعض الاختلافات الأخرى بين المنهجين، التي سنسلط عليها الضوء في الفقرات التالية. يعطي الشكل السابق خطًا زمنيًا للتبادل النموذجي للرسائل، حيث تُسمَّى كل رسالة بنوع DCE-RPC الخاص بها. يرسل العميل رسالة طلب Request، ويرد الخادم في النهاية برسالة استجابة Response، ويرسل العميل إشعارًا Ack بالاستجابة. يرسل العميل دوريًا رسالة Ping إلى الخادم بدلًا من إقرار الخادم برسائل الطلب، والذي يستجيب برسالة Working للإشارة إلى أن الإجراء البعيد لا يزال قيد التنفيذ. إذا اُستلِم ردُّ الخادم بسرعة معقولة، فلن تُرسَل أية رسائل Ping. تُدعَم أنواع الرسائل الأخرى أيضًا على الرغم من عدم ظهورها في الشكل، حيث يمكن للعميل إرسال رسالة إنهاء Quit إلى الخادم، مطالبًا إياه بإنهاء استدعاءٍ سابق لا يزال قيد التنفيذ، فيستجيب الخادم برسالة Quack أي إشعار بالإنهاء quit acknowledgment. يمكن للخادم أيضًا الرد على رسالة طلب Request برسالة رفض Reject (تشير إلى رفض الاستدعاء)، ويمكنه الرد على رسالة Ping برسالة Nocall (تشير إلى أن الخادم لم يسمع المستدعي مطلقًا). يحدث كل اتفاق طلب / رد في DCE-RPC ضمن سياق نشاط activity. النشاط عبارة عن قناة طلب / رد منطقية بين زوج من المشاركين، ويمكن أن يكون هناك اتفاق رسالةٍ واحد فقط نشط على قناة معينة في نفس الوقت. يتعين على برامج التطبيق فتح قنوات متعددة إذا كانت تريد الحصول على أكثر من اتفاق طلب / رد فيما بينها في نفس الوقت مثل نهج القناة المنطقية المتزامنة الموصوفة أعلاه. يحدّد حقلُ ActivityId الخاص بالرسالة النشاطَ الذي تنتمي إليه الرسالة، ثم يميز حقل SequenceNum بين الاستدعاءات التي أُجريَت كجزءٍ من نفس النشاط، حيث يؤدّي هذا الحقل نفسَ الغرض من حقل XID الخاص ببروتوكول SunRPC، ولكن يتتبع DCE-RPC الرقم التسلسلي الأخير المستخدَم كجزء من نشاطٍ معين، وذلك لضمان دلالات مرة واحدة على الأكثر بخلاف SunRPC. يستخدم DCE-RPC حقل ServerBoot للاحتفاظ بمعرّف تشغيل الجهاز للتمييز بين الردود المرسلة قبل وبعد إعادة تشغيل جهاز الخادم. هناك خيار تصميم آخر أُجري في DCE-RPC مختلف عن SunRPC وهو دعم التجزئة وإعادة التجميع في بروتوكول RPC. كما هو مذكور أعلاه، حتى إذا وفّر بروتوكولٌ أساسي مثل IP التجزئة / إعادة التجميع، فإن الخوارزمية الأعقد التي تُطبَّق كجزء من RPC يمكن أن تؤدي إلى انتعاشٍ recovery أسرع وتقليلٍ في استهلاك حيز النطاق التراسلي عند فقد الأجزاء fragments. يعرّف الحقل FragmentNum بشكل فريد كل جزءٍ أو قطعة fragment تشكّل رسالة طلب أو رسالة رد معينة، ويُسنَد رقمُ جزء فريد لكل جزء DCE-RPC مثل (0 و1 و2 و3 وهكذا). يطبّق كلٌّ من العميل والخادم آلية إشعارٍ انتقائية selective acknowledgment، والتي تعمل على النحو التالي عند وصف الآلية بحيث يرسل العميل رسالة طلبٍ مجزأة إلى الخادم، وتُطبَّق نفس الآلية عندما يرسل الخادم استجابة مجزأة إلى العميل. أولًا، يحتوي كل جزءٍ fragment يشكّل رسالة طلب على FragmentNum فريد ورايةٍ flag تشير إلى ما إذا كانت هذه الرزمة packet هي جزء من استدعاء (frag) أو الجزء الأخير من استدعاء ()call، حيث تحمل رسائلُ الطلب التي تناسب رزمة واحدة رايةً. يعرف الخادم أنه تلقى رسالة الطلب كاملةً عندما يكون لديه الرزمة دون وجود فجوات في أرقام الأجزاء. ثانيًا، يرسل الخادم رسالة Fack، إشعار جزء fragment acknowledgment، إلى العميل استجابةً لكل جزءٍ قادم. يحدّد هذا الإشعار أعلى رقم للجزء الذي استلمه الخادم بنجاح، أي يكون الإشعار تراكميًا، كما هو الحال في بروتوكول TCP. ولكن يُقِر الخادم بصورة انتقائية بأي أرقام أجزاءٍ أعلى تلقاها مخالفةً للترتيب، ويفعل ذلك باستخدام متجّه بتات يحدد هذه الأجزاء المخالفة للترتيب بالنسبة لأعلى جزءٍ من الترتيب تلقاه. أخيرًا، يستجيب العميل بإعادة إرسال الأجزاء المفقودة. يوضح الشكل التالي كيفية عمل كل ذلك. لنفترض أن الخادم قد تلقى بنجاح أجزاءً fragments حتى الرقم 20، بالإضافة إلى الأجزاء 23 و25 و26. يستجيب الخادم بإشعار Fack الذي يحدد الجزء 20 على أنه أعلى جزء في الترتيب، بالإضافة إلى متجه بتات SelAck مع البت الثالث (23 = 20 + 3)، والخامس (25 = 20 + 5) ، والسادس (26 = 20 + 6) المُشغَّل. يُعطَى حجم المتجه (الذي يقاس بكلماتٍ مؤلفة من 32 بتًا) في حقل SelAckLen من أجل دعم متجه بتاتٍ طويلٍ (تقريبًا) كيفي. بما أن DCE-RPC يدعم الرسائل الكبيرة جدًا (إن طول حقل FragmentNum يبلغ 16 بتًا، مما يعني أن بإمكانه دعم 64 ألف جزء)، فليس من المناسب للبروتوكول إطلاق جميع الأجزاء التي تشكّل رسالةً بأسرع ما يمكن بما أن القيام بذلك قد يغمر جهاز الاستقبال. يطبّق DCE-RPC بدلًا من ذلك خوارزميةً للتحكم في التدفق تشبه إلى حدٍ كبير خوارزمية TCP، حيث لا تُقِر كل رسالة Fack بالأجزاء المستلَمة فحسب، بل تُعلِم المرسل أيضًا بعدد الأجزاء التي قد ترسلها الآن. هذا هو الغرض من حقل WindowSize في الشكل السابق، والذي يخدم بالضبط نفس الغرض من حقل AdvertisedWindow الخاص ببروتوكول TCP باستثناء أنه يحسب الأجزاء fragments بدلًا من البايتات. يطبّق DCE-RPC أيضًا آلية للتحكم في الازدحام مشابهة لآلية TCP. قد لا يكون من المستغرب أن تتجنب بعض بروتوكولات RPC ذلك عن طريق تجنب التجزئة نظرًا لتعقيد التحكم في الازدحام. يوجد لدى المصممين مجموعة كبيرة من الخيارات المفتوحة لهم عند تصميم بروتوكول RPC. تتخذ SunRPC نهجًا أبسط وتضيف القليل نسبيًا إلى النقل الأساسي بخلاف أساسيات تحديد الإجراء الصحيح وتحديد الرسائل. يضيف DCE-RPC المزيد من الوظائف، مع إمكانية تحسين الأداء في بعض البيئات على حساب تعقيد أكبر. آلية gRPC على الرغم من أن أصولها من Google، ولكن gRPC لا تمثل Google RPC، فيرمز الحرف "g" إلى شيء مختلف في كل إصدار. رمز الحرف "g" إلى "glamorous" في الإصدار 1.10، وأشار إلى "goose" في الإصدار 1.18.تحظى gRPC بشعبية لأنها تتيح للجميع (كمصدر مفتوح) خبرةَ عشر سنوات داخل Google من خلال استخدام RPC لإنشاء خدمات سحابية قابلة للتوسّع. هناك بعض الاختلافات الرئيسية بين gRPC والمثالين الآخرين اللذين تناولناهما للتو. الاختلاف الأكبر هو أن gRPC مصممٌ للخدمات السحابية بدلًا من نموذج العميل / الخادم الأبسط الذي سبقه، ففي عالم العميل / الخادم، يستدعي العميل طريقةً في عملية خادم معينة تعمل على جهاز خادم معين. يُفترض أن تكون إحدى عمليات الخادم كافيةً لخدمة الاستدعاءات من جميع عمليات العميل التي قد تستدعيها. يستدعي العميل باستخدام الخدمات السحابية طريقةً في خدمة service، والتي تُنفَّذ من خلال عددٍ قابلٍ للتوسّع من عمليات الخادم من أجل دعم استدعاءات عدة عملاء كيفيًا في نفس الوقت، ويعمل كلٌّ من هذه العمليات على جهاز خادم مختلف. هذا هو المكان الذي تلعب فيه السحابة: توفّر مراكز البيانات عددًا يبدو لا نهائيًا من أجهزة الخادم المتاحة لتوسيع نطاق الخدمات السحابية. نعني مصطلح "قابل للتوسع scalable" أن عدد عمليات الخادم المتطابقة التي تختار إنشائها يعتمد على ضغط العمل (أي عدد العملاء الذين يريدون الخدمة في أي وقت معين) ويمكن تعديل هذا الرقم ديناميكيًا بمرور الوقت. أحد التفاصيل الأخرى هو أن الخدمات السحابية لا تنشئ عادةً عمليةً جديدة، في حد ذاتها، ولكنها تطلق حاويةً container جديدة، وهي في الأساس عمليةٌ مغلفةٌ داخل بيئة معزولة تتضمن جميع حزم البرمجيات التي تحتاجها العملية لتعمل. تُعَد Docker اليوم المثال الأساسي لمنصة حاويات. بالعودة إلى الادعاء القائل بأن الخدمة هي أساسًا مستوىً إضافيًا من التوجّه غير المباشر فوق الخادم، وهذا يعني أن المستدعي يحدد الخدمة التي يريد استدعاءها، ويوجه موازنُ الحِمل load balancer هذا الاستدعاء إلى إحدى عمليات الخوادم العديدة المتاحة (الحاويات) التي تطبّق تلك الخدمة، كما هو موضح في الشكل السابق. يمكن تطبيق موازن الحِمل بطرقٍ مختلفة، بما في ذلك جهاز عتاد، ولكنه يُطبَّق عادةً بواسطة عملية وكيل proxy تُشغَّل في آلة افتراضية (مستضافةٌ أيضًا في سحابة) وليس كجهاز فيزيائي. هناك مجموعة من أفضل الممارسات لتطبيق شيفرة الخادم الفعلي الذي يستجيب في النهاية لهذا الطلب، وبعض الآليات السحابية الإضافية لإنشاء / إتلاف create/destroy الحاويات وطلبات موازنة الحِمل عبر تلك الحاويات. إن أفضل الممارسات في بناء الخدمات بهذه الطريقة السحابية الأصلية هي: Kubernetes وهو اليوم بمثابة المثال الأساسي لنظام إدارة الحاويات هذا، ومعمارية الخدمات الصغيرة micro-services architecture. كلا الموضوعين مثيران للاهتمام، لكنهما خارج نطاق هذه السلسلة. ما يهمنا هنا هو بروتوكول النقل في صميم gRPC. هناك خروجٌ كبير عن البروتوكولين السابقين، ليس من حيث المشاكل الأساسية التي تحتاج إلى معالجة، ولكن من حيث نهج gRPC لمعالجة هذه المشاكل. يستعين gRPC بمصادر خارجية للعديد من المشكلات التي تواجه البروتوكولات الأخرى، مما يؤدي إلى حزم gRPC لتلك القدرات في نموذجٍ سهل الاستخدام. دعنا نلقي نظرة على التفاصيل. أولًا، يعمل gRPC فوق TCP بدلًا من UDP، مما يعني أنه يستعين بمصادر خارجية لمشاكل إدارة الاتصال والنقل الموثوق لرسائل الطلب والرد ذات الحجم الكيفي. ثانيًا، يعمل gRPC فعليًا فوق نسخةٍ مؤمَّنة من بروتوكول TCP تسمى طبقة النقل الآمنة Transport Layer Security أو اختصارًا TLS، وهي طبقة رقيقة تقع فوق بروتوكول TCP في مكدس البروتوكول، مما يعني أنها تستعين بمصادر خارجية لتأمين قناة الاتصال بحيث لا يستطيع الخصوم سرقة أو التنصت على تبادل الرسائل. ثالثًا، يعمل gRPC فعليًا فوق HTTP / 2 (والذي يقع في حد ذاته فوق TCP وTLS)، مما يعني أن لدى مصادر gRPC الخارجية مشكلتان إضافيتان: (1) تشفير / ضغط البيانات الثنائية بكفاءة في رسالة، (2) تعدد إرسال عدة استدعاءات بعيدة من أجل اتصال TCP واحد. يشفّر gRPC المعرّف الخاص بالطريقة البعيدة مثل URI، ومعاملات الطلب للطريقة البعيدة كمحتوىً في رسالة HTTP، والقيمة المعادة من الطريقة البعيدة في استجابة HTTP. يوضّح الشكل التالي مكدس gRPC الكامل، والذي يتضمن أيضًا العناصر الخاصة باللغة. (تتمثل إحدى نقاط قوة gRPC في المجموعة الواسعة من لغات البرمجة التي يدعمها، ويوضح الشكل التالي مجموعة فرعية صغيرة منها فقط). نناقش TLS وHTTP في مقالات لاحقة، لكننا نجد أنفسنا في حلقة اعتمادية مثيرة للاهتمام: حيث تُعد آلية RPC تشعبًا عن بروتوكول النقل المستخدَم لتنفيذ التطبيقات الموزعة، ويُعتبر HTTP مثالًا عن بروتوكول مستوى التطبيق، إلّا أنّ gRPC يعمل فوق HTTP وليس العكس. التفسير المختصر هو أن الطبقات توفر طريقة ملائمة للبشر لفهم الأنظمة المعقدة، ولكن ما نحاول فعله حقًا هو حل مجموعة من المشكلات (مثل النقل الموثوق للرسائل ذات الحجم الكيفي وتحديد المرسلين والمستلمين، تطابق رسائل الطلب مع رسائل الرد، وما إلى ذلك) وإن الطريقة التي تجمَّع فيها هذه الحلول في البروتوكولات، ثم وضع تلك البروتوكولات فوق بعضها البعض هي نتيجةً للتغييرات المتزايدة بمرور الوقت. لو بدأ الإنترنت بآلية RPC موجودةٍ في كل مكان مثل بروتوكول TCP، فربما طُبِّق HTTP فوقها (مثل أغلب البروتوكولات الأخرى على مستوى التطبيق تقريبًا) وربما قضت Google وقتها في تحسين هذا البروتوكول بدلًا من اختراع بروتوكولٍ خاص بها (كما فعلت هي والآخرين مع بروتوكول TCP). لكن ما حدث بدلًا من ذلك أنّ الويب أصبح التطبيق القاتل للإنترنت، مما يعني أن بروتوكول التطبيق الخاص به HTTP أصبح مدعومًا عالميًا من بقية البنية التحتية للإنترنت: جدران الحماية وموازنات الحِمل والتشفير والاستيثاق والضغط وما إلى ذلك. أصبح HTTP بفعالية بروتوكولَ نقل الطلب / الرد العالمي للإنترنت، نظرًا لأن جميع عناصر الشبكة هذه قد صمِّمت للعمل جيدًا مع بروتوكول HTTP. بالعودة إلى خصائص gRPC الفريدة، فإن أكبر قيمة يقدمها هي دمج التدفق streaming في آلية RPC، أي أن gRPC يدعم أربعة أنماط طلب / رد مختلفة: RPC البسيط Simple RPC: يرسل العميل رسالة طلبٍ واحدة ويستجيب الخادم برسالة ردٍ واحدة. Server Streaming RPC: يرسل العميل رسالة طلبٍ واحدة ويستجيب الخادم بتدفقٍ من رسائل الرد. يكمل العميل عمله بمجرد حصوله على جميع استجابات الخادم. Client Streaming RPC: يرسل العميل تدفقًا من الطلبات إلى الخادم، ويرسل الخادم استجابة واحدة عادةً (ولكن ليس بالضرورة) بعد أن يتلقى جميع طلبات العميل. تدفق RPC ثنائي الاتجاه Bidirectional Streaming RPC: يبدأ العميل الاستدعاء، ولكن يمكن للعميل والخادم بعد ذلك قراءة وكتابة الطلبات والاستجابات بأي ترتيب، حيث أن التدفقات مستقلةٌ تمامًا عن بعضها. تعني هذه الحرية الإضافية في كيفية تفاعل العميل والخادم أن بروتوكول نقل gRPC يحتاج إلى إرسال بيانات وصفية metadata ورسائل تحكم إضافية، بالإضافة إلى رسائل الطلب والرد الفعلية، بين النظيرين. تتضمن الأمثلة شيفرات الخطأ Error والحالة Status (للإشارة إلى نجاح أو سبب فشل شيء ما)، وTimeouts (للإشارة إلى المدة التي يرغب العميل انتظارَ الرد فيها) ، وPING (إشعار البقاء نشطًا keep-alive للإشارة إلى أن جانبًا أو آخر لا يزال قيد التشغيل)، وEOS (إشعار نهاية التدفق end-of-stream للإشارة إلى عدم وجود المزيد من الطلبات أو الاستجابات)، وGOAWAY (إشعار من الخوادم للعملاء للإشارة إلى أنهم لن يقبلوا بعد الآن أي تدفقاتٍ جديدة). إن الطريقة التي تُمرَّر فيها معلومات التحكم هذه بين الجانبين يمليها إلى حدٍ كبير بروتوكول النقل الأساسي، الذي هو HTTP / 2 في هذه الحالة، على عكس العديد من البروتوكولات الأخرى في هذه السلسلة، حيث يتضمن HTTP بالفعل مجموعةً من حقول الترويسات وشيفرات الرد التي يستفيد منها gRPC. قد يتضمن طلب RPC البسيط (بدون تدفق) رسالة HTTP التالية من العميل إلى الخادم: HEADERS (flags = END_HEADERS) :method = POST :scheme = http :path = /google.pubsub.v2.PublisherService/CreateTopic :authority = pubsub.googleapis.com grpc-timeout = 1S content-type = application/grpc+proto grpc-encoding = gzip authorization = Bearer y235.wef315yfh138vh31hv93hv8h3v DATA (flags = END_STREAM) <Length-Prefixed Message> مما يؤدي إلى رسالة الاستجابة التالية من الخادم إلى العميل: HEADERS (flags = END_HEADERS) :status = 200 grpc-encoding = gzip content-type = application/grpc+proto DATA <Length-Prefixed Message> HEADERS (flags = END_STREAM, END_HEADERS) grpc-status = 0 # OK trace-proto-bin = jher831yy13JHy3hc تُعَد HEADERS وDATA في هذا المثال رسالتين قياسيتين للتحكم في HTTP، والتي تصف بدقة وفعالية "ترويسة الرسالة" و"حمولة الرسالة". كل سطر يتبع HEADERS (ولكن قبل DATA) هو زوج attribute = value الذي يشكّل الترويسة (فكر في كل سطر على أنه مشابه لحقل الترويسة). الأزواج التي تبدأ بنقطتين (:status = 200 على سبيل المثال) هي جزء من معيار HTTP (تشير الحالة 200 إلى النجاح مثلًا). وتلك الأزواج التي لا تبدأ بنقطتين هي تخصيصات محدّدة بالآلية gRPC (تشير grpc-encoding = gzip على سبيل المثال إلى أن البيانات في الرسالة التالية قد ضُغِطت باستخدام gzip، وتشير grpc-timeout = 1S إلى أن العميل قد ضبط مهلة زمنية مقدارها ثانية واحدة). هناك قطعة أخيرة لشرحها وهو سطر الترويسة: content-type = application/grpc+proto الذي يشير إلى أن جسم الرسالة كما حدّده سطر DATA له معنى فقط لبرنامج التطبيق، أي طريقة الخادم الذي يطلب هذا العميل الخدمة منه. تحدد سلسلة +proto أن المستلم سيكون قادرًا على تفسير البتات في الرسالة وفقًا لمواصفات واجهة مخزَن البروتوكول المؤقت Protocol Buffer أو اختصارًا proto. مخازن البروتوكول المؤقتة هي طريقة gRPC لتحديد كيفية تشفير المعاملات الممرَّرة إلى الخادم في رسالة، والتي تُستخدم بدورها لإنشاء الأجزاء الجذعية التي تقع بين آلية RPC الأساسية والوظائف الفعلية التي تُستدعى. ترجمة -وبتصرّف- للقسم Remote Procedure Call من فصل End-to-End Protocols من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: بروتوكولات تدفق البايتات الموثوقة في الشبكات الحاسوبية: آلية الإرسال والبدائل تثبيت وإعداد نظام الوصول عن بعد VNC على نظام توزيعة ديبيان 10 توجيه Routing الرزم ضمن الشبكات الحاسوبية

سننشئ في هذا المقال رسومًا من النمط Pop Art Explosion باستخدام برنامج سكريبوس Scribus، حيث سنستخدم التقنيات المحدَّدة المُستخدَمة التالية لإنشاء هذا التصميم: إنشاء أشكال. إنشاء مضلع. تحويل الأشكال باستخدام الدوران. إنشاء نقش أو نمط Pattern. التعبئة باستخدام نقش. تحويل النص إلى مخططات تفصيلية Outlines. سيكون ممكنًا لأي شخص لديه معرفة أساسية ببرنامج سكريبوس Scribus اتباع هذه الخطوات، ولكن الأشخاص الذين لم يستخدموا برنامج سكريبوس من قبل لا يمكنهم ذلك. الإعداد ستحتاج أولًا إلى تنزيل الخط Startling Font وتثبيته إن لم يكن لديك سابقًا، ولكن يمكنك استخدام الخط الذي تريده، لهذا افتح برنامج سكريبوس وأنشئ مستندًا جديدًا، حيث سيكون القياس A4 أو رسالة Letter Portrait جيدًا. سيحتاج هذا المشروع الصغير إلى مساحة كبيرة بعض الشيء، لذلك يُفضَّل إنشاء كل طبقة على صفحة مختلفة كالآتي: اختر قائمة صفحة Page ثم إضافة Insert. غيّر عدد الصفحات إلى 2 ثم اضغط موافق. الخلفية انتقل إلى صفحة المستند الأولى. اختر قائمة إدراج Insert، ثم شكل، بعد ذلك اختر أشكال افتراضية Default Shapes، ثم مثلث قائم الزاوية وهو الشكل الثالث في القائمة. انقر في مكان ما بالقرب من وسط الصفحة. أدخل العرض 14 نقطة والارتفاع 150 نقطة ثم اضغط موافق (أو يمكنك تعديل العرض والارتفاع من نافذة خصائص Properties). اضبط لون الحدّ Line colour على القيمة "لا شيء" في تبويب ألوان Colours من نافذة خصائص Properties. اضبط لون التعبئة على اللون "الأحمر" بدرجة ظل 60%. بهذا ستكون قد حصلت على مثلث البداية الأول كما في الشكل التالي: حدّد المثلث ثم اختر قائمة عنصر ثم مضاعفة/تحويل ثم نسخ مطابق Duplicate. حدد النسخة المكرَّرة ثم اضغط على أيقونة "اقلب أفقيًا Flip Horizontal" (السهم الأفقي ذو الرأسين) في تبويب X وY وZ، وذلك في نافذة خصائص. غيّر العرض إلى 24 نقطة. اضبط لون التعبئة على "اللون الأصفر" في تبويب ألوان Colors من نافذة خصائص. اسحب المثلث الأصفر الجديد إلى اليمين قليلًا، لتتمكّن من تحديد المثلث الآخر بسهولة أكبر. حدّد المثلث الأصفر، ثم اضغط على مفتاح Shift، مع تحديد المثلث الأحمر. اختر قائمة نوافذ Windows ثم حدّد الخيار "حاذِ ووزّع Align and Distribute". اضبط "متعلق بـ Relative To" على الخيار "الاختيار الأخير Last Selected" في نافذة "حاذِ ووزّع". اضغط على أيقونة "حاذِ الجوانب اليمنى للعناصر بالجانب الأيسر للمربط Align right sides of items to left side of anchor". اضغط على أيقونة "حاذِ الجوانب العليا Align Tops". يجب أن يظهر لديك الآن مثلثان مثل الشكل التالي: حدّد المثلث الأحمر. انتقل إلى قائمة عنصر Item ثم مضاعفة/تحويل، ثم تحويل Transform. اضغط على زر إضافة Add واختر "تدوير Rotation" من القائمة. اضبط الزاوية على القيمة 13.9 درجة، والتي يجب عليك كتابتها يدويًا. حدّد الدائرة العلوية اليسرى في مربع "نقطة أساسية Origin". اضبط عدد النسخ على القيمة 25. اضغط موافق. بهذا نكون قد أنجزنا نصف المهمة، والآن لننتقل إلى الجزء الآخر. حدّد المثلث الأصفر (قد تحتاج إلى تحديده وسحبه للتأكد من عدم تحديد أي شيء آخر). اختر قائمة عنصر ثم تحويل. اضغط على زر "إضافة" واختر "تدوير" من القائمة. اضبط الزاوية على القيمة 13.9 درجة. حدّد الدائرة العلوية اليمنى هذه المرة في مربع "نقطة أساسية Origin". اضبط عدد النسخ على القيمة 25. اضغط موافق. يجب أن تظهر لديك الآن هذه "الزهرة" الجميلة الموجودة في الشكل التالي: لا تقلق بشأن عدم تساوي الحواف، إذ سنصلح ذلك في النهاية من خلال ما يلي: حدّد كل ما رسمته على هذه الصفحة. اختر قائمة عنصر ثم تجميع ثم اختر مجموعة Group. إنشاء شكل الانفجار Explosion يجب الآن رسم "الانفجار" الذي يقع بين الخلفية والنص. انتقل للأسفل إلى الصفحة الثانية. اختر قائمة إدراج Insert، ثم إدراج مضلع Insert Polygon، بعد ذلك خصائص Properties. غيّر عدد الزوايا إلى 7. انقر على مربع الاختيار "طبّق المعامل Apply Factor" لتفعيله. اضبط "المعامل Factor" على ‎-45% (ناقص 45). اضبط "الانحناء الداخلي Curvature" على 20%. انقر بالقرب من منتصف الصفحة. أدخل العرض بقيمة 260 نقطة والارتفاع بقيمة 160 نقطة. انقر على موافق، أو اسحب الشكل إلى وسط الصفحة إن لزم الأمر. حدّد الشكل ثم اضبط التدوير Rotation على القيمة 330 درجة في تبويب X وY وZ من نافذة خصائص. يجب أن يكون لديك الآن شكل يشبه ما يلي: اضبط عرض الخط على 3 نقاط في تبويب خط Line من نافذة خصائص. اضبط لون التعبئة على اللون "الأبيض" في تبويب ألوان Colours من نافذة خصائص. اختر قائمة عنصر، ثم مضاعفة/تحويل، بعد ذلك نُسخ مطابقة Multiple Duplicate. اضغط موافق دون إجراء أي تغييرات. لنشكّل الآن نمط تعبئة منقطة كما يلي: اختر قائمة إدراج، ثم شكل، ثم أشكال افتراضية، بعدها اختر دائرة. انقر في أي مكان فارغ في الصفحة. أدخل القيمة 16 نقطة للعرض و16 نقطة للارتفاع أيضًا، ثم اضغط على موافق. اضبط لون التعبئة على اللون "الأزرق" في تبويب ألوان في نافذة خصائص. اضبط الظل Shade على القيمة 60%. اضبط لون الحد على "لا شيء None". حدّد هذه الدائرة الصغيرة، ثم اختر قائمة عنصر، ثم مضاعفة/تحويل، ثم تحويل. اضغط على زر "إضافة" واختر "ترجمة" من القائمة. اضبط القيم الأفقية والرأسية على 8 نقاط. اضبط عدد النسخ على القيمة 1. اضغط موافق. ألغِ تحديد كل شيء وأعِد تحديد الدائرة المنسوخة فقط (الموجودة على اليمين). اضبط لون التعبئة على "لا شيء" في تبويب ألوان من نافذة خصائص. اسحب وحدد كلتا الدائرتين. اختر قائمة عنصر ثم تجميع، ثم اختر مجموعة. اختر قائمة عنصر ثم "أرسل إلى"، بعد ذلك اختر نقوش Send to Patterns. أدخل الاسم "Dots" ثم اضغط موافق. حدّد الشكل الشبيه بالأشواك الذي أنشأته مسبقًا (وهو في الواقع النسخة المكرَّرة الموجودة في الأعلى). اضغط على نمط التعبئة في تبويب ألوان من نافذة خصائص، واختر "نقش Pattern" من القائمة. حدّد النقش "Dots". اضغط على خصائص أسفل النقوش، ثم اضبط كلًا من قيمة تحجيم-س X-Scale وتحجيم-ص Y-Scale على 25% في قسم "تحجيم Scaling". يجب أن يكون لديك الآن شكل مملوء بالنقاط كما يلي: اسحب وحدّد كل الأشكال ذات الأشواك. اختر قائمة "عنصر"، ثم "تجميع"، ثم "مجموعة Group". النص انتقل للأسفل إلى الصفحة الثالثة. أنشئ إطار نص يبلغ عرضه حوالي 400 نقطة وارتفاعه 160 نقطة. انقر نقرًا مزدوجًا على الإطار وأدخل الكلمة "BANG" (بدون علامات الاقتباس) كنص. انقر على خلفية الصفحة لإلغاء تحديد الإطار. أعد تحديد الإطار. اختر الخط "Startling Font" من نافذة خصائص النص، والتي يمكنك الوصول إليها من قائمة "نوافذ"، ثم "خصائص المحتوى". اضبط حجم الخط ليكون 100 نقطة. اضبط لون النص ليكون لونه أحمر، وذلك في تبويب الألوان والمؤثرات Colour & Effects من نافذة خصائص النص. اختر قائمة عنصر ثم تحويل لـ Convert To ثم اختر مخططات تفصيلية Outlines. أعد تحديد النص. اختر قائمة "عنصر"، ثم "التجميع"، ثم اختر فك التجميع Ungroup. اختر قائمة "عنصر"، ثم "أدوات المسار"، ثم اجمع المضلعات Combine Polygons. أعِد تحديد النص. اضبط لون الحد على اللون "الأسود" في تبويب ألوان من نافذة خصائص. اضبط عرض الخط على 3 نقاط في تبويب خط Line من نافذة خصائص. اختر قائمة عنصر، ثم مضاعفة/تحويل، ثم نُسخ مطابقة Multiple Duplicate. ثم اضغط على موافق دون إجراء أي تغييرات. حدد النص (النسخة العلوية). اضغط على المؤشر للأسفل مرتين من لوحة المفاتيح. اضغط على المؤشر لليمين مرتين من لوحة المفاتيح. اضبط لون التعبئة على اللون "الأسود" (في حالة رغبتك في تحريك الظل لمسافة أبعد). اختر قائمة عنصر ثم مستوى Level ثم للأسفل Lower. يجب أن يكون لديك الآن نص له ظل مثل الشكل التالي: اسحب وحدّد النص. اختر قائمة عنصر، ثم تجميع، ثم مجموعة. تجميع الأجزاء مع بعضها البعض حدّد النص. مرّر للأعلى واضغط Shift، ثم حدد الشكل الذي يشبه الأشواك. انتقل لأعلى مرةً أخرى واضغط Shift، ثم حدد "الزهرة". افتح نافذة حاذِ ووزّع Align & Distribute مرةً أخرى إن أغلقتها سابقًا، ثم تأكّد من ضبط "متصل بـ Relative To" على القيمة "الاختيار الأخير Last Selected". اضغط على أيقونة "مَركِز على المحور الرأسي Centre on vertical axis". اضغط على أيقونة "مَركِز على المحور الأفقي Centre on horizontal axis". الخطوة النهائية الخطوة الأخيرة هي ترتيب كل الأشياء مع بعضها البعض، وذلك باتباع ما يلي: اختر قائمة إدراج ثم شكل ثم أشكال افتراضية ثم دائرة. انقر في أي مكان على صفحتك. أدخل عرضًا وارتفاعًا بمقدار 300 نقطة. اضغط على موافق. اضبط لون الحد على اللون "الأبيض" من تبويب ألوان في نافذة خصائص. اضبط عرض الخط على 6 نقاط. حدّد الدائرة البيضاء، ثم اضغط مفتاح Shift، وحدّد "الزهرة". تأكّد من ضبط "متصل بـ Relative To" على القيمة "الاختيار الأخير Last Selected" من نافذة حاذِ ووزّع Align & Distribute. اضغط على أيقونة "مَركِز على المحور الرأسي Centre on vertical axis". اضغط على أيقونة "مَركِز على المحور الأفقي Centre on horizontal axis". وبهذا تكون قد أنشأت شكل Pop Art Explosion التالي: ترجمة -وبتصرّف- للمقال How to create a Pop Art Explosion. اقرأ أيضًا كيفية إنشاء لافتة نيون Neon Sign في برنامج سكريبوس Scribus كيفية إنشاء أشكال معقدة ذات زوايا دائرية في برنامج سكريبوس Scribus خطوات تطوير شعار باستخدام برنامج سكريبوس Scribus كيفية إنشاء التأثير Distressing Mask في برنامج سكريبوس لإنتاج تأثيرات تعبئة جذابة

يدعم TCP تجريد تدفق البايت، أي أن برامج التطبيقات تكتب البايت في التدفق، والأمر متروك لبروتوكول TCP لاتخاذ القرار بأن لديه بايتات كافية لإرسال جزء. لكن ما هي العوامل التي تحكم هذا القرار؟ سنتابع في هذا المقال ما تحدثنا عنه في المقال السابق حول بروتوكولات تدفق البايتات الموثوقة بالاعتماد على مثال TCP، وسنكمل الحديث هنا عن هذه البروتوكولات آخذين جانب آلية الإرسال والبدائل. إذا تجاهلنا إمكانية التحكم في التدفق، أي بفرض أن النافذة مفتوحة على مصراعيها كما هو الحال عند بدء الاتصال لأول مرة، عندئذ يكون لدى بروتوكول TCP ثلاث آليات لبدء إرسال جزء. أولًا، يحتفظ بروتوكول TCP بمتغير، يسمى عادةً حجم الجزء الأقصى maximum segment size أو اختصارًا MSS، ويرسل جزءًا بمجرد أن يجمع بايتاتٍ بحجم MSS من عملية الإرسال. يُضبَط MSS على حجم أكبر جزء يمكن أن يرسله TCP دون التسبب في تجزئة عنوان IP المحلي. أي ضُبِط MSS على أقصى وحدة إرسال maximum transmission unit أو اختصارًا MTU للشبكة المتصلة مباشرة، مطروحًا منها حجم ترويستي TCP و IP. الشيء الثاني الذي ينبّه بروتوكول TCP لإرسال جزء هو أن عملية الإرسال طلبت منه صراحةً القيام بذلك. يدعم بروتوكول TCP العملية push، وتستدعي عملية الإرسال هذه العملية لتفريغ flush المخزن المؤقت للبايتات غير المرسلة بفعالية. المنبّه trigger الأخير لإرسال جزء هو إنطلاق المؤقت timer، حيث يحتوي الجزء الناتج على العديد من البايتات المخزَّنة حاليًا للإرسال. وعلى أية حال لن يكون هذا "المؤقت" كما تتوقعه بالضبط كما سنرى قريبًا. متلازمة النوافذ الساذجة Silly Window Syndrome لا يمكننا بالتأكيد تجاهل التحكم في التدفق فقط، والذي يلعب دورًا واضحًا في تقييد المرسل. فإذا كان لدى المرسل بايتات بحجم MSS من البيانات لإرسالها وكانت النافذة مفتوحة على الأقل بهذا القدر، فإن المرسل يرسل جزءًا كاملًا. افترض أن المرسل يجمّع البايتات لإرسالها، ولكن النافذة مغلقة حاليًا. لنفترض الآن وصول ACK يفتح النافذة بفعالية بما يكفي لإرسال المرسل، بحجم MSS / 2 بايت مثلًا. هل يجب على المرسل إرسال جزء نصف ممتلئ أم الانتظار حتى تفتح النافذة بحجم MSS كامل؟ لم تذكر المواصفات الأصلية شيئًا بشأن هذه النقطة، وقررت عمليات التنفيذ الأولي لبروتوكول TCP المضي قدمًا وإرسال جزء نصف كامل، ولكن ليس هناك ما يخبرنا إلى متى سيبقى بهذه الحالة قبل أن تفتح النافذة أكثر. اتضح أن استراتيجية الاستفادة الكبيرة من أية نافذةٍ متاحة تؤدي إلى حالة تُعرَف الآن باسم متلازمة النوافذ الساذجة، حيث يساعد الشكل التالي على تصور ما يحدث: إذا فكّرت في تدفق TCP على أنه حزامٌ ناقل به حاويات "ممتلئة" أو أجزاء بيانات data segments تسير في اتجاهٍ واحد وحاويات فارغة هي الإشعارات ACKs تسير في الاتجاه العكسي. فإن الأجزاء ذات الحجم MSS تتوافق مع الحاويات الكبيرة والأجزاء ذات الحجم 1 بايت تتوافق مع حاويات صغيرة جدًا. طالما أن المرسل يرسل أجزاءًا بحجم MSS ويرسل المستقبل إشعارات ACKs على الأقل بحجم MSS من البيانات في كل مرة، وبالتالي سيعمل كل شيء جيدًا (كما في القسم أ من الشكل الآتي). لكن ماذا لو اضطر المستقبل إلى تقليل النافذة بحيث لا يتمكن المرسل في وقتٍ ما من إرسال MSS كامل من البيانات؟ إذا ملأ المرسل حاويةً فارغة حجمها أصغر من MSS بمجرد وصولها، فسيرسل المستقبل إشعارًا بهذا العدد الأصغر من البايتات، وبالتالي تظل الحاوية الصغيرة المدخلة في النظام إلى أجلٍ غير مسمى فيه، أي أنها تُملَأ وتُفرَغ على الفور عند كل طرف ولا تُدمَج مطلقًا مع الحاويات المجاورة لإنشاء حاويات أكبر، كما في القسم (ب) من الشكل التالي. اُكتشِف هذا السيناريو عندما وجدت التطبيقات الأولى لبروتوكول TCP نفسها تملأ الشبكة بأجزاء صغيرة. تُعتبر متلازمة النوافذ الساذجة مشكلةً فقط عندما يرسل المرسل جزءًا صغيرًا أو يفتح جهاز الاستقبال النافذة بمقدار صغير. إذا لم يحدث أي من هذين الأمرين، فلن تُدخَل الحاوية الصغيرة مطلقًا في التدفق. من غير الممكن تحريم إرسال مقاطع صغيرة، فقد يقوم التطبيق بعملية push بعد إرسال بايت واحد على سبيل المثال، ولكن من الممكن منع جهاز الاستقبال من إدخال حاوية صغيرة (أي نافذة صغيرة مفتوحة)، حيث يجب أن ينتظر جهاز الاستقبال حيزًا يساوي حجم MSS قبل أن يعلن عن نافذة مفتوحة، وذلك بعد الإعلان عن نافذةٍ صفرية. نظرًا لإمكانية استبعاد إمكانية إدخال حاويةٍ صغيرة في التدفق، إلا أننا نحتاج أيضًا إلى آلياتٍ لدمجها. يمكن للمستقبل القيام بذلك عن طريق تأخير ACK، أي إرسال ACK واحد مدمج بدلًا من إرسال عدة رسائلٍ أصغر، ولكن هذا حل جزئي فقط لأن جهاز الاستقبال ليس لديه طريقة لمعرفة المدة التي يمكن فيها تأخير انتظار وصول جزء آخر أو انتظار التطبيق لقراءة المزيد من البيانات (وبالتالي فتح النافذة). يقع الحل النهائي على عاتق المرسل، وهو ما يعيدنا إلى مشكلتنا الأصلية: متى يقرر مرسل TCP إرسال جزءsegment؟ خوارزمية Nagle بالعودة إلى مرسل TCP، إذا كانت هناك بياناتٌ لإرسالها ولكن النافذة مفتوحة بحجمٍ أقل من حجم MSS، فقد نرغب في الانتظار بعض الوقت قبل إرسال البيانات المتاحة، ولكن السؤال هو كم طول هذه المدة؟ إذا انتظرنا وقتًا طويلًا، فإننا نُضِر بذلك التطبيقات التفاعلية مثل تطبيق Telnet. وإذا لم ننتظر طويلًا بما فيه الكفاية، فإننا نجازف بإرسال مجموعةٍ من الرزم الصغيرة والوقوع في متلازمة النوافذ الساذجة. الجواب هو إدخال مؤقت timer والإرسال عند انتهاء مدته. يمكننا استخدام مؤقت قائم على النبضات، مثل مؤقت ينطلق كل 100 ميلي ثانية. قدّم Nagle حلًا رائعًا للتوقيت الذاتي. الفكرة هي أنه طالما لدى بروتوكول TCP أي بيانات قيد الإرسال in flight، فإن المرسل سيتلقى في النهاية ACK. يمكن التعامل مع ACK كإطلاق مؤقت، ينبِّه بإرسال المزيد من البيانات. توفر خوارزمية Nagle قاعدة بسيطة وموحدة لاتخاذ قرار بشأن توقيت بدء الإرسال. When the application produces data to send if both the available data and the window >= MSS send a full segment else if there is unACKed data in flight buffer the new data until an ACK arrives else send all the new data now من المقبول دائمًا إرسال جزء كامل إذا سمحت النافذة بذلك، كما يحق لك إرسال كمية صغيرة من البيانات على الفور إذا لم يكن هناك أي أجزاء قيد النقل. ولكن إذا كان هناك أي شيء قيد الإرسال، فيجب على المرسل انتظار ACK قبل إرسال الجزء التالي. وبالتالي سيرسل تطبيقٌ تفاعلي مثل Telnet الذي يكتب باستمرار بايتًا واحدًا في المرة الواحدة البياناتِ بمعدل جزء واحد لكل RTT. ستحتوي بعض الأجزاء على بايت واحد، بينما يحتوي البعض الآخر على عدد بايتات بقدر ما كان المستخدم قادرًا على الكتابة في وقت واحد ذهابًا وإيابًا. تسمح واجهة المقبس للتطبيق بإيقاف تشغيل خوارزمية Nagel عن طريق تعيين خيار TCP_NODELAY نظرًا لأن بعض التطبيقات لا يمكنها منح مثل هذا التأخير لكل عملية كتابة تقوم بها لاتصالٍ من نوع TCP، حيث يعني ضبط هذا الخيار إرسال البيانات في أسرع وقتٍ ممكن. إعادة الإرسال التكيفي Adaptive Retransmission بما أن بروتوكول TCP يضمن التسليم الموثوق للبيانات، فإنه يعيد إرسال كل جزء إذا لم يُستلَم إشعار ACK خلال فترةٍ زمنية معينة. يضبط بروتوكول TCP هذه المهلة الزمنية كدالة لوقت RTT الذي يتوقعه بين طرفي الاتصال. إن اختيار قيمة المهلة الزمنية المناسبة ليس بهذه السهولة لسوء الحظ، نظرًا لمجال قيم RTT الممكنة بين أي زوجٍ من المضيفين في الإنترنت، بالإضافة إلى الاختلاف في RTT بين نفس المضيفين بمرور الوقت. لمعالجة هذه المشكلة، يستخدم بروتوكول TCP آلية إعادة الإرسال التكيفية. سنقوم بوصف هذه الآلية الآن وتطورها مع مرور الوقت حيث اكتسب مجتمع الإنترنت المزيد من الخبرة باستخدام TCP. الخوارزمية الأصلية نبدأ بخوارزمية بسيطة لحساب قيمة المهلة الزمنية timeout بين زوجٍ من المضيفين. هذه هي الخوارزمية التي وُصفت في الأصل في مواصفات بروتوكول TCP، ولكن يمكن استخدامها بواسطة أي بروتوكول طرفٍ إلى طرف end-to-end protocol. تكمن الفكرة في الاحتفاظ بمتوسط تشغيل RTT ثم حساب المهلة الزمنية كدالة لوقت RTT. يسجل TCP الوقت في كل مرة يرسل فيها جزء بيانات، ويقرأ بروتوكول TCP الوقت مرةً أخرى عند وصول ACK لهذا الجزء، ثم يأخذ الفرق بين هاتين المرتين على أنه SampleRTT. ثم يحسب TCP قيمة EstimatedRTT كمتوسط مرجح بين التقدير estimate السابق وهذه العينة sampleالجديدة، حيث: EstimatedRTT = alpha x EstimatedRTT + (1 - alpha) x SampleRTT يُحدَّد المعامل alpha لتنعيم EstimatedRTT. تتتبّع قيمةُ alpha الصغيرة التغييراتِ في RTT ولكن ربما تتأثر بشدة بالتقلبات المؤقتة. ومن ناحيةٍ أخرى، تكون قيمة alpha الكبيرة أكثر استقرارًا ولكن ربما لا تكون سريعة بما يكفي للتكيف مع التغييرات الحقيقية. أوصت مواصفات TCP الأصلية بإعداد قيمة alpha بين 0.8 و 0.9. يستخدم بروتوكول TCP المعامل EstimatedRTT لحساب المهلة الزمنية timeout بطريقة متحفظة إلى حدٍ ما: TimeOut = 2 x EstimatedRTT خوارزمية كارن / بارتريدج Karn/Partridge اُكتشِف عيبٌ واضح في الخوارزمية السابقة البسيطة بعد عدة سنوات من الاستخدام على الإنترنت. كانت المشكلة أن الإشعار ACK لا يُقِر حقًا بالإرسال، بل باستلام البيانات في الحقيقة، أي عندما يُعاد إرسال جزء ثم وصول ACK إلى المرسل، فمن المستحيل تحديد ما إذا كان ينبغي إرفاق هذا الإشعار بالإرسال الأول أو الثاني للجزء بغرض قياس sample RTT. من الضروري معرفة الإرسال الذي سيُربَط به لحساب العينة SampleRTT بدقة. إذا افترضت أن الإشعار ACK للإرسال الأصلي ولكنه كان في الحقيقة للثاني كما هو موضح في الشكل التالي، فإن SampleRTT كبيرةٌ جدًا كما في القسم (أ) من الشكل التالي، وإذا افترضت أن الإشعار ACK للإرسال الثاني ولكنه كان في الواقع للإرسال الأول، فإن عينة SampleRTT صغيرةٌ جدًا كما في القسم (ب) من الشكل التالي: الحل الذي جرى اقتراحه في عام 1987 بسيط جدًا: يتوقف بروتوكول TCP عن أخذ عيناتٍ من RTT عندما يعيد إرسال جزء ما، فهو يقيس SampleRTT فقط للأجزاء التي أُرسلت مرةً واحدة فقط. يُعرف هذا الحل باسم خوارزمية كارن / بارتريدج تيّمنًا بمخترعَيها. يتضمن الإصلاح المقترح أيضًا تغييرًا صغيرًا ثانيًا في آلية مهلة TCP الزمنية. يضبط بروتوكول TCP المهلة التالية لتكون ضعف آخر مهلة في كل مرة يعيد فيها الإرسال، بدلًا من إسنادها إلى آخرEstimatedRTT. اقترح كارن و بارتريدج أن يستخدم بروتوكولُ TCP تراجعًا أسيًا exponential backoff، على غرار ما يفعله إيثرنت. الدافع لاستخدام التراجع الأسي بسيط: الازدحام هو السبب الأكثر احتمالًا لفقدان الأجزاء، مما يعني أن مصدر TCP يجب ألا يتفاعل بقوة مع انقضاء المهلة الزمنية، فكلما انقضت مهلة الاتصال الزمنية، يجب أن يصبح المصدر أكثر حذرًا. سنرى هذه الفكرة مرة أخرى، مجسَّدةً في آلية أعقد لاحقًا. خوارزمية جاكوبسون / كارلس Jacobson/Karels قُدّمت خوارزمية كارن / بارتريدج في وقت كان فيه الإنترنت يعاني من مستويات عالية من ازدحام الشبكة، فصُمِّم نهج هذه الخوارزمية لإصلاح بعض أسباب هذا الازدحام، ولكن على الرغم من تقديمها تحسينًا، إلا أنه لم يتم القضاء على الازدحام. اقترح باحثان آخران (جاكوبسون وكارلس) تغييرًا جذريًا في بروتوكول TCP لمحاربة الازدحام في العام التالي (1988). سنركز على هذا الاقتراح المتعلق بتحديد انتهاء المهلة وإعادة إرسال جزء ما. يجب أن يكون ارتباط آلية المهلة الزمنية بالازدحام واضحًا، فإذا انقضت المهلة في وقت مبكرٍ جدًا، فقد تعيد إرسال جزء بدون داعٍ، والذي يضيف فقط إلى الحِمل على الشبكة. السبب الآخر للحاجة إلى قيمة مهلة دقيقة هو أن المهلة تُؤخَذ للإشارة إلى الازدحام، مما يؤدي إلى تشغيل آلية للتحكم في الازدحام. أخيرًا، لاحظ أنه لا يوجد شيء يتعلق بحساب مهلة جاكوبسون وكارلس الخاص ببروتوكول TCP. يمكن استخدامه من قبل أي بروتوكول من طرفٍ إلى طرف. تكمن المشكلة الرئيسية في حساب الخوارزمية الأصلية في أنها لا تأخذ في الاعتبار تباين عينات RTT. إذا كان الاختلاف بين العينات صغيرًا، فيمكن الوثوق في EstimatedRTT بصورةٍ أفضل ولا يوجد سبب لضرب هذا التقدير في 2 لحساب المهلة الزمنية. يشير التباين الكبير في العينات من ناحية أخرى إلى أن قيمة المهلة لا ينبغي أن تكون مرتبطة بإحكام شديد بقيمة EstimatedRTT. بينما في النهج الجديد، يقيس المرسل SampleRTT جديدًا كما كان يتم سابقًا، ثم تُطوى هذه العينة الجديدة في حساب المهلة على النحو التالي: Difference = SampleRTT - EstimatedRTT EstimatedRTT = EstimatedRTT + ( delta x Difference) Deviation = Deviation + delta (|Difference| - Deviation) حيث تقع قيمة delta بين 0 و1. أي أننا نحسب كلًا من متوسط وقت RTT والتغير في هذا المتوسط، ثم يحسب TCP قيمة المهلة كدالة لكل من EstimatedRTT وDeviation على النحو التالي: TimeOut = mu x EstimatedRTT + phi x Deviation يُعيَّن mu على القيمة 1 وphi على القيمة 4 بناءً على الخبرة. وهكذا تكون TimeOut قريبةً من EstimatedRTT عندما يكون التباين صغيرًا، حيث يؤدي التباين الكبير إلى سيطرة مصطلح الانحراف Deviation على الحساب. التطبيق Implementation هناك نقطتان جديرتان بالملاحظة فيما يتعلق بتطبيق المهلات الزمنية في بروتوكول TCP. الأولى هي إمكانية تطبيق حساب EstimatedRTT وDeviation دون استخدام حساب الأعداد العشرية. فبدلًا من ذلك، تُوسَّع العملية الحسابية بالكامل بمقدار 2n، مع اختيار delta لتكون 1/2n. يتيح لنا ذلك إجراء العمليات الحسابية الصحيحة، وتطبيق الضرب والقسمة باستخدام الإزاحات shifts، وبالتالي تحقيق أداءٍ أعلى. يُعطى الحساب الناتج عن طريق جزء الشيفرة التالية، حيث n = 3 (أي delta = 1/8). لاحظ تخزين EstimatedRTT وDeviation في نماذجهما الموسّعَين، بينما قيمة SampleRTT في بداية الشيفرة و TimeOut في النهاية هي قيمٌ حقيقية غير مُوسَّعة. إذا وجدت صعوبة في تتبع الشيفرة، فقد ترغب في محاولة إدخال بعض الأرقام الحقيقية فيها والتحقق من أنها تعطي نفس النتائج مثل المعادلات أعلاه: { SampleRTT -= (EstimatedRTT >> 3); EstimatedRTT += SampleRTT; if (SampleRTT < 0) SampleRTT = -SampleRTT; SampleRTT -= (Deviation >> 3); Deviation += SampleRTT; TimeOut = (EstimatedRTT >> 3) + (Deviation >> 1); } النقطة الثانية هي أن خوارزمية جاكوبسون / كارلس جيدة فقط مثل الساعة المستخدمة لقراءة الوقت الحالي. كانت دقة الساعة كبيرة في تطبيقات يونيكس النموذجية في ذلك الوقت حيث وصلت إلى 500 ميلي ثانية، وذلك أكبر بكثير من متوسط RTT عبر دولة في مكانٍ ما والذي يكون بين 100 و200 ميلي ثانية. لجعل الأمور أسوأ، فحص تطبيق يونيكس لبروتوكول TCP فيما إذا كان يجب أن يحدث انتهاء للمهلة في كل مرة تُحدَّد فيها الساعة 500 ميلي ثانية ولن يأخذ سوى عينةٍ من وقت الذهاب والإياب مرة واحدة لكل RTT. و قد يعني الجمع بين هذين العاملين أن المهلة ستحدث بعد ثانية واحدة من إرسال الجزء. تشتمل توسّعات TCP على آلية تجعل حساب RTT هذا أدق قليلًا. تستند جميع خوارزميات إعادة الإرسال التي ناقشناها إلى مهلات الإشعارات، والتي تشير إلى احتمال فقد جزءٍ ما. لاحظ أن المهلة لا تخبر المرسل فيما إذا اُستلِمت بنجاحٍ أي أجزاءٍ أرسلها بعد فقدان جزء، وذلك لأن إشعارات TCP تراكمية cumulative، أي أنها تحدد فقط الجزء الأخير المُستلم دون أي فجوات سابقة. ينمو استقبال الأجزاء التي تظهر بعد زيادة الفجوة بصورةٍ متكررة كما تؤدي الشبكات الأسرع إلى نوافذ أكبر. إذا أخبرت ACK المرسلَ أيضًا عن الأجزاء اللاحقة، إن وجدت، فقد يكون المرسل أذكى بشأن الأجزاء التي يعيد إرسالها، إضافةً لاستخلاص استنتاجات أفضل حول حالة الازدحام، وإجراء تقديرات RTT أفضل. حدود السجلات Record Boundaries ليس بالضرورة أن يكون عدد البايتات التي يكتبها المرسل نفس عدد البايتات التي قرأها المستقبل نظرًا لأن بروتوكول TCP هو بروتوكول تدفق بايتات، فقد يكتب التطبيق 8 بايتات، ثم 2 بايت، ثم 20 بايت إلى اتصال TCP، بينما يقرأ التطبيق على جانب الاستقبال 5 بايتات في المرة الواحدة داخل حلقة تتكرر 6 مرات. لا يقحم بروتوكول TCP حدود السجلات بين البايتين الثامن والتاسع، ولا بين البايتين العاشر والحادي عشر. هذا على عكس بروتوكول الرسائل الموّجهة، مثل بروتوكول UDP، حيث تكون الرسالة المرسَلة بنفس طول الرسالة المُستلَمة. يمتلك بروتوكول TCP، على الرغم من كونه بروتوكول تدفق بايتات، ميزتين مختلفتين يمكن للمرسل استخدامهما لإدراج حدود السجلات في تدفق البايتات هذا، وبالتالي إعلام المستقبِل بكيفية تقسيم تدفق البايتات إلى سجلات. (تُعَد القدرة على تحديد حدود السجلات أمرًا مفيدًا في العديد من تطبيقات قواعد البيانات على سبيل المثال) وضُمِّنت هاتان الميزتان في الأصل في بروتوكول TCP لأسباب مختلفة تمامًا، ثم جرى استخدامهما لهذا الغرض بمرور الوقت، وهما: الآلية الأولى هي ميزة البيانات العاجلة urgent data feature، التي طُبِّقت بواسطة الراية URG وحقل UrgPtr في ترويسة TCP. صُمِّمت آلية البيانات العاجلة في الأصل للسماح للتطبيق المرسِل بإرسال بيانات خارج النطاق إلى نظيره. نعني بعبارة خارج النطاق out-of-band البياناتِ المنفصلة عن تدفق البيانات الطبيعي (أمر مقاطعة عملية جارية بالفعل على سبيل المثال). حُدِّدت هذه البيانات خارج النطاق في الجزء segment باستخدام حقل UrgPtr وكان من المقرر تسليمها إلى عملية الاستلام بمجرد وصولها، حتى لو عنى ذلك تسليمها قبل بيانات ذات رقمٍ تسلسلي سابق. لكن، لم تُستخدَم هذه الميزة بمرور الوقت، لذلك بدلًا من الإشارة إليها ببيانات "عاجلة" ، فقد اُستخدمت للدلالة على بيانات "خاصة"، مثل علامة السجل record marker. طُوِّر هذا الاستخدام لأنه، كما هو الحال مع عملية push، يجب على TCP على الجانب المستلم إبلاغ التطبيق بوصول بيانات عاجلة، أي أن البيانات العاجلة في حد ذاتها ليست مهمة. إنها تشير إلى حقيقة أن عملية الإرسال يمكنها إرسال إشارة فعالة إلى جهاز الاستقبال بأن هناك أمرٌ مهم. الآلية الثانية لإدخال علامات نهاية السجلات في بايت هي العملية push. صُمِّمت هذه الآلية في الأصل للسماح لعملية الإرسال بإعلام بروتوكول TCP بأنه يجب عليه إرسال أو تفريغ flush أي بايتات جمَّعها لنظيره. يمكن استخدام العملية push لتطبيق حدود السجلات لأن المواصفات تنص على أن بروتوكول TCP يجب أن يرسل أي بيانات مخزَّنة مؤقتًا عند المصدر عندما يقول التطبيق push، ويُعلِم بروتوكول TCP، اختياريًا، التطبيق في الوجهة عند وجود جزء وارد يحتوي على مجموعة الراية PUSH. إذا كان جانب الاستقبال يدعم هذا الخيار (لا تدعم واجهة المقبس هذا الخيار)، فيمكن عندئذٍ استخدام العملية push لتقسيم تدفق TCP إلى سجلات. برنامج التطبيق حرٌ دائمًا بحشر حدود السجلات دون أي مساعدة من بروتوكول TCP، حيث يمكنه إرسال حقل يشير إلى طول السجل الذي يجب أن يتبعه، أو يمكنه حشر علامات حدود السجل الخاصة به في تدفق البيانات على سبيل المثال. إضافات بروتوكول TCP لقد ذكرنا أن هناك إضافات Extensions لبروتوكول TCP تساعد في التخفيف من بعض المشاكل التي واجهها حيث أصبحت الشبكة الأساسية أسرع. صُمِّمت هذه الإضافات ليكون لها تأثيرٌ ضئيل على بروتوكول TCP قدر الإمكان، حيث تُدرَك كخياراتٍ يمكن إضافتها إلى ترويسة TCP. (سبب احتواء ترويسة TCP على حقل HdrLen هو أن الترويسة يمكن أن تكون بطول متغير، يحتوي الجزء المتغير من ترويسة TCP على الخيارات المُضافة). أهمية إضافة هذه الإضافات كخيارات بدلًا من تغيير جوهر ترويسة TCP هو أن المضيفين لا يزالون قادرين على التواصل باستخدام TCP حتى لو لم يقوموا بتطبيق الخيارات، ولكن يمكن للمضيفين الذين يقومون بتطبيق الإضافات الاختيارية الاستفادة منها. يتفق الجانبان على استخدام الخيارات أثناء مرحلة إنشاء اتصال TCP. تساعد الإضافة الأولى على تحسين آلية ضبط مهلة TCP الزمنية. يمكن لبروتوكول TCP قراءة ساعة النظام الفعلية عندما يكون على وشك إرسال جزء بدلًا من قياس RTT باستخدام حدث قاسٍ coarse-grained، ووضع هذا الوقت (فكر به على أنه علامة زمنية timestamp مؤلفة من 32 بتًا) في ترويسة الجزء، ثم يُرجِع echoes المستقبل هذه العلامة الزمنية مرةً أخرى إلى المرسل في إشعاره، ويطرح المرسل هذه العلامة الزمنية من الوقت الحالي لقياس وقت RTT. يوفر خيار العلامة الزمنية مكانًا مناسبًا لبروتوكول TCP لتخزين سجل وقت إرسال جزء، أي يخزن الوقت في الجزء نفسه. لاحظ أن نقاط النهاية في الاتصال لا تحتاج إلى ساعات متزامنة، حيث تُكتَب العلامة الزمنية وتُقرَأ في نهاية الاتصال نفسها. تعالج الإضافة الثانية مشكلة التفاف wrapping around حقل SequenceNum المكون من 32 بت لبروتوكول TCP في وقت قريب جدًا على شبكة عالية السرعة. يستخدم بروتوكول TCP العلامة الزمنية المؤلفة من 32 بتًا الموصوفة للتو لتوسيع حيز الأرقام التسلسلية بفعالية بدلاً من تحديد حقل رقم تسلسلي جديد مؤلف من 64 بتًا. أي يقرر بروتوكول TCP قبول أو رفض جزء بناءً على معرّف بطول 64 بت يحتوي على حقل SequenceNum بترتيب 32 بت المنخفض والعلامة الزمنية بترتيب 32 بت العالي. بما أن العلامة الزمنية تتزايد دائمًا، فإنها تعمل على التمييز بين تجسبدَين مختلفين لنفس الرقم التسلسلي. لاحظ استخدام العلامة الزمنية في هذا الإعداد فقط للحماية من الالتفاف، حيث لا يُتعامَل معها كجزء من الرقم التسلسلي لغرض طلب البيانات أو الإشعار بوصولها. تسمح الإضافة الثالثة لبروتوكول TCP بالإعلان عن نافذةٍ أكبر، مما يسمح له بملء الأنابيب ذات جداء (التأخير × حيز النطاق التراسلي) الأكبر والتي تتيحها الشبكات عالية السرعة. تتضمن هذه الإضافة خيارًا يحدد عامل توسيع scaling factor للنافذة المعلن عنها. أي يسمح هذا الخيار لطرفي TCP بالاتفاق على أن حقل AdvertisedWindow يحسب أجزاءًا أكبر (عدد وحدات البيانات ذات 16 بايت الممكن عدم الإقرار بها من قبل المرسل على سبيل المثال) بدلًا من تفسير الرقم الذي يظهر في حقل AdvertisedWindow على أنه يشير إلى عدد البايتات المسموح للمرسل بعدم الإقرار بها. يحدد خيار توسيع النافذة عدد البتات التي يجب على كل جانبٍ إزاحة حقل AdvertisedWindow بها لليسار قبل استخدام محتوياته لحساب نافذة فعالة. تسمح الإضافة الرابعة لبروتوكول TCP بتوفير إشعاره التراكمي cumulative acknowledgment مع الإشعارات الانتقائية selective acknowledgments لأية أجزاءٍ إضافية جرى استلامها ولكنها ليست متجاورة مع جميع الأجزاء المُستلمة مسبقًا، وهذا هو خيار الإشعار الانتقائي أو SACK. يستمر جهاز الاستقبال بالإقرار أو الإشعار عن الأجزاء بشكلٍ طبيعي عند استخدام خيار SACK، أي لا يتغير معنى حقل Acknowledge، ولكنه يستخدم أيضًا حقولًا اختيارية في الترويسة لإرسال إشعارات وصول أي كتلٍ إضافية من البيانات المستلمة. يتيح ذلك للمرسل إعادة إرسال الأجزاء المفقودة فقط وفقًا للإشعار الانتقائي. هناك استراتيجيتان مقبولتان فقط للمرسل بدون SACK. تستجيب الاستراتيجية المتشائمة pessimistic لانتهاء المهلة بإعادة إرسال الجزء المنتهية مهلته، وكذلك أي أجزاء سترسَل لاحقًا أيضًا، وتفترض الإستراتيجية المتشائمة الأسوأ والذي هو فقد كل تلك الأجزاء. عيب الاستراتيجية المتشائمة هو أنها قد تعيد إرسال الأجزاء المُستلمة بنجاح في المرة الأولى دون داعٍ. الإستراتيجية الأخرى هي الإستراتيجية المتفائلة optimistic، والتي تستجيب لانتهاء المهلة بإعادة إرسال الجزء المنتهية مهلته فقط. يفترض النهج المتفائل السيناريو الأكثر تفاؤلًا والذي هو فقد جزء segment واحد فقط. عيب الإستراتيجية المتفائلة أنها بطيئة للغاية دون داعٍ، عندما تضيع سلسلة من الأجزاء المتتالية، كما يحدث عندما يكون هناك ازدحام. كما أنها بطيئة نظرًا لعدم القدرة على اكتشاف خسارة كل جزءٍ حتى يتلقى المرسل ACK لإعادة إرسال الجزء السابق، لذلك فهي تستهلك وقت RTT واحدًا لكل جزءٍ حتى يعيد إرسال جميع الأجزاء في السلسلة المفقودة. تتوفر استراتيجية أفضل للمرسل مع خيار SACK وهي: أعد إرسال الأجزاء التي تملأ الفجوات بين الأجزاء التي جرى الإقرار بها انتقائيًا. بالمناسبة، لا تمثّل هذه الإضافات القصة الكاملة. حيث سنرى بعض الإضافات الأخرى عندما ننظر في كيفية تعامل بروتوكول TCP مع الازدحام. تتعقب هيئة تخصيص أرقام الإنترنت Internet Assigned Numbers Authority أو اختصارًا IANA جميع الخيارات المحددة لبروتوكول TCP (إضافةً للعديد من بروتوكولات الإنترنت الأخرى). الأداء Performance تذكر أن في بداية السلسلة قد قدّم المقياسين الكميّين اللذين يجري من خلالِهما تقييم أداء الشبكة وهما: زمن الاستجابة latency والإنتاجية throughput. لا تتأثر هذه المقاييس فقط بالعتاد الأساسي، مثل تأخير الانتشار propagation delay وحيز نطاق الرابط التراسلي link bandwidth، كما هو مذكور في تلك المناقشة، ولكن تتأثر أيضًا بتكاليف البرمجيات الزائدة. يمكننا مناقشة كيفية قياس أداء البروتوكول القائم على البرمجيات بشكل هادف الآن بعد أن أصبح متاحًا لنا رسمًا بيانيًا كاملًا له متضمنًا بروتوكولات نقل بديلة. تكمن أهمية هذه القياسات في أنها تمثل الأداء الذي تراه برامج التطبيق. نبدأ، كما ينبغي لأي تقرير لنتائج التجارب، بوصف طريقتنا التجريبية. وهذا يشمل الجهاز المستخدم في التجارب، حيث تحتوي كل محطة عمل على زوج من معالجات Xeon لوحدة المعالجة المركزية بتردد 2.4 جيجاهرتز والتي تعمل بنظام لينوكس في هذه الحالة. يجري استخدام زوج من محوّلات إيثرنت، المسمَّى NIC بطاقة واجهة الشبكة network interface card، على كل جهاز لتمكين سرعات أعلى من 1 جيجابت في الثانية. يمتد الإيثرنت على غرفة جهاز واحدة لذا لا يمثل الانتشار مشكلة، مما يجعل هذا مقياسًا لتكاليف المعالجات / البرمجيات الزائدة. يحاول برنامجُ الاختبار الذي يعمل أعلى واجهة المقبس ببساطة نقلَ البيانات بأسرع ما يمكن من جهازٍ إلى آخر، ويوضح الشكل السابق هذا الإعداد. قد تلاحظ أن هذا الإعداد التجريبي لا يمثل ميزة خاصة من حيث العتاد أو سرعة الروابط. لا يتمثل الهدف من هذا القسم في إظهار مدى سرعة تشغيل بروتوكول معين، ولكن لتوضيح المنهجية العامة لقياس أداء البروتوكول والإبلاغ عنه. يجري اختبار الإنتاجية لمجموعة متنوعة من أحجام الرسائل باستخدام أداة قياس معيارية تسمى TTCP. يوضح الشكل التالي نتائج اختبار الإنتاجية. الشيء الرئيسي الواجب ملاحظته في هذا الرسم البياني هو أن معدل النقل يتحسن مع زيادة حجم الرسائل. وهذا أمرٌ منطقي، حيث تتضمن كل رسالة قدرًا معينًا من الحِمل الزائد، لذا فإن الرسالة الأكبر تعني أن هذا الحِمل يُستهلَك على عددٍ أكبر من البايتات. يُسطَّح منحني سرعة النقل الأعلى من 1 كيلوبايت، وعند هذه النقطة يصبح الحِمل لكل رسالة غير مهم عند مقارنته بالعدد الكبير من البايتات التي يتعين على مكدّس البروتوكول معالجتها. تجدر الإشارة إلى أن الحد الأقصى للإنتاجية أقل من 2 جيجابت في الثانية، وهي سرعة الرابط المتاحة في هذا الإعداد. ستكون هناك حاجة لمزيد من الاختبار وتحليل النتائج لمعرفة مكان الاختناق أو معرفة إذا كان هناك أكثر من عنق زجاجة أو اختناق bottleneck. قد يعطي النظر إلى حِمل وحدة المعالجة المركزية مؤشرًا على ما إذا كانت وحدة المعالجة المركزية هي مكان الاختناق أم أن اللوم يقع على حيز النطاق التراسلي للذاكرة أو أداء محوّل adaptor الشبكة أو بعض المشكلات الأخرى. نلاحظ أيضًا أن الشبكة في هذا الاختبار "مثالية" بصورةٍ أساسية. لا يوجد أي تأخير أو خسارة تقريبًا، وبالتالي فإن العوامل الوحيدة التي تؤثر على الأداء هي تطبيق بروتوكول TCP إضافةً إلى عتاد وبرمجيات محطة العمل. ولكن نتعامل في معظم الأوقات مع شبكاتٍ بعيدة عن الكمال، ولا سيما روابطنا المقيدة بحيّز النطاق التراسلي وروابط الميل الأخير والروابط اللاسلكية المعرّضة للضياع. نحتاج إلى فهم كيفية تعامل بروتوكول TCP مع الازدحام قبل أن نقّدر تمامًا كيف تؤثر هذه الروابط على أداء TCP. هدّدت سرعة روابط الشبكة المتزايدة بشكل مطرد بالتقدم على ما يمكن تسليمه إلى التطبيقات في أوقات مختلفة من تاريخ الشبكات. بدأ جهد بحثي كبير في الولايات المتحدة في عام 1989 لبناء "شبكات جيجابت gigabit networks" على سبيل المثال، حيث لم يكن الهدف فقط بناء روابط ومبدلات يمكن تشغيلها بسرعة 1 جيجابت في الثانية أو أعلى، ولكن أيضًا لإيصال هذه الإنتاجية على طول الطريق إلى عملية تطبيقٍ واحدة. كانت هناك بعض المشكلات الحقيقية (كان لابد من تصميم محولات شبكة، وبنيات محطات عمل، وأنظمة تشغيل مع مراعاة إنتاجية النقل من شبكة إلى تطبيق على سبيل المثال) وكذلك بعض المشكلات المُدرَكة التي تبين أنها ليست خطيرة للغاية. وكان على رأس قائمة مثل هذه المشاكل القلقُ من أن بروتوكولات النقل الحالية، وخاصةً بروتوكول TCP، قد لا تكون على مستوى التحدي المتمثل في عمليات الجيجابت. كما اتضح، كان أداء بروتوكول TCP جيدًا في مواكبة الطلبات المتزايدة للشبكات والتطبيقات عالية السرعة. أحد أهم العوامل هو إدخال توسيع النافذة للتعامل مع منتجات تأخير حيز النطاق التراسلي الأكبر، ولكن غالبًا ما يكون هناك فرقٌ كبير بين الأداء النظري لبروتوكول TCP وما يجري تحقيقه عمليًا. يمكن أن تؤدي المشكلات البسيطة نسبيًا مثل نسخ البيانات مرات أكثر من اللازم أثناء انتقالها من محول الشبكة إلى التطبيق إلى انخفاض الأداء، كما يمكن أن تؤدي ذاكرة التخزين المؤقت غير الكافية إلى انخفاض الأداء عندما يكون منتج تأخير حيز النطاق التراسلي كبيرًا. وديناميكيات TCP معقدة بدرجة كافية، بحيث يمكن للتفاعلات الدقيقة بين سلوك الشبكة وسلوك التطبيق وبروتوكول TCP نفسه تغيير الأداء بصورةٍ كبيرة. من الجدير بالذكر أن بروتوكول TCP يستمر في الأداء الجيد مع زيادة سرعات الشبكة، ويندفع الباحثون لإيجاد حلول عند حدوث تعارض مع بعض القيود (المرتبطة عادةً بالازدحام أو زيادة منتجات تأخير حيز النطاق التراسلي أو كليهما). خيارات التصميم البديلة SCTP وQUIC على الرغم من أن بروتوكول TCP قد أثبت أنه بروتوكول قوي يلبي احتياجات مجموعة واسعة من التطبيقات، إلا أن مساحة تصميم بروتوكولات النقل كبيرة جدًا. ليس بروتوكول TCP بأي حالٍ النقطة الصالحة الوحيدة في مساحة التصميم هذه. نختم مناقشتنا لبروتوكول TCP من خلال النظر في خيارات التصميم البديلة. بينما نقدم شرحًا حول سبب اتخاذ مصممي TCP الخيارات التي قاموا بها، فإننا نلاحظ وجود بروتوكولات أخرى اتخذت خيارات أخرى، وقد يظهر المزيد من هذه البروتوكولات في المستقبل. هناك صنفان على الأقل من بروتوكولات النقل: البروتوكولات الموجَّهة بالتدفق stream-oriented protocols مثل بروتوكول TCP وبروتوكولات الطلب / الرد request/reply protocols مثل بروتوكول RPC. قسمنا مساحة التصميم ضمنيًا إلى نصفين ووضعنا بروتوكول TCP مباشرةً في نصف عالم البروتوكولات الموجَّهة بالتدفق. يمكننا أيضًا تقسيم البروتوكولات الموجهة بالتدفق إلى مجموعتين، موثوقة reliable وغير موثوقة unreliable، مع احتواء الأولى على بروتوكول TCP والأخيرة أكثر ملاءمة لتطبيقات الفيديو التفاعلية التي تفضل إسقاط أو إهمال إطار بدلًا من تحمّل التأخير المرتبط بإعادة الإرسال. يُعَد بناء تصنيف لبروتوكول النقل أمرًا مثيرًا للاهتمام ويمكن مواصلته بتفاصيل أكثر، ولكن العالم ليس أبيض وأسود كما قد نحب. افترض ملاءمة بروتوكول TCP كبروتوكول نقل لتطبيقات الطلب / الرد على سبيل المثال. بروتوكول TCP هو بروتوكول ثنائي الاتجاه، لذلك سيكون من السهل فتح اتصال TCP بين العميل والخادم، وإرسال رسالة الطلب في اتجاه واحد، وإرسال رسالة الرد في الاتجاه الآخر، ولكن هناك نوعان من التعقيدات. الأول هو أن بروتوكول TCP هو بروتوكول موجَّهٌ بالبايت وليس بروتوكول موجَّه بالرسائل، وأن تطبيقات الطلب / الرد تتعامل دائمًا مع الرسائل. (سنكتشف مسألة البايتات مقابل الرسائل بتفصيل أكبر بعد قليل). التعقيد الثاني هو أنه في تلك المواقف التي تتلاءم فيها كل من رسالة الطلب ورسالة الرد في رزمة شبكة واحدة، يحتاج بروتوكول الطلب / الرد المصمم جيدًا رزمتان فقط لتطبيق التبادل، بينما يحتاج بروتوكول TCP إلى تسع رزم على الأقل: ثلاث لتأسيس الاتصال، واثنان لتبادل الرسائل، وأربع لإنهاء الاتصال. إذا كانت رسائل الطلب أو الرد كبيرة بما يكفي لأن تتطلب رزم شبكةٍ متعددة (قد يستغرق الأمر 100 رزمة لإرسال إستجابة بحجم 100000 بايت على سبيل المثال)، ستكون التكاليف الزائدة لإعداد الاتصال وإلغائه غير منطقية. ليس الأمر دائمًا أن بروتوكولًا معينًا لا يمكنه دعم وظيفةٍ معينة، ففي بعض الأحيان يكون هناك تصميم أكثر كفاءة من تصميم آخر في ظل ظروف معينة. ثانيًا، قد تتساءل عن سبب اختيار TCP لتقديم خدمة تدفق بايتات موثوقة بدلًا من خدمة تدفق رسائل موثوقة، حيث تُعتبر الرسائل الخيار الطبيعي لتطبيق قاعدة البيانات الذي يريد تبادل السجلات. هناك إجابتان على هذا السؤال: الأول هو أن البروتوكول الموجَّه بالرسائل يجب أن ينشئ حدًا أعلى لأحجام الرسائل، فالرسالة الطويلة التي بلا حدود هي تدفق بايتات. ستكون هناك تطبيقات تريد إرسال رسائل أكبر بالنسبة إلى أي حجم رسالة يحدده البروتوكول، مما يجعل بروتوكول النقل عديم الفائدة ويجبر التطبيق على تنفيذ خدماته الشبيهة بالنقل. السبب الثاني هو أنه على الرغم من أن البروتوكولات الموجهة بالرسائل هي بالتأكيد أكثر ملاءمة للتطبيقات التي ترغب في إرسال السجلات إلى بعضها البعض، إلا أنه يمكنك بسهولة إدخال حدود السجل في تدفق البايتات لتطبيق هذه الوظيفة. القرار الثالث الذي اُتخِذ في تصميم TCP هو أنه يسلّم البايتات بناءً على التطبيق. هذا يعني أنه قد يحتفظ بالبايتات التي استلمها مخالفةً للترتيب من الشبكة، في انتظار بعض البايتات المفقودة لملء ثغرة. هذا مفيد للغاية للعديد من التطبيقات ولكن تبين أنه غير مفيد تمامًا إذا كان التطبيق قادرًا على معالجة البيانات المخالفة للترتيب. فلا تحتاج صفحة الويب مثلًا التي تحتوي على كائنات متعددة مضمَّنة إلى تسليم جميع الكائنات بالترتيب قبل البدء في عرض الصفحة. هناك صنف من التطبيقات يفضِّل التعامل مع البيانات المخالفة للترتيب في طبقة التطبيق، مقابل الحصول على البيانات في وقت أقرب عند إسقاط الرزم أو سوء ترتيبها داخل الشبكة. أدت الرغبة في دعم مثل هذه التطبيقات إلى إنشاء بروتوكولي نقل معياريين من IETF. كان أولها بروتوكول SCTP، بروتوكول نقل التحكم في التدفق Stream Control Transmission Protocol. يوفر بروتوكول SCTP خدمة توصيل مُرتَّبة جزئيًا، بدلًا من خدمة TCP المُرتَّبة بدقة. (يتخذ بروتوكول SCTP أيضًا بعض قرارات التصميم الأخرى التي تختلف عن بروتوكول TCP، بما في ذلك اتجاه الرسالة ودعم عناوين IP المتعددة لجلسة واحدة). وحّدت منظمة IETF في الآونة الأخيرة بروتوكولًا محسَّنًا لحركة مرور الويب، يُعرف باسم QUIC. رابعًا، اختار بروتوكول TCP تطبيق مراحل إعداد / تفكيك صريحة، لكن هذا ليس مطلوبًا، حيث سيكون من الممكن إرسال جميع معاملات الاتصال الضرورية مع رسالة البيانات الأولى في حالة إعداد الاتصال. اختار TCP اتباع نهجٍ أكثر تحفظًا يمنح المتلقي الفرصة لرفض الاتصال قبل وصول أي بيانات. يمكننا إغلاق الاتصال الذي كان غير نشط لفترة طويلة من الزمن بهدوء في حالة التفكيك، ولكن هذا من شأنه أن يعقّد تطبيقات مثل تسجيل الدخول عن بُعد الذي يريد الحفاظ على الاتصال نشطًا لأسابيع في كل مرة، حيث ستُجبَر هذه التطبيقات على إرسال رسائل "keep alive" خارج النطاق للحفاظ على حالة الاتصال عند الطرف الآخر من الاختفاء. أخيرًا، بروتوكول TCP هو بروتوكول قائم على النافذة window-based، لكن هذا ليس الاحتمال الوحيد. البديل هو التصميم القائم على المعدَّل rate-based design، حيث يخبر المستلمُ المرسلَ بالمعدّل (معبرًا عنه إما بالبايتات أو بالرزم في الثانية) الذي يكون على استعداد لقبول البيانات الواردة إليه، فقد يخبر المتلقي المرسل على سبيل المثال أنه يستطيع استيعاب 100 رزمة في الثانية. هناك ازدواجية مثيرة للاهتمام بين النوافذ والمعدَّل، حيث أن عدد الرزم (البايتات) في النافذة، مقسومًا على RTT، هو المعدل بالضبط. يشير حجم النافذة المكوَّن من 10 رزم و 100 ميلي ثانية RTT على سبيل المثال إلى أنه يُسمح للمرسل بالإرسال بمعدل 100 رزمة في الثانية. يرفع جهاز الاستقبال أو يخفض المعدل الذي يمكن للمرسل الإرسال به بفعالية من خلال زيادة أو تقليل حجم النافذة المعلن عنها. تُرَد هذه المعلومات مرةً أخرى إلى المرسل في حقل AdvertisedWindow من إشعار ACK كل جزء في بروتوكول TCP. تتمثل إحدى المشكلات الرئيسية في البروتوكول المستند إلى المعدل في عدد المرات التي يُرحَّل فيها المعدل المطلوب (والذي قد يتغير بمرور الوقت) إلى المصدر: هل هو لكل رزمة أم مرة واحدة لكل RTT أم عندما يتغير المعدل فقط؟ على الرغم من أننا قد ناقشنا للتو النافذة مقابل المعدل في سياق التحكم في التدفق، إلا أنها قضية متنازع عليها بشدة في سياق التحكم في الازدحام، والتي ستُناقش لاحقًا. بروتوكول QUIC أُنشِئ بروتوكول اتصالات إنترنت بروتوكول UDP السريعة Quick UDP Internet Connections أواختصارًا QUIC في Google في عام 2012، ولا يزال يخضع للتوحيد القياسي standardization في منظمة IETF في وقت كتابة هذا الكتاب، ولقد شهد بالفعل قدرًا معتدلًا من النشر (في بعض متصفحات الويب وعدد كبير من مواقع الويب الشائعة). حقيقة أنه كان ناجحًا إلى هذه الدرجة هي في حد ذاتها جزءٌ مثير للاهتمام من قصة QUIC، وكانت قابلية النشر التزامًا رئيسيًا لمصممي البروتوكول. يأتي الدافع وراء بروتوكول QUIC مباشرةً من النقاط التي أشرنا إليها أعلاه حول بروتوكول TCP: لقد تبين أن بعض قرارات التصميم غير مثالية لمجموعة من التطبيقات التي تعمل عبر بروتوكول TCP، كحركة مرور بروتوكول HTTP (الويب). أصبحت هذه المشكلات أوضح بمرور الوقت، نظرًا لعوامل مثل ظهور الشبكات اللاسلكية ذات زمن الاستجابة العالي، وتوافر شبكات متعددة لجهاز واحد (شبكة Wi-Fi والشبكة الخلوية على سبيل المثال)، والاستخدام المتزايد للتشفير واستيثاق الاتصالات على الويب. تستحق بعض قرارات تصميم بروتوكول QUIC الرئيسية المناقشة في حين أن وصفه الكامل خارج نطاقنا. إذا كان وقت استجابة الشبكة مرتفعًا (من رتبة مئات الميلي ثانية) فيمكن أن تزيد بسرعة بعض فترات RTT إزعاجًا واضحًا للمستخدم النهائي. يستغرق عادةً إنشاء جلسة HTTP عبر بروتوكول TCP مع تأمين طبقة النقل ثلاث رحلاتٍ ذهابًا وإيابًا (واحدة لتأسيس جلسة TCP واثنتان لإعداد معاملات التشفير) قبل إرسال رسالة HTTP الأولى. أدرك مصممو QUIC أنه يمكن تقليل هذا التأخير (وهو النتيجة المباشرة لنهج متعدد الطبقات لتصميم البروتوكول) بصورةٍ كبيرة إذا دُمِج إعداد الاتصال ومصافحات الأمان المطلوبة وحُسِّن لأدنى حد من وقت الذهاب والإياب. لاحظ أيضًا كيف قد يؤثر وجود واجهات متعددة للشبكة على التصميم. إذا فقد هاتفك المحمول اتصال Wi-Fi وتحتاج إلى التبديل إلى اتصال خلوي، سيتطلب ذلك عادةً مهلة TCP على اتصالٍ واحد وسلسلة جديدة من المصافحات على الاتصال الآخر. كان جعل الاتصال شيئًا يمكنه الاستمرار عبر اتصالات طبقة الشبكة المختلفة هدفًا تصميميًا آخر لبروتوكول QUIC. أخيرًا، يُعد نموذج تدفق البايتات الموثوق لبروتوكول TCP تطابقًا ضعيفًا مع طلب صفحة الويب، عند الحاجة إلى جلب العديد من الكائنات ويمكن البدء بعرض الصفحة قبل وصولها جميعًا. أحد الحلول لذلك هو فتح اتصالات TCP متعددة على التوازي، ولكن هذا الأسلوب (الذي اُستخدِم في الأيام الأولى للويب) له مجموعة من العيوب الخاصة به، لا سيما فيما يتعلق بالتحكم في الازدحام. ومن المثير للاهتمام أنه جرى اتخاذ العديد من قرارات التصميم التي شكّلت تحدياتٍ لنشر بروتوكول نقل جديد بحلول الوقت الذي ظهر فيه QUIC. والجدير بالذكر أن العديد من "الصناديق المتوسطة middleboxes" مثل الجدران النارية firewalls وNAT لديها فهم كافٍ لبروتوكولات النقل المنتشرة على نطاق واسع (TCP وUDP) بحيث لا يمكن الاعتماد عليها لتمرير بروتوكول نقل جديد. ونتيجة لذلك يتواجد بروتوكول QUIC في الواقع فوق بروتوكول UDP، أي أنه بروتوكول نقلٍ يعمل فوق بروتوكول نقل. يطبّق بروتوكول QUIC إنشاء اتصالٍ سريع مع التشفير والاستيثاق authentication في أول RTT، ويفضّل توفير معرّف اتصال على استمراره عبر التغييرات في الشبكة الأساسية. وهو يدعم تعدد إرسال عدة تدفقات على اتصال نقل واحد، لتجنب توقف رأس الخط الذي قد ينشأ عند إسقاط رزمةٍ واحدة بينما يستمر وصول البيانات المفيدة الأخرى. ويحافظ على خصائص تجنب الازدحام لبروتوكول TCP. بروتوكول QUIC هو التطور الأكثر إثارة للاهتمام في عالم بروتوكولات النقل. العديد من قيود بروتوكول TCP معروفةٌ منذ عقود، ولكن يمثّل بروتوكول QUIC واحدًا من أنحج الجهود حتى الآن للتركيز على نقطة مختلفة في مساحة التصميم. ويقدم دراسة حالة رائعة في النتائج غير المتوقعة للتصميمات متعددة الطبقات وفي تطور الإنترنت، نظرًا لأنه مستوحى من تجربة بروتوكول HTTP والويب، والتي نشأت بعد فترة طويلة من تأسيس بروتوكول TCP بشكل جيد في الإنترنت. بروتوكول TCP متعدد المسارات Multipath TCP ليس من الضروري دائمًا تحديد بروتوكول جديد إذا وجدت أن البروتوكول الحالي لا يخدم حالة استخدام معينة بشكل كافٍ. من الممكن في بعض الأحيان إجراء تغييرات جوهرية في كيفية تطبيق بروتوكول موجود، ولكن تظل وفية للمواصفات الأصلية. يعد بروتوكول Multipath TCP مثالًا على مثل هذه الحالة. تتمثل فكرة Multipath TCP في توجيه الرزم خلال مسارات متعددة عبر الإنترنت، باستخدام عنوانَي IP مختلفين لإحدى نقاط النهاية على سبيل المثال. يمكن أن يكون هذا مفيدًا بشكل خاص عند تسليم البيانات إلى جهازٍ محمول متصل بكل من شبكة Wi-Fi والشبكة الخلوية (وبالتالي يملك عنوانين IP فريدين). يمكن أن تواجه فقدانًا كبيرًا في الرزمة نظرًا لكون كلتا الشبكتين لاسلكيتين، لذا فإن القدرة على استخدامهما لحمل الرزم يمكن أن تحسّن تجربة المستخدم بصورة كبيرة. الحل هو أن يعيد الجانب المستلم من TCP بناء تدفق البايتات الأصلي بالترتيب قبل تمرير البيانات إلى التطبيق، والذي يظل غير مدرك أنه يجلس على بروتوكول Multipath TCP. (وهذا على عكس التطبيقات التي تفتح عمدًا اتصالين أو أكثر من اتصالات TCP للحصول على أداء أفضل). يبدو بروتوكول Multipath TCP بسيطًا، ولكنه من الصعب للغاية الحصول عليه بصورةٍ صحيحة لأنه يكسر العديد من الافتراضات حول كيفية تطبيق التحكم في تدفق TCP، وإعادة تجميع الجزء segment بالترتيب، والتحكم في الازدحام. نتركه كتمرينٍ لك لاستكشاف التفاصيل الدقيقة، حيث يُعد القيام بذلك طريقةً رائعة للتأكد من أن فهمك الأساسي لبروتوكول TCP سليم. ترجمة -وبتصرّف- للقسم Reliable Byte Stream من فصل ProtocolsEnd-to-End من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبيةالمقال السابق: تأسيس الشبكات الحاسوبية والتعرف على تطبيقاتها البرمجيات المستخدمة في بناء الشبكات الحاسوبية التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية دليل بصري لكيفية استخدام أنفاق SSH

سننشئ في هذا المقال لافتة نيون بسيطة، حيث سنطبّق طريقةً بسيطة جدًا لإنشاء هذا التأثير، لكن يوصى باستخدام إما برنامج إنكسكيب Inkscape أو جيمب GIMP (أو مزيج من الاثنين معًا) للحصول على نتائج أكثر احترافية. التقنيات المحددة المستخدمة إنشاء ألوان جديدة. تحويل النص إلى مخططات تفصيلية Outlines. إنشاء وإدارة الطبقات. إنشاء نمط خط جديد وتطبيقه على شكل. تحويل Transforming الشكل عن طريق إعادة التحجيم Re-scaling. استخدام تعتيم Opacity الطبقة. يمكن لأي شخص لديه فهم جيد لأساسيات سكريبوس تطبيق هذه الخطوات بسهولة. الإعداد الخط Font ستحتاج إلى الخط Dosis Bold الذي يمكنك تنزيله مجانًا، فإذا استخدمت الخط Dosis Bold، فستجد أن الخط المستدير ذو السماكة المتوسطة أفضل. ستميل بعض الخطوط السميكة إلى إفساد التأثير، وتسبب الخطوط الرفيعة أيضًا إفساد الأشياء ولكن بطريقة مختلفة، كما تميل الخطوط ذات الزوايا إلى أن تبدو غريبةً بعض الشيء، لكن لا تتردد في تجربتها ومشاهدة الفرق. الألوان افتح برنامج سكريبوس وأنشئ مستندًا فارغًا جديدًا (استخدم القياس A4 Portrait). ستحتاج أولًا إلى إعداد ألوان اللافتة. يجب أن يكون لديك بالفعل اللونان الأبيض والأسود في لافتتك ولكننا سنحتاج إلى ثلاثة ألوان أخرى. اختر قائمة تحرير Edit ثم الألوان والتعبئة Colors. اضغط على جديد New أو إضافة. أدخل اسم اللون "Neon Red 1". حدّد "CMYK" نمطًا للألوان. اضبط قيم CMYK على النحو التالي: C 0% وM 50% وY 12% وK 0%. اضغط على "موافق OK" لإنشاء اللون الجديد. كرّر ما سبق للون "Neon Red 2" الذي قيمه هي: C 0% وM 68% وY 25% وK 0%، واللون "Neon Red 3" الذي قيمه هي: C 0% وM 95% وY 83% وK 0%. اضغط على موافق OK عند إنشاء الألوان الثلاثة الجديدة. يوضّح الشكل التالي كل الألوان التي ستحتاج إليها: الخلفية يجب الآن رسم خلفية داكنة، وهنا سنستخدم اللون الأسود الكلاسيكي، ولكن يمكنك استخدام اللون الذي تريده. اختر قائمة إدراج Insert ثم شكّل Insert Shape، ثم أشكال افتراضية Default Shapes، ثم مستطيل Rectangle. ارسم مستطيلًا من أعلى يسار الصفحة إلى منتصف الجانب الأيمن. اذهب إلى نافذة خصائص Properties ثم اختر تبويب "ألوان ‎"Colors واجعل لون التعبئة أسود. النص الأساسي أنشئ إطار نص بعرض الصفحة وحوالي ربع ارتفاع الصفحة تحت المستطيل الأسود حتى تتمكن من رؤية ما تفعله، وهذا يضمن أن الإطار كبير بما يكفي ليناسب النص الكبير. انقر نقرًا مزدوجًا على إطار النص وأدخِل كلمة "NEON" (بدون علامات الاقتباس) في الإطار. انقر في مكان ما خارج إطار النص ثم أعد تحديده. انتقل إلى نافذة خصائص Properties ثم اختر تبويب نص Text، أو من نافذة خصائص المحتوى، ثم اختر نص Text في الإصدار 1.5.7 من برنامج سكريبوس. بعد ذلك حدّد الخط "Dosis Bold" أو أيًا كان الخط الذي تستخدمه. اضبط حجم الخط على القيمة 140 نقطة أو أي حجم تريده، ولكن اجعله كبيرًا جدًا. تحويل النص اختر قائمة عنصر ثم تحويل لـ Convert To، ثم مخططات تفصيلية Outlines. أعد تحديد النص واختر قائمة عنصر ثم التجميع، ثم اختر فك التجميع Ungroup. اختر قائمة عنصر ثم أدوات المسار، بعد ذلك اختر ادمج المضلعات Combine Polygons. بهذا يكون قد أصبح النص الآن شكلًا واحدًا ويمكن تعديله بسهولة، حيث يجب أن يكون لديك شيء يشبه الشكل التالي: إضافة طبقة جديدة اختر قائمة نوافذ Windows ثم الطبقات Layers. اضغط على أيقونة "+" (أسفل مربع الحوار) لإنشاء طبقة جديدة. انقر نقرًا مزدوجًا على اسم الطبقة الجديدة وأعد تسميتها بالاسم "Sign" (بدون علامات الاقتباس). انقر على طبقة "الخلفية Background" في مربع الحوار. حدّد النص المحوَّل. انقر بزر الفأرة الأيمن واختر القائمة "أرسل إلى الطبقة ‎"Send to Layer، ثم اختر Sign. انقر على طبقة "Sign" في نافذة Layers. وبذلك سيُنقَل النص الذي ستستخدمه إلى طبقة Sign (ستعرف الغرض من هذه الخطوة لاحقًا). تأثير النيون يجب الآن إنشاء التأثير الذي ستستخدمه لتشكيل تأثير النيون، لذلك سنستخدم نمط الخط Line Style. اختر قائمة تحرير Edit ثم أنماط Styles. اضغط على جديد New وحدد "نمط الخط Line Style" من القائمة. أعِد تسمية النمط باسم "Red Neon" أو أي شيء تريده، ولكن اجعله مناسبًا لغرضه. يجب بعد ذلك إنشاء الخطوط المختلفة التي ستشكل نمط خطك الجديد، وذلك باتباع الآتي: اضغط على أيقونة "+" (أسفل اسم النمط مباشرةً)، إذ سيؤدي ذلك إلى إنشاء خط جديد داخل النمط. اضغط على رمز "+" مرتين أيضًا حتى تتشكل لديك أربعة خطوط. انقر على أعلى خط. غيّر الخيار "حرف استهلالي مسطح Flat Cap" الموجود على يسار قائمة الخطوط، إلى "مستدير Round Cap". غيّر الخيار "وصلة مائلة Mitre Join" إلى "وصلة مستديرة Round Join". زِد عرض الخط إلى 9 نقاط، ولاحظ كيف يعيد برنامج سكريبوس ترتيب الخطوط. غيّر اللون إلى "Neon Red 3" وهو اللون الأحمر الداكن. بهذا تكون قد ضبطت أحد الخطوط، وتبقّى عليك أن تطبّق الخطوات نفسها على الخطوط الأخرى كالآتي: حدد الخط العلوي مرةً أخرى (إنه مختلف عن الخط الأخير الذي عدّلناه للتو). غيّر الحرف الاستهلالي Cap والوصلة Join إلى "مستدير Round". زِد العرض إلى 7 نقاط (أصغر قليلًا من الخط الأخير). غيّر اللون إلى "Neon Red 2" (ثاني أغمق لون). حدد الخط العلوي مرةً أخرى، وغيّر الحرف الاستهلالي والوصلة إلى "مستدير"، ثم زِد العرض إلى 5 نقاط، مع تغيير اللون إلى "Neon Red 1". حدّد الخط العلوي مرةً أخرى، وغيّر الحرف الاستهلالي والوصلة إلى "مستدير"، مع زيادة العرض إلى 3 نقاط، ثم غيّر اللون إلى "اللون الأبيض White". وبذلك تكون قد أنشأت نمط الخط الجديد الخاص بك كما يوضّح الشكل التالي: اضغط على "تطبيق Apply" ثم على "اكتمل Done"، ويمكنك أيضًا إغلاق مربع حوار مدير الأنماط Style Manager. بهذا يكون قد حان الوقت الآن لتطبيق نمط الخط الجديد على النص المحوَّل. تطبيق النمط حدد النص المحوَّل. حدّد نمط الخط الجديد "Red Neon" في تبويب خط Line من نافذة خصائص Properties. سيبدو كل شيء جيدًا حتى الآن، لكننا لم تنتهِ بعد، إذ عليك اتخاذ الخطوات الموالية: اضبط لون التعبئة على "لا شيء None" في تبويب ألوان Colours من نافذة Properties، فهذا يضمن أنه يمكنك استخدام النص فوق أي خلفية، وليس فقط فوق المستطيل الأسود الذي نستخدمه حاليًا. اسحب النص إلى منتصف المستطيل الأسود الذي تستخدمه خلفيةً. إذا تساءلت عن سبب ضبط الحروف الاستهلالية والوصلات على الخيار "مستدير Round" سابقًا، فلاحظ الفرق في الشكل التالي: الانعكاس Reflection افتح نافذة الطبقات Layers من قائمة نوافذ Windows. انقر على أيقونة "+" لإنشاء طبقة جديدة أخرى. انقر نقرًا مزدوجًا على اسم الطبقة الجديد وأعد تسميتها إلى "Reflection". لاحظ أن طبقة "Reflection" الجديدة فوق طبقة "Sign"، لكننا نريدها تحتها. حدّد طبقة "Reflection"، ثم اضغط على أيقونة "السهم للأسفل Down Arrow"، حيث سيؤدي ذلك إلى تحريك الطبقة الجديدة إلى أسفل أو خلف الطبقة التي عليها اللافتة sign. حدد الطبقة "Sign". حدّد النص واختر قائمة عنصر Item ثم مضاعفة/تحويل، بعد ذلك اختر نسخ مطابق Duplicate. حدّد النسخة الجديدة، ثم انقر بزر الفأرة الأيمن واختر الخيار أرسل إلى الطبقة Send to Layer، بعدها اختر طبقة "Reflection". حدّد الطبقة "Reflection". حدد النص المكرَّر. اختر قائمة عنصر ثم مضاعفة/تحويل ثم اختر تحويل Transform. اضغط على زر إضافة Add وحدّد الخيار "تحجيم Scaling" من القائمة. تأكد من أن رمز "الارتباط linked" في الجانب الأيسر من مربع الحوار كما في الشكل التالي مفعَّل، حيث تكون روابط السلسلة مرتبطةً ببعضها البعض. وإن لم يكن مفعَّلًا، فما عليك إلّا النقر عليه. أنقِص أيًا من عاملي التحجيم إلى القيمة 93%، وسيتغير العامل الآخر تلقائيًا أيضًا. انقر على موافق OK. اسحب يدويًا النص الأصغر خلف النص الأصلي مع توسيطه عموديًا، ولكن أعلى بقليل من النص الأصلي. سيبدو الأمر غريبًا بعض الشيء حاليًا، و لكن لا بأس فهناك خطوة أخرى. اضبط "عتمة Opacity" الطبقة Reflection على القيمة 50% في نافذة الطبقات. يجب أن تكون لافتتك مكتملةً الآن مع انعكاس زجاج غير مرئي، ولكن قد تحتاج إلى تحريك بعض الأشياء حتى تحصل على التأثير الذي يناسبك. هذا كل شيء، ولكن يمكنك تجربة خطوط وألوان مختلفة. مثال تطبيقي طبّق الخطوات التالية لتحصل على الشكل التالي: نزّل الصورة التي سنستخدمها خلفيةً في هذا المثال. سنستخدم الخط "Santa Fe LET". يجب تعديل تباعد الأحرف لتفادي تداخلها. أنشئ مجموعةً من الألوان الزرقاء للدائرة. تحتاج الدائرة إلى قدر كبير من التعديل، لهذا جرّب استخدام "عمليات المسار Path Operations" مثل القص باستخدام المستطيلات بدلًا من تعديل الدائرة مباشرةً. يجب تدوير كل النص بمقدار 10 درجات، أو يمكنك تدويره قبل تعديل الدائرة. ترجمة -وبتصرّف- للمقال How to create a neon sign. اقرأ أيضًا كيفية إنشاء التأثير Distressing Mask في برنامج سكريبوس لإنتاج تأثيرات تعبئة جذابة كيفية إنشاء أشكال معقدة ذات زوايا دائرية في برنامج سكريبوس Scribus كيفية إنشاء الظلال في برنامج سكريبوس Scribus خطوات تطوير شعار باستخدام برنامج سكريبوس Scribus

بروتوكول النقل الأعقد هو البروتوكول الذي يوفر خدمة تدفق بايتات موثوقة Reliable Byte Stream وموجهة نحو الاتصال، على عكس بروتوكول فك تعدد الإرسال demultiplexing البسيط كبروتوكول UDP. أثبتت هذه الخدمة أنها مفيدة لمجموعةٍ واسعة من التطبيقات لأنها تحرر التطبيق من القلق بشأن البيانات المفقودة أو المُعاد ترتيبها. ربما يكون بروتوكول التحكم في الإرسال Transmission Control Protocol عبر الإنترنت هو البروتوكول الأكثر استخدامًا من هذا النوع، كما أنه مضبوطٌ بعناية. لهذين السببين يدرس هذا القسم بروتوكول TCP بالتفصيل، على الرغم من أننا نحدد ونناقش خيارات التصميم البديلة في نهاية القسم. يضمن بروتوكول TCP التسليمَ الموثوق به والمرتّب لتدفقٍ من البايتات. إنه بروتوكول ثنائي الاتجاه full-duplex، مما يعني أن كل اتصال TCP يدعم زوجًا من تدفقات البايتات، حيث يتدفق كلٌّ منهما في اتجاه. يتضمن أيضًا آليةً للتحكم في التدفق لكل من تدفقات البايتات هذه التي تسمح للمستقبل بتحديد مقدار البيانات التي يمكن للمرسل إرسالها في وقتٍ معين. أخيرًا، يدعم بروتوكول TCP آلية فك تعدد الإرسال، مثل بروتوكول UDP، والتي تسمح لبرامج تطبيقات متعددة على أي مضيف معين بإجراء محادثة مع نظرائها في نفس الوقت. يطبّق بروتوكول TCP أيضًا، بالإضافة إلى الميزات المذكورة أعلاه، آلية التحكم في الازدحام عالية الضبط. تتمثل فكرة هذه الآلية في التحكم في مدى سرعة إرسال بروتوكول TCP للبيانات، ليس من أجل منع المرسل من الإفراط في تشغيل جهاز الاستقبال، ولكن من أجل منع المرسل من زيادة التحميل على الشبكة. يخلط العديد من الأشخاص بين التحكم في الازدحام congestion control والتحكم في التدفق flow control، لذلك سنعيد صياغة الفرق. يتضمن التحكم في التدفق منع المرسلين من تجاوز سعة أجهزة الاستقبال، بينما يتضمّن التحكم في الازدحام منع حقن الكثير من البيانات في الشبكة، مما يتسبب في زيادة تحميل المبدّلات switches أو الروابط links. وبالتالي فإن التحكم في التدفق هو مشكلة شاملة، بينما يهتم التحكم في الازدحام بكيفية تفاعل المضيفين والشبكات. قضايا طرف إلى طرف End-to-End Issues يوجد في صميم بروتوكول TCP خوارزمية النافذة المنزلقة sliding window. على الرغم من كونها نفس الخوارزمية الأساسية المُستخدمة غالبًا على مستوى الروابط، نظرًا لأن بروتوكول TCP يعمل عبر طبقة الإنترنت بدلًا من الرابط الفيزيائي نقطة لنقطة، إلا أنّ هناك العديد من الاختلافات المهمة. يحدد هذا القسم الفرعي هذه الاختلافات ويشرح كيف تعقّد بروتوكول TCP، ثم تصف الأقسام الفرعية التالية كيف يعالج بروتوكول TCP هذه التعقيدات وغيرها. أولًا، بينما تعمل خوارزمية النافذة المنزلقة على مستوى الروابط المقدمة عبر رابطٍ فيزيائي واحد يربط دائمًا نفس جهازي الحاسوب، فيدعم بروتوكول TCP الاتصالات المنطقية بين العمليات التي تعمل على أي جهازَي حاسوب على شبكة الإنترنت. هذا يعني أن بروتوكول TCP يحتاج إلى مرحلة تأسيس اتصال صريحة يتفق خلالها طرفا الاتصال على تبادل البيانات مع بعضهما بعضًا. يماثل هذا الاختلاف الاضطرار إلى الاتصال dial up بالطرف الآخر، بدلًا من امتلاك خط هاتف مخصَّص dedicated phone line. ويحتوي بروتوكول TCP أيضًا على مرحلة تفكيك اتصال صريحة. أحد الأشياء التي تحدث أثناء إنشاء الاتصال هو قيام الطرفين بإنشاء حالة مشتركة ما لتمكين خوارزمية النافذة المنزلقة من البدء. يجب فصل الاتصال حتى يعرف كل مضيف أنه لا بأس من تحرير هذه الحالة. ثانيًا، في حين أنه يوجد لدى رابط فيزيائي واحد يربط دائمًا نفس جهازي الحاسوب وقت رحلة ذهاب وإياب round-trip time أو اختصارًا RTT ثابت، فمن المحتمل أن يكون لدى اتصالات TCP أوقات ذهابٍ وإيابٍ مختلفة. قد يساوي وقت RTT من أجل اتصال TCP بين مضيفٍ في سان فرانسيسكو ومضيفٍ في بوسطن على سبيل المثال، مفصول بينهما بعدة آلاف من الكيلومترات، 100 ميلي ثانية، بينما قد يساوي وقت RTT من أجل اتصال TCP بين مضيفين في نفس الغرفة، على بعد أمتار قليلة فقط، 1 ميلي ثانية فقط. يجب أن يكون بروتوكول TCP نفسه قادرًا على دعم كلا الاتصالين. و لجعل الأمور أسوأ، فقد يبلغ وقت RTT لِاتصال TCP بين المضيفين في سان فرانسيسكو وبوسطن 100 ميلي ثانية في الساعة 3 صباحًا، ولكنّ وقت RTT يبلغ 500 ميلي ثانية في الساعة 3 مساءً. يمكن أن تكون الاختلافات في وقت RTT ممكنةً أثناء اتصال TCP الذي لا يدوم سوى بضع دقائق. ما يعنيه هذا بالنسبة لخوارزمية النافذة المنزلقة هو أن آلية المهلة الزمنية timeout التي تؤدي إلى إعادة الإرسال يجب أن تكون قابلة للتكيُّف. (بالتأكيد، يجب أن تكون المهلة الزمنية لرابط من نقطةٍ إلى نقطة معاملًا قابلًا للإعداد، ولكن ليس من الضروري تكييف هذا المؤقت مع زوجٍ معين من العقد). ثالثًا، إمكانية إعادة ترتيب الرزم أثناء عبورها للإنترنت، إنما هذا غير ممكن على رابط من نقطة إلى نقطة حيث يجب أن تكون الرزمة الأولى الموضوعة في أحد طرفي الرابط هي أول ما يظهر في الطرف الآخر. لا تسبب الرزم المخالفة قليلًا للترتيب مشاكلًا لأن خوارزمية النافذة المنزلقة يمكنها إعادة ترتيب الرزم بصورةٍ صحيحة باستخدام الرقم التسلسلي. تكمن المشكلة الحقيقية في المدى الذي يمكن أن تصل إليه رزمٌ مخالفة للترتيب، أو، كما يُقال بطريقة أخرى، مدى تأخر وصول الرزمة إلى الوجهة. يمكن أن تتأخر الرزمة في الإنترنت في أسوأ الحالات حتى انتهاء صلاحية حقل IP الذي هو العُمر time to live أو (TTL)، وفي ذلك الوقت تُهمَل الرزمة (وبالتالي لا يوجد خطر من وصولها متأخرة). يفترض بروتوكول TCP أن كل رزمة لها عمرٌ أقصى مع العلم أن بروتوكول IP يرمي الرزم بعيدًا بعد انتهاء صلاحية حقل TTL. يُعد العمر الدقيق، المعروف باسم الحد الأقصى لعمر الجزء maximum segment lifetime أو اختصارًا MSL، خيارًا هندسيًا، والإعداد الحالي الموصى به هو 120 ثانية. ضع في بالك أن بروتوكول IP لا يفرض مباشرة هذه القيمة البالغة 120 ثانية، أي أنه ببساطة تقدير تقليدي يقوم به بروتوكول TCP لطول مدة بقاء الرزمة على الإنترنت. يجب أن يكون بروتوكول TCP جاهزًا حتى تظهر الرزم القديمة جدًا فجأة في جهاز الاستقبال، مما قد يؤدي إلى إرباك خوارزمية النافذة المنزلقة. رابعًا، تُصمَّم أجهزة الحواسيب المتصلة برابط من نقطة إلى نقطة لدعم الروابط. فإذا حُسِب جداء التأخير × حيز النطاق التراسلي للرابط ليكون 8 كيلوبايت على سبيل المثال، مما يعني أن حجم النافذة حُدِّد للسماح بما يصل إلى 8 كيلوبايت من البيانات بعدم الإقرار unacknowledged في وقت معين، وعندها فمن المحتمل أن يكون لأجهزة الحاسوب في أيٍّ من طرفي الرابط القدرة على تخزين ما يصل إلى 8 كيلوبايت من البيانات. سيكون تصميم النظام بخلاف ذلك سخيفًا. يمكن توصيل أي نوع من أجهزة الحاسوب تقريبًا بالإنترنت، مما يجعل كمية الموارد المخصصة لأي اتصال TCP متغيرًا بدرجة كبيرة، لا سيما بالنظر إلى أن أي مضيف يمكنه دعم مئات اتصالات TCP في نفس الوقت. وهذا يعني أن بروتوكول TCP يجب أن يتضمن آلية يستخدمها كل جانب "لمعرفة" الموارد (مقدار مساحة المخزن المؤقت على سبيل المثال) التي يستطيع الجانب الآخر تطبيقها على الاتصال. وهذه هي مشكلة التحكم في التدفق. خامسًا، نظرًا لأن جانب الإرسال للرابط المتصل مباشرةً لا يمكنه الإرسال بصورةٍ أسرع مما يسمح به حيز نطاق الرابط التراسلي، ولأن مضيفًا واحدًا فقط يضخ البيانات في الرابط، فلا يمكن جعل الرابط مزدحمًا عن غير قصد. يكون الحِمل على الرابط مرئيًا على شكل رتل من الرزم عند المرسل، وفي المقابل، ليس لدى جانب الإرسال من اتصال TCP فكرة عن الروابط التي سيجري اجتيازها للوصول إلى الوجهة. قد يكون جهاز الإرسال متصلًا مباشرةً بشبكة إيثرنت سريعة نسبيًا على سبيل المثال، وقادرة على إرسال البيانات بمعدل 10 جيجابت في الثانية، ولكن يجب اجتياز رابطٍ بسرعة 1.5 ميجابت في الثانية في مكان ما في منتصف الشبكة. لجعل الأمور أسوأ، قد تحاول البيانات التي تنشئها العديد من المصادر المختلفة اجتياز هذا الرابط البطيء نفسه، وهذا يؤدي إلى مشكلة ازدحام الشبكة. نختم هذه المناقشة لقضايا طرفٍ إلى طرف من خلال مقارنة نهج TCP لتوفير خدمة توصيلٍ موثوقة / مرتبة مع النهج الذي تستخدمه الشبكات القائمة على الدارات الافتراضية مثل شبكة X.25 المهمة تاريخيًا. يُفترض أن شبكة IP الأساسية غير موثوقة في بروتوكول TCP وتسلّم الرسائل مخالفةً للترتيب، أي يستخدم بروتوكول TCP خوارزمية النافذة المنزلقة على أساس طرفٍ إلى طرف لتوفير تسليمٍ موثوق / مرتب. وفي المقابل، تستخدم شبكات X.25 بروتوكول النافذة المنزلقة داخل الشبكة، على أساس النقل قفزة بقفزة hop-by-hop. الافتراض الكامن وراء هذا النهج هو أنه إذا ُسلِّمت الرسائل بصورة موثوقة ومرتّبة بين كل زوج من العقد على طول المسار بين مضيف المصدر والمضيف الوجهة، فإن الخدمة من طرفٍ إلى طرف تضمن أيضًا تسليمًا موثوقًا / مرتبًا. تكمن مشكلة هذا النهج الأخير في أن سلسلةً من الضمانات السريعة المتتالية من نقل قفزة بقفزة لا تضيف بالضرورة ضمانًا شاملًا. أولًا، إذا أضيف رابطٌ غير متجانس (رابط إيثرنت مثلًا) إلى أحد طرفي المسار، فلا يوجد ضمان بأن هذه الخطوة ستحافظ على نفس الخدمة مثل الخطوات الأخرى. ثانيًا، إذا ضمِن بروتوكول النافذة المنزلقة تسليم الرسائل بصورة صحيحة من العقدة A إلى العقدة B، ومن ثم من العقدة B إلى العقدة C، فإنه لا يضمن أن العقدة B تتصرف بصفةٍ مثالية، حيث عُرفت عقد الشبكة بإدخال أخطاءٍ في الرسائل أثناء نقلها من مخزن الإدخال المؤقت إلى مخزن الإخراج المؤقت. ومن المعروف أيضًا أن عقد الشبكة تعيد ترتيب الرسائل عن طريق الخطأ. لا يزال من الضروري توفير فحوصات طرفٍ إلى طرف لضمان خدمة موثوقة / مرتبة نتيجة لأسباب الضعف البسيطة هذه، على الرغم من تطبيق المستويات الأدنى من النظام أيضًا لهذه الوظيفة. صيغة الجزء segment format بروتوكول TCP هو بروتوكول موجَّهٌ بالبايت، مما يعني أن المرسل يكتب البايت في اتصال TCP ويقرأ المتلقي البايت من خلال اتصال TCP. على الرغم من أن "تدفق البايتات" يصف الخدمة التي يقدمها بروتوكول TCP لعمليات التطبيق، فإن بروتوكول TCP نفسه لا يرسل البايتات الفردية عبر الإنترنت. وبدلًا من ذلك، يخزن بروتوكول TCP على المضيف المصدر ما يكفي من البايتات من عملية الإرسال لملء رزمةٍ بحجم معقول ثم يرسل هذه الرزمة إلى نظيره على المضيف الوجهة. يفرغ بروتوكول TCP على المضيف الوجهة بعد ذلك محتويات الرزمة في مخزن الاستلام المؤقت، وتقرأ عملية الاستلام من هذا المخزن المؤقت في أوقات فراغها. يوضح الشكل التالي هذا الموقف، حيث يُظهر تدفق البيانات في اتجاه واحد فقط بهدف التبسيط. تذكر أن اتصال TCP واحدًا يدعم عمومًا تدفقات البايتات في كلا الاتجاهين. تسمَّى الرزم المتبادلة بين نظراء بروتوكول TCP في الشكل السابق باسم الأجزاء segments، لأن كل واحد يحمل جزء من تدفق البايتات. يحتوي كل جزء TCP على العنوان الموضح في الشكل التالي. وستوضّح معظم هذه الحقول ضمن هذا القسم. يحدد حقلا SrcPort وDstPort منفذي ports المصدر والوجهة، على التوالي، تمامًا كما في بروتوكول UDP. يتحد هذان الحقلان، بالإضافة إلى عناوين IP المصدر والوجهة، لتعريف كل اتصال TCP بشكل فريد. وهذا يعني أن مفتاح فك تعدد الإرسال demux الخاص ببروتوكول TCP مُعطى بواسطة صف رباعي العناصر 4-tuple (حيث tuple هو (صف وتُجمَع إلى صفوف) هي بنية بيانات تُمثِّل سلسلةً مرتبة من العناصر غير القابلة للتبديل، وبالتالي لا يمكن تعديل القيم الموجودة فيها) وهنا هذا الصف مؤلَّف من 4 عناصر. (SrcPort, SrcIPAddr, DstPort, DstIPAddr) لاحظ أن اتصالات TCP تأتي وتذهب، وبالتالي من الممكن إنشاء اتصال بين زوجٍ معين من المنافذ، واستخدامه لإرسال البيانات واستلامها، وإغلاقه، ثم تضمين نفس زوج المنافذ في اتصال ثانٍ في وقت لاحق. نشير أحيانًا إلى هذه الحالة على أنهما تجسيدان incarnations مختلفان لنفس الاتصال. تُضمَّن جميع حقول Acknowledgement و SequenceNum و AdvertisedWindow في خوارزمية نافذة بروتوكول TCP المنزلقة. بما أن بروتوكول TCP هو بروتوكول موجهٌ بالبايت، فإن لكل بايت من البيانات رقم تسلسلي. يحتوي حقل SequenceNum على رقمٍ تسلسلي للبايت الأول من البيانات المنقولة في هذا الجزء، ويحمل حقلا Acknowledgement و AdvertisedWindow معلومات حول تدفق البيانات في الاتجاه الآخر. لتبسيط مناقشتنا، نتجاهل حقيقة أن البيانات يمكن أن تتدفق في كلا الاتجاهين، ونركز على البيانات التي لها رقم تسلسلي SequenceNum معين يتدفق في اتجاه واحد، وتتدفق قيم الحقلين Acknowledgement و AdvertisedWindow في الاتجاه المعاكس، كما هو موضح في الشكل التالي: يُستخدم حقل الرايات Flags المكوّن من 6 بتات لنقل معلومات التحكم بين نظراء بروتوكول TCP. تتضمن الرايات المحتملة رايات SYN و FIN و RESET و PUSH و URG و ACK. تُستخدَم رايتا SYN و FIN عند إنشاء اتصال TCP وإنهائه على التوالي. تُضبَط الراية ACK في أي وقت يكون حقل Acknowledgement صالحًا، مما يعني أنه يجب على المستلم الانتباه إليه. تشير الراية URG إلى أن هذا الجزء يحتوي على بياناتٍ عاجلة، فعند تعيين هذه الراية، يشير حقل UrgPtr إلى مكان بدء البيانات غير العاجلة الموجودة في هذا الجزء. يجري احتواء البيانات العاجلة في الجزء الأمامي من جسم الجزء segment body، بعدد بايتاتٍ يصل إلى قيمة الراية UrgPtr في الجزء. تشير الراية PUSH إلى أن المرسل قد استدعى عملية PUSH، مما يشير إلى الجانب المستلم من TCP بوجوب إعلام عملية الاستلام بهذه الحقيقة. أخيرًا، تشير الراية RESET إلى أن جهاز الاستقبال قد أصبح مرتبكًا، لأنه تلقى جزءًا لم يتوقع تلقيه على سبيل المثال، وبالتالي يريد إلغاء الاتصال. أخيرًا، يُستخدَم حقل المجموع الاختباري Checksum تمامًا بنفس الطريقة المستخدمة في بروتوكول UDP، أي يُحسَب عبر ترويسة TCP وبيانات TCP والترويسة الزائفة pseudoheader، والتي تتكون من عنوان المصدر وعنوان الوجهة وحقول الطول من ترويسة IP. المجموع الاختباري مطلوب لبروتوكول TCP في كلٍ من IPv4 و IPv6. بما أن ترويسة TCP متغيرة الطول (يمكن إرفاق الخيارات بعد الحقول الإلزامية)، فيُضمَّن حقل HdrLen الذي يعطي طول الترويسة بكلمات ذات حجم 32 بتًا. يُعرف هذا الحقل أيضًا باسم حقل الإزاحة Offset، لأنه يقيس الإزاحة من بداية الرزمة إلى بداية البيانات. تأسيس الاتصال وإنهاؤه يبدأ اتصال TCP عندما يقوم عميلٌ "مستدعٍ caller" بفتحٍ فعّال active open لخادم "مُستدعَى callee". وبفرض أن الخادم قد أجرى في وقتٍ سابق فتحًا سلبيًا غير فعّال passive open، فيشارك الجانبان في تبادل الرسائل لإنشاء الاتصال. (تذكر أن الطرف الذي يرغب في بدء اتصال يجري فتحًا فعالًا، بينما الطرف الذي يرغب في قبول الاتصال يجري فتحًا سلبيًا. ويسمح بروتوكول TCP بإعداد الاتصال ليكون متماثلًا symmetric، حيث يحاول كلا الجانبين فتح الاتصال في نفس الوقت، ولكن الحالة الشائعة هي أن يجري أحد الجانبين فتحًا فعّالًا والآخر يجري فتحًا سلبيًا. يبدأ الطرفان في إرسال البيانات بعد انتهاء مرحلة إنشاء الاتصال فقط. وبالمثل، فبمجرد انتهاء المشارك من إرسال البيانات، فإنه يغلق اتجاهًا واحدًا للاتصال، مما يتسبب في بدء بروتوكول TCP بجولة من رسائل إنهاء الاتصال. لاحظ أنه في حين أن إعداد الاتصال هو نشاط غير متماثل asymmetric (أحد الجانبين يجري فتحًا سلبيًا والجانب الآخر يجري فتحًا فعّالًا)، فإن تفكيك teardown الاتصال يكون متماثلًا symmetric (يجب على كل جانب إغلاق الاتصال بشكل مستقل). لذلك من الممكن أن يكون أحد الطرفين قد أنهى إغلاقًا، مما يعني أنه لم يعد بإمكانه إرسال البيانات، ولكن يجب إبقاء النصف الآخر من الاتصال ثنائي الاتجاه مفتوحًا ومواصلة إرسال البيانات بالنسبة للجانب الآخر. طريقة المصافحة الثلاثية Three-Way Handshake تسمى الخوارزمية التي يستخدمها بروتوكول TCP لإنشاء اتصال وإنهائه بمصافحة ثلاثية. نصف أولًا الخوارزمية الأساسية ثم نوضّح كيف يستخدمها بروتوكول TCP. تتضمن طريقة المصافحة الثلاثية تبادل ثلاث رسائل بين العميل والخادم، كما هو موضح في الجدول الزمني الوارد في الشكل التالي. الفكرة هي وجود طرفين يريدان الاتفاق على مجموعة من المعاملات، والتي هي أرقام البداية التسلسلية التي يخطط الجانبان لاستخدامها في تدفقات البايتات الخاصة بهما في حالة فتح اتصال TCP. قد تكون هذه المعاملات أي حقائق يريد كل جانب أن يعرفها الجانب الآخر. أولًا، يرسل العميل (المشارك الفعّال) جزءًا إلى الخادم (المشارك السلبي) يوضح الرقم التسلسلي الأولي الذي يخطط لاستخدامه (Flags=SYN,SequenceNum= x). يستجيب الخادم بعد ذلك بجزء واحد يقوم بوظيفة مزدوجة وهي الإقرار برقم العميل التسلسلي Flags = ACK وAck = x + 1، وتحديد رقم البداية التسلسلي الخاص به Flags = SYN وSequenceNum = y. وبالتالي ضُبطت بتات SYN وACK في حقل Flags في هذه الرسالة الثانية. أخيرًا، يستجيب العميل بجزء ثالث يعترف برقم الخادم التسلسلي Flags = ACK وAck = y + 1. السبب الذي يجعل كل جانب يعترف برقمٍ تسلسلي أكبر بمقدار واحد عن الرقم المرسَل هو أن حقل الإشعار Acknowledgement يحدد بالفعل "الرقم التسلسلي التالي المتوقع"، وبالتالي يُعترف ضمنيًا بجميع الأرقام التسلسلية السابقة. جرى جدولة مؤقتٍ timer لكل جزء من الجزأين الأولين على الرغم من عدم ظهوره في هذا المخطط الزمني. وعند عدم تلقي الاستجابة المتوقعة، فسيُعاد إرسال الجزء. قد تسأل نفسك لماذا يجب على العميل والخادم تبادل أرقام البداية التسلسلية مع بعضهما بعضًا في وقت إعداد الاتصال. سيكون من الأسهل إذا بدأ كل جانب ببساطة برقمٍ تسلسلي "معروف"، مثل 0. تتطلب مواصفات TCP أن يختار كل جانب من جوانب الاتصال رقم بداية تسلسليًا أوليًا عشوائيًا، والسبب في ذلك هو الحماية من وجود تجسيدين لنفس الاتصال يعيدان استخدام نفس الأرقام التسلسلية في وقتٍ قريب جدًا، أي في الوقت الذي لا يزال فيه فرصةٌ بأن يتداخل جزءٌ من تجسيد اتصالٍ سابق مع تجسيد اتصالٍ لاحق. مخطط انتقال الحالة State-Transition Diagram بروتوكول TCP معقدٌ بدرجةٍ كافية بحيث تتضمن مواصفاته مخطط انتقال الحالة. توجد نسخةٌ من هذا المخطط في الشكل الآتي. يوضح هذا المخطط فقط الحالات المشاركة في فتح اتصال (كل شيء فوق الحالة ESTABLISHED) وفي إغلاق الاتصال (كل شيء أدنى الحالة ESTABLISHED). يكون كل شيء يحدث أثناء فتح الاتصال، أي تشغيل خوارزمية النافذة المنزلقة، مخفيًا في الحالة ESTABLISHED. من السهل فهم مخطط انتقال حالة TCP، حيث يشير كل صندوقٍ إلى حالة يمكن لأحد طرفي اتصال TCP أن يجد نفسه فيها. تبدأ جميع الاتصالات في الحالة CLOSED، ومع تقدم الاتصال، ينتقل الاتصال من حالة إلى أخرى وفقًا للأقواس. يُسمَّى كل قوس بوسم tag لنموذج حدث / إجراء event/action. وبالتالي إذا كان الاتصال في حالة LISTEN مع وصول جزء SYN (أي جزء مع ضبط راية SYN على سبيل المثال)، ينتقل الاتصال إلى الحالة SYN_RCVD ويتخذ إجراء الرد بجزء ACK + SYN. لاحظ أن نوعين من الأحداث يؤديان إلى انتقال الحالة: وصول جزء من النظير (الحدث على القوس من LISTEN إلى SYNRCVD على سبيل المثال) استدعاء عملية التطبيق المحلي عمليةً على بروتوكول TCP (حدث الفتح الفعال على القوس من الحالة CLOSED إلى SYNSENT على سبيل المثال). بعبارة أخرى، يحدّد مخطط انتقال الحالة الخاص ببروتوكول TCP بفعالية دلالات semantics كلٍ من واجهة نظير لنظير peer-to-peer interface وَواجهة خدمته. تُوفَّر صيغة syntax لهاتين الواجهتين من خلال صيغة الجزء ومن خلال بعض واجهات برمجة التطبيقات على التوالي، مثل واجهة برمجة تطبيقات المقبس socket API. دعنا الآن نتتبع التحولات النموذجية المأخوذة من خلال المخطط في الشكل السابق. ضع في اعتبارك أنه في كل طرفٍ من طرفي الاتصال، يجري بروتوكول TCP انتقالات مختلفة من حالة إلى أخرى. يستدعي الخادم أولًا عملية فتحٍ سلبية على بروتوكول TCP عند فتح اتصال، مما يؤدي إلى انتقال TCP إلى حالة LISTEN. يجري العميل فتحًا فعالًا في وقت لاحق، مما يؤدي إلى إرسال نهاية الاتصال جزء SYN إلى الخادم والانتقال إلى حالة SYNSENT. ينتقل الخادم إلى حالة SYNRCVD عندما يصل جزء SYN إليه ويستجيب بجزء SYN + ACK. يؤدي وصول هذا الجزء إلى انتقال العميل إلى الحالة ESTABLISHED وإرسال ACK مرة أخرى إلى الخادم. وينتقل الخادم أخيرًا إلى الحالة ESTABLISHED عند وصول ACK. وبالتالي كأننا قد قمنا للتو بتتبع طريقة المصافحة الثلاثية. هناك ثلاثة أشياء يجب ملاحظتها حول النصف المخصص لإنشاء الاتصال في مخطط انتقال الحالة. أولًا، في حالة فقد ACK الخاص بالعميل إلى الخادم، وهو ما يتوافق مع المرحلة الثالثة من طريقة المصافحة الثلاثية، فإن الاتصال لا يزال يعمل بصورةٍ صحيحة. وذلك لأن جانب العميل موجود بالفعل في حالة ESTABLISHED، لذلك يمكن أن تبدأ عملية التطبيق المحلي في إرسال البيانات إلى الطرف الآخر. سيكون لكل جزء من أجزاء البيانات هذه مجموعة رايات ACK، والقيمة الصحيحة في حقل Acknowledgement، لذلك سينتقل الخادم إلى الحالة ESTABLISHED عند وصول جزء البيانات الأول. هذه في الواقع نقطةٌ مهمة حول بروتوكول TCP، حيث يبلّغ كل جزء عن الرقم التسلسلي الذي يتوقع المرسل رؤيته بعد ذلك، حتى إذا كان هذا يكرّر نفس الرقم التسلسلي الموجود في جزءٍ واحد أو أكثر من الأجزاء السابقة. الشيء الثاني الواجب ملاحظته حول مخطط انتقال الحالة هو أن هناك انتقالًا مضحكًا خارج حالة LISTEN عندما تستدعي العملية المحلية عملية إرسال على بروتوكول TCP. بمعنى أنه من الممكن للمشارك السلبي تحديد طرفي الاتصال (أي نفسه والمشارك البعيد الذي يرغب في الاتصال به)، ومن ثم تغيير رأيه بشأن انتظار الجانب الآخر وإنشاء اتصال فعال بدلًا من ذلك. على حد علمنا، هذه ميزة من ميزات بروتوكول TCP التي لا تستفيد منها أية عملية تطبيق. آخر شيء يجب ملاحظته بشأن المخطط هو الأقواس غير الظاهرة. تجدول معظم الحالات التي تتضمن إرسال جزءٍ إلى الجانب الآخر أيضًا مهلةً زمنية timeout تؤدي في النهاية إلى إعادة إرسال الجزء عند عدم حدوث الاستجابة المتوقعة. لا تُوصف عمليات إعادة الإرسال هذه في مخطط انتقال الحالة. في حال عدم وصول الاستجابة المتوقعة بعد عدة محاولات، يستسلم بروتوكول TCP ويعود إلى الحالة CLOSED. الشيء المهم حول عملية إنهاء الاتصال الواجب أخذه بعين الاعتبار هو أن عملية التطبيق على جانبي الاتصال يجب أن تغلق نصف الاتصال الخاص بها بشكل مستقل. إذا أغلق جانبٌ واحد فقط الاتصال، فهذا يعني أنه ليس لديه المزيد من البيانات للإرسال، ولكنه لا يزال متاحًا لتلقي البيانات من الجانب الآخر. يؤدي هذا إلى تعقيد مخطط انتقال الحالة لأنه يجب أن يأخذ في الاعتبار احتمال أن يستدعي الجانبان معامل الإغلاق في نفس الوقت، بالإضافة إلى احتمال أن يستدعي أحد الجانبين الإغلاق ثم، في وقت لاحق، يستدعي الجانب الآخر الإغلاق. وبالتالي يوجد في أي جانبٍ ثلاثُ مجموعات من الانتقالات التي تحصل على اتصال من الحالة ESTABLISHED إلى الحالة CLOSED: يجري إغلاق هذا الجانب أولًا: ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED يغلق الجانب الآخر أولًا: ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED يغلق كلا الجانبين في نفس الوقت: ESTABLISHED → FIN_WAIT_1 → CLOSING → TIME_WAIT → CLOSED يوجد في الواقع تسلسل رابع، وإن كان نادرًا، للانتقالات التي تؤدي إلى الحالة CLOSED، حيث يتبع القوس من الحالة FINWAIT1 إلى الحالة TIME_WAIT. الشيء الرئيسي الواجب معرفته حول تفكيك الاتصال هو أن الاتصال في حالة TIME_WAIT لا يمكنه الانتقال إلى حالة CLOSED حتى ينتظر ضِعف الحد الأقصى من الوقت الذي قد يبقى فيه مخطط بيانات IP على الإنترنت (أي 120 ثانية). والسبب في ذلك هو أنه بينما يرسل الجانب المحلي من الاتصال ACK كاستجابةٍ للجزء FIN الخاص بالجانب الآخر، فإنه لا يعرف أن ACK قد سُلِّم بنجاح. لذلك قد يعيد الجانب الآخر إرسال الجزء FIN الخاص به، وقد يتأخر الجزء FIN الثاني في الشبكة. إذا سُمِح للاتصال بالانتقال مباشرةً إلى الحالة CLOSED، فقد يأتي زوجٌ آخر من عمليات التطبيق ويفتح نفس الاتصال (مثل استخدم نفس زوج أرقام المنافذ)، وقد يبدأ الجزء FIN المتأخر من تجسيد الاتصال السابق على الفور في إنهاء التجسيد اللاحق لذلك الاتصال. إعادة النظر في خوارزمية النافذة المنزلقة Sliding Window Revisited نحن الآن جاهزون لمناقشة بروتوكول TCP لخوارزمية النافذة المنزلقة، والتي تخدم عدة أغراض: (1) تضمن التسليم الموثوق للبيانات، (2) تضمن تسليم البيانات بالترتيب، (3) تفرض التحكم في التدفق بين المرسل والمُستقبِل. استخدام بروتوكول TCP لخوارزمية النافذة المنزلقة هو نفسه على مستوى الرابط بالنسبة لأول وظيفتين من هذه الوظائف الثلاث، بينما يختلف بروتوكول TCP عن خوارزمية مستوى الرابط في أنه يحتوي على وظيفة التحكم في التدفق أيضًا. يعلن جهاز الاستقبال عن حجم النافذة للمرسل بدلًا من وجود نافذةٍ منزلقة ذات حجم ثابت، ويحدث ذلك باستخدام حقل AdvertisedWindow في ترويسة TCP، ويمتلك المرسل بعد ذلك على ما لا يزيد عن قيمة بايتات الحقل AdvertisedWindow من البيانات غير المعترف بها في أي وقت. يحدد جهاز الاستقبال قيمة مناسبة للحقل AdvertisedWindow بناءً على مقدار ذاكرة الاتصال المخصصة لغرض تخزين البيانات مؤقتًا. الفكرة هي منع المرسل من الإفراط في تشغيل مخزن المستقبل المؤقت (سنناقش هذا بإسهاب أدناه). التسليم الموثوق والمرتب افترض الموقف الموضح في الشكل التالي لمعرفة كيفية تفاعل جانبي الإرسال والاستقبال من بروتوكول TCP مع بعضهما بعضًا لتنفيذ تسليمٍ موثوقٍ ومرتّب. يحتفظ TCP على جانب الإرسال بمخزن إرسال مؤقت، ويُستخدم هذا المخزن المؤقت لتخزين البيانات التي أُرسلت ولكن لم يجري الاقرار بها بعد، وكذلك البيانات التي كتبها التطبيق المرسل ولكن لم تُرسل. يحتفظ TCP على جانب الاستقبال بمخزن استقبالٍ مؤقت، حيث يحتفظ هذا المخزن المؤقت بالبيانات التي تصل مخالفةً للترتيب، وكذلك البيانات ذات الترتيب الصحيح (مثل عدم وجود بايتاتٍ مفقودة في وقت سابق من التدفق) ولكن عملية التطبيق لم تتح لها الفرصة لقراءتها بعد. نتجاهل في البداية حقيقة أن كلًا من المخازن المؤقتة والأرقام التسلسلية ذات حجم محدود وبالتالي ستلتف في النهاية لجعل المناقشة التالية أسهل، ولا نفرق أيضًا بين المؤشر إلى المخزن المؤقت حيث يُخزَّن بايتٌ معين من البيانات وبين الرقم التسلسلي لذلك البايت. بالنظر أولًا إلى جانب الإرسال، يحتفظ مخزن الإرسال المؤقت بثلاث مؤشرات، لكل منها معنى واضح: LastByteAcked وLastByteSent وLastByteWritten. أي: LastByteAcked <= LastByteSent بما أن المستقبل لا يمكنه أن يقِر أو يرسل إشعارًا بوصول بايتٍ لم يُرسَل بعد، ولأن بروتوكول TCP لا يمكنه إرسال بايتٍ لم تكتبه عملية التطبيق بعد، فلاحظ أيضًا أنه ليس ضروريًا حفظ أي من البايتات الموجودة على يسار LastByteAcked في المخزن المؤقت لأنه جرى التعرف عليها بالفعل، ولا يلزم تخزين أي من البايتات الموجودة على يمين LastByteWritten لأنها لم تُنشَأ بعد. LastByteSent <= LastByteWritten يجري الاحتفاظ بمجموعة مماثلة من المؤشرات (الأرقام التسلسلية) على جانب الاستقبال: LastByteRead وNextByteExpected وLastByteRcvd، ولكن التفاوتات أقل بسبب مشكلة التسليم المخالف للترتيب. تكون العلاقة الأولى LastByteRead <NextByteExpected صحيحة لأنه لا يمكن للتطبيق قراءة البايت حتى يُستلَم ويجب استقبال جميع البايتات السابقة أيضًا. يشير NextByteExpected إلى البايت مباشرةً بعد أحدث بايت لتلبية هذا المعيار. وثانيًا عندها إذا وصلت البيانات بالترتيب، فإن NextByteExpected يشير إلى البايت بعد LastByteRcvd، بينما إذا وصلت البيانات مخالفةً للترتيب، فإن NextByteExpected يشير إلى بداية الفجوة gap الأولى في البيانات، كما في الشكل السابق. لاحظ أنه لا تحتاج البايتات الموجودة على يسار LastByteRead أن تُخزَّن مؤقتًا لأن عملية التطبيق المحلي قد قرأتها بالفعل، ولا تحتاج البايتات الموجودة على يمين LastByteRcvd إلى تخزينها مؤقتًا لأنها لم تصل بعد. NextByteExpected <= LastByteRcvd + 1 التحكم في التدفق Flow Control معظم المناقشة أعلاه مشابهة لتلك الموجودة في خوارزمية النافذة المنزلقة القياسية. الاختلاف الحقيقي الوحيد هو أننا هذه المرة أوضحنا حقيقة أن عمليات تطبيق المرسل والمستقبل تملأ وتفرّغ المخزن المؤقت المحلي، على التوالي. (أخفت المناقشة السابقة حقيقة أن البيانات الواردة من عقدة المنبع تملأ مخزن الإرسال المؤقت وأن البيانات التي تُرسَل إلى عقدة المصب تفرّغ مخزن الاستقبال المؤقت). لابد من الفهم الجيد لذلك قبل المتابعة، إذ تأتي الآن النقطة التي تختلف فيها الخوارزميتان بصورةٍ أكبر. نعيد في ما يلي تقديم حقيقة أن كلا المخزنين المؤقتين لهما حجمٌ محدد، يُشار إليهما MaxSendBuffer وMaxRcvBuffer، على الرغم من أننا لا نقلق بشأن تفاصيل كيفية تطبيقها. أي نحن مهتمون فقط بعدد البايتات التي تُخزَّن مؤقتًا وليس في المكان الذي تُخزَّن فيه هذه البايتات بالفعل. تذكر أنه في بروتوكول النافذة المنزلقة، يحدّد حجمُ النافذة مقدارَ البيانات التي يمكن إرسالها دون انتظار إشعارٍ من المستقبل. وبالتالي يخنق جهاز الاستقبال المرسل عن طريق الإعلان عن نافذة لا تزيد عن كمية البيانات التي يمكنه تخزينها مؤقتًا. لاحظ أن بروتوكول TCP على جانب الاستقبال يجب أن يحافظ على ما يلي: LastByteRcvd - LastByteRead <= MaxRcvBuffer وذلك لتجنب تجاوز المخزن المؤقت الخاص به، لذلك يعلن عن نافذة بحجم AdvertisedWindow = MaxRcvBuffer - ((NextByteExpected - 1) - LastByteRead) والذي يمثل مقدار المساحة الخالية المتبقية في المخزن المؤقت الخاص به. يُقِر المستلم بالبيانات بمجرد وصولها طالما وصلت جميع البايتات السابقة أيضًا. وينتقل LastByteRcvd إلى اليمين (أي يزداد)، مما يعني أن النافذة المعلن عنها قد تتقلص، حيث يعتمد ما إذا تقلّصت أم لا على مدى سرعة عملية التطبيق المحلي في استهلاك البيانات. إذا كانت العملية المحلية تقرأ البيانات بنفس السرعة التي تصل بها، مما يؤدي إلى زيادة LastByteRead بنفس معدل LastByteRcvd، فإن النافذة المُعلن عنها تظل مفتوحة، أي AdvertisedWindow = MaxRcvBuffer، ولكن إذا تأخرت عملية الاستلام، ربما لأنها تؤدي عمليةً مكلفة للغاية على كل بايت من البيانات التي تقرأها، فإن النافذة المُعلن عنها تصبح أصغر مع كل جزء يصل حتى تصل في النهاية إلى القيمة 0. يجب أن يلتزم بروتوكول TCP على جانب الإرسال بالنافذة المعلن عنها من جهاز الاستقبال. هذا يعني أنه في أي وقت، يجب أن يضمن أن: LastByteSent - LastByteAcked <= AdvertisedWindow أي يحسب المرسل نافذة فعالة تحد من مقدار البيانات الممكن إرسالها: EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked) يجب أن يكون EffectiveWindow أكبر من 0 قبل أن يتمكن المصدر من إرسال المزيد من البيانات. لذلك من الممكن أن يصل جزءٌ ما للإقرار بـ x بايت، مما يسمح للمرسل بزيادة LastByteAcked بمقدار x، ولكن نظرًا لأن عملية الاستلام لم تكن تقرأ أي بيانات، فإن النافذة المُعلن عنها أصبحت الآن أصغر بمقدار x بايت من الوقت السابق، وبالتالي سيتمكّن المرسل من تحرير مساحة المخزن المؤقت، مع عدم إرسال أي بيانات أخرى. يجب أن يتأكد جانب الإرسال أيضًا طوال هذا الوقت من أن عملية التطبيق المحلي لا تتجاوز مخزن الإرسال المؤقت، أي: LastByteWritten - LastByteAcked <= MaxSendBuffer إذا حاولت عملية الإرسال كتابة y بايت إلى TCP، ولكن: (LastByteWritten - LastByteAcked) + y> MaxSendBuffer عندها سيوقف بروتوكول TCP عملية الإرسال ولا يسمح لها بتوليد المزيد من البيانات. أصبح من الممكن الآن فهم كيف تؤدي عملية الاستلام البطيئة إلى إيقاف عملية الإرسال السريعة في النهاية. أولًا، يمتلئ مخزن الاستقبال المؤقت، مما يعني تقلص النافذة المعلن عنها إلى 0. وتعني النافذة المعلن عنها بالقيمة 0 أن جانب الإرسال لا يمكنه نقل أي بيانات، بالرغم من الإقرار بالبيانات التي أرسلها سابقًا بنجاح. أخيرًا، يدل عدم القدرة على نقل أي بيانات على إمتلاء مخزن الإرسال المؤقت، مما يؤدي في النهاية إلى إيقاف بروتوكول TCP لعملية الإرسال. يكون بروتوكول TCP قادرًا على فتح نافذته احتياطيًا بمجرد أن تبدأ عملية الاستلام في قراءة البيانات مرةً أخرى، مما يسمح لبروتوكول TCP في طرف الإرسال بنقل البيانات من المخزن المؤقت الخاص به. ، تُزاد قيمة LastByteAcked عندما يجري الإقرار بهذه البيانات في النهاية، وتصبح مساحة المخزن المؤقت التي تحتوي على هذه البيانات المعترف بها حرة، ويُلغى إيقاف عملية الإرسال ويُسمَح لها بالمتابعة. هناك تفصيلٌ متبقٍ يجب حله، وهو كيف يعرف الجانب المرسل أن النافذة المُعلن عنها لم تعد 0؟ يرسل بروتوكول TCP دائمًا جزء segment استجابةً لجزء البيانات المستلمة، وتحتوي هذه الاستجابة على أحدث القيم للحقلين Acknowledge و AdvertisedWindow، حتى في حال عدم تغيُّر هذه القيم منذ آخر مرة أُرسلت فيها، وهذه هي المشكلة. لا يُسمَح للمرسل بإرسال أي بيانات أخرى بمجرد أن يعلن جانب الاستلام عن نافذة بحجم 0، مما يعني أنه ليس لديه طريقة لاكتشاف أن النافذة المُعلن عنها لم تعد 0 في وقت ما في المستقبل. لا يرسل بروتوكول TCP على جانب الاستقبال أجزاءًا بلا بيانات nondata تلقائيًا، إنما يرسلها فقط استجابةً لجزء بياناتٍ واصلة. يتعامل بروتوكول TCP مع هذا الوضع على النحو التالي: يستمر جانب الإرسال في إرسال جزء بحجم بايتٍ واحد من البيانات بين الحين والآخر عندما يعلن الجانب الآخر عن نافذة بحجم 0. يعلم جانب الإرسال أن هذه البيانات لن تُقبل على الأرجح، لكنه يحاول على أية حال، نظرًا لتنبيه trigger كل جزء من هذه الأجزاء المكونة من 1 بايت استجابةً تحتوي على النافذة المعلن عنها حاليًا. في النهاية، ينبّه triggers أحد هذه المسابر المكونة من 1 بايت استجابةً تبلّغ عن نافذةٍ غير صفرية معلن عنها. لاحظ أن هذه الرسائل ذات 1 بايت تسمى مسابر النافذة الصفرية Zero Window Probes وعمليًا يجري إرسالها كل 5 إلى 60 ثانية. أما بالنسبة للبايت المفرد من البيانات الذي سيُرسل في المسبار: فهو البايت التالي للبيانات الفعلية الموجودة خارج النافذة مباشرةً (يجب أن تكون بيانات حقيقية إذا قبِلها المستقبل). لاحظ أن السبب الذي يجعل الجانب المرسل يرسل جزء المسبار هذا دوريًا هو أن بروتوكول TCP مصمم لجعل جانب الاستقبال بسيطًا قدر الإمكان، فهو ببساطة يستجيب لأجزاء من المرسل، ولا يبدأ أي إجراءٍ بمفرده. هذا مثال على قاعدة تصميم بروتوكولٍ معترف بها (على الرغم من عدم تطبيقها عالميًا)، والتي نطلق عليها قاعدة المرسل الذكي / المستقبل الغبي smart sender/ dumb receiver بسبب عدم وجود اسمٍ أفضل. الحماية من الالتفاف Protecting Against Wraparound يأخذ هذا القسم والقسم التالي في الاعتبار حجم حقلي SequenceNum وAdvertisedWindow وتأثيرات أحجامهما على أداء وصحة بروتوكول TCP. يبلغ طول الحقل SequenceNum الخاص ببروتوكول TCP 32 بتًا، بينما يبلغ طول الحقل AdvertisedWindow 16 بتًا. مما يعني أن بروتوكول TCP قد استوفى بسهولة متطلبات خوارزمية النافذة المنزلقة بحيث تكون مساحة الرقم التسلسلي ضعف حجم النافذة: 232 >> 2 × 216، ومع ذلك فإن هذا المطلب ليس بالشيء المهم لهذين الحقلين، وبإمكانك افتراض كل حقلٍ على حدة. تكمن أهمية مساحة الرقم التسلسلي 32 بت في أن الرقم التسلسلي المُستخدَم في اتصالٍ معين قد يلتف، أي يمكن إرسال بايتٍ برقمٍ تسلسلي S في وقت واحد، ثم قد يرسَل بايتٌ ثانٍ بنفس الرقم التسلسلي S في وقت لاحق. نفترض أن الرزم لا يمكنها البقاء على الإنترنت لفترة أطول من MSL الموصى بها، وبالتالي نحتاج حاليًا إلى التأكد من أن الرقم التسلسلي لا يلتف خلال فترة زمنية مدتها 120 ثانية. يعتمد حدوث ذلك أم لا على مدى سرعة نقل البيانات عبر الإنترنت، أي مدى السرعة التي يمكن بها استهلاك مساحة الرقم التسلسلي 32 بت. (تفترض هذه المناقشة أننا نحاول استهلاك مساحة الرقم التسلسلي بأسرع ما يمكن، ولكن بالطبع سنكون كذلك إذا كنا نقوم بعملنا المتمثل في الحفاظ على الأنبوب ممتلئًا) يوضح الجدول التالي المدة التي يستغرقها الرقم التسلسلي للالتفاف حول الشبكات ذات أحياز النطاق التراسلي bandwidths المختلفة. table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } حيز النطاق التراسلي Bandwidth الوقت اللازم للالتفاف Time until Wraparound T1 مقداره 1.5 ميجابت في الثانية 6.4 ساعات T3 مقداره 45 ميجابت في الثانية 13 دقيقة Fast Ethernet مقداره 100 ميجابت في الثانية 6 دقائق OC-3 مقداره 155 ميجابت في الثانية 4 دقائق OC-48 مقداره 2.5 جيجابت في الثانية 14 ثانية OC-192 مقداره 10 جيجابت في الثانية 3 ثوان 10GigE مقداره 10 جيجابت في الثانية 3 ثوان كما ترى مساحة الرقم التسلسلي 32 بت كافيةٌ عند حيز نطاقٍ تراسلي متواضع، ولكن بالنظر إلى أن روابط OC-192 أصبحت شائعة الآن في الشبكات الرئيسية backbone للإنترنت، وأن معظم الخوادم تأتي الآن بواجهات 10Gig Ethernet (أو 10 جيجابت في الثانية)، فنكون قد تجاوزنا الآن هذه النقطة وسيكون 32 بتًا صغيرًا جدًا. عملت مؤسسة IETF على توسيع بروتوكول TCP الذي يوسّع بفعاليةٍ مساحة الرقم التسلسلي للحماية من التفاف الرقم التسلسلي. الحفاظ على الأنبوب ممتلئا Keeping the Pipe Full تكمن أهمية حقل AdvertisedWindow ذي 16 بتًا في أنه يجب أن يكون كبيرًا بما يكفي للسماح للمرسل بالحفاظ على الأنبوب ممتلئًا. من الواضح أن جهاز الاستقبال حر في عدم فتح النافذة بالحجم الذي يسمح به حقل AdvertisedWindow، فنحن مهتمون بالحالة التي يكون فيها لدى المستقبل مساحة تخزين كافية للتعامل مع أكبر قدرٍ ممكن من البيانات المسموح بها AdvertisedWindow. لا يُحدَّد حجم حقل AdvertisedWindow في هذه الحالة بحيز النطاق الشبكة التراسلي فقط ولكن بجداء التأخير × حيز النطاق التراسلي بدلًا من ذلك، والذي يجب فتحه بصورةٍ كافية للسماح بإرسال الجداء الكامل للتأخير × حيز النطاق التراسلي للبيانات المُراد إرسالها. بافتراض أن RTT تبلغ 100 ميلي ثانية (رقم نموذجي للاتصال عبر البلاد في الولايات المتحدة)، يعطي الجدول التالي جداء التأخير × حيز النطاق التراسلي للعديد من تقنيات الشبكة: حيز النطاق التراسلي Bandwidth جداء التأخير × حيز النطاق التراسلي Delay × Bandwidth Product T1 مقداره 1.5 ميجابت في الثانية 18 كيلوبايت T3 مقداره 45 ميجابت في الثانية 549 كيلوبايت Fast Ethernet مقداره 100 ميجابت في الثانية 1.2 ميجا بايت OC-3 مقداره 155 ميجابت في الثانية 1.8 ميجا بايت OC-48 مقداره 2.5 جيجابت في الثانية 29.6 ميجا بايت OC-192 مقداره 10 جيجابت في الثانية 118.4 ميجا بايت 10GigE مقداره 10 جيجابت في الثانية 118.4 ميجا بايت كما ترى فإن حقل AdvertisedWindow الخاص ببروتوكول TCP في حالةٍ أسوأ من حقل SequenceNum الخاص به، فهو ليس كبيرًا بما يكفي للتعامل حتى مع اتصال T3 عبر الولايات المتحدة القارية، نظرًا لأن الحقل 16 بت يسمح لنا بالإعلان عن نافذة حجمها 64 كيلو بايت فقط. يوفر توسيع TCP نفسه المذكور أعلاه آليةً لزيادة حجم النافذة المعلن عنها بفعالية. بهذا نكون قد تعرفنا على برتوكولات تدفق البايتات الموثوقة في الشبكات الحاسوبية آخذين بروتوكول TCP مثالًا في ذلك، وسنتابع بالمقال الموالي شرحها بالتخصيص في آليات الإرسال والبدائل. ترجمة -وبتصرّف- للقسم Reliable Byte Stream من فصل ProtocolsEnd-to-End من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبيةالمقال السابق: تأسيس الشبكات الحاسوبية والتعرف على تطبيقاتها البرمجيات المستخدمة في بناء الشبكات الحاسوبية التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية دليل بصري لكيفية استخدام أنفاق SSH

سنتحدث في هذا المقال مشكلة تواصل العمليات في البداية، والدور الذي يلعبه مستوى النقل transport في معمارية الشبكة، والذي يُسمى أحيانًا بروتوكول طرفٍ إلى طرف end-to-end، بعدها سنعرض الخدمات التي تحقق هذا الدور، مع شرح خدمة فك تعدد إرسال demultiplexing بسيطة من بين هذه الخدمات باستخدام بروتوكول UDP مشكلة تواصل العمليات Getting Processes to Communicate يمكن استخدام العديد من التقنيات لتوصيل مجموعة حواسيبٍ معًا، بدءًا من شبكات الإيثرنت البسيطة، والشبكات اللاسلكية، وحتى الشبكات المتشابكة ذات النطاق العالمي. وبمجرد الترابط، فستكون المشكلة التالية هي تحويل خدمة تسليم الرزمة من مضيف إلى مضيف إلى قناة اتصال بنمط عملية إلى عملية. هذا هو الدور الذي يلعبه مستوى النقل transport في معمارية الشبكة، والذي يُسمى أحيانًا بروتوكول طرفٍ إلى طرف end-to-end لأنه يدعم الاتصال بين برامج التطبيق التي تعمل في العقد النهائية. تتجسد قوة بروتوكول طرف إلى طرف بعاملين مهمين: الأول من جهة الطبقات الأعلى، حيث أن عمليات مستوى طبقة التطبيق التي تستخدم خدمات مستوى طبقة النقل لها متطلباتٌ معينة. تحدّد القائمة التالية بعض الخصائص العامة المُتوقَّع توفيرها ببروتوكول النقل: ضمان تسليم الرسالة. تسليم الرسائل بنفس ترتيب إرسالها. تسليم نسخةً واحدة على الأكثر من كل رسالة. دعم الرسائل الكبيرة العشوائية. دعم التزامن بين المرسل والمستقبل. السماح للمستلم بتطبيق التحكم في التدفق على المرسل. دعم عمليات تطبيق متعددة على كل مضيف. لاحظ أن هذه القائمة لا تتضمن جميع الوظائف التي قد تحتاجها عمليات التطبيق من الشبكة، فلا تتضمن ميزات الأمن مثل الاستيثاق أو التشفير والتي توّفرها عادةً بروتوكولاتٌ تقع فوق مستوى النقل. (سنناقش الموضوعات المتعلقة بالأمن لاحقًا). أما العامل الثاني فهو يتعلق بالطبقات السفلى، حيث أن الشبكة الأساسية التي يعمل عليها بروتوكول النقل لها قيودٌ معينة في مستوى الخدمة التي يمكن أن يوفرها. تتمثل بعض القيود الأكثر شيوعًا للشبكة في امكانية: إسقاط الرسائل. إعادة ترتيب الرسائل. تسليم نسخ مكررة من رسالة معينة. تقييد حجم الرسائل بحجمٍ محدود. تسليم الرسائل بعد تأخير طويل وعشوائي. ويقال أن مثل هذه الشبكة توفر أفضل جهدٍ best-effort من مستوى الخدمة، كما يتضح من الإنترنت. وبالتالي، يكمن التحدي في تطوير الخوارزميات التي ترقّي الخصائص الأقل من الخصائص المثالية للشبكة الأساسية إلى مستوى عالٍ من الخدمة التي تتطلبها برامج التطبيق. تستخدم بروتوكولات النقل المختلفة مجموعات مختلفة من هذه الخوارزميات. يبحث هذا المقال في هذه الخوارزميات في سياق أربع خدمات تمثيلية هي: خدمة فك تعدد إرسال demultiplexing بسيطة غير متزامنة وخدمة تدفق بايتٍ موثوقة و"خدمة طلب / رد request/reply" وخدمة تطبيقات الزمن الحقيقي. نستخدم، في حالة خدمات فك تعدد الإرسال وتدفق البايت، بروتوكول مخطط بيانات المستخدم User Datagram Protocol أو اختصارًا UDP وبروتوكول التحكم في الإرسال Transmission Control Protocol أو اختصارًا TCP على التوالي لتوضيح كيفية تقديم هذه الخدمات عمليًا. بينما نناقش، في حالة خدمة الطلب / الرد، الدور الذي تلعبه في خدمة استدعاء الإجراءات البعيدة Remote Procedure Call أو اختصارًا RPC وميزاتها. لا يحتوي الإنترنت على بروتوكول RPC واحد، لذلك قمنا بتغطية هذه المناقشة بوصفٍ لثلاثة من بروتوكولات RPC المستخدمة على نطاق واسع: SunRPC وDCE-RPC وgRPC. أخيرًا، تفرض تطبيقات الزمن الحقيقي متطلباتٍ خاصة على بروتوكول النقل، مثل الحاجة إلى نقل معلومات التوقيت التي تسمح بإعادة تشغيل عينات الصوت أو الفيديو في النقطة الزمنية المناسبة. سيتم التركيز على المتطلبات التي وضعتها التطبيقات على مثل هذا البروتوكول من خلال أكثر الأمثلة استخدامًا وهو بروتوكول النقل في الوقت الحقيقي Real-Time Transport Protocol أو اختصارًا RTP. فك تعدد الإرسال البسيط Simple Demultiplexor باستخدام بروتوكول UDP إن أبسط بروتوكول نقل ممكن هو الذي يوسّع خدمة التوصيل من مضيف إلى مضيف للشبكة الأساسية إلى خدمة اتصال عمليةٍ إلى عملية. من المحتمل أن يكون هناك العديد من العمليات التي تعمل على أي مضيفٍ معين، لذلك يحتاج البروتوكول إلى إضافة مستوىً من فك تعدد الإرسال، مما يسمح لعمليات تطبيقٍ متعددة على كل مضيف بمشاركة الشبكة. لا يضيف بروتوكول النقل أي وظيفة أخرى لخدمة أفضل جهد التي تقدمها الشبكة الأساسية بصرف النظر عن هذا المطلب. يُعد بروتوكول مخطط بيانات المستخدم UDP للإنترنت مثالًا عن بروتوكول النقل هذا. المشكلة الوحيدة المثيرة للاهتمام في مثل هذا البروتوكول هي شكل العنوان المستخدم لتحديد العملية المستهدفة. على الرغم من أنه من الممكن للعمليات تحديد بعضها بعضًا مباشرةً باستخدام معرّف العملية process id أو اختصارًا pid المخصّص لنظام التشغيل، فإن مثل هذا النهج عمليٌّ فقط في نظامٍ موزَّع مغلَقٍ يعمل فيه نظام تشغيل واحد على جميع المضيفين ويسند لكل عمليةٍ معرّفًا فريدًا. الأسلوب الأكثر شيوعًا، والذي يستخدمه بروتوكول UDP، هو للعمليات التي تحدّد بعضها بعضًا بطريقةٍ غير مباشرة باستخدام محددٍ موقع مجرد abstract locator، يسمى عادةً منفذًا port. الفكرة الأساسية هي أن ترسل عملية المصدر رسالة إلى منفذ وأن تتلقّى عملية الوجهة الرسالة من منفذ. تحتوي ترويسة بروتوكول طرفٍ إلى طرف الذي يطبّق وظيفة فك تعدد الإرسال هذه على معرّفٍ (منفذ) لكل من مرسل (مصدر) ومُستقبِل (وجهة) للرسالة. يوضح الشكل التالي ترويسة UDP على سبيل المثال. لاحظ أن حقل منفذ UDP يبلغ طوله 16 بتًا فقط، وهذا يعني أن هناك ما يصل إلى 64 ألفًا من المنافذ المحتملة، ومن الواضح أنها غير كافية لتحديد جميع العمليات على جميع الأجهزة المضيفة في الإنترنت. لحسن الحظ، لا تُفسَّر المنافذ عبر الإنترنت بالكامل، ولكن فقط على مضيفٍ واحد، أي يحدّد منفذٌ على مضيفٍ معين العملية فعليًا زوج "منفذ ومضيف". يشكّل هذا الزوج مفتاح فك تعدد الإرسال لبروتوكول UDP. المشكلة التالية هي كيفية تعرّف العملية على منفذ العملية التي تريد إرسال رسالة إليها. تبدأ عادةً عملية العميل في تبادل الرسائل مع عملية الخادم، وبمجرد اتصال العميل بالخادم، يعرف الخادم منفذ العميل (من حقل SrcPrt المضمَّن في ترويسة الرسالة) ويمكنه الرد عليه. وبالتالي فإن المشكلة الحقيقية هي بكيفية تعرّف العميل على منفذ الخادم في المقام الأول. من الأساليب الشائعة أن يقبل الخادم الرسائل على منفذٍ معروف جيدًا، أي يتلقّى كل خادم رسائله على منفذٍ ثابت منشورٍ على نطاقٍ واسع، مثل خدمة هاتف الطوارئ المتوفرة في الولايات المتحدة على رقم الهاتف المعروف 911. يتلقى خادم اسم النطاق Domain Name Server أو اختصارًا DNS في الإنترنت، على سبيل المثال، الرسائل على المنفذ المعروف جيدًا (53) على كل مضيف، وتستمع خدمة البريد للرسائل على المنفذ (25)، ويقبل برنامج يونيكس talk الرسائلَ على المنفذ المعروف (517)، وغير ذلك. يُنشَر هذا الربط mapping دوريًا في RFC وهو متاح في معظم أنظمة يونيكس في الملف /etc/services. يكون المنفذ المعروف في بعض الأحيان مجردَ نقطة بداية الاتصال: يستخدم العميل والخادم المنفذَ المعروف جيدًا للاتفاق على منفذٍ آخر سيستخدمانه في الاتصالات اللاحقة، مما يترك المنفذ المعروف متاحًا للعملاء الآخرين. تتمثل الإستراتيجية البديلة في تعميم هذه الفكرة، بحيث لا يوجد سوى منفذٍ واحد معروف جيدًا، وهو المنفذ الذي تقبل فيه خدمة رابط المنافذ port mapper الرسائل. وبالتالي يرسل العميل رسالةً إلى منفذ رابط المنافذ المعروف جيدًا طالبًا منه المنفذ الذي يجب أن يستخدمه للتحدث إلى "أية" خدمة، فيرجع رابطُ المنافذ المنفذ المناسب. تسهّل هذه الإستراتيجية تغيير المنفذ المرتبط بخدمات مختلفة بمرور الوقت وتسهّل لكل مضيفٍ استخدام منفذ مختلف لنفس الخدمة. إن المنفذ هو مجرد فكرةٍ مجردة كما ذكرنا للتو، وتختلف الطريقة التي تُطبَّق فيها بالضبط من نظامٍ إلى آخر، أو بصورةٍ أدق، من نظام تشغيل لآخر، وتُعد واجهة برمجة تطبيقات المقبس socket API مثالٌ على تطبيق المنافذ. يُطبَّق المنفذ عادةً بواسطة رتل رسائل، كما هو موضح في الشكل التالي. يلحق البروتوكول (بروتوكول UDP مثلًا) الرسالة بنهاية الرتل عند وصولها، وتُهمَل الرسالة في حالة امتلاء الرتل. لا توجد آلية للتحكم في التدفق في بروتوكول UDP لإخبار المرسل بإبطاء السرعة، حيث تُزَال رسالةٌ من مقدمة الرتل عندما تريد عملية التطبيق تلقي رسالة. وإذا كانت قائمة الانتظار فارغة، فستُوقَف العملية حتى تصبح الرسالة متاحة. أخيرًا، على الرغم من أن بروتوكول UDP لا يطبّق التحكم في التدفق أو التسليم الموثوق / المرتب، إلا أنه يوفر وظيفةً أخرى بخلاف فك تعدد إرسال الرسائل إلى بعض عمليات التطبيق، كما يضمَن صحة الرسالة باستخدام المجموع الاختباري checksum (يُعَد المجموع الاختباري لبروتوكول UDP اختياريًا في IPv4 ولكنه إلزامي في IPv6). خوارزمية المجموع الاختباري الأساسية لبروتوكول UDP هي نفسها المستخدمة في بروتوكول IP، أي أنها تضيف مجموعةً من الكلمات ذات 16 بتًا باستخدام حساب متمم الواحد ones’ complement وتحسب متمم الواحد للنتيجة. لكن بيانات الإدخال المستخدمة في المجموع الاختباري غير متوقعة بعض الشيء. يأخذ المجموع الاختباري لبروتوكول UDP ترويسة UDP ومحتويات جسم الرسالة وشيئًا يسمَّى الترويسة الزائفة pseudoheader كمدخلات. تتكون الترويسة الزائفة من ثلاثة حقولٍ من ترويسة IP، هي رقم البروتوكول protocol number وعنوان IP المصدر وعنوان IP الوجهة، بالإضافة إلى حقل طول UDP، حيث يُضمَّن حقل طول UDP مرتين في حساب المجموع الاختباري. يُعَد الدافع وراء وجود الترويسة الزائفة هو التحقق من تسليم هذه الرسالة بين نقطتي النهاية الصحيحتين. إذا عُدِّل عنوان IP الوجهة أثناء نقل الرزمة على سبيل المثال، مما يتسبب في خطأ بتسليم الرزمة، فستُكتشَف هذه الحقيقة بواسطة مجموع بروتوكول UDP الاختباري. ترجمة -وبتصرّف- للقسم Simple Demultiplexor من الفصل End-to-End Protocols من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية كيف تختار سياسة فعالة للجدار الناري لتأمين خواديمك - الجزء الثاني التشبيك المتقدم Advanced Internetworking في الشبكات الحاسوبية التشبيك Internetworking بين أنواع مختلفة من الشبكات الحاسوبية

تُعَد عمليات التعبئة Fills المختلفة المتوفرة في برنامج سكريبوس Scribus رائعة، ولكنك قد تحتاج إلى شيئ مختلف في بعض الأحيان. لذلك يمكنك من خلال قضاء بعض الوقت في برنامج جيمب GIMP؛ إنشاء جميع أنواع التأثيرات التي يمكنك استخدامها في سكريبوس لجعل عمليات التعبئة الخاصة بك أكثر تميزًا. سنتعلّم في هذا المقال كيفية إنشاء التأثير "distressing mask" -كما في الشكل الآتي- الذي يمكنك استخدامه في جميع أنواع المشاريع، وليس للنصوص فقط، ولكن يجب أولًا تثبيت الخط Crash Scene على جهازك الذي يمكنك تنزيله مجانًا. التقنيات المحددة المستخدمة في برنامج جيمب GIMP إنشاء نمط Pattern. تطبيق المرشّح أو الفلتر Cartoon. إضافة قناع طبقة. في برنامج سكريبوس تحويل النص إلى مضلعات. تحويل المضلعات إلى إطار صورة. إنشاء التأثير Distressing Mask ستحتاج أولًا إلى إنشاء صورة أساسية، وذلك من خلال الآتي: انتقل إلى برنامج جيمب. اختر قائمة ملف File ثم جديد New. اضبط عرض الصورة الجديدة إلى 800 بكسل والارتفاع إلى 200 بكسل. افتح القائمة المنسدلة "خيارات متقدمة Advanced Options"، واضبط خيار التعبئة "Fill With" على اللون الأبيض. ثم اضغط على "موافق OK". سننشئ نمطًا بعد ذلك كما يلي: اختر قائمة Filters، ثم Render، ثم Clouds، وبعد ذلك Solid Noise. اضبط "Detail" على القيمة 3، وهذا يعطي النمط قليلًا من شكل الحبيبات Graininess. اضبط الحجم X والحجم Y على القيمة 4، وهذا يعطي تأثيرًا ممتعًا ولكن لا تتردد في تجربة قيم مختلفة. استمر في الضغط على زر "New Seed" حتى تحصل على النمط الذي يناسبك. ثم اضغط موافق OK. بهذا يكون قد أصبح لديك الآن نمط غائم، ولكن يمكنك تعديله قليلًا للحصول على تأثير أفضل. اختر القائمة Filters ثم Artistic ثم Cartoon. اضبط "نصف قطر القناع Mask radius" على القيمة 8 و"نسبة اللون الأسود Percent black" على القيمة 0.2، إذ تٌعَد هذه القيم مناسبةً لما نريده هنا، ولكن يجب عليك تجربة قيم أخرى لاحقًا. ثم اضغط موافق OK. حوّلت النمط الآن إلى شكلٍ ذو نمط جرونجي "grungy"، وهذا ما تريده لذلك ستحتاج الآن إلى تحويله إلى قناع طبقة. اختر قائمة طبقة Layer ثم قناع Mask ثم إضافة قناع طبقة Add Layer Mask. حدّد الخيار "نسخة ذات تدرج رمادي من الطبقة Grayscale copy of layer". اضغط على زر إضافة Add. وبذلك يكون قد نُسِخ النمط إلى قناع طبقة. سترى في مربع حوار "الطبقات Layers" نسختين من الصورة كما في الشكل التالي، انقر على الصورة اليسارية لتحديدها (النسخة الموجودة على اليمين هي قناع الطبقة نفسه). انقر نقرًا مزدوجًا على العينة اللونية الأمامية (الموجودة على اليسار) في مربع حوار مربع الأدوات كما في الشكل التالي: حدّد اللون الأسود من خلال أي طريقة تريدها ثم اضغط على موافق OK. اختر قائمة تحرير Edit، ثم اختر خيار التعبئة Fill with FG Color. كما يمكنك جعل نمطك أغمق أيضًا. بعد كل ما سبق احفظ الصورة الآن وانتقل إلى برنامج سكريبوس، وذلك باتباع الآتي: اختر قائمة ملف File ثم حفظ Save، وأدخِل اسمًا للملف، ثم اضغط على حفظ Save. اختر قائمة ملف File ثم تصدير Export As، ثم أعطِ الملف اسمًا، واختر "PNG" مثل نوع الملف (اخترنا النوع PNG لأننا بحاجة إلى الشفافية)، ثم اضغط على تصدير Export. اقبل كل الإعدادات الافتراضية واضغط على تصدير Export مرةً أخرى. بهذا يكون قد انتهى كل العمل الذي نريده على برنامج جيمب GIMP،وبهذا سننتقل إلى برنامج سكريبوس Scribus. إنشاء النص اذهب إلى برنامج سكريبوس. اختر قائمة ملف File ثم جديد New. اقبل الإعدادات الافتراضية ثم اضغط على موافق OK. أنشئ إطار نص كبير بعرض صفحة A4. انقر نقرًا مزدوجًا على الإطار واكتب النص (اكتب النص "CRASH" على سبيل المثال). انتقل إلى نافذة خصائص Properties ثم نص Text، أو يمكنك الانتقال إلى نافذة خصائص المحتوى من قائمة نوافذ في الإصدار 1.5.7، بعد ذلك حدّد الخط الذي تريد استخدامه (اخترنا الخط "Crash Scene" في مثالنا). اضبط حجم الخط على 120 نقطة أو الحجم الذي تريده، لكن اختره كبيرًا. افتح قائمة "الألوان والمؤثرات Color & Effects"، وحدّد اللون الذي تريد استخدامه. في مثالنا هذا اخترنا اللون الأحمر القياسي، ولكن يمكنك اختيار اللون الذي تريده. تطبيق قناع على النص حدّد إطار النص ثم اختر قائمة عنصر Item ثم "تحويل لـ Convert To"، ثم اختر مخططات تفصيلية Outlines. أعد تحديد النص وانقر بزر الفأرة الأيمن، ثم اختر فك التجميع Ungroup من القائمة. اختر قائمة عنصر Item ثم أدوات المسار، بعد ذلك ادمج المضلعات Combine Polygons. أعد تحديد النص المحوَّل وانقر بزر الفأرة الأيمن واختر تحويل إلى Convert to، ثم اختر إطار صورة Image Frame من القائمة. انقر بزر الفأرة الأيمن فوق إطار الصورة الجديد، واختر الخيار "استيراد صورة ‎"Get Image من القائمة. حدد ملف PNG الذي صدّرته من جيمب GIMP ثم اضغط على موافق. انقر بزر الفأرة الأيمن على النص واختر "اضبط الصورة إلى الإطار Resize Image to Frame" من القائمة. الخلاصة تهانينا! بهذا تكون قد أنهيت كل شيء، ويمكنك محاولة تجريب ألوان وأنماط مختلفة، وبما أن النص قد أصبح الآن شكلًا، فيمكنك أيضًا محاولة ضبط التعبئة لتكون تدرجًا لونيًا Gradient وراقب ما يحدث. يمكن أن يمنحك استخدام خطوط مختلفة وبتعبئات مختلفة جميع أنواع التأثيرات غير العادية والمفيدة، كما يمكنك استخدام تقنية مماثلة على العديد من أنواع الكائنات الأخرى في برنامج سكريبوس. يمثّل الشكل التالي مثالًا يختلف فيه الخط ويكون لون التعبئة أخضر، ولكن القناع هو نفسه. ويمثّل الشكل التالي مثالًا، حيث جرت تعبئة وجه مبتسم بتدرج لوني نصف قطري من اللون السماوي إلى الأبيض، كما جرى تغيير لون التعبئة في برنامج جيمب GIMP إلى اللون الأبيض بدلًا من الأسود. أو يمكنك استخدام مرشّح Filter مختلف -Qbist مثلًا- لإنشاء قناع الطبقة، مع استخدام تدرج لوني خطي حر Free Linear Gradient مع العديد من نقاط التوقف اللونية كما في الشكل التالي: لا يوجد حصر للاحتمالات تقريبًا، لهذا استمتع بالتجربة. ترجمة -وبتصرّف- للمقال How to create a distressing mask to make more interesting fill effects. اقرأ أيضًا خطوات تطوير شعار باستخدام برنامج سكريبوس Scribus كيفية إنشاء الظلال في برنامج سكريبوس Scribus كيفية إنشاء أشكال معقدة ذات زوايا دائرية في برنامج سكريبوس Scribus

سنأخذك في هذا المقال عبر عملية إبداعية خيالية لإنشاء شعار شركة جديد من مرحلة الرسم الأولى، وصولًا إلى نموذج ثلاثي الأبعاد، كما سترى كيفية استخدام تطبيقات مختلفة مجانية ومفتوحة المصدر لإنشاء الشعار من البداية إلى النهاية. لن نوضّح كيفية إنشاء الشعار خطوةً بخطوة، فقد أنشأنا الشعار بالفعل على أمل أن يكون مصدر إلهام للأشخاص الذين قد يرغبون في إلقاء نظرة على برامج مختلفة ولكنهم لا يعرفون من أين يبدأون أو ما يمكنهم فعله بهذه البرامج؛ أما جميع التطبيقات المستخدَمة هنا فهي مجانية تمامًا للتنزيل والاستخدام دون قيود. الرسم الأولي سنكلّفك بمهمة إنشاء شعار لمشروع تجاري جديد يؤجّر اليخوت لقضاء العطلات، وهنا افترض أن العميل قد أعطاك موجزًا للتصميم مخصصًا لشعار بسيط يُظهر شيئًا قد تراه على أحد اليخوت/ ولنستخدم صورة نافذة اليخت مع إطلالة على البحر من وراء النافذة. ستحتاج أولًا إلى رسم أولي، وهو أي شيء لإعطاء العميل فكرةً عما ستنشئه، ولهذا عليك باتباع ما يأتي: افتح برنامج سكريبوس Scribus وأنشئ مستندًا فارغًا. أظهر الشبكة وتتبعها لتسهيل عملية الرسم. أنشئ ثلاثة ألوان جديدة، هي الأزرق الفاتح والأزرق المتوسط والأزرق الداكن. أنشئ دائرةً كبيرةً بداخلها دائرة أصغر قليلًا. استخدم عملية المسار Path Operation لقص الدائرة الأصغر من الدائرة الأكبر لإنشاء حلقة. املأ الحلقة باللون الأزرق الداكن وأزل الحدود الخارجية outline. أنشئ دائرةً أصغر داخل الحلقة. ارسم خطًا منحنيًا يسمى بخط بيزير عبر الدائرة وعدّله لتشكيل شكل موجة. اجعل الخط أثخن وحوّله إلى حد Stroke. اطرح الخط من الدائرة واقسمه لإنشاء شكلين جديدين. لوّن الشكل العلوي باللون الأزرق الفاتح، والشكل السفلي باللون الأزرق المتوسط (مع إزالة الحدود الخارجية أيضًا). لديك الآن الرسم الأولي الموضَّح في الشكل التالي لتريه للعميل: لنفترض أن العميل قد أحب الفكرة، ولكنه يريد جعل الشعار أكثر"ديناميكية" لإظهار الضوء عليه. هنا يمكن تنفيذ الأمر من خلال الخطوات التالية: أنشئ لونًا جديد من اللون الأزرق الفاتح (الأبيض تقريبًا). غيّر تعبئة الشكل العلوي لتكوين متجه ذو تدرج لوني حر بين اللون الأزرق الفاتح ولون الشكل الأصلي. انقل متجه التدرج اللوني إلى شكل قطري من أعلى اليسار إلى أسفل اليمين داخل حدود الحلقة الخارجية. طبّق الشيء نفسه على الشكل الآخر، ثم الشيء نفسه على الحلقة. لتتشكّل لديك نسخة "مضاءة" من الشعار كما في الشكل التالي: وبافتراض أن العميل قد توقع شيئًا ثلاثي الأبعاد، فعلينا أن نطبّق ذلك. الإصدار الثاني من الشعار أدوات رسوميات برنامج سكريبوس جيدة، لكنها لا تستطيع التعامل مع التأثيرات المعقدة بسهولة، لذلك لننتقل إلى برنامج إنكسكيب Inkscape. أنت تعلم أيضًا أن برنامج سكريبوس يمكنه حفظ الصفحات مثل ملفات SVG، والتي يمكن لبرنامج إنكسكيب التعامل معها، وبالتالي فأنت لست بحاجة إلى رسم الشعار مرةً أخرى، ويمكنك اتباع ما يأتي فقط: صدّر الشعار كملف SVG من برنامج سكريبوس. افتح برنامج إنكسكيب وحمّل الشعار. تأكد من أن كل شيء يبدو على ما يرام ولكن احتفظ بالشعار بأكمله مجموعة. طبّق المرشّح "Bevel / Button" على الشعار، وعدّل هذا المرشّح مع تغيير مصدر الإضاءة إلى بقعة ضوء Spot Light للحصول على تأثير "ثلاثي الأبعاد" جميل كما في الشكل التالي: يبدو هذا الشكل جيدًا، ولكن جرّب المرشّح "ميلان Bevel / حد بارز Raised Border" بدلًا من ذلك، إذ ستحصل على شيء يبدو جميلًا أيضًا ولكن بطريقة مختلفة مثل الشكل التالي: ثم جرّب استخدام التأثير "ظلال Shadows / وميض مقطوع Cutout Glow"، والذي يبدو أيضًا رائعًا مثل الشكل التالي: تُعَد كل الخيارات الثلاثة السابقة جيدة، ولكن لنستخدم الإصدار الذي طبّقنا عليه المرشّح "Button"، مع الحرص على جعله يبدو "ثلاثي الأبعاد". ارسم شكل شبه منحرف بحيث يكون الجانب الأيسر له أقصر من الجانب الأيمن، واستخدم المسار إضافات Extensions ثم تعديل المسار Modify Path، ثم المنظور Perspective لإعطاء الشعار منظور مثل الشكل التالي: وهنا أحب العميل ذلك، ولكنه يريد شيئًا ثلاثي الأبعاد فعليًا. الانتقال تعلم أن برنامج إنكسكيب يمكن أن ينتج بعض التأثيرات ثلاثية الأبعاد الرائعة، لكنك تدرك أن أي تغييرات أخرى قد يرغب فيها العميل ستستغرق وقتًا طويلًا لتغييرها عند رسمها في برنامج إنكسكيب، إذ سيؤدي مجرد تغيير الزاوية قليلًا إلى حدوث الكثير من المتاعب، إلا إذا طبّقت كل شيء تطبيقًا صحيحًا. إذًا لننتقل إلى برنامج بلندر Blender. بما أن برنامج بلندر يمكنه أيضًا استيراد ملفات SVG، فلن تضطر إلى إعادة رسم الشعار مرةً أخرى، ولكنك ستحتاج إلى تنظيف ملف SVG قبل الدخول إلى برنامج بلندر لتسهيل التعديل لاحقًا، لهذا اتبع ما يلي: أعِد تحميل ملف SVG الأصلي (الذي صدّرناه من برنامج سكريبوس) إلى برنامج إنكسكيب. فُك تجميع الشعار. حدّد الحلقة فقط وانتقل إلى قائمة مسار Path ثم تبسيط Simplify. كرّر الشيء نفسه مع الشكلين الآخرين. احفظ الرسم المبسَّط حديثًا كملف جديد. التطبيق ثلاثي الأبعاد 3D افتح برنامج بلندر Blender واستورد الشعار المبسَّط كملف SVG الذي حفظته من برنامج إنكسكيب. كبّر الشعار المستورَد لتتمكّن من رؤيته بصورةٍ أفضل، وانقله إلى المركز، ثم أعِد النسخة الأصل إلى مركز شبكة بلندر. حدّد كل شكل على حدة وامنح كل شكل مادة Material جديدة باللون الصحيح كما في الشكل التالي: أخرِج Extrude الحلقة بمقدار 0.004، وأعطها ميلانًا Bevel بمقدار 0.002، مع إزاحةٍ قدرها ‎-0.002 ودقة Resolution بمقدار 2. كرّر الشيء نفسه مع الشكلين الآخرين ولكن أخرِجهما بمقدار 0.003 بدلًا من ذلك، وهذا لإبقائهما "داخل" الحلقة. يُعَد الشكل السابق جيدًا، ولكن هناك مشكلة في "زوايا" الأشكال وهو ما يوضّحه الشكل التالي: بما أن البرامج Scribus وInkscape وBlender لا تتعامل مع المنحنيات بالطريقة نفسها تمامًا، فيمكن أن تكون ثمة اختلافات عند نقل الرسومات فيما بين هذه البرامج، وهذا يعني أنه يجب إصلاح هذه الزوايا الآن، إذ لن يحب عميلك الأشكال ذات الزوايا الغريبة. تذكّر أن تحفظ نموذجك قبل أن تبدأ بالتغيير لتتمكّن من العودة إلى هذا النموذج عند حدوث فوضى. سنستخدم إصلاحًا سريعًا يعمل مع هذا النموذج، لذلك يجب عليك إصلاح النماذج الخاصة بك إصلاحًا صحيحًا، وذلك باتباع الخطوات الآتية: حدد أحد الأشكال وانتقل إلى وضع التحرير Edit Mode. اسحب عقدة الرأس المحدَّد على طول الشكل لمنعها من القطع في نهاية الشكل. كرّر الشيء نفسه على الشكل الآخر. يبدو كل شيء أفضل الآن، إذًا لنُعِدّ المشهد باتباع الخطوات الموالية: غيّر المصباح Lamp ليصبح بقعة Spot، ودوّره ليشير إلى أعلى يسار الشعار. حرّك الكاميرا ودوّرها لتظهِر الجانب الأيمن من الشعار. اضبط بيئة الإضاءة Environmental Lighting على الإعداد الافتراضي 1. اضبط تظليل ألفا للمشهد على القيمة شفاف Transparent. صيّر Render المشهد واحفظ النتيجة المصيَّرة في ملف. اعرِض الشعار الجديد -الموضَّح في الشكل التالي- على العميل الذي سيعجبه العمل كثيرًا، لكنه يريد رؤيته عمليًا مع إضافة ظل له. التعديلات النهائية حان الوقت الآن لإجراء مزيد من المعالجة بعد أن حصلتَ على الصورة الأساسية، ولكننا في هذه المرة سنستخدم برنامج جيمب GIMP. انتقل إلى برنامج جيمب GIMP وحمّل الصورة التي صدّرتها للتو من برنامج بلندر. أضف تأثير الظل من خلال قائمة Filters ثم اختر Light and Shadow ثم Drop Shadow. استخدم أداة التحديد الدائرية Ellipse Select لتحديد المنطقة الموجودة حول الشعار والظل، بعد ذلك أنشئ فراغًا بين الشعار / الظل والتحديد. أنشئ مسارًا Path من التحديد. قص الصورة وفق التحديد (للتخلص من المنطقة غير الضرورية). احفظ الصورة الجديدة بتنسيق TIFF. تجربة الشعار عمليا ارجع إلى برنامج سكريبوس وأنشئ مستندًا جديدًا. أنشئ إطار صورة وضَع صورة شعارك فيه. غيّر حجم الصورة و/ أو حجم الإطار حتى يبدو كل شيء صحيح. انقر بزر الفأرة الأيمن ثم اختر "خصائص الصورة الموسّعة Extended Image Properties". اختر المسار الدائري ثم موافق. فعّل مسار القطع Clipping Path من تبويب شكل Shape في نافذة خصائص. أضف نصًا وخلفيةً حول الصورة، ثم انقل الصورة إلى الأعلى بحيث يتدفق النص حولها. وبهذا يكون قد أصبح كل شيء جاهزًا للعميل. الخاتمة لقد رأينا في هذا المقال كيف تعاملت تطبيقات مختلفة مع رسم أولي مُنشَأ في برنامج سكريبوس للحصول على نموذج ثلاثي الأبعاد مكتمل، ثم العودة إلى برنامج سكريبوس مرةً أخرى، وبذلك رأينا روعة هذه البرامج المجانية. ترجمة -وبتصرّف- للمقال Evolution of a logo. اقرأ أيضًا كيفية إنشاء الظلال في برنامج سكريبوس Scribus كيفية بدء استخدام برنامج سكريبوس Scribus كيفية إنشاء أشكال معقدة ذات زوايا دائرية في برنامج سكريبوس Scribus كيفية إنشاء مجموعة ثلاثية الأبعاد من الأحرف في Adobe Photoshop كيفية تصميم شعار شارة بيسبول باستخدام برنامج Adobe Illustrator

لا يحتوي برنامج سكريبوس Scribus على طريقة لإنشاء ظلال Drop shadow مضمَّنة به، لهذا يمكنك بالتأكيد استخدام برنامج جيمب Gimp أو إنكسكيب Inkscape لإنشاء بعض التأثيرات التي تشبه الظل المسقَط Drop shadow، ثم تستورده في شكل صورة. سنعرض في هذا المقال طريقةً تُظهر الظلال كأنها منشَأةً بالكامل ضمن برنامج سكريبوس. تجدر الإشارة إلى أن الإصدار 1.5.7 الجديد والداعم للغة العربية، والذي مازال في وضع التطوير من برنامج سكريبوس؛ يحتوي على خيار تطبيق الظل للعناصر في تبويب "ظل ساقط Drop shadow" من نافذة خصائص. ولكن تعلّم طرق إضافية لتشكيل الظلال سيكون مفيدًا لإجراءات مختلفة في مشاريع مستقبلية لزيادة المهارة والمعرفة في استخدام البرنامج. المشكلة سنستخدم التدرجات اللونية Gradients لتشكيل الظلال، لكن تكمن الصعوبة في أنه إن أردنا إنشاء ظلال لكائن له شكل مستطيل، فلا يوجد تدرج مناسب يعمل بهذه الطريقة، حيث يتشكّل تلاشٍ أفقي عند الحواف الرأسية وآخر رأسي عند الحواف الأفقية كما في الشكل التالي: الحل يجب أن نذكر في البداية أن هذه الطريقة ليست مثالية، ولكن ما سنفعله هو إنشاء قالب مربّع مولَّف من عناصر ذات أشكال مثلثة، وترتيب التدرج اللوني في كل جزء حتى نحصل على تدرجات لونية في الحواف جميعها في الاتجاه الصحيح. سنحصل في النهاية على كائن مجمَّع يمكنك حفظه في سجل القصاصات الخاص بك (من قائمة عنصر ثم اختر "أرسل إلى"، بعد ذلك اختر "سجل القصاصات")، ثم إعادة استخدامه وتغيير حجمه حسب الحاجة وبالطريقة التي تريدها، حيث سننشئ الشكل التالي: يتكوّن هذا الشكل من 4 مثلثات، وهي مثلثات قائمة الزاوية لأن الشكل الناتج هو مربع، وأوتار هذه المثلثات لها نفس الطول. سنرسم مثلثين منها فقط، ثم ننسخ المثلثين الباقيين، حيث تكون خصائص المثلث الأول كما يلي: حيث يجب أن يُظهِر المثلث الآخر دورانًا بمقدار 60 درجة. ويمكنك ملاحظة أن حجم وأبعاد هذه المثلثات عشوائية. فوائد الخصائص يجب أن تكون هذه المثلثات قائمةً ومتساوية الأضلاع أيضًا، وبالتالي فإن الارتفاع يساوي نصف القاعدة بالضبط. ليس هناك داعٍ لإجراء حسابات مثلثات، لأنه يمكننا رؤية تلامس المثلثات في وسط المربع. لقد ضبطنا المثلث الأول بحيث يكون الارتفاع 250 نقطة والعرض 125 نقطة، وضبطنا المثلث الآخر بحيث يكون العرض 250 نقطة والارتفاع 125 نقطة. قد يكون وضع المثلثين في المكان الصحيح أمرًا صعبًا، ولكنه سيكون أسهل باستخدام الخصائص، لهذا اختر أرقامًا مُقرَّبةً لقيم X-Pos وY-Pos، ثم طابِق قيم المثلثين لتحصل على الشكل التالي: حدّد الإطارين السابقين، ثم انتقل إلى قائمة عنصر Item واختر "مضاعفة/تحويل"، ثم اختر نُسخ مطابقة Multiple Duplicate، وانسخ نسخةً واحدةً مع ترك المواضع للإزاحة الأفقية والرأسية عند القيمة 0. سيبدو وكأنه لم يحدث شيء، ولكن هذا بسبب وجود نسخة من كل منهما فوق النسخ الأصلية. اضغط باستمرار على مفتاح Shift، وحدّد المثلثين العلويين (نريد الطبقة العليا فقط)، بعدها اقلب أحد المثلثين أفقيًا، ثم اقلب الثاني رأسيًا أو بالعكس حتى تحصل على الشكل التالي: الألوان والتدرجات اللونية Gradients لنعمل الآن على كل مثلث واحدًا تلو الآخر. لقد تركنا اللون الافتراضي للحدود باللون الأسود حتى الآن رغم أننا لا نريدها، لذلك اجعل المثلثات بلا حدود. سيحتاج المثلثان العلوي والسفلي إلى تعبئة متدرجة رأسية، بينما يحتاج المثلثان اليميني واليساري إلى تعبئة متدرجة أفقية. سنستخدم في هذا المثال اللونين الأسود والأبيض فقط، ولكن يجب أن يكون اللون الأبيض على الجهة الخارجية للمربع النهائي. إذا تركت علامة اللون الأسود عند قمم المثلثات، فلن يكون هناك لون كافٍ عند الحافة الخارجية ليَظهر هذا التدرج اللوني، لذلك نقترح تحريك علامة اللون الأسود بنسبة 80% على الأقل عن موضع البداية، حيث ستكون الإعدادات الفعلية إما 80% أو 20% نظرًا لوجود مثلثات متقابلة، وهنا اختر القيمة التي تناسبك بحيث يكون المظهر النهائي هو دليلك لاختيار القيمة الصحيحة. استخدام برنامج سكريبوس كأداة فنية يقولون أن الخَبز علم والطبخ فن، ولكن يمكن القول أن برنامج سكريبوس هو علم وفن في آن واحد. لقد اخترنا جميع الأرقام الصحيحة مثل الارتفاع والعرض وقيم X-Pos وY-Pos، ولكن ظهر هذا التقاطع الأبيض الرفيع في المربع السابق، وهو حقيقي وسيظهر في ملفات PDF النهائية التي ستنشئها. استمر بالضغط على المفتاحَين Shift وAlt، إذ يمكنك التحرك ضمن مئات من النقاط مع تحريك كل مثلث نحو المركز. وبعد تحريك كل من المثلثات الأربعة بمقدار 0.06 نقطة (0.021 مم أو 0.001 بوصة) باتجاه المركز، يمكنك استخدام ميزة تقريب Zoom in عالية في برنامج سكريبوس على الأقل بمقدار 800 إلى 1600%، ويمكنك في النهاية التحقق بعد التصدير إلى ملف PDF من وجود هذا التقاطع الأبيض الذي قد يكون أحد أسبابه أنه كلما اقتربت من المثلثات، فستبدأ في رؤية تأثير حافة يشبه التجعّد في الزوايا. لا تنس عملية الحفظ اجمع المثلثات في مجموعة ثم احفظها في سجل القصاصات Scrapbook وستصبح بعد ذلك جاهزةً للاستخدام. بهذا نكون قد صنعنا مربعًا في النهاية، لكن يمكننا أن نمده بهذه الطريقة تلبيةً لاحتياجاتنا، لهذا ضَع ما يحلو لك من الإطارات الأخرى، لكن سيحتاج إطار النص إلى تحديد لون خلفيته. النتيجة يوضّح الشكل الآتي مثالَين عن بعض حالات الاستخدام مع إطار نص وإطار صورة، حيث تركنا سابقًا القليل من الظل في الجزء العلوي واليميني لتحديد حواف الإطار (التُقطت لقطة الشاشة هذه من برنامج Adobe Reader، لذلك فهذه ليست حواف الإطار التي يمكن رؤيتها في برنامج سكريبوس)، بحيث يبدو الظل أغمق خلف إطار النص، وقد يرجع ذلك فقط إلى التباين بين اللون الأبيض وحواف الصورة الداكنة. لاحظ أيضًا أنه يمكنك ضبط تعتيم opacity الظل لتفتيحه حسب الحاجة، مما يقلل بصريًا من تأثير تجعد الزاوية. إذا أردت استخدام ألوان أخرى، فخذ نسخةً من سجل القصاصات الخاص بك وفك تجميعها، وغيّر الألوان حسب الرغبة. وضعنا في المثال الآتي عنصر سجل القصاصات على صفحة مخصَّصة أكبر من حجم الكائن بقليل، ثم صدّرنا الصفحة كملف TIFF، واستوردناها إلى برنامج جيمب Gimp، وبعد ذلك طبّقنا تمويهًا في برنامج جيمب، وذلك من النوع Gaussian blur لتنعيم الحواف والمحتوى، ثم صدّرناه بتنسيق TIFF لتحميله في ملف صورة. يمكنك ضبط إعدادات الصور من خلال تحديد الخيار "ملائمة حجم الإطار Scale to Frame Size" من نافذة خصائص الصورة التي تصل إليها من خلال قائمة "نوافذ" ثم خصائص المحتوى، لكن اترك الخيار "نسبي Proportional" دون تحديد، حتى تتمكن من ضبط حجم إطار الصورة ومحتوياته حسب الحاجة. يمكنك حفظ هذا الإطار في سجل القصاصات الخاص بك لاستخدامه لاحقًا. يحتوي برنامج Gimp على العديد من أنواع التمويه المختلفة ولكل منها إعدادات مختلفة للحصول على الشكل الذي تريده. ترجمة -وبتصرّف- للمقال Drop Shadows. اقرأ أيضًا كيفية بدء استخدام برنامج سكريبوس Scribus كيفية إنشاء أشكال معقدة ذات زوايا دائرية في برنامج سكريبوس Scribus كيفية إنشاء مجموعة ثلاثية الأبعاد من الأحرف في Adobe Photoshop

يُصنَّف هذا المقال تحت عنوان "التحوّل من التقليدية إلى الرقمية"، وسنعرض كل الخطوات التي نستخدمها للرسم والمسح الضوئي وتنظيف الخطوط التقليدية، عند استخدام هذه التقنية مع قصص الويب المصورة مثل المُستخدمة في موقع Pepper&Carrot. سنوضّح أولًا سير العمل من الرسم ثم "التحبير" ولكن بالقلم الرصاص، ثم سنمسح الخطوط ضوئيًا وننظّفها في برنامج Krita للاحتفاظ بالخطوط المرسومة بقلم الرصاص فقط، وسنوضّح بعد ذلك كيفية تلوين الخطوط، وجعلها شفافة لتكون جاهزةً لتلونيها كاملةً لاحقًا. 1. الاستعداد ابدأ برسم رسومات صغيرة عشوائية على ورقة قياسها A4، حيث سنرسم تعبيرات الوجه عادةً أولًا، ثم الحركات والصور المصغَّرة thumbnails أحيانًا، ولا يُفترَض أن يبدو الرسم جيدًا تمامًا لتضعه في كتاب، فهو رسمٌ عشوائي ومسودةٌ تحتفظ بها لنفسك، حيث سنرسم هذه المسودة من أجل ألا نشعر بالضغط عند رسم أشكالٍ سيئة على الورقة النهائية، وقد اخترنا صورةً مصغَّرة لنعمل عليها من بين جميع الرسمات العشوائية الأخرى، وحدّدناها باللون البرتقالي في الشكل التالي. قد تكون هذه الصورة المصغَّرة تركيبةً كلاسيكيةً ومبتذلةً قليلًا للركض والقفز، لكن لنراها بتفاصيل أكثر. 2. الخطوط التوجيهية Guidelines نبدأ أولًا بأخذ المكان المناسب للرسم، ثم نرسم الخطوط التوجيهية على ورقة جديدة كما في الشكل الآتي. أبقِ هذه الخطوط خفيفةً ودقيقةً للغاية، مع ضغط خفيف جدًا على القلم الأزرق. يمكنك استخدام علامة الرصاص التجارية التي تريدها، ولكن ننصحك باستخدام الرصاص Pentel Blue lead 0.5mm، كما يمكنك استخدام أقواس كبيرة في الرسم بحيث تحافظ على الأشياء دون تفاصيل، مع وجوب التعامل مع القلم أيضًا بصورةٍ مختلفة عن المعتاد، بحيث لا ترسم باستخدام الرسغ أو الإصبع، ولكن أشرِك الذراع بأكملها في رسم الخطوط. 3. الرسم باللون الأزرق Blue sketch تابع الرسم بقلم الرصاص الأزرق وأضِف التفاصيل، وابذل قصارى جهدك لبناء الخطوط الرئيسية مع إبقاء الأشكال بسيطة، إلى جانب اترك مساحة للحصول على حرية للخطوة التالية، إذ ليس الهدف الأساسي عمل رسم أزرق مثالي ثم إعادة رسم كل خط من الخطوط، فذلك سيكون مملًا. 4. المسح Erasing امسح الرسمة الزرقاء برفق باستخدام ممحاة مطاطية، إذ تُعَد عملية مسح خطوط Pentel الزرقاء أمرًا صعبًا، لذلك لا تخاطر بفقدان جزء من الرسم. يكون الغرض من هذه الخطوة هو تسهيل إزالة خط الرسم باستخدام برنامج Krita لاحقًا، لأنه سيكون داكنًا بصورة أقل، وستوفّر هذه الخطوة الحرية لعملية التحبير inking، وسيسهّل لنا الرسم الساطع عملية إخراج خطوط قلم الرصاص الداكنة. 5. التحبير Inking دون حبر حبّر رسومك باستخدام قلم رصاص 0.5mm B، فهو ناعم على الورق ويسمح باختلافات رمادية داكنة وفاتحة، وهو دقيق جدًا أيضًا. 6. مسح الرسومات ضوئيا Scan لقد استخدمنا هنا برنامج Xsane لنظام تشغيل Linux Xubuntu 14.04 من الحزمة الافتراضية، حيث يمكننا إعداد Xsane لالتقاط الصورة من الماسح الضوئي، وحفظها تلقائيًا بتنسيق PNG 300dpi مع الألوان تلقائيًا على قرص الحاسوب الصلب. 7. الانتقال إلى برنامج Krita افتح الملف في برنامج Krita، حيث أنّ التعديلات الوحيدة التي أجريناها على تثبيت برنامج Krita هي استخدام مظهر داكن واستخدام إعدادات لأحدث مجموعة من الفُرَش. يمكنك الحصول على الملف الخام الممسوح ضوئيًا من المصادر في نهاية هذا المقال. 8. القص Cropping يمكن تدوير الصورة من خلال الانتقال إلى قائمة Image، ثم تدوير Rotate، بعدها تدوير الصورة بمقدار 90 درجة إلى اليمين واختيار أداة القص، مع تفعيل الخيار Thirds Decoration من خيارات الأداة، إذ تساعد هذه الخطوط في إعداد عملية قص أفضل. وقد أضفنا الصورة تحت الخط الأخضر لإظهار خطوط التكوين التي نريدها. 9. منحنيات ضبط اللون في المرشح Filter افتح قائمة Filter ثم اختر Adjust، ثم منحنيات ضبط اللون Color Adjustement curves، وأجرِ تسويةً لقناة اللون الأحمر والأخضر كما في الشكل الآتي دون لمس قناة اللون الأزرق، وبالتالي يجب أن تحصل على صورة زرقاء كاملة، وستدمج بذلك البيانات الزرقاء للرسمة مع كل هذا اللون الأزرق، وبالتالي ستُزال الخطوط الزرقاء نوعًا ما. اضغط على تعديل الإعدادات المسبقة "Edit Presets" في الزاوية العلوية اليمنى، ثم اضغط على "Bookmark current"، حيث سيُضاف إعدادك المسبق إلى القائمة كما في الشكل الآتي، ويمكنك أيضًا إعادة تسمية العنصر بالنقر بزر الفأرة الأيمن، مثل اسم الإعداد المسبق التالي الذي هو "RGB->Blue only". 10. إزالة التشبع الأقصى Desaturate Max سنزيل الآن كل اللون الأزرق من عملنا الفني من خلال الذهاب إلى قائمة Filter ثم Adjust، وبعدها Desaturate، مع استخدام الخيار Max من القائمة. 11. تعديل القيم باستخدام المستويات Levels افتح المستويات Levels من خلال الانتقال إلى قائمة Filter ثم Adjust، وبعدها Levels، ثم حرّك مؤشر المثلث الأسود الصغير ليبدأ الرسم البياني في إظهار البيانات ونظّف جميع الضوضاء البيضاء الرمادية. ستحصل عادةً على جبل صغير في الرسم البياني على الجزء الأبيض (اليميني) الذي يجب تنظيفه عند مسح الورقة ضوئيًا، بحيث يجب قص اللون الأسود أيضًا لأننا نريد تجنب وجود بكسلات سوداء على الخطوط. 12. التنظيف اليدوي لديك الآن الوقت لتأخذ فرشاة وتختار اللون الأسود أو الأبيض، ثم تصلح عملك الفني بطريقة رقمية. لا تستخدم اللون الأسود كاملًا بل الأسود بنسبة 90%، لذلك استخدم محفوظات ألوانك في محدّد الألوان المتقدم advanced color selector لاسترداد اللون في كل مرة تحتاجه فيها، بعدها نظّف الشيء الذي لا تريده يدويًا، أو أعِد رسم الخط الذي لم يعجبك، أو شوّه الرسم بالكامل وحوّله إلى شيءٍ آخر. بهذا نكون قد رسمنا هنا باستخدام فرشاة صغيرة ونظّفنا باستخدام إعداد مسبق أكبر مثل الفرشاة الدوّارة، إذ نظّفنا باستخدام التلوين باللون الأبيض فوق كل البقع الرمادية الداكنة الصغيرة. 13. تلوين الخطوط افتح قائمة Filter ثم اختر Adjust، بعدها HSV Adjustement، وانقر على تلوين "Colorize"، بعدها يمكنك ضبط الصِبغة hue والتشبّع اللوني saturation، ولا نوصي بتعديل الإضاءة Lightness، فاللون الذي اخترناه هنا هو Burnt Sienna الداكن. احفظ الإعدادات المسبقة إذا كنت بحاجة إلى العثور على إعدادات اللون نفسها في المرة القادمة. 14. إزالة اللون الأبيض يجب الاحتفاظ بخطوط الرسمة فقط، لذلك نحتاج إلى إزالة الخلفية البيضاء، ولكن الصورة مسطحة. يمكن الوصول إلى المرشح الذي يعالج هذه المشكلة من خلال الانتقال إلى قائمة Filter ثم Colors ثم Color to Alpha، حيث يكون الإعداد الافتراضي لهذا المرشح هو إزالة الأبيض النقي، وتكون العتبة الافتراضية مثاليةً لهذه المهمة. 15. إدارة الطبقات أزلنا الخلفية البيضاء من الرسمة ثم سننشئها مرةً أخرى، ولكنها ستكون هذه المرة على طبقة منفصلة تحت الرسمة من خلال إنشاء طبقة جديدة، ووضعها تحت الرسمة. املأ هذه الطبقة باللون الأبيض من خلال تحدّد اللون الأبيض، ثم انتقل إلى قائمة Edit ثم Fill أي املأها باللون الأمامي، بعدها أعِد تسمية الطبقات ليكون مشروعك أوضح. 16. حفظ الصورة احفظ عملك الفني باسم مثل الشكل: kra.*. 17. خطوط الرسم النهائية الصورة التالية هي نسخة نهائية ذات دقة منخفضة، فإذا أردت إلقاء نظرة على الدقة الكاملة، فنزلها من خلال الرابط الموجود في نهاية هذا المقال. الملخص قد تبدو هذه الطريقة لإزالة الخطوط الزرقاء معقدةً وطويلةً لأننا فصّلنا الخطوات باستخدام ملاحظات وصور متعددة، ولكن ستكون مدة هذه المهمة 3 دقائق بمجرد إتقانها، ويمكنك تكرارها بسهولة على حزمة من عشر صفحات من رسوم الويب المصورة في أقل من 30 دقيقة، والمعلومات الرئيسية التي يجب تذكره هي: منحنيات ضبط اللون وجعل الصورة زرقاء من خلال تسوية قنوات الأحمر والأخضر بنقرتين باستخدام إعداد مسبق. إزالة التشبّع الأقصى Desaturate Max بنقرتين مع أو بدون إعداد مسبق. الأجزاء الأخرى سهلة للغاية ضمن سير العمل (القص والتباين وإزالة ألفا)، فهي هذه الطريقة هي الأسرع من بين كل الطرق المستخدمة في برنامج Gimp أو Photoshop، وتعطي أفضل النتائج وتتمحور حول برنامج واحد هو Krita. النتيجة بهذا يكون الملف قد أصبح جاهزًا لتلقّي طبقة تلوين بين طبقة الخلفية وطبقة الخطوط. الملفات المصدرية .Raw scanner (PNG, 300dpi, Xsane). .End .kra files ready to color (Krita 2.8.5, .kra). يمكن تنزيلها من sta.sh حيث حجمها 11 ميجابايت. ترجمة -وبتصرّف- للمقال Clean blue sketch traditional line-art to color it digital with in Krita لصاحبه David Revoy. اقرأ أيضًا أفضل مؤشر في برنامج كريتا Krita لإنشاءعملك الفني تحبير مسودة الرسم في كريتا استخدام الألوان في نمط التصاميم المسطحة في كريتا خطوات العمل المعتادة في كريتا

لربما من غير المفاجئ أن تعلم أن الأجهزة المتنقلة تمثّل بعض التحديات لِمعمارية الإنترنت. صُمِّم الإنترنت في عصرٍ كانت فيه الحواسيب كبيرة وغير متحركة، وبينما كان لدى مصممي الإنترنت على الأرجح فكرة أن الأجهزة المتنقلة قد تظهر في المستقبل، فمن العدل أن نفترض أنها لم تكن أولويةً قصوى لاستيعابها. توجد اليوم الحواسيب المتنقّلة في كل مكان، لا سيما على شكل حواسيب محمولة laptops وهواتف ذكية smartphones، وبصورةٍ متزايدة في أشكال أخرى، مثل الطائرات بدون طيار drones. سنلقي نظرةً في هذا القسم على بعض التحديات التي يفرضها ظهور الأجهزة المتنقّلة وبعض الأساليب الحالية لاستيعابها. تحديات الشبكات المتنقلة من السهل اليوم الظهور في نقطة اتصال لاسلكية، والاتصال بالإنترنت باستخدام المعيار 802.11 أو بعض بروتوكولات الشبكات اللاسلكية الأخرى، والحصول على خدمة إنترنت جيدة جدًا. إحدى تقنيات التفعيل الرئيسية التي جعلت نقطة الاتصال hotspot ممكنة هي بروتوكول DHCP. يمكنك الاستقرار في المقهى، وفتح الحاسوب المحمول، والحصول على عنوان IP لحاسوبك المحمول الذي يتحدث إلى موجهٍ افتراضي default router وخادم نظام أسماء النطاقات Domain Name System أو اختصارًا DNS، وبالتالي لديك كل ما تحتاجه بالنسبة لفئة واسعة من التطبيقات. ولكن إذا نظرنا عن كثب قليلًا، فمن الواضح أنه بالنسبة لبعض سيناريوهات التطبيقات، فإن مجرد الحصول على عنوان IP جديد في كل مرة تتحرك فيها، وهو ما يفعله بروتوكول DHCP لك، لا يكفي دائمًا. لنفترض أنك تستخدم الحاسوب المحمول أو الهاتف الذكي لإجراء مكالمةٍ هاتفية عبر بروتوكول الإنترنت الصوتي، وتنتقل من نقطة اتصالٍ إلى أخرى أثناء التحدث على الهاتف، أو حتى التبديل من شبكة Wi-Fi إلى الشبكة الخلوية للاتصال بالإنترنت. من الواضح أنك تحتاج إلى الحصول على عنوان IP جديد عندما تنتقل من شبكة وصول إلى أخرى، وهو عنوانٌ متوافق مع الشبكة الجديدة. ولكن لا يعرف الحاسوب أو الهاتف الموجود في الطرف الآخر من محادثتك على الفور المكانَ الذي انتقلت إليه أو عنوان IP الجديد الخاص بك. وبالتالي سيستمر إرسال الرزم إلى العنوان الذي اعتدت أن تكون فيه في حالة عدم وجود آلية أخرى، وليس إلى مكان وجودك الآن. هذه المشكلة موضحة في الشكل الآتي، حيث تحتاج الرزم من عقدة التراسل المقابلة correspondent node إلى إيجاد طريقها إلى الشبكة الجديدة ثم الانتقال إلى العقدة المتنقلة، عندما تنتقل العقدة المتنقلة من شبكة 802.11 في القسم (أ) إلى الشبكة الخلوية في القسم (ب) من الشكل التالي: هناك العديد من الطرق المختلفة لمعالجة المشكلة الموضحة للتو، وسنلقي نظرةً على بعضٍ منها. بافتراض وجود طريقة ما لتمرير الرزم بحيث تصل إلى عنوانك الجديد بدلًا من عنوانك القديم، فإن المشاكل التالية الظاهرة على الفور تتعلق بالأمن. إذا كانت هناك آلية يمكنك من خلالها أن تقول، "عنوان IP الجديد الخاص بي هو X" على سبيل المثال، فكيف يمكنك منع بعض المهاجمين من إصدار مثل هذا البيان دون إذنك، وبالتالي تمكينهم إما من استلام الرزم الخاصة بك، أو تمرير رزمك إلى طرف ثالث غير مقصود؟ وبالتالي نرى أن الأمن security والتنقل mobility مرتبطان ارتباطًا وثيقًا. إحدى القضايا التي أبرزتها المناقشة أعلاه هي حقيقة أن عناوين IP تخدم مهمتين في الواقع، فهي تُستخدَم مثل معرّفٍ identifier لنقطة النهاية، كما تُستخدَم لتحديد locate موقع نقطة النهاية. فكّر في المعرّف على أنه اسم طويل العمر لنقطة النهاية، ومحدّد locator الموقع على أنه بعض المعلومات المؤقتة المحتملة حول كيفية توجيه الرزم إلى نقطة النهاية. طالما أن الأجهزة لا تتحرك، أو لا تتحرك كثيرًا، فإن استخدام عنوان واحد لكلتا الوظيفتين يبدو معقولًا جدًا. ولكن بمجرد أن تبدأ الأجهزة في التحرك، فإنك تفضل أن يكون لديك معرّف لا يتغير أثناء التنقل وهذا ما يسمى أحيانًا معرّف نقطة النهاية أو معرّف المضيف، مع محدّد موقعٍ منفصل. كانت فكرة فصل محددات المواقع عن المعرّفات موجودةً منذ وقت طويل، ومعظم أساليب التعامل مع التنقل الموصوفة أدناه توفر مثل هذا الفصل بشكلٍ ما. يُظهر الافتراض بأن عناوين IP لا تتغير في العديد من الأماكن المختلفة. حيث وضعت بروتوكولات النقل مثل بروتوكولات TCP افتراضاتٍ تاريخية حول بقاء عنوان IP ثابتًا طوال عمر الاتصال على سبيل المثال، لذلك يمكن أن يتمثل أحد الأساليب في إعادة تصميم بروتوكولات النقل بحيث يمكنها العمل مع تغيير عناوين نقطة النهاية. البديل الشائع لمحاولة تغيير بروتوكول TCP هو أن يعيد التطبيق إنشاء اتصال TCP دوريًا في حالة تغيير عنوان IP الخاص بالعميل. قد يبدو هذا غريبًا، ولكن هذا هو بالضبط ما يحدث إذا كان التطبيق قائمًا على بروتوكول HTTP (متصفح ويب مثل كرومChrome أو تطبيق تدفق مثل نتفلكس Netflix على سبيل المثال). تتمثل الإستراتيجية في أن يعمل التطبيق حول الحالات الممكن أن يكون فيها عنوان IP الخاص بالمستخدم قد تغير، بدلًا من محاولة الحفاظ على المظهر الذي لا يتغير. بينما نحن جميعًا على دراية بنقاط النهاية التي تتحرك، فإن الموجهات يمكنها أيضًا التحرك. هذا بالتأكيد أقل شيوعًا اليوم من تنقل نقط النهاية، ولكن هناك الكثير من البيئات التي قد يكون فيها الموجه المتنقل منطقيًا. أحد الأمثلة هو فريق الاستجابة للطوارئ الذي يحاول نشر شبكةٍ بعد أن تسببت بعض الكوارث الطبيعية في تدمير جميع البنية التحتية الثابتة. هناك افتراضات إضافية عندما تكون جميع العقد في الشبكة، وليس فقط نقاط النهاية، متنقلة، وهو موضوعٌ سيُناقش لاحقًا. توجد نقطتان للتوضيح قبل أن نبدأ في إلقاء نظرة على بعض الأساليب لدعم الأجهزة المتنقلة. من الشائع أن نجد الناس يخلطون بين الشبكات اللاسلكية والتنقل. فغالبًا ما يُعثَر على التنقل واللاسلكية معًا. لكن يتعلق الاتصال اللاسلكي حقًا بالحصول على البيانات من العقدة A إلى العقدة B بدون سلك، بينما يتعلق التنقل بالتعامل مع ما يحدث عندما تتحرك العقدة أثناء اتصالها. من المؤكد أن العديد من العقد التي تستخدم قنوات الاتصال اللاسلكي ليست متنقلة، وتستخدم العقد المتنقلة اتصالًا سلكيًا في بعض الأحيان (على الرغم من أن هذا أقل شيوعًا). أخيرًا، نحن مهتمون في الغالب بما يمكن أن نسميه التنقل في طبقة الشبكة. أي أننا مهتمون بكيفية التعامل مع العقد التي تنتقل من شبكةٍ إلى أخرى. يمكن التعامل مع الانتقال من نقطة وصول إلى أخرى في نفس شبكة 802.11 بآليات خاصة بمعيار 802.11، والشبكات الخلوية لديها أيضًا طرق للتعامل مع التنقل، ولكن نحتاج في الأنظمة غير المتجانسة الكبيرة مثل الإنترنت إلى دعم التنقل على نطاق أوسع عبر الشبكات. التوجيه إلى المضيفين المتنقلين باستخدام بروتوكول Mobile IP بروتوكول IP المتنقّل هو الآلية الأساسية في معمارية الإنترنت اليوم لمعالجة مشكلة توجيه الرزم إلى المضيفين المتنقلين. حيث يقدم بعض الإمكانيات الجديدة ولكنه لا يتطلب أي تغيير من المضيفين غير المتنقلين أو معظم الموجهات، مما يجعله قابلًا للانتشار بصورة متزايدة. من المفترض أن يكون للمضيف المتنقل عنوان IP دائم، يُسمى العنوان المحلي home address الخاص به، والذي يحتوي على بادئة شبكة تساوي تلك الخاصة بشبكته المحلية home network. هذا هو العنوان الذي سيستخدمه المضيفون الآخرون عندما يرسلون الرزم في البداية إلى المضيف المتنقل، نظرًا لأنه لا يتغير، ويمكن أن تستخدمه التطبيقات طويلة العمر أثناء تجوال المضيف. ويمكننا التفكير فيه كمعرّف المضيف طويل الأمد. يكتسب عادةً المضيف، عندما ينتقل إلى شبكةٍ خارجيةٍ foreign network جديدة بعيدة عن شبكته المحلية، عنوانًا جديدًا على تلك الشبكة باستخدام بعض الوسائل مثل بروتوكول DHCP. سيتغير هذا العنوان في كل مرة يتجول فيها المضيف إلى شبكة جديدة، لذلك يمكننا التفكير به على أنه أشبه بمحدّد موقع للمضيف، ولكن من المهم ملاحظة أن المضيف لا يفقد عنوانه المحلي الدائم عندما يكتسب عنوانًا جديدًا على الشبكة الخارجية. يُعَد هذا العنوان المحلي أمرًا بالغ الأهمية لقدرته على الحفاظ على الاتصالات أثناء تحرك المضيف. يتطلب دعم التنقل بعض الوظائف الجديدة في موجهٍ واحد على الأقل بينما تظل غالبية الموجّهات دون تغيير، ويُعرف هذا الموجه بالوكيل المحلي home agent للعقدة المتنقلة. ويقع هذا الموجه على الشبكة المحلية للمضيف المتنقل. يلزم أيضًا موجهٌ ثانٍ بوظيفة محسّنة في بعض الحالات، وهو الوكيل الخارجي foreign agent، ويقع هذا الموجه على شبكة تتصل بها العقدة المتنقلة عندما تكون بعيدةً عن شبكتها المحلية. سننظر أولاً في تشغيل بروتوكول Mobile IP عند استخدام وكيلٍ خارجي. يوضح الشكل التالي مثالاً لشبكة مع وكلاء محليين وخارجيين: يعلن كلٌّ من الوكلاء المحليين والخارجيين دوريًا عن وجودهم على الشبكات التي يرتبطون بها باستخدام رسائل إعلان الوكيل. قد يطلب مضيف متنقل أيضًا إعلانًا عند توصيله بشبكة جديدة. يمكّن إعلانُ الوكيل المحلي المضيفَ المتنقل من معرفة عنوان الوكيل المحلي قبل أن يغادر شبكته المحلية. يسمع المضيف المتنقل إعلانًا من وكيلٍ خارجي عندما يتصل بشبكةٍ خارجية ويسجِّل لدى الوكيل، مع توفير عنوان وكيله المحلي. يتصل الوكيل الخارجي بعد ذلك بالوكيل المحلي، ويزوده بعنوان الرعاية care-of address. عادة ما يكون هذا هو عنوان IP الخاص بالوكيل الخارجي. يمكننا أن نرى في هذه المرحلة أن أي مضيف يحاول إرسال رزمة إلى المضيف المتنقل سيرسلها بعنوان وجهة يساوي العنوان المحلي لتلك العقدة. سيؤدي تمرير IP العادي إلى وصول تلك الرزمة إلى الشبكة المحلية للعقدة المتنقلة التي يقع عليها الوكيل المحلي، وبالتالي يمكننا تقسيم مشكلة توصيل الرزمة إلى العقدة المتنقلة إلى ثلاثة أجزاء: كيف يعترض الوكيلُ المحلي رزمة مخصَّصة للعقدةِ المتنقلة؟ كيف يسلّم الوكيل المحلي بعد ذلك الرزمة إلى الوكيل الخارجي؟ كيف يسلّم الوكيل الخارجي الرزمة إلى العقدة المتنقلة؟ قد تبدو المشكلة الأولى سهلة إذا نظرت إلى الشكل السابق، حيث يكون الوكيل المحلي بوضوح هو المسار الوحيد بين المضيف المرسل والشبكة المحلية، وبالتالي يجب أن يتلقى الرزم الموجَّهة إلى العقدة المتنقلة. ولكن ماذا لو كانت عقدة الإرسال (المقابلة) على الشبكة 18، أو ماذا لو حاول موجهٌ آخر متصل بالشبكة 18 توصيلَ الرزمة دون مرورها عبر الوكيل المحلي؟ لمعالجة هذه المشكلة، ينتحل الوكيل المحلي فعليًا صفة العقدة المتنقلة، باستخدام تقنية تسمى proxy ARP. تعمل هذه التقنية تمامًا مثل بروتوكول تحليل العناوين Address Resolution Protocol أو اختصارًا ARP، باستثناء أن الوكيل المحلي يُدرج عنوان IP الخاص بالعقدة المتنقلة، بدلًا من عنوانه الخاص، في رسائل ARP، فيستخدم عنوان الجهاز الخاص به، بحيث تتعلم جميع العقد الموجودة على نفس الشبكة ربط عنوان الجهاز الخاص بالوكيل المحلي بعنوان IP الخاص بالعقدة المتنقلة. أحد الجوانب الدقيقة لهذه العملية هو حقيقة أن معلومات ARP يمكن تخزينها مؤقتًا في عقد أخرى على الشبكة. يصدر الوكيل المحلي رسالة ARP بمجرد تسجيل العقدة المتنقلة مع وكيلٍ خارجي، للتأكد من إبطال ذاكرات التخزين المؤقت هذه في الوقت المناسب. نظرًا لأن رسالة ARP ليست استجابة لطلب ARP عادي، فقد يطلق عليها اسم ARP مجاني gratuitous ARP. المشكلة الثانية هي تسليم الرزمة المُعترَضة إلى الوكيل الخارجي. هنا نستخدم تقنية الأنفاق الموضحة سابقًا. يلف الوكيل المحلي ببساطة الرزمة داخل ترويسة IP المخصصة للوكيل الخارجي وينقلها إلى الشبكة المتشابكة. ترى جميع الموجّهات المتداخلة فقط رزمة IP مخصصة لعنوان IP الخاص بالوكيل الخارجي. هناك طريقة أخرى للنظر إلى ذلك وهي أن نفق IP يُنشَأ بين الوكيل المحلي والوكيل الخارجي، ويسقط الوكيل المحلي الرزم المخصَّصة للعقدة المتنقلة في هذا النفق. يجرِّد الوكيل الخارجي ترويسة IP الإضافية للرزمة الواصلة إليه ويجد بالداخل رزمة IP المخصّصة لِعنوان العقدة المتنقلة المحلي. من الواضح أن الوكيل الخارجي لا يمكنه التعامل مع هذا مثل أية رزمة IP قديمة لأن هذا قد يتسبب في إعادته إلى الشبكة المحلية. فبدلًا من ذلك، يجب أن يتعرف على العنوان على أنه عنوان عقدة متنقلة مسجلة، ثم يسلّم الرزمة إلى عنوان الجهاز الخاص بالعقدة المتنقلة (عنوان Ethernet على سبيل المثال)، والذي يمكن التعرف عليه كجزء من عملية التسجيل registration. إحدى الملاحظات الممكن أخذها حول هذه الإجراءات هي أنه من الممكن أن يكون الوكيل الخارجي والعقدة المتنقلة في نفس الصندوق، أي يمكن للعقدة المتنقلة أداء وظيفة الوكيل الخارجي نفسها. لإنجاح هذا العمل، يجب أن تكون العقدة المتنقلة قادرة على الحصول ديناميكيًا على عنوان IP الموجود في حيز عناوين الشبكة الخارجية باستخدام DHCP مثلًا. سيُستخدَم بعد ذلك هذا العنوان كعنوان رعاية. سيكون لهذا العنوان رقم شبكة هو 12 في مثالنا. يملك هذا الأسلوب الميزة المرغوبة المتمثلة في السماح للعقد المتنقلة بالاتصال بالشبكات التي ليس لديها وكلاء خارجيين، وبالتالي يمكن تحقيق التنقل من خلال إضافة وكيل محلي وبعض البرامج الجديدة فقط على العقدة المتنقلة (بافتراض استخدام DHCP على الشبكة الخارجية). ماذا عن حركة المرور في الاتجاه الآخر (من العقدة المتنقلة إلى العقدة الثابتة على سبيل المثال)؟ تبين أن هذا أسهل بكثير. تضع العقدة المتنقلة فقط عنوان IP الخاص بالعقدة الثابتة في حقل الوجهة لرزم IP الخاصة بها بينما تضع عنوانها الدائم في حقل المصدر، وتُمرر الرزم إلى العقدة الثابتة باستخدام الوسائل العادية. إذا كانت كلتا العقدتين في المحادثة متحركتين، فستُستخدَم الإجراءات الموضحة أعلاه في كل اتجاه. تحسين المسار في بروتوكول Mobile IP هناك عيب كبير في النهج السابق: يمكن أن يكون المسار من عقدة التراسل المقابلة إلى العقدة المتنقلة دون المستوى الأمثل على نحوٍ ملحوظ. أحد الأمثلة هو عندما تكون العقدة المتنقلة والعقدة المقابلة على نفس الشبكة، لكن الشبكة المحلية للعقدة المتنقلة تقع على الجانب الآخر من الإنترنت. تعالج العقدة المقابلة المرسِلة جميع الرزم إلى الشبكة المحلية، أي تجتاز الرزم الإنترنت للوصول إلى الوكيل المحلي، الذي ينقلها بعد ذلك عبر الإنترنت للوصول إلى الوكيل الخارجي. من الواضح أنه سيكون من الجيد أن تكتشف عقدة التراسل المقابلة أن العقدة المتنقلة موجودة بالفعل على نفس الشبكة وتسلّم الرزمة مباشرة. يتمثل الهدف في الحالة الأعم في توصيل الرزم مباشرةً قدر الإمكان من العقدة المرسلة المقابلة إلى العقدة المتنقلة دون المرور عبر وكيلٍ محلي. يشار إلى هذا أحيانًا بمشكلة توجيه المثلث triangle routing problem نظرًا لأن المسار من عقدة التراسل المقابلة إلى العقدة المتنقلة عبر الوكيل المحلي يأخذ جانبين من المثلث، بدلًا من الجانب الثالث وهو المسار المباشر. الفكرة الأساسية وراء حل توجيه المثلث هي السماح للعقدة المقابلة بمعرفة عنوان الرعاية للعقدة المتنقلة. يمكن للعقدة المقابلة بعد ذلك إنشاء نفقٍ خاص بها للوكيل الخارجي. يحدث التعامل مع هذا على أنه تحسين للعملية الموضحة للتو. إذا جُهِّز المرسل بالبرمجيات اللازمة لتعلم عنوان الرعاية مع إنشاء نفقٍ خاص به، فيمكن حينئذٍ تحسين المسار. إذا لم يكن الأمر كذلك، فإن الرزم تتبع المسار دون المستوى الأمثل. إذا رأى وكيلٌ محلي رزمةً مخصصة لإحدى العقد المتنقلة التي يدعمها، يمكنه استنتاج أن المرسل لا يستخدم المسار الأمثل. لذلك فإنه يرسل رسالة "تحديث ربط" binding update إلى المصدر، بالإضافة إلى تمرير رزمة البيانات إلى الوكيل الخارجي. يستخدم المصدر، إذا كان قادرًا، هذا التحديث الملزم لإنشاء مدخلةٍ في ذاكرة الربط المخبئية binding cache، والتي تتكون من قائمة الروابط بين عناوين العقدة المتنقلة وعناوين الحماية. في المرة التالية التي يحتوي فيها هذا المصدر على رزمة بيانات لإرسالها إلى تلك العقدة المتنقلة، سيجد الرابط في الذاكرة المخبئية ويمكنه نقل الرزمة مباشرةً إلى الوكيل الخارجي عبر نفق. هناك مشكلة واضحة في هذا المخطط، وهي أن الذاكرة المخبئية الملزمة قد تصبح قديمة إذا انتقل المضيف المتنقل إلى شبكةٍ جديدة. إذا اُستخدِمت مدخلةُ مخبئية قديمة، فسيتلقى الوكيلُ الخارجي الرزم المرسَلة عبر نفقٍ لعقدة متنقلة لم تعد مُسجَّلة على شبكتها. في هذه الحالة، يرسل الوكيل الخارجي رسالة تحذير بالربط إلى المرسل لإخباره بالتوقف عن استخدام مدخلة الذاكرة المخبئية. يعمل هذا المخطط فقط في الحالة التي لا يكون فيها الوكيل الخارجي هو العقدة المتنقلة نفسها. لذلك يجب حذف مدخلات الذاكرة المخبئية بعد فترة زمنية معينة، وتُحدد هذه المدة في رسالة تحديث الرابط. يوفر التوجيهُ المتنقل بعضَ التحديات الأمنية المثيرة للاهتمام، والتي أصبحت أوضح الآن بعد أن رأينا كيف يعمل بروتوكول Mobile IP. يمكن للمهاجم الذي يرغب في اعتراض الرزم الموجهة إلى عقدة أخرى في الشبكة المتشابكة على سبيل المثال الاتصالَ بالوكيل المحلي لتلك العقدة والإعلان عن نفسه كوكيلٍ خارجي جديدٍ للعقدة، وبالتالي من الواضح أن بعض آليات المصادقة مطلوبة. التنقل في بروتوكول IPv6 هناك عدد قليل من الاختلافات المهمة بين دعم التنقل في IPv4 و IPv6. والأهم من ذلك، أنه كان من الممكن بناء دعم التنقل في معايير IPv6 إلى حدٍ كبير منذ البداية، وبالتالي التخفيف من عددٍ من مشاكل النشر الإضافية. (قد يكون من الأصح القول أن IPv6 هو مشكلة نشر تزايدي كبيرة، والتي بمجرد حلها ستوفر دعمًا للتنقل كجزء من سلسلة إجراءات). بما أن جميع المضيفين الذين لديهم إمكانية IPv6 يمكنهم الحصول على عنوان لحظة توصيلهم بشبكةٍ خارجية (باستخدام العديد من الآليات المحددة مثل جزء من مواصفات الإصدار السادس v6 الأساسية)، فإن Mobile IPv6 يلغي الوكيل الخارجي ويتضمن القدرات اللازمة للعمل كوكيلٍ خارجي في كل مضيف. أحد الجوانب الأخرى المثيرة للاهتمام في IPv6 الذي يُشغَّل مع Mobile IP هو تضمينه لمجموعة مرنة من الترويسات المتوسعة. يُستخدَم هذا في سيناريو التوجيه الأمثل الموضح أعلاه. يمكن لعقدة IPv6 إرسال رزمة IP إلى عنوان الرعاية مع العنوان المحلي المضمَّن في ترويسة التوجيه بدلًا من تمرير رزمة عبر نفق إلى العقدة المتنقلة في عنوان العناية الخاص بها. تتجاهل جميع العقد الوسيطة هذه الترويسة، ولكنها تُمكّن العقدة المتنقلة من التعامل مع الرزمة كما لو أُرسِلت إلى العنوان المحلي، وبالتالي تمكينها من مواصلة تقديم بروتوكولات الطبقة العليا مع الوهم بأن عنوان IP الخاص بها ثابت. يُعد استخدام ترويسة التوسع بدلًا من نفقٍ أكثر كفاءة من منظور استهلاك حيز النطاق التراسلي ومعالجته. أخيرًا، نلاحظ أن العديد من المشكلات المفتوحة لا تزال قائمة في الشبكات المتنقلة. تزداد أهمية إدارة استهلاك الطاقة للأجهزة المتنقلة، بحيث يمكن بناء أجهزة أصغر ذات طاقة بطارية محدودة. هناك أيضًا مشكلة الشبكات المتنقلة المخصصة، أي تمكين مجموعة من العقد المتنقلة من تشكيل شبكة في غياب أي عقدٍ ثابتة، والتي تواجه بعض التحديات الخاصة. فئةٌ صعبة خاصة من الشبكات المتنقلة هي شبكات المستشعرات sensor networks. عادةً ما تكون المستشعرات صغيرة وغير مكلفة وغالبًا ما تعمل على البطارية، مما يعني أنه يجب أيضًا مراعاة مشكلات انخفاض استهلاك الطاقة وقدرة المعالجة المحدودة. وبما أن الاتصالات اللاسلكية والتنقل يسيران جنبًا إلى جنب، ستستمر التطورات المستمرة في التقنيات اللاسلكية في إنتاج تحديات وفرص جديدة للشبكات المتنقلة. التهام السحابة للإنترنت السحابة والإنترنت أنظمة تكافلية. لقد كانا مختلفين تاريخيًا، لكن الخط الفاصل بينهما أصبح غامضًا بشكل متزايد اليوم. يوفّر الإنترنت اتصالًا شاملًا بين أي مضيفين (حاسوب محمول للعميل وجهاز خادم بعيد على سبيل المثال)، وتدعم السحابة عدة مراكز بيانات بحجم المستودع، يوفر كلٌّ منها تكلفةً فعالة لتبريد وتشغيل عددٍ كبير من أجهزة الخادم. يتصل المستخدمون النهائيون بأقرب مركز بيانات عبر الإنترنت بنفس الطريقة التي يتصلون بها بخادم في غرفة آلةٍ بعيدة. هذا وصف دقيق للعلاقة بين الإنترنت والسحابة في الأيام الأولى لمزودي خدمات السحابة التجارية، مثل: Amazon، وMicrosoft، وGoogle. كان لسحابة Amazon مثلًا في عام 2009 مركزان للبيانات، أحدهما على الساحل الشرقي للولايات المتحدة والآخر على الساحل الغربي. يشغّل كل من مزودي الخدمات السحابية الرئيسيين عشرات من مراكز البيانات المنتشرة في جميع أنحاء العالم اليوم، ولا ينبغي أن يكون مفاجئًا أنهم يقعون في موقع استراتيجي بالقرب من نقاط تبادل الإنترنت Internet Exchange Points أو اختصارًا IXP، والتي توفر كل واحدة منها اتصالًا غنيًا ببقية الإنترنت. يوجد أكثر من 150 نقطة IXP في جميع أنحاء العالم، وعلى الرغم من عدم قيام كل مزود خدمة سحابية بتكرار مركز بيانات كامل بالقرب من كل واحد (العديد من هذه المواقع عبارة عن مرافق مشتركة في الموقع)، فمن العدل أن نقول إنه من المحتمل أن يُوزَّع المحتوى السحابي الأكثر استخدامًا (أفلام نتفليكس Netflix، مثلًا، الأكثر شهرة ومقاطع فيديو يوتيوب YouTube وصور فيسبوك Facebook على العديد من المواقع. هناك نتيجتان لهذا التشتت الواسع للسحابة. الأول هو أن المسار من طرف إلى طرف من عميل إلى خادم لا يمر بالضرورة عبر الإنترنت بالكامل. من المحتمل أن يجد المستخدم المحتوى الذي يريد الوصول إليه قد نُسِخ في نقطة اتصالٍ قريبة، والتي عادة ما تكون مجرد قفزة نظام AS واحدة بدلًا من أن تكون في الجانب البعيد من الكرة الأرضية. النتيجة الثانية هي أن مزودي الخدمات السحابية الرئيسيين لا يستخدمون الإنترنت العام لربط مراكز البيانات الموزعة الخاصة بهم. من الشائع لمزودي الخدمات السحابية الحفاظ على المحتوى الخاص بهم متزامنًا عبر مراكز البيانات الموزعة، لكنهم يفعلون ذلك عادةً عبر شبكة رئيسية backbone خاصة. هذا يسمح لهم بالاستفادة من أي تحسينات يريدونها دون الحاجة إلى التفاعل الكامل مع أي شخص آخر. يتيح بروتوكول BGP إمكانية توصيل أي زوجٍ من المضيفين، ويتفاعل معظم المستخدمين عمليًا مع التطبيقات التي تعمل في السحابة، والتي تبدو أشبه بالشكل التالي. (أحد التفاصيل المهمة التي لا ينقلها الشكل هي أن مزودي الخدمات السحابية لا يقومون عادةً ببناء شبكة WAN من خلال وضع الألياف الخاصة بهم، ولكنهم بدلًا من ذلك يستأجرون الألياف من مزودي الخدمة، مما يعني أن الشبكة الرئيسية للسحابة الخاصة والشبكة الرئيسية لمزود الخدمة غالبًا ما تشتركان في نفس البنية التحتية المادية). لاحظ أنه على الرغم من إمكانية نسخ المحتوى عبر العديد من مواقع السحابة، إلا أننا لا نمتلك التقنية اللازمة لنسخ الأشخاص حتى الآن. هذا يعني أنه عندما يرغب المستخدمون المنتشرون على نطاق واسع في التحدث مع بعضهم البعض، كجزء من مكالمة جماعية عبر الفيديو على سبيل المثال، فإن شجرة البث المتعدد تُوزَّع عبر السحابة. لا يُشغَّل البث المتعدد عادةً في الموجهات الخاصة بالشبكة الرئيسية لمزود الخدمة، ولكنه يعمل بدلًا من ذلك في عمليات الخادم الموزَّعة عبر مجموعةٍ فرعية من أكثر من 150 موقعًا تعمل كنقاط اتصال الإنترنت الرئيسية. تسمى شجرة البث المتعدد المُنشأَة بهذه الطريقة باسم التراكب overlay. ترجمة -وبتصرّف- للقسم Routing Among Mobile Devices من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: تقنية تبديل التسمية متعددة البروتوكولات MPLS في الشبكات الحاسوبية توجيه Routing الرزم ضمن الشبكات الحاسوبية تطبيق مبدلات وموجهات الشبكات الحاسوبية برمجيا وعتاديا

هناك شيء صغير ستركّز عليه عينيك لساعات عند إنشاء عمل فني باستخدام برنامج Krita، وهذا الشيء الصغير هو المؤشر Cursor، حيث يمثّل المؤشر رأس "قلمك الرقمي Digital pen"، وستظهر من رأس هذه الفرشاة بضع أو مئات الألوف من ضربات الفرشاة اللازمة لإنشاء عمل فني، لذلك يُعَد هذا الجزء مهمًا حقًا للعديد من مستخدمي أي برنامج رسمٍ رقمي. لقد أضاف فريق برنامج Krita على مر السنين إعدادات مسبَقة Presets متعددة وطرح الفريق في الوقت الحاضر أنواعًا مختلفةً من المؤشرات، ولكن ما هو أفضل مؤشر في برنامج Krita يمكنك اختياره لإنشاء عملك الفني الخاص؟ ولماذا تفضّل هذا المؤشر على الآخر؟ وما هي إيجابياته، وما هي سلبياته؟ سنشارك في هذا المقال نصائحًا وملاحظات حول هذه الميزة المهمة وسنجري مراجعةً كاملةً لمؤشر الفرشاة Brush cursor. الإعدادات تُعَد نافذة "المؤشر Cursor" واجهةً مهمة جدًا ضمن إعداد نوافذ Krita، بحيث تظهر هذه النافذة في البداية عند فتح الإعدادات في شريط القوائم العلوي، وعندا اختر Settings ثم Configure Krita. يقترح برنامج Krita في هذه النافذة إعدادَ شكلين من أشكال المؤشر هما شكل المؤشر Cursor Shape، وشكل المخطط Outline Shape. حيث يمكنك باستخدام خيار شكل المؤشر تحديد إعداد مسبق من قائمة، بحيث يُستبدَل المؤشر الفعلي بشكل آخر. يُضبَط هذا الخيار افتراضيًا على القيمة بلا مؤشر No Cursor وتحتوي القائمة على تسعة خيارات أخرى، ويُعَد الخيار "Cursor Shape" مجرد صورة ثابتة بالأبيض أو الأسود ملصوقةً في موضع المؤشر (x,y) على لوحة الرسم، وهذه الصور الثابتة قابلة للإعداد في شيفرة Krita المصدرية مثل صور من النوع xpm.* ضمن المجلد "krita/data/cursors". الخيار الثاني "Outline Shape" وهو أكثر تعقيدًا، فهو زخرفة أنشأها برنامج Krita حول الموضع (x,y) مع مزيد من الملاحظات الديناميكية حول شكل الفرشاة المحدَّدة ونوعها وحجمها. يُضبَط هذا الخيار افتراضيًا على قيمة مخطط المعاينة Preview Outline، ويحتوي على أربعة خيارات أخرى. أخيرًا، يقترح لك مربع الاختيار الموجود أسفل هاتين القائمتين إظهار أو إخفاء شكل المخطط Outline Shape أثناء الرسم (أي عندما يضغط القلم على الجهاز اللوحي)، ويُحدَّد افتراضيًا لإظهاره دائمًا كما في الشكل التالي: كل الاحتمالات الممكنة إذا جمعت القائمتين السابقتين، فيمكنك الحصول على ستة وثلاثين مؤشرًا، بحيث يحتوي الجدول التالي كل احتمالات أشكال المؤشرات حتى تتمكن من الحصول على فكرة عنها جميعًا، وسنستخدم إعدادين مسبقين في هذا المقال حسب المهمة التي ننفّذها، حيث ميّزناهما باللون الأخضر في الجدول التالي: خيار التلوين No Cursor + Preview Outline سنستخدم الإعدادات الافتراضية للتلوين والتلوين السريع، وهذه الإعدادات الافتراضية هي No Cursor+Preview Outline. هناك سبب وجيه لاختيار هذا الإعداد افتراضيًا، فهو يناسب معظم الحالات، ويوضّح الشكل الآتي شكل هذا الإعداد أثناء التلوين، بحيث يتحول المؤشر إلى شكل الفرشاة التي اخترتها، ويجب أن يكون لديك دائمًا فكرة عن نوع وحجم الفرشاة التي اخترتها، إذ يمكنك التمييز بين أثر الفرشاة المزخرفة ذات الخطوط العريضة المحدَّدة، وفرشاة البخاخة الكبيرة ذات المخطط الدائري، إذ يتغير لون مخطط المعاينة Preview Outline أيضًا تبعًا للون خلفية عملك الفني، ويكون المخطط داكنًا عندما تحرّك المؤشر فوق خلفية بيضاء، في حين يكون ساطعًا فوق خلفية داكنة. وكما أنه يغير الألوان ويعتمد صِبغات اللون الأحمر والأزرق والزهري وغير ذلك لزيادة التباين مع لون الخلفية؛ يتحول مخطط المعاينة إلى اللون الأحمر النقي تقريبًا في الشكل التالي عندما يكون مخطط المعاينة فوق طرف القبعة الشخصية: يُعَد مخطط المعاينة Preview Outline خيارًا ممتازًا في الحالات جميعها تقريبًا، حيث يعطي معاينةً لإعداد الفرشاة المسبق، بأفضل كثيرًا من خياري مخطط المعاينة الآخرَين، وهما مخطط الدائرة Circle Outline، أو المخطط المائل Tilt Outline. إذ يعرض هذان الخياران فقط دائرةً لها أكبر قطر للفرشاة المحدَّدة، ويضيف المخطط المائل خطًا صغيرًا لإظهار اتجاه الإمالة إذا كان جهازك اللوحي يدعم الإمالة. يُعَد مخطط المعاينة بعيدًا عن المثالية، على الرغم من أنه لا يزال المفضل بعد سنوات من الرسم باستخدام برنامج Krita، حيث يجب تقديم جميع سلبيات مخطط المعاينة الافتراضي بهدف معرفة سبب الحاجة إلى استخدام إعداد ثانٍ للمؤشر في برنامج Krita، وهذه السلبيات هي: مشوّش ومتعرّج: يمكنك رؤية هذا التأثير مع معظم الإعدادات المسبقة باستخدام مستشعرات التدوير، إذ تتحرك البكسلات المتعرّجة وتتتبّع شكل المؤشر أثناء تحرّكه على لوحة الرسم، وبالتالي يصبح التركيز على العمل الفني أصعب. له أثر غريب عند أقصى عرض للفرشاة: يغيّر برنامج Krita حجم مخطط المعاينة عندما يكون مستشعر الحجم الديناميكي منسوبًا إلى إعدادات الفرشاة النشطة المسبقة، ويتميّز برنامج Mypaint وClip Paint Studio بعدم إعطاء هذا النوع من التأثير الديناميكي حيث يُفضَّل هنا أن يكون حد القطر الأقصى مرئيًا دائمًا لإعطاء معاينة أفضل لحجم العرض الأكبر، ويساعد الحفاظ على إظهار الحجم الأقصى في مطابقة حدود الشكل البرتقالي عندما نملأ منطقة على سبيل المثال كما يلي: في برنامج Krita: في برنامج Mypaint: غير دقيق: لا يُظهِر مخطط المعاينة مركزه، ولكن يمكن حل هذه المشكلة عن طريق إضافة أداة صغيرة مع مخطط المعاينة، حيث تُستخدَم هذه الطريقة غالبًا عند إضافة تفاصيل للرسم، ويقترح برنامج Krita خيارين لحل هذه المشكلة، حيث أن الخيار الأول هو استخدام شكل مؤشر Cursor Shape إضافي في الأعلى مثل الإعداد المسبَق"مؤشر صغير Small Cursor"، وهذا المؤشر كبير بعض الشيء، إذ يبلغ حجمه 3 × 3 بكسلات ولكنه يعمل على خلفية بيضاء وسوداء؛ أما الحل الآخر فهو إضافة المؤشر Single Pixel white أو Single Pixel Dark. يُعَد الحلّان فعّالان للغاية، لأن وجود بكسل واحد في المركز من أجل الدقة يساعد حقًا في توجيه بداية ضربة الفرشاة، وهذه المؤشرات غير قابلة للتكيف مع لون الخلفية، وتحتاج إلى تبديل يدوي في كثير من الأحيان لسوء الحظ. يومض بكثرة: وهو تأثير جانبي آخر لإظهار ديناميكية مستشعر الحجم في الوقت الحقيقي، إذ يتغير المؤشر من أقصى عرض إلى أدنى عرض فجأةً، وهو ما يحوّل تجربة الرسم إلى تجربة "وامضة" ومضطربة للغاية. في برنامج Krita: عدم وجود وميض في برنامج Mypaint: خيار الرسم Triangle Righthanded + No Outline استخدِم مؤشر مثلث اليمينيين Triangle Righthanded بمفرده بدون مخطط لحل مشكلة الوميض والدقة في تخطيط المعاينة، فلهذا المؤشر طرف حاد عند الرسم (توجد أيضًا نسخة للناس اليساريين)، بحيث يبدو طرف المثلث وكأنه طرف مثلث لقلم رصاص حاد، إذ يمكنك التظليل بسرعة دون الحصول على تأثير وميض مشوش كما في الشكل التالي: حدود شكل المؤشر Cursor Shape واضحة، فمن الصعب الحصول على معاينة عند تغيير إعداد الفرشاة المسبَق (كالحالة عند التبديل إلى إعداد ممحاة مسبق أثناء الرسم، أو عند استخدام فرشاة تشويه كبيرة لدفع وتعديل رسم)، ولكن لا يزال بإمكانك الضغط على مفتاح Shift من لوحة المفاتيح، وسيُظهِر برنامج Krita قطر الفرشاة مع وجود إشارة تغيير الحجم. يُعَد أداء شكل المؤشرات Cursors Shape في Krita أفضل من أشكال المخطط Outline Shapes، إذ يمنحك خيار شكل المؤشر معاينةً أفضل عن موقعك الحقيقي، بينما يكون لشكل المخطط دائمًا زمن تأخير يجب تتبّعه. يمكنك أن ترى كيف يتأخر المخطط خلف المؤشر في الرسوم المتحركة الصغيرة الآتية، حيث يكون شكل المؤشر دائمًا في الوقت الحقيقي بينما يتأخر شكل المخطط، ويُعَد زمن التأخير المنخفض أمرًا مهمًا جدًا عند الرسم أو التظليل، أو عند رسم تفاصيل صغيرة بسرعة، كما يتأخر مخطط المعاينة دائمًا بضع ميلي ثانية، ويكون ذلك جيدًا بما يكفي أثناء الرسم باستخدام فُرَش كبيرة، ولكن لا يمكنك الانتقال إليه بمجرد البدء في إضافة تفاصيل دقيقة أو إنشاء خطوط، وهذا يُعَد سرًا من الأسرار المهمة للحصول على دقة وضبط أفضل عند الرسم. الخلاصة لدينا الآن بفضل برنامج Krita خيارات متعددة لتغطية العديد من حالات الاستخدام، إذ يمكن دائمًا حل أي موقف تقريبًا مع هذا الطيف الواسع من الإعدادات. نأمل أن تستمتع باستكشاف جميع المؤشرات، ونأمل أيضًا أن تساعد هذه المقالة المستخدمين عند الضياع في هذا النوع من الخيارات. ترجمة -وبتصرّف- للمقال What is the best Krita cursor؟ لصاحبه David Revoy. اقرأ أيضًا خطوات العمل المعتادة في كريتا استخدام الألوان في نمط التصاميم المسطحة في كريتا تلميحات مختلفة حول استخدام الفرش في كريتا

نواصل مناقشتنا بشأن التحسينات على بروتوكول IP من خلال وصف إضافةٍ إلى معمارية الإنترنت المستخدمة على نطاق واسع جدًا ولكنها مخفية إلى حدٍ كبير عن المستخدمين النهائيين. يجمع هذا التحسين، المسمى Multiprotocol Label Switching أو اختصارًا MPLS، بين بعض خصائص الدارات الافتراضية ومرونة وقوة مخططات البيانات. ترتبط تقنية MPLS إلى حدٍ كبير بالمعمارية القائمة على مخطط بيانات بروتوكول الإنترنت، فهي تعتمد على عناوين IP وبروتوكولات توجيه IP للقيام بعملها. تمرر الموجهات التي تدعم تقنية MPLS الرزم أيضًاعن طريق فحص تسميات labels قصيرة وثابتة الطول نسبيًا، وهذه التسميات لها نطاق محلي، تمامًا كما هو الحال في شبكة الدارات الافتراضية virtual circuit. ربما كان هذا التزاوج بين تقنيتين متعارضتين على ما يبدو هو الذي تسبب في النظر إلى تقنية MPLS بصورة متباينة إلى حدٍ ما في مجتمع هندسة الإنترنت. هناك سؤال قبل النظر في كيفية عمل تقنية MPLS وهو "ما هي الفائدة من ذلك؟" قُدِّمت العديد من الادعاءات حول MPLS ولكن هناك ثلاثة أشياء رئيسية تدفع لاستخدامها اليوم وهي: لتفعيل قدرات بروتوكول IP على الأجهزة التي ليس لديها القدرة على تمرير مخططات بيانات IP بالطريقة العادية. لتمرير رزم IP على طول المسارات الصريحة، وهي المسارات المحسوبة مسبقًا والتي لا تتطابق بالضرورة مع تلك المحددة من قِبل بروتوكولات توجيه IP العادية. لدعم أنواع معينة من خدمات الشبكة الخاصة الافتراضية virtual private network. وتجدر الإشارة إلى أن أحد الأهداف الأصلية، الذي هو تحسين الأداء، ليس مدرجًا على القائمة. يرتبط هذا كثيرًا بالتطورات التي أجريت في خوارزميات تمرير موجّهات IP في السنوات الأخيرة ومع مجموعة معقدة من العوامل تتجاوز معالجة الترويسة التي تحدد الأداء. أفضل طريقة لفهم كيفية عمل تقنية MPLS هي إلقاء نظرة على بعض الأمثلة على استخدامها. سننظر في أمثلة لتوضيح تطبيقات MPLS الثلاثة في الأقسام الثلاثة التالية. التمرير المعتمدة على الوِجهة Destination-Based Forwarding كانت إحدى المنشورات الأولى التي قدمت فكرة إرفاق تسمياتٍ labels برزم IP ورقةً كتبها شاندرامينون Chandranmenon وفارجيز Vargese والتي وصفت فكرة تسمى الأدلة الخيطية threaded indices. تُطبَّق الآن فكرة مشابهة جدًا في الموجهات التي تدعم تقنية MPLS. يوضح المثال التالي كيف تعمل هذه الفكرة: افترض الشبكة الموضحة في الشكل السابق. يكون لكلٍ من الموجهَين في أقصى اليمين (R3 وR4) شبكة متصلة واحدة، مع بادِئتين prefixes هما 18.1.1/24 و18.3.3/24. تحتوي الموجّهات المتبقية R1 وR2 على جداول توجيه تشير إلى الواجهة الصادرة التي يستخدمها كل موجهٍ عند تمرير الرزم إلى إحدى هاتين الشبكتين. يخصّص الموجه، الذي يُفعّل تقنية MPLS عليه، تسميةً لكل بادئة في جدول التوجيه الخاص به ويعلن عن كلٍّ من التسمية والبادئة التي يمثلها إلى الموجهات المجاورة له. يُنقل هذا الإعلان في بروتوكول توزيع التسميات Label Distribution Protocol، وهذا موضح في الشكل الآتي. يخصص الموجه R2 قيمة التسمية 15 للبادئة 18.1.1 وقيمة التسمية 16 للبادئة 18.3.3. يمكن اختيار هذه التسميات بما يلائم الموجّه المخصّص ويمكن عدّها كأدلة في جدول التوجيه. يعلن الموجه R2 عن ارتباطات التسمية label bindings لجيرانه بعد تخصيص هذه التسميات، حيث نرى في هذه الحالة أن الموجه R2 يعلن عن ارتباطٍ بين التسمية 15 والبادئة 18.1.1 إلى الموجه R1. يعني هذا الإعلان أن الموجه R2 قال: "الرجاء إرفاق التسمية 15 بجميع الرزم المرسلة لي والمخصصة للبادئة 18.1.1". يخزّن الموجه R1 التسمية في جدولٍ جنبًا إلى جنب مع البادئة التي يمثلها على أنها تسمية بعيدة أو صادرة لأي رزمٍ يرسلها إلى تلك البادئة. نرى إعلان تسميةٍ آخر من الموجه R3 إلى الموجه R2 للبادئة 18.1.1 في القسم (ج) من الشكل التالي، ويضع الموجه R2 التسمية البعيدة التي تعلمها من الموجه R3 في المكان المناسب في جدوله: يمكننا النظر إلى ما يحدث عند تمرير رزمةٍ في هذه الشبكة في هذه المرحلة. افترض أن رزمةً موجهة إلى عنوان IP الذي هو18.1.1.5 تصل من اليسار إلى الموجه R1. يشار إلى الموجه R1 في هذه الحالة باسم موجه تسمية طرفي Label Edge Router أو اختصارًا LER، حيث يجري الموجه LER بحث IP كاملًا عند وصول رزم IP ثم يطبّق التسميات عليها كنتيجةٍ للبحث. قد يرى الموجه R1 في هذه الحالة أن العنوان 18.1.1.5 يطابق البادئة 18.1.1 في جدول التمرير الخاص به، وأن هذه المدخلة تحتوي على واجهة صادرة وقيمة تسمية بعيدة، لذلك يرفق الموجّه R1 التسميةَ 15، وهي تسميةٌ بعيدة، بالرزمة قبل إرسالها. ينظر الموجه R2 فقط إلى التسمية الموجودة في الرزمة عند وصولها إليه وليس إلى عنوان IP. يشير جدول التمرير في الموجّه R2 إلى أنه يجب إرسال الرزم التي تصل بقيمة تسمية 15 إلى الواجهة 1 وأنه يجب أن تحمل قيمة التسمية 24، كما هو مُعلَن بواسطة الموجه R3. لذلك يعيد الموجه R2 كتابة التسمية أو يستبدلها ويمررها إلى الموجّه R3. ما الذي تحقّق من خلال كل هذا التطبيق ومبادلة التسميات؟ لاحظ أنه لم يكن الموجه R2 بحاجةٍ فعلًا لفحص عنوان IP، عندما مرر الرزمة في هذا المثال، حيث نظر الموجّه R2 فقط إلى التسمية الواردة بدلًا من ذلك، وبالتالي فقد استبدلنا البحث العادي عن عنوان وجهة IP ببحثٍ عن تسمية. لفهم سبب أهمية ذلك، من المفيد أن نتذكر أنه على الرغم من أن عناوين IP دائمًا ما تكون بنفس الطول، إلا أن بادئات IP متغيرة الطول، وتحتاج خوارزميةُ البحث عن عنوان IP الوجهة إلى العثور على أطول تطابق longest match، البادئة الأطول التي تتطابق مع البتات الأعلى ترتيبًا في عنوان IP للرزمة المُررة. إن آلية تمرير التسمية هي خوارزمية تطابقٍ تام exact match algorithm. من الممكن تنفيذ خوارزمية تطابق تام بسيطة للغاية، على سبيل المثال، باستخدام التسمية كدليلٍ في مصفوفة، حيث يكون كل عنصر في المصفوفة سطرًا واحدًا في جدول التمرير. لاحظ أنه بينما تتغيّر خوارزمية التمرير من أطول تطابق إلى تطابق تام، يمكن أن تكون خوارزمية التوجيه أي خوارزمية توجيه IP قياسية (بروتوكول OSPF على سبيل المثال). المسار الذي تتبعه الرزمة في هذه البيئة هو بالضبط نفس المسار الذي كانت ستتّبعه إن لم يجرِ تضمين تقنية MPLS، والذي هو المسار المختار بواسطة خوارزميات توجيه IP، فكل ما تغير هو خوارزمية التمرير فقط. يوضح هذا المثال مفهومًا أساسيًا مهمًا لِتقنية MPLS. ترتبط كل تسمية MPLS بصنف تمرير مكافئ forwarding equivalence class أو اختصارًا FEC، وهي مجموعةٌ من الرزم التي ستتلقى نفس معالجة التمرير في موجهٍ معين. كل بادئةٍ في جدول التوجيه هي من صنف FEC في هذا المثال؛ أي أن جميع الرزم التي تطابق البادئة 18.1.1 تُمرر على نفس المسار بغض النظر عن البتات ذات الترتيب المنخفض لعنوان IP. وبالتالي يمكن لكل موجه تخصيص تسمية واحدة ترتبط بالبادئة 18.1.1، ويمكن تمرير أي رزمةٍ تحتوي على عنوان IP تتطابق البتات ذات الترتيب العالي فيه مع تلك البادئة باستخدام تلك التسمية. تُعد أصناف FEC مفهومًا قويًا ومرنًا للغاية كما سنرى في الأمثلة اللاحقة. ويمكن تشكيل أصناف FEC باستخدام أية معاييرٍ تقريبًا، فيمكن اعتبار جميع الرزم المقابلة لعميلٍ معين بنفس صنف FEC على سبيل المثال. بالعودة إلى المثال الحالي، نلاحظ أن تغيير خوارزمية التمرير من تمرير IP العادية إلى خوارزمية تبديل التسمية له نتيجة مهمة وهي أنه يمكن استخدام الأجهزة التي لم تكن تعرف سابقًا كيفية تمرير رزم IP لتمرير حركة مرور IP في شبكة MPLS. كان التطبيق الأول والأكثر شهرة لهذه النتيجة هو مبدّلات شبكة ATM، والتي يمكن أن تدعم تقنية MPLS دون أي تغييرات على أجهزة التمرير الخاصة بها. تدعم مبدلات ATM خوارزمية تمرير مبادلة التسمية التي وصفناها للتو، ويمكن تحويلها إلى موجّهات تبديل التسمية Label Switching Routers أو اختصارًا LSRs من خلال تزويد هذه المبدلات ببروتوكولات توجيه IP وبطريقةٍ لتوزيع ارتباطات التسميات label bindings، حيث أن موجهات LSR هي الأجهزة التي تشغّل بروتوكولات تحكم IP ولكنها تستخدم خوارزمية تمرير بتبديل التسمية. طُبِّقت نفس الفكرة على المبدلات الضوئية optical switches في الآونة الأخيرة. ذكرنا أن التسميات "مرفقةٌ attached" بالرزم، ولكن أين بالضبط؟ تعتمد الإجابة على نوع الرابط الذي ينقل الرزم. تظهر طريقتان شائعتان لحمل التسميات على الرزم في الشكل الآتي. تُدخَل تسميةٌ على شكل "حشوة shim" بين ترويسة الطبقة 2 و ترويسة IP (أو أية ترويسة طبقة 3 أخرى) كما هو موضح في الجزء السفلي من الشكل الآتي، وذلك عندما تُحمل رزم IP كإطاراتٍ frames كاملة كما هو الحال في معظم أنواع الروابط بما في ذلك روابط الإيثرنت وروابط نقطة لنقطة (PPP). لكن إذا كان من المقرر أن يعمل مبدل ATM كموجّه تبديل تسمية LSR MPLS، فيجب أن تكون التسمية في مكان يمكن للمبدل استخدامه، وهذا يعني أنه يجب أن يكون في ترويسة خلية ATM، حيث يمكن العثور على حقول معرّف الدارة الافتراضية virtual circuit identifier أو اختصارًا VCI ومعرّف المسار الافتراضي virtual path identifier أو اختصارًا VPI. ماذا استفدنا بعد أن ابتكرنا الآن مخططًا يمكن أن يعمل مبدل ATM كموجّه LSR من خلاله؟ شيءٌ واحد يجب ملاحظته هو أنه يمكننا الآن إنشاء شبكة تستخدم مزيجًا من موجهات IP التقليدية، وموجهات التسميات الطرفية، ومبدلات ATM التي تعمل مثل موجه LSR، وتستخدم جميعها بروتوكولات التوجيه نفسها. لابد من التفكير في البديل عن ذلك، لفهم فوائد استخدام نفس البروتوكولات. نرى في القسم (أ) من الشكل الآتي مجموعةً من الموجهات المترابطة بواسطة دارات افتراضية عبر شبكة ATM، وهو إعدادٌ يسمى شبكة تراكب overlay network. بُنيت الشبكات من هذا النوع غالبًا لأن مبدلات ATM المتاحة تجاريًا تدعم إنتاجيةً أعلى من الموجهات. أصبحت اليوم مثل هذه الشبكات أقل شيوعًا لأن الموجهات استوعبت مبدلات ATM بل وتجاوزتها. ولكن لا تزال هذه الشبكات موجودة بسبب القاعدة الكبيرة المثبتة لمبدلات ATM في الشبكات الرئيسية backbone، والتي بدورها تشكّل نتيجة جزئية لقدرة تقنية ATM على دعم مجموعة من الإمكانات مثل محاكاة الدارة وخدمات الدارات الافتراضية. يُحتمَل أن يكون كل موجّه في شبكة التراكب متصلًا بكلٍ من الموجهات الأخرى بواسطة دارة افتراضية، ولكننا أظهرنا الدارات من الموجه R1 إلى جميع الموجهات النظيرة في هذه الحالة من أجل الوضوح. للموجه R1 خمسة جيران للتوجيه ويحتاج إلى تبادل رسائل بروتوكول التوجيه مع كلٍ منهم، فنقول أن الموجه R1 له خمسة تقاربات adjacencies توجيهية. بينما اُستبدِلت مبدلات ATM بموجهات LSR في القسم (ب) من الشكل السابق. لم يعد هناك داراتٌ افتراضية تربط الموجهات، وبالتالي فإن الموجّه R1 له تقارب مجاور واحد فقط، مع الموجه LSR1. يؤدي تشغيل تقنية MPLS على المبدلات في الشبكات الكبيرة إلى انخفاضٍ كبير في عدد التقاربات الواجب على كل موجّه الحفاظ عليها ويمكن أن يقلل بصورةٍ كبيرة من حجم العمل الذي يتعين على الموجهات القيام به لإبقاء بعضها بعضًا على علمٍ بتغييرات هيكل الشبكة topology. الميزة الثانية لتشغيل نفس بروتوكولات التوجيه على الموجهات الطرفية وعلى موجهات LSR هي أن الموجّهات الطرفية لديها الآن نظرةٌ كاملة لهيكل الشبكة. هذا يعني أن الموجهات الطرفية ستحظى بفرصةٍ أفضل لاختيار مسارٍ جديد جيد مما لو أعادت مبدلات ATM توجيه الدارة VC المتأثرة دون معرفة الموجهات الطرفية في حالة فشل رابطٍ أو عقدةٍ داخل الشبكة. لاحظ أن خطوة "استبدال" مبدلات ATM بموجهات LSR تتحقق فعليًا عن طريق تغيير البروتوكولات التي تعمل على المبدلات، ولكن لا يلزم تغيير عتاد التمرير، أي أنه يمكن تحويل مبدل ATM إلى موجه MPLS LSR من خلال ترقية برمجياته فقط. وقد يستمر موجه MPLS LSR في دعم قدرات تقنية ATM القياسية في نفس الوقت الذي تشغّل فيه بروتوكولات تحكم MPLS، فيما يشار إليه بوضع "السفن في الليل ships in the night". وُسِّعت فكرة تشغيل بروتوكولات تحكم IP على الأجهزة غير القادرة على تمرير رزم IP محليًا إلى شبكات الإرسال المتعدد بتقسيم الطول الموجي Wavelength Division Multiplexing أو اختصارًا WDM والإرسال المتعدد بالتقسيم الزمني Time Division Multiplexing أو اختصارًا TDM مثل شبكة SONET. يُعرف هذا باسم تقنية MPLS المعمَّمة Generalized MPLS أو اختصارًا GMPLS. كان جزء من الدافع وراء تقنية GMPLS هو تزويد الموجهات بالمعرفة بهيكلية شبكةٍ ضوئية، تمامًا كما في حالة شبكة ATM، والأهم من ذلك هو حقيقة عدم وجود بروتوكولات قياسية للتحكم في الأجهزة الضوئية، لذلك أثبتت تقنية MPLS أنها مناسبةٌ لهذه الوظيفة. التوجيه الصريح Explicit Routing يحتوي بروتوكول IP على خيار توجيه المصدر، ولكنه لا يُستخدم على نطاقٍ واسع لعدة أسباب، منها حقيقة عدم قدرته على تحديد سوى عددٍ محدود من القفزات hops ولأنه يُعالَج عادةً خارج "المسار السريع" في معظم الموجّهات. توفر تقنية MPLS طريقة ملائمة لإضافة قدرات مشابهة لتوجيه المصدر إلى شبكات IP، على الرغم من أن هذه القدرات غالبًا ما يشار إليها على أنها توجيه صريح explicit routing بدلًا من توجيه المصدر source routing. أحد أسباب هذا التمييز هو أنه عادةً لا يكون مصدر الرزمة الحقيقي هو من يختار المسار. حيث يكون أحد الموجهات داخل شبكة مزود الخدمة غالبًا. يوضح الشكل الآتي مثالًا عن كيفية تطبيق قدرة توجيه MPLS الصريح. يُطلق على هذا النوع من الشبكات اسم شبكة السمكة fish network بسبب شكلها (يشكل الموجهان R1 و R2 ذيل السمكة؛ بينما يكون الموجه R7 رأسها). لنفترض أن مشغّل الشبكة في الشكل السابق قد حدد أن أية حركة مرور متدفقة من الموجه R1 إلى الموجه R7 يجب أن تتبع المسار R1-R3-R6-R7 وأن أية حركة مرور تنتقل من الموجه R2 إلى الموجه R7 يجب أن تتبع المسار R2-R3-R4-R5-R7. قد يكون أحد أسباب هذا الاختيار هو الاستفادة الجيدة من السعة المتاحة على طول المسارين المتميزين من الموجه R3 إلى الموجه R7. يمكننا التفكير في حركة المرور من الموجه R1 إلى الموجه R7 على أنها تشكل أول صنف تمرير متكافئ FEC، وتشكّل حركة المرور من الموجه R2 إلى الموجه R7 ثاني تمرير FEC. يُعَد تمرير حركة المرور في هذين الصنفين على طول مسارات مختلفة مع توجيه IP العادي أمرًا صعبًا، لأن الموجه R3 لا ينظر عادةً إلى مصدر حركة المرور عند اتخاذ قرارات التمرير. من السهل تحقيق التوجيه المطلوب إذا فعّلت الموجهات تقنية MPLS نظرًا لأن هذه التقنية تستخدم مبادلة التسمية لتمرير الرزم. إذا أرفق الموجهان R1 و R2 تسميات مميزة ضمن الرزم قبل إرسالها إلى الموجه R3، وبالتالي تحديد هذه الرزم على أنها ضمن عمليات تمرير FEC مختلفة، فعندها يمكن للموجه R3 تمرير الرزم من الموجهَين R1 و R2 على طول مسارات مختلفة. السؤال الذي يطرح نفسه بعد ذلك هو كيف تتفق جميع الموجّهات في الشبكة على التسميات الواجب استخدامها وعلى كيفية تمرير الرزم ذات التسميات الخاصة؟ من الواضح أننا لا نستطيع استخدام نفس الإجراءات كما هو موضح في القسم السابق لتوزيع التسميات، لأن هذه الإجراءات تنشئ تسمياتٍ تجعل الرزم تتبع المسارات العادية التي اختارها توجيه IP، وهو بالضبط ما نحاول تجنبه. لذلك هناك حاجةٌ إلى آلية جديدة. اتضح أن البروتوكول المستخدم لهذه المهمة هو بروتوكول حجز الموارد Resource Reservation Protocol أو اختصارًا RSVP. يكفي الآن أن نقول أنه يمكن إرسال رسالة RSVP على طول مسارٍ محددٍ بوضوح (R1-R3-R6-R7 مثلًا) واستخدامها لإعداد مدخلات جدولِ إعادةِ تمرير التسميات على طول هذا المسار. هذا يشبه إلى حد كبير عملية إنشاء دارة افتراضية virtual circuit. أحد تطبيقات التوجيه الصريح هو هندسة حركة المرور traffic engineering، والتي تشير إلى مهمة ضمان توفر موارد كافية في الشبكة لتلبية الطلبات المفروضة عليها. يُعد التحكم في المسارات التي تتدفق عليها حركة المرور جزءًا مهمًا من هندسة حركة المرور. يمكن أن يساعد التوجيه الصريح أيضًا في جعل الشبكات أكثر مرونة في مواجهة الفشل، باستخدام إمكانية تسمى إعادة التوجيه السريع fast reroute. يمكن إجراء حساب مسارٍ مسبق من الموجّه A إلى الموجّه B الذي يتجنب صراحة رابطًا معينًا L على سبيل المثال. يمكن أن يرسل الموجه A كل حركة المرور الموجَّهة إلى الموجه B أسفل المسار المحسوب مسبقًا في حالة فشل الرابط L. يعني الجمع بين حساب المسار الاحتياطي المسبق وتوجيه الرزم الصريح على طول المسار أن الموجّه A لا يحتاج إلى انتظار رزم بروتوكول التوجيه لتشق طريقها عبر الشبكة أو تنفيذ خوارزميات التوجيه بواسطة العديد من العقد الأخرى في شبكة الاتصال. يمكن أن يؤدي ذلك ضمن ظروف معينة إلى تقليل الوقت الذي تستغرقه إعادة توجيه reroute الرزم حول نقطة الفشل بشكل كبير. نقطة أخيرة يجب ملاحظتها حول التوجيه الصريح هي أن المسارات الصريحة لا يلزم حسابها بواسطة مشغل الشبكة كما في المثال أعلاه. يمكن للموجهات استخدام خوارزمياتٍ مختلفة لحساب المسارات الصريحة تلقائيًا. وأكثر هذه الطرق شيوعًا هو المسار المقيَّد الأقصر أولًا constrained shortest path first أو اختصارًا CSPF، وهي خوارزمية حالة رابط link-state، ولكنها تأخذ أيضًا قيودًا مختلفة في الحسبان. إذا كان مطلوبًا العثور على مسارٍ من الموجه R1 إلى الموجه R7 يمكن أن يحمل حِملًا متاحًا قدره 100 ميجابت في الثانية على سبيل المثال، فيمكننا القول أن القيد هو أن كل رابط يجب أن يحتوي على 100 ميجابت في الثانية على الأقل من السعة المتاحة. حيث تعالج خوارزمية CSPF هذا النوع من المشاكل. الشبكات الخاصة الافتراضية Virtual Private Networks والأنفاق Tunnels تتمثل إحدى طرق إنشاء الشبكات الخاصة الافتراضية VPN في استخدام الأنفاق. اتضح أنه يمكن عدّ MPLS وسيلة لبناء الأنفاق، وهذا يجعلها مناسبة لبناء شبكات VPN من أنواع مختلفة. يمكن فهم أبسط شكل من أشكال شبكة MPLS VPN ألا وهو شبكة VPN في الطبقة 2. حيث تُستخدَم تقنية MPLS لنقل بيانات الطبقة 2 (مثل إطارات إيثرنت أو خلايا ATM) عبر شبكةٍ من الموجهات التي تدعم تقنية MPLS في هذا النوع من شبكات VPN. أحد أسباب إنشاء الأنفاق هو توفير نوعٍ من خدمة الشبكة (مثل البث المتعدد) التي لا تدعمها بعض الموجّهات في الشبكة. يُطبَّق نفس المنطق هنا: ليست موجهاتُ IP مبدلاتِ ATM، لذلك لا يمكنك توفير خدمة ATM ذات الدارة الافتراضية عبر شبكةٍ من الموجهات التقليدية. ولكن إذا كان لديك زوج من الموجهات المتصلة ببعضها بعضًا بواسطة نفق، فيمكنها إرسال خلايا ATM عبر النفق ومحاكاة دارة ATM. مصطلح هذه التقنية ضمن منظمة IETF هو محاكاة الأسلاك الزائفة pseudowire emulation. يوضح الشكل التالي هذه الفكرة: لقد رأينا بالفعل كيف بُنيت أنفاق IP: حيث يغلِّف الموجهُ عند مدخل النفق البياناتِ المُراد إرسالها عبر النفق في ترويسة IP (ترويسة النفق)، والذي يمثّل عنوان الموجه في أقصى نهاية النفق ويرسل البيانات مثل أي رزمة IP أخرى. يستقبل الموجهُ المتلقي الرزمة مع عنوانها الخاص في الترويسة، ويزيل ترويسة النفق، ويعثر على البيانات التي نُقِلت عبر الأنفاق التي يعالجها بعد ذلك. يعتمد ما تفعله بهذه البيانات على ماهيتها. فإذا كان هناك رزمة IP أخرى، فستُمرر مثل رزمة IP العادية، ولكن يمكن ألا تكون رزمة IP طالما أن الموجه المتلقي يعرف ما يجب فعله مع الرزم المغايرة عن رزم IP. سنعود إلى مسألة كيفية التعامل مع البيانات المغايرة عن بيانات IP بعد قليل. لا يختلف نفق MPLS كثيرًا عن نفق IP، إلا أن ترويسة النفق تتكون من ترويسة MPLS بدلًا من ترويسة IP. نرى في المثال الموضَّح في الشكل الآتي أن الموجه R1 قد أرفق التسمية (15) بكل رزمة أرسلها باتجاه البادئة 18.1.1. ستتبَع هذه الرزمة بعد ذلك المسار R1-R2-R3، حيث يفحص كل موجّه في المسار تسمية MPLS فقط. وبالتالي نلاحظ أنه لم يكن هناك شرط بأن يرسل الموجه R1 رزم IP فقط على طول هذا المسار، حيث يمكن تغليف أي بيانات في ترويسة MPLS وستتبَع نفس المسار، لأن الموجّهات المتداخلة لا تنظر أبدًا خارج ترويسة MPLS، فإن ترويسة MPLS تشبه تمامًا ترويسة نفق IP (باستثناء أن طولها 4 بايتات فقط بدلًا من 20 بايتًا). المشكلة الوحيدة في إرسال حركة مرور ليست بحركة مرور IP على طول نفق، مثل حركة مرور MPLS أو غير ذلك، هي معرفة ما يجب فعله عند وصولها إلى نهاية النفق. الحل العام هو حَملُ نوعٍ من معرّف فك تعدد الإرسال demultiplexing identifier في حمولة النفق والذي يخبر الموجه في نهاية النفق بما يجب القيام به. اتضح أن تقنية MPLS مناسبة تمامًا لمثل هذا المعرّف. سيجعل مثالٌ ما ذلك واضحًا. لنفترض أننا نريد تمرير خلايا ATM ضمن نفق من موجهٍ إلى آخر عبر شبكةٍ من الموجهات التي تدعم تقنية MPLS. نفترض أن الهدف هو محاكاة دارة ATM افتراضية، أي أن الخلايا تصل إلى مدخل، أو رأس، النفق بمنفذ إدخالٍ معين باستخدام معرّف VCI معين، ويجب أن تترك نهاية النفق على منفذ إخراج معين ويُحتمَل أن يكون معرّف VCI مختلفًا. يمكن تحقيق ذلك من خلال ضبط موجّهات الرأس والذيل على النحو التالي: يجب ضبط موجه الرأس head router بكلٍ من المنفذ الوارد، ومعرّف VCI الوارد، وتسمية فك تعدد الإرسال لهذه الدارة التي جرى محاكاتها، وعنوان موجه نهاية النفق. يجب ضبط موجه الذيل tail router بكلٍ من المنفذ الصادر، ومعرّف VCI الصادر، وتسمية فك تعدد الإرسال. يمكننا أن نرى كيفية تمرير خلية ATM بمجرد تزويد الموجهات بهذه المعلومات. يوضح الشكل الآتي هذه الخطوات: تصل خلية ATM إلى منفذ الإدخال المحدد بقيمة معرّف VCI المناسبة (وهي القيمة 101 في هذا المثال). يرفق موجه الرأس تسمية فك تعدد الإرسال demultiplexing label التي تحدد الدارة المُحاكاة. ثم يرفق موجه الرأس تسميةً ثانية، وهي تسمية النفق التي ستأخذ الرزمة إلى موجه الذيل. تُفهم هذه التسمية من خلال آليات مختلفة. تمرر الموجّهات بين الرأس والذيل الرزمة باستخدام تسمية النفق فقط. يزيل موجه الذيل تسمية النفق، ويجد تسمية فك تعدد الإرسال، ويتعرف على الدارة المُحاكاة. يعدّل موجه الذيل قيمة معرّف VCI الخاص بشبكة ATM إلى القيمة الصحيحة (202 في هذه الحالة) ويرسلها إلى المنفذ الصحيح. قد يكون عنصرٌ واحد في هذا المثال غير مفهوم وهو أن الرزمة تحتوي على تسميتين مرفقتين بها. هذه إحدى ميزات تقنية MPLS المثيرة للاهتمام، حيث يمكن تكديس التسميات على رزمة بأي عمق، ويوفر ذلك بعض إمكانات التوسّع المفيدة. حيث يُسمح لنفقٍ واحد في هذا المثال بحمل عدد كبير من الدارات المُحاكاة. يمكن تطبيق نفس الأساليب الموصوفة هنا لمحاكاة العديد من خدمات الطبقة 2 الأخرى، بما في ذلك خدمات ترحيل الإطار Frame Relay والإيثرنت. وتجدر الإشارة إلى أنه يمكن توفير قدرات متطابقة تقريبًا باستخدام أنفاق IP، أي أن ميزة تقنية MPLS الرئيسية هنا هي ترويسة النفق الأقصر. اُستخدمت تقنية MPLS أيضًا لدعم شبكات VPN من الطبقة 3 قبل استخدامها في نفق خدمات الطبقة 2. لن ندخل في تفاصيل شبكات VPN من الطبقة الثالثة، فهي معقدة للغاية، لكنها تمثّل أحد أكثر استخدامات تقنية MPLS شيوعًا اليوم. تَستخدم شبكات VPN من الطبقة الثالثة أيضًا مكدّساتٍ من تسميات MPLS لنقل الرزم خلال نفق عبر شبكة IP، ولكنّ الرزم التي أُرسِلت عبر النفق هي نفسها رزم IP، لذلك تُسمّى شبكة VPN من الطبقة 3. يشغّل مزود خدمةٍ واحد شبكةً من الموجهات التي تدعم تقنية MPLS ويوفّر خدمة شبكة IP "خاصة وهميًا" لأي عددٍ من العملاء المميزين في شبكة VPN من الطبقة 3. أي أن كل عميلٍ للمزود لديه عدد من المواقع، ويوهم مزودُ الخدمة كل عميل بأنه لا يوجد عملاء آخرون على الشبكة. ويرى العميل شبكة IP تربط مواقعه الخاصة ولا يرى أي مواقع أخرى. هذا يعني أن كل عميل معزول عن جميع العملاء الآخرين من حيث التوجيه والعنونة. لا يمكن للعميل A إرسال الرزم مباشرة إلى العميل B والعكس صحيح، ويمكن للعميل A استخدام عناوين IP التي استخدمها أيضًا العميل B. الفكرة الأساسية موضحة في الشكل السابق. تُستخدم تقنية MPLS لنقل الرزم من موقع إلى آخر كما هو الحال في شبكات VPN من الطبقة 2، ولكن يُطبَّق ضبط الأنفاق تلقائيًا عن طريق استخدام بروتوكول BGP بصورةٍ مفصّلة إلى حدٍ ما، وهذا يتجاوز نطاق هذا الكتاب. في الواقع، يمكن للعميل A عادةً إرسال البيانات إلى العميل B بطريقة مقيدة. فيكون لكلٍ من العميل A والعميل B بعض الاتصال بالإنترنت العالمي، وبالتالي من المحتمل أن يرسل العميل A رسائل بريدٍ إلكتروني على سبيل المثال إلى خادم البريد داخل شبكة العميل B. تمنع "الخصوصية privacy" التي تقدمها شبكة VPN العميل A من الوصول غير المقيد إلى جميع الأجهزة والشبكات الفرعية داخل شبكة العميل B. تُعد تقنية MPLS أداةً متعددة الاستخدامات إلى حدٍ ما ومُطبَّقةً على مجموعةٍ واسعة من مشاكل الشبكات المختلفة. فهي تجمع بين آلية التمرير بتبديل التسمية التي ترتبط عادةً بشبكات الدارات الافتراضية مع بروتوكولات التوجيه والتحكم لشبكات مخططات بيانات IP لإنتاج صنفٍ من الشبكات تقع في مكانٍ ما بين طرفين تقليديين. يعمل هذا على توسيع قدرات شبكات IP لتمكين تحكمٍ أدق في التوجيه ودعم مجموعة من خدمات VPN. ترجمة -وبتصرّف- للقسم Multiprotocol Label Switching من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: البث المتعدد Multicast الفعال على شبكة بحجم شبكة الإنترنت النقل الموثوق Reliable Transmission في الشبكات الحاسوبية

تطبّق شبكاتُ الوصول المتعدد، مثل شبكة إيثرنت، البثَّ المتعدد في العتاد. ولكن هناك تطبيقات تحتاج إلى قدرة بثٍ متعدد أوسع تكون فعالةً على شبكة بحجم شبكة الإنترنت. يجب إرسال نفس البيانات إلى جميع المضيفين عندما تبث محطة راديو بثًا إذاعيًا broadcast عبر الإنترنت على سبيل المثال، حيث يضبط المستخدم هذه المحطة. ويكون الاتصال وفق علاقة واحد إلى متعدد one-to-many في هذا المثال. تتضمن الأمثلة الأخرى لتطبيقات واحد إلى عدّة إرسالَ نفس الأخبار أو أسعار الأسهم الحالية أو تحديثات البرامج أو القنوات التلفزيونية إلى عدة مضيفين، ويُطلَق على المثال الأخير اسم IPTV. هناك أيضًا تطبيقات يكون اتصالها متعدد إلى متعدد many-to-many، مثل مؤتمرات الوسائط المتعددة عن بعد أو الألعاب متعددة اللاعبين عبر الإنترنت أو عمليات المحاكاة الموزعة. حيث يتلقى أعضاء المجموعة بيانات من عدة مرسلين في مثل هذه الحالات، عادةً من بعضهم بعضًا، ويتلقون جميعًا نفس البيانات من أي مرسل معين. لا تناسب اتصالات IP العادية، والتي يجب فيها توجيه كل رزمةٍ وإرسالها إلى مضيف واحد، لمثل هذه التطبيقات. إذا كان التطبيق يحتوي على بياناتٍ لإرسالها إلى مجموعة، فسيتعين عليه إرسال رزمةٍ منفصلة بها البيانات المتطابقة إلى كل عضوٍ في المجموعة. يستهلك هذا التكرار حيز نطاقٍ تراسلي أكثر من اللازم. ولا تُوزَّع حركة المرور الزائدة بالتساوي بل تُركّز على المضيف المرسل، وقد تتجاوز بسهولة سعة المضيف المرسل والشبكات والموجّهات القريبة. يوفر بروتوكول IP بثًا متعددًا على مستوى بروتوكول IP ومشابهًا للبث المتعدد على مستوى الرابط الذي توفره شبكات الوصول المتعدد مثل شبكة الإيثرنت من أجل دعم الاتصال متعدد إلى متعدد many-to-many ومن واحد إلى متعدد one-to-many. نحتاج أيضًا، بعد أن قدمنا مفهوم البث المتعدد لبروتوكول IP، إلى مصطلح لخدمة واحد إلى واحد one-to-one التقليدية لبروتوكول IP، حيث يشار إلى هذه الخدمة على أنها بث أحادي unicast. نموذج بث IP المتعدد الأساسي هو نموذج عدة إلى عدة معتمد على مجموعات البث المتعدد، حيث يكون لكل مجموعة عنوان IP متعدد البث خاص بها. يتلقى المضيفون الذين هم أعضاء في مجموعة نسخًا من أي رزم تُرسَل إلى عنوان البث المتعدد لتلك المجموعة. يمكن أن يكون المضيف في مجموعات متعددة، ويمكنه الانضمام إلى المجموعات وتركها بحرية عن طريق إخبار موجهه المحلي باستخدام بروتوكول سُيناقش قريبًا. وبالتالي فإن عناوين البث المتعدد مرتبطة بمجموعة مجردة تتغير عضويتها ديناميكيًا بمرور الوقت، بينما نفكر في عناوين البث الأحادي باعتبارها مرتبطةً بعقدةٍ أو واجهة. يسمح نموذج خدمة البث IP المتعدد الأصلي لأي مضيف بإرسال حركة مرور متعددة البث إلى مجموعة، أي ليس من الضروري أن يكون عضوًا في المجموعة، وقد يكون هناك أي عدد من هؤلاء المرسلين لمجموعة معينة. يرسل المضيف نسخةً واحدة من الرزمة موجهة إلى عنوان البث المتعدد للمجموعة باستخدام بروتوكول IP متعدد البث لإرسال الرزمة المتطابقة إلى كل عضو في المجموعة. لا يحتاج مضيف الإرسال إلى معرفة عنوان IP الأحادي البث لكل عضو في المجموعة لأن هذه المعرفة تُوزَّع بين الموجهات في الشبكة المتشابكة internetwork كما سنرى. وبالمثل، لا يحتاج مضيف الإرسال إلى إرسال نسخٍ متعددة من الرزمة لأن الموجهات ستنشئ نسخًا كلما كان عليها تمرير الرزمة عبر أكثر من رابطٍ واحد. يكون البث المتعدد لبروتوكول IP أكثرَ قابلية للتوسع لأنه يزيل حركة المرور (الرزم) الزائدة التي كان من الممكن إرسالها عدة مرات عبر نفس الروابط، وخاصة تلك القريبة من المضيف المرسل، مقارنة باستخدام بروتوكول IP أحادي البث لتقديم نفس الرزم إلى العديد من أجهزة الاستقبال. اُستكمِل البث المتعدد الأصلي متعدد إلى متعدد many-to-many الخاص ببروتوكول IP بدعم شكلٍ من أشكال البث المتعدد من واحد إلى متعدد. يحدّد مضيف الاستقبال كلًا من مجموعة البث المتعدد ومضيف الإرسال المحدّد في هذا النموذج من البث المتعدد من واحد إلى متعدد، المسمّى البث المتعدد المحدّد بالمصدر Source-Specific Multicast أو اختصارًا SSM. سيتلقى المضيف المستقبل بعد ذلك البث المتعدد الموجَّه إلى المجموعة المحددة، ولكن فقط إذا كانت من المرسل المحدّد. تتلاءم العديد من تطبيقات البث المتعدد للإنترنت (مثل البث الإذاعي الراديوي) مع نموذج SSM. يُشار أحيانًا إلى نموذج IP الأصلي متعدد إلى متعدد باسم البث المتعدد لأي مصدر Any Source Multicast أو اختصارًا ASM. يشير المضيف إلى رغبته في الانضمام إلى مجموعة البث المتعدد أو تركها من خلال الاتصال بالموجه المحلي الخاص به باستخدام بروتوكول خاص لهذا الغرض فقط. هذا البروتوكول في الإصدار IPv4 هو بروتوكول إدارة مجموعات الإنترنت Internet Group Management Protocol أو اختصارًا IGMP، أما في الإصدار IPv6، فهو اكتشاف المستمع المتعدد Multicast Listener Discovery أو اختصارًا MLD، ثم يتحمّل الموجه بعد ذلك مسؤولية جعل البث المتعدد يتصرف بصورة صحيحة فيما يتعلق بهذا المضيف. يستطلع الموجهُ الشبكةَ دوريًا لتحديد المجموعات التي لا تزال ذات أهمية للمضيفين المرتبطين بالشبكة، نظرًا لأن المضيف قد يفشل في ترك مجموعة البث المتعدد في الوقت المناسب (بعد حدوث عطل أو فشل آخر على سبيل المثال). عناوين البث المتعدد Multicast Addresses يحتوي بروتوكول IP على مجالٍ فرعي subrange محجوز لعناوين البث المتعدد. تُسنَد هذه العناوين في الإصدار IPv4 في حيز عناوين الصنف D، ويحتوي الإصدار IPv6 أيضًا على جزءٍ من حيز العناوين المحجوز لعناوين مجموعة البث المتعدد. بعض المجالات الفرعية لنطاقات البث المتعدد محجوزةٌ للبث المتعدد داخل النطاق intradomain، بحيث يمكن إعادة استخدامها بشكل مستقل عن طريق النطاقات المختلفة. هناك 28 بتًا من عناوين البث المتعدد المحتملة في الإصدار IPv4 عندما نتجاهل البادئة المشتركة بين جميع عناوين البث المتعدد. يمثل هذا مشكلة عند محاولة الاستفادة من البث المتعدد للعتاد على شبكة محلية LAN. لنأخذ حالة شبكة الإيثرنت، حيث تحتوي عناوين البث المتعدد للإيثرنت على 23 بتًا فقط عندما نتجاهل بادئتها المشتركة، أي يتعين على بروتوكول IP ربط عناوين بث IP المتعدد المؤلَّفة من 28 بتًا مع عناوين بث الإيثرنت المتعدد ذات 23 بتًا للاستفادة من البث المتعدد عبر شبكة الإيثرنت. يُطبَّق ذلك عن طريق أخذ 23 بت ذات الترتيب المنخفض لأي عنوان IP متعدد البث لاستخدامها كعنوان إيثرنت متعدد البث وتجاهل 5 بتات عالية الترتيب. وبالتالي تُربَط 32 ( أو25) عنوان IP مع كل عنوان من عناوين الإيثرنت. يضبط المضيفُ على شبكة إيثرنت المُنضَم إلى مجموعة IP متعددة البث واجهةَ الإيثرنت الخاصة به لتلقي أي رزمٍ مع عنوان بث الإيثرنت المتعدد المقابل. يتسبب هذا بأن المضيف المستقبل لن يتلقى فقط حركة مرور البث المتعدد التي يريدها ولكن أيضًا حركة المرور المرسلة إلى أيٍّ من مجموعات البث المتعدد 31 الأخرى التي تُربَط مع عنوان الإيثرنت نفسه، إذا وُجِّهت إلى شبكة الإيثرنت هذه. لذلك يجب على بروتوكول IP في المضيف المستقبل فحصَ ترويسة IP لأي رزمةٍ متعددة البث لتحديد ما إذا كانت الرزمة تنتمي حقًا إلى المجموعة المطلوبة. إن عدم تطابق أحجام عناوين البث المتعدد يعني أن حركة مرور البث المتعدد قد تضع عبئًا على المضيفين الذين لا يهتمون حتى بالمجموعة التي أُرسِلت حركة المرور إليها. يمكن تخفيف هذه المشكلة لحسن الحظ في بعض شبكات التبديل switched networks، مثل شبكة الإيثرنت المبدَّلة، عن طريق المخططات حيث تتعرف المبدّلات switches على الرزم غير المرغوب فيها وتتجاهلها. أحد الأسئلة المحيّرة هو كيف يتعرف المرسلين والمستقبلين على عناوين البث المتعدد التي يجب استخدامها في المقام الأول. يُتعامل مع هذا عادةً عن طريق وسائل خارج النطاق out-of-band means، وهناك بعض الأدوات المتطورة للغاية لتفعيل الإعلان عن عناوين المجموعات على الإنترنت. التوجيه متعدد البث باستخدام بروتوكولات DVMRP وPIM وMSDP تشير جداول تمرير البث الأحادي الخاصة بالموجّه، بالنسبة لأي عنوان IP، إلى الرابط الواجب استخدامه من أجل تمرير رزمة البث الأحادي unicast. يجب أن يحتوي الموجه أيضًا، لدعم البث المتعدد، على جداول تمرير البث المتعدد التي تشير، استنادًا إلى عنوان البث المتعدد، إلى الروابط (ربما أكثر من رابط) لاستخدامها لتمرير رزمة بث متعدد (يكرر الموجّه الرزمة في حالة مُرِرت عبر روابط متعددة). وبالتالي تحدد جداولُ تمرير البثِ الأحادي بصورة جماعية مجموعةً من المسارات، وتحدد جداولُ تمرير البث المتعدد بصورة جماعية مجموعةً من الأشجار هي: أشجار توزيع البث المتعدد multicast distribution trees. ولدعم البث المتعدد الخاص بالمصدر ولبعض أنواع أي مصدرٍ متعدد البث Any Source Multicast أيضًا، يجب أن تحدّد جداولُ تمرير البث المتعدد الروابطَ الواجب استخدامها بناءً على مجموعة عناوين البث المتعدد وعنوان IP (أحادي البث) الخاص بالمصدر، وتحدد مجموعةً من الأشجار أيضًا. توجيه البث المتعدد هو العملية التي تُحدَّد من خلالها أشجار توزيع البث المتعدد، أو بصورة أكثر تحديدًا هي العملية التي تُنشَأ من خلالها جداول تمرير البث المتعدد. لا يكفي أن "يعمل" بروتوكول توجيه البث المتعدد كما هو الحال مع التوجيه الأحادي، أي يجب أيضًا أن يتوسّع على نحوٍ معقول مع نمو الشبكة، ويجب أن يستوعب استقلالية نطاقات domains التوجيه المختلفة. بروتوكول DVMRP يمكن توسيع توجيه متجّه المسافة Distance-vector المستخدَم في البث الأحادي لدعم البث المتعدد. يُطلق على البروتوكول الناتج اسم بروتوكول توجيه متجه المسافة متعدد البث Distance Vector Multicast Routing Protocol أو اختصارًا DVMRP. كان بروتوكول DVMRP أول بروتوكول توجيه متعدد البث مستخدمٍ على نطاق واسع. تذكّر أنه في خوارزمية متجه المسافة، يحتفظ كل موجهٍ بجدول Destination وCost وNextHop، ويتبادل قائمة أزواج (Destination وCost) مع جيرانه المتصلين مباشرة به. توسيع هذه الخوارزمية لدعم البث المتعدد هو عملية من مرحلتين: أولًا، ننشئ آلية بث تسمح بتمرير الرزمة إلى جميع الشبكات على الإنترنت. ثانيًا، نحن بحاجة إلى تحسين هذه الآلية بحيث تعمل على تقليم prune الشبكات التي لا تحتوي على مضيفين ينتمون إلى مجموعة البث المتعدد، وبالتالي يُعَد بروتوكول DVMRP أحد بروتوكولات توجيه البث المتعدد الموصوفة ببروتوكولات الإغراق والتقليم flood-and-prune. يعرف كل موجهٍ أن أقصر مسار حالي إلى وجهة destination معينة يمر عبر موجّه القفزة التالية NextHop بالنظر إلى جدول توجيه أحادي البث. وبالتالي يمرر الموجه، الذي تلقّى رزمة بث متعدد من المصدر S، الرزمة على جميع الروابط الصادرة (باستثناء تلك التي وصلت عليها الرزمة) إذا وفقط إذا وصلت الرزمة عبر الرابط الموجود في أقصر مسار إلى المصدر S (مثل وصول الرزمة من موجّه القفزة التالية NextHop المرتبطة بالمصدر S في جدول التوجيه). تغرق floods هذه الإستراتيجية بفعالية الرزم خارج المصدر S ولكنها لا تعيد الرزم مرةً أخرى نحوه. هناك نوعان من أوجه النقص الرئيسية لهذا النهج. أولًا، هو أنه يغرق الشبكة حقًا، أي ليس لديه شرطٌ لتجنب الشبكات المحلية التي ليس لها أعضاء في مجموعة البث المتعدد، حيث سنعالج هذه المشكلة لاحقًا. وثانيًا هو أنه سيُمرر رزمةٍ معينةٍ عبر شبكة LAN بواسطة كل من الموجهات المتصلة بهذه الشبكة المحلية، ويرجع ذلك إلى استراتيجية التمرير المتمثلة في إغراق الرزم على جميع الروابط بخلاف تلك التي وصلت عليها الرزمة، بغض النظر عما إذا كانت هذه الروابط جزءًا من أقصر مسار شجرة جذرها في المصدر أم لا. يكمن حل وجه النقص الثاني في التخلص من رزم البث الإذاعي broadcast المكرَّرة التي تُنشَأ عند توصيل أكثر من موجهٍ بشبكة LAN معينة. تتمثل إحدى طرق القيام بذلك في تخصيص موجهٍ كموجّه أب parent لكل رابط له صلةٌ بالمصدر. حيث يُسمح فقط للموجه الأب بتمرير رزم البث المتعدد من ذلك المصدر عبر الشبكة المحلية. يُحدَّد الموجه الذي يحتوي على أقصر مسار إلى المصدر S على أنه الموجه الأب، أي سيُكسر التعادل بين موجهين وفقًا لأي موجه يحتوي على أصغر عنوان. يمكن لموجهٍ معين معرفة ما إذا كان هو الموجه الأب للشبكة المحلية (بالنسبة لكل مصدر محتمل) بناءً على رسائل متجه المسافة التي يتبادلها مع جيرانه. لاحظ أن هذا التحسين يتطلب أن يحتفظ كل موجه، لكل مصدر، لوقت إضافي بكل من الروابط الخاصة به والتي تشير إلى ما إذا كان هو الموجه الأب لزوج المصدر / الرابط أم لا. ضع في بالك أن المصدر هو عبارة عن شبكة وليس مضيفًا في إعدادات الإنترنت، نظرًا لأن موجه الإنترنت مهتم فقط بتمرير الرزم بين الشبكات. تسمى الآلية الناتجة أحيانًا بث المسار العكسي إذاعيًا Reverse Path Broadcast أو اختصارًا RPB أو تمرير المسار العكسي Reverse Path Forwarding أو اختصارًا RPF. المسار عكسي لأننا نفكر في أقصر مسارٍ نحو المصدر عند اتخاذ قرارات التمرير، مقارنةً بتوجيه البث الأحادي، الذي يبحث عن أقصر مسار إلى وِجهةٍ معينة. تطبّق آليةُ RPB البثَّ الإذاعي لأقصر مسارshortest-path broadcast. نريد الآن تقليم مجموعة الشبكات التي تتلقى كل رزمة موجهة إلى المجموعة G لاستبعاد تلك التي ليس لديها أعضاء مضيفون في المجموعة G. يمكن تحقيق ذلك على مرحلتين: أولًا، نحتاج إلى التعرّف على الحالات التي لا تحتوي فيها الشبكة الطرفية أو التي تكون عبارةً عن ورقة في الشجرة leaf network على أعضاء مجموعة. يُعَد تحديد أن الشبكة عبارة عن شبكةٍ طرفية leaf أمرًا سهلًا. فإذا كان الموجه الأب هو الموجه الوحيد على الشبكة، فإن الشبكة تكون عبارةً عن شبكةٍ طرفية. يُحدَّد ما إذا كان أي من أعضاء المجموعة واقعًا على الشبكة من خلال جعل كل مضيفٍ عضوٍ في المجموعة G يعلن دوريًا عن هذه الحقيقة عبر الشبكة. ثم يستخدم الموجه هذه المعلومات ليقرر ما إذا كان سيمرر رزمة البث المتعدد الموجّهة إلى المجموعة G عبر شبكة LAN هذه أم لا. تتمثل المرحلة الثانية في نشر معلومات "لا يوجد أعضاء من المجموعة G هنا" إلى شجرة أقصر مسار. يحدث ذلك عن طريق جعل الموجه يزيد من أزواج (Destination, Cost) التي يرسلها إلى جيرانه من خلال المجموعات التي تهتم الشبكة الطرفية بتلقي رزم البث المتعدد منها. يمكن بعد ذلك نشر هذه المعلومات من موجهٍ لآخر، بحيث يعرف الموجّهُ المجموعاتِ الواجب تمرير رزم البث المتعدد إليها وذلك من أجل كل رابطٍ من روابطه. لاحظ أن تضمين كل هذه المعلومات في تحديث التوجيه يُعَد أمرًا مكلفًا إلى حدٍ ما. ولا يحدث تبادل هذه المعلومات من الناحية العملية إلا عندما تبدأ بعض المصادر في ارسال رزمٍ إلى تلك المجموعة. تستخدم هذه الإستراتيجية آلية RPB، التي تضيف مقدارًا صغيرًا من الحِمل الزائد إلى خوارزمية متجه المسافة الأساسية، حتى يصبح عنوان البث المتعدد المحدَّد نشطًا. تصرّح الموجهات غير المهتمة بتلقي الرزم الموجّهة إلى تلك المجموعة عن ذلك، وتُنشر هذه المعلومات إلى الموجّهات الأخرى. بروتوكول PIM-SM طُوِّر بروتوكول البث المتعدد المستقل Protocol Independent Multicast، أو PIM، استجابةً لمشاكل التوسع لبروتوكولات توجيه البث المتعدد السابقة. وخصوصًا عند ملاحظة أن البروتوكولات الحالية لم تتسّع جيدًا في البيئات التي ترغب فيها نسبة صغيرة نسبيًا من الموجّهات في تلقي حركة مرور لمجموعة معينة. فلا يُعَد الاستمرار في بث حركة المرور إذاعيًا إلى جميع الموجهات إلى أن تطلب صراحةً إزالتها من ذلك التوزيع اختيارًا جيدًا للتصميم في حال لم تُرِد معظم الموجّهات استقبال حركة المرور في المقام الأول. هذا الموقف شائع جدًا بحيث يقسّم بروتوكول PIM المشكلة إلى الوضع المتناثر sparse mode والوضع الكثيف dense mode، حيث يشير مصطلحا المتناثر والكثيف إلى نسبة الموجهات التي تريد البث المتعدد. يستخدم وضع بروتوكول PIM الكثيف PIM-DM خوارزمية الإغراق والتقليم flood-and-prune مثل بروتوكول DVMRP ويعاني من نفس مشكلة قابلية التوسّع. أصبح وضع بروتوكول PIM المتناثر PIM-SM هو بروتوكول توجيه البث المتعدد المهيمن وهو محور مناقشتنا هنا. يشير الجزء "البروتوكول المستقل protocol independent" في PIM إلى حقيقة أنه، على عكس البروتوكولات السابقة مثل بروتوكول DVMRP، لا يعتمد بروتوكول PIM على أي نوعٍ معين من التوجيه أحادي البث unicast، ولكن يمكن استخدامه مع أي بروتوكول توجيه أحادي البث، كما سنرى لاحقًا. تنضم الموجّهات صراحةً إلى شجرة توزيع البث المتعدد في الوضع PIM-SM باستخدام رسائل بروتوكول PIM المعروفة باسم رسائل الانضمام Join. لاحظ الاختلاف مع أسلوب بروتوكول DVMRP في إنشاء شجرة بث أولًا ثم تقليم الموجّهات غير المهتمة. السؤال الذي يطرح نفسه هو مكان إرسال رسائل الانضمام لأنه يمكن لأي مضيف (وأي عددٍ من المضيفين) إرسالها إلى مجموعة البث المتعدد. لمعالجة هذا الأمر، يخصّص الوضع PIM-SM لكل مجموعة موجهًا خاصًا يُعرَف باسم نقطة الالتقاء rendezvous point أو اختصارًا RP. تُضبَط عدة موجّهات في النطاق كنقاط RP مرشَّحة، ويحدِّد الوضع PIM-SM مجموعةً من الإجراءات التي يمكن من خلالها لجميع الموجهات في نطاقٍ ما الاتفاق على الموجه لاستخدامه كنقطة RP لمجموعة معينة. هذه الإجراءات معقدة نوعًا ما، حيث يجب أن تتعامل مع مجموعة متنوعة من السيناريوهات، مثل فشل نقطة RP مرشحة وتقسيم النطاق إلى شبكتين منفصلتين بسبب عدد من حالات فشل الرابط أو العقدة. افترض أن جميع الموجّهات في نطاقٍ ما تعرف عنوان IP أحادي البث الخاص بنقطة RP لمجموعةٍ معينة في بقية هذه المناقشة. أُنشئت شجرة تمرير البث المتعدد كنتيجة لإرسال الموجهاتِ رسائلَ الإنضمام Join إلى نقطة RP. يسمح الوضع PIM-SM بإنشاء نوعين من الأشجار: شجرة مشتركة shared tree، يستخدمها جميع المرسلين، وشجرة خاصة بالمصدر source-specific tree، والتي يستخدمها فقط مضيف إرسال محدد. يُنشئ وضعُ العملية العادي الشجرةَ المشتركة أولًا، متبوعةً بشجرة واحدة أو أكثر من الأشجار الخاصة بالمصدر إذا كان هناك حركة مرور كافية لضمان ذلك. من المهم والمفترض وجود شجرة واحدة فقط للمجموعة، وليس شجرة واحدة لكل مرسلٍ إلى مجموعة، نظرًا لأن بناء الأشجار يثبّت الحالة في الموجّهات على طول الشجرة. تُرسَل رسالة الإنضمام Join التي يرسلها موجهٌ إلى نقطة RP لمجموعة G باستخدام بث IP أحادي عادي. هذا موضح في القسم (أ) من الشكل السابق، حيث يرسل الموجه R4 رسالة Join إلى نقطة التقاء بعض المجموعات. رسالة الانضمام الأولية هي "wildcarded"، أي أنها تُطبَّق على جميع المرسلين. يجب أن تمر رسالة الإنضمام بوضوح عبر تسلسلٍ معين من الموجّهات قبل الوصول إلى نقطة RP (الموجّه R2 مثلًا). ينظُر كلُّ موجهٍ على طول المسار إلى رسالة Join وينشئ مدخلة جدول تمرير للشجرة المشتركة، تسمى مدخلة (* , G) (حيث * تعني "جميع المرسلين"). وينظر إلى الواجهة التي وصلت عليها رسالة Join لإنشاء مدخلة جدول التمرير، ويضع علامةً على تلك الواجهة كواجهةٍ يجب تمرير رزم البيانات لهذه المجموعة عليها. ثم يحدّد الواجهة المُستخدمة لتمرير رسالة Join نحو نقطة RP. حيث ستكون هذه الواجهة الوحيدة المقبولة للرزم الواردة المرسَلة إلى هذه المجموعة. ثم يمرر رسالة Join نحو نقطة RP. تصل الرسالة إلى نقطة RP في النهاية، لتكمل بناء فرع الشجرة. تظهر الشجرة المشتركة التي أُنشئت على هذا النحو كخطٍ مستمر من نقطة RP إلى الموجه R4 في القسم (أ) من الشكل السابق. بما أن المزيد من الموجهات ترسل رسائل انضمام Join إلى نقطة RP، فإنها تتسبب في إضافة فروع جديدة إلى الشجرة، كما هو موضح في القسم (ب) من الشكل السابق. لاحظ أنه تحتاج رسالة Join فقط إلى الذهاب إلى الموجه R2 في هذه الحالة، والذي يمكنه إضافة الفرع الجديد إلى الشجرة ببساطة عن طريق إضافة واجهة صادرة جديدة إلى مدخلة جدول التمرير التي أُنشئت لهذه المجموعة. لا يحتاج الموجه R2 لتمرير رسالة Join إلى نقطة RP. لاحظ أيضًا أن النتيجة النهائية لهذه العملية هي بناء شجرة يكون جذرها نقطة RP. افترض مثلًا أن مضيفًا يرغب في إرسال رسالة إلى المجموعة. للقيام بذلك، ينشئ رزمةً بعنوان مجموعة البث المتعدد المناسب كوجهة لها ويرسلها إلى موجهٍ معروفٍ باسم الموجه المكلَّف designated router أو اختصارًا DR على شبكته المحلية. افترض أن الموجه DR هو الموجه R1 في الشكل السابق. لا توجد حالة لمجموعة البث المتعدد هذه بين الموجّه R1 ونقطة RP في هذه المرحلة، لذا يمرر الموجه R1 رزمة البث المتعدد إلى نقطة RP من خلال نفق tunnel بدلًا من مجرد تمريرها. أي أن الموجه R1 يغلّف رزمة البث المتعدد داخل رسالة Register الخاصة بالبروتوكول PIM التي يرسلها إلى عنوان IP أحادي البث الخاص بنقطة RP. تتلقى نقطة RP الرزمة الموجهة إليها تمامًا مثل نقطة نهاية نفق IP، وتنظر في حمولة رسالة Register، فتجد في الداخل رزمة IP موجَّهةً إلى عنوان البث المتعدد لهذه المجموعة. تعرف نقطة RP ما يجب فعله بمثل هذه الرزمة بالطبع، فهي ترسلها إلى الشجرة المشتركة التي تكون نقطة RP هي جذرها. هذا يعني أن نقطة RP ترسل الرزمة إلى الموجه R2، في مثال الشكل السابق، القادر على تمريرها إلى الموجهَين R4 وR5. يظهر التسليم الكامل للرزمة من الموجه R1 إلى الموجهَين R4 وR5 في الشكل الآتي. نرى انتقال الرزمة الممرَّرة عبر نفق من الموجه R1 إلى نقطة RP مع ترويسة IP إضافية تحتوي على عنوان نقطة RP أحادي البث، ثم تصنع رزمة البث المتعدد الموجَّهة إلى المجموعة G طريقها على طول الشجرة المشتركة إلى الموجهَين R4 وR5. قد نميل إلى إعلان النجاح عند ذلك، حيث يمكن لجميع المضيفين الإرسال إلى جميع المستقبلين بهذه الطريقة. ولكن هناك بعض عدم الكفاءة في حيز النطاق التراسلي bandwidth وتكلفة المعالجة في تغليف وفك تغليف الرزم في الطريق إلى نقطة RP، لذلك تفرض نقطةُ RP المعرِفةَ حول هذه المجموعة في الموجهات المتداخلة بحيث يمكن تجنب الأنفاق. حيث ترسل رسالة انضمام Join إلى المضيف المرسل (القسم (ج) من الشكل السابق). تتسبب رسالة الانضمام Join في أن تتعرف الموجهات على طول المسار (الموجه R3) على المجموعة نظرًا لأن هذه الرسالة تنتقل نحو المضيف، بحيث يمكن للموجه المكلَّف designated router أو اختصارًا DR إرسال الرزمة إلى المجموعة كرزم متعددة البث أصلية native، أي ليست ممرَّرة عبر نفق tunneled على سبيل المثال. من التفاصيل المهمة الواجب ملاحظتها في هذه المرحلة أن رسالةَ الانضمام Join التي أرستلها نقطة RP إلى المضيف المرسل خاصةٌ بهذا المرسل، بينما تنطبق الرسائل السابقة المرسَلة بواسطة الموجهَين R4 و R5 على جميع المرسلين. وبالتالي فإن تأثير رسالة الإنضمام الجديدة هو إنشاء حالة خاصة بالمرسل sender-specific state في الموجهات بين المصدر المحدَّد و نقطة RP. يُشار إلى ذلك بالحالة (S , G)، نظرًا لأنها تنطبق على مرسلٍ واحد لمجموعةٍ واحدة، وتتناقض مع الحالة (G , *) التي جرى تثبيتها بين أجهزة الاستقبال و نقطة RP التي تنطبق على جميع المرسلين. وهكذا نرى في القسم (ج) من الشكل السابق مسارًا خاصًا بالمصدر من الموجه R1 إلى نقطة RP (يشار إليه بالخط المتقطع في الشكل) وشجرةً صالحةً لجميع المرسلين من نقطة RP إلى المستقبلين (يشار إليها بالخط المستمر في الشكل) . التحسين التالي المحتمل هو استبدال الشجرة المشتركة بالكامل بشجرة خاصة بالمصدر. وهذا أمرٌ مرغوب فيه لأن المسار من المرسل إلى المستقبل عبر نقطة RP قد يكون أطول بكثير من أقصر مسارٍ ممكن. من المحتمل أن يُعاد تشغيل هذا التحسين مرةً أخرى بسبب معدل بيانات مرتفع يُلاحَظ من بعض المرسلين. يرسل الموجه الموجود في نهاية الشجرة، كالموجه R4 في مثالنا، رسالة Join خاصةً بالمصدر نحو المصدر في هذه الحالة. إن الموجهات على طول الطريق تنشئ حالة (S , G) لهذه الشجرة نظرًا لأن الموجه الموجود في نهاية الشجرة يتبع أقصر مسار نحو المصدر، والنتيجة هي شجرة جذورها في المصدر، بدلًا من نقطة RP. سننتهي بالشجرة الموضحة في القسم (د) من الشكل السابق بافتراض تبديل كلٍ من الموجهَين R4 و R5 إلى الشجرة الخاصة بالمصدر. لاحظ أن هذه الشجرة لم تعد تتضمن نقطة RP على الإطلاق. لقد أزلنا الشجرة المشتركة من هذه الصورة لتبسيط الشكل، ولكن يجب أن تظل جميع الموجّهات التي تحتوي على مستقبلي مجموعةٍ ما على الشجرة المشتركة في حال ظهور مرسلين جُدد. يمكننا الآن أن نرى لماذا بروتوكول PIM بروتوكول مستقل independent. حيث تستفيد جميع آلياته الخاصة ببناء الأشجار وصيانتها من توجيه البث الأحادي دون الاعتماد على أي بروتوكول توجيه أحادي البث. يُحدَّد تشكيل الأشجار بالكامل من خلال المسارات التي تتبعها رسائل الانضمام، والتي يحددها اختيار أقصر المسارات التي يجريها توجيه البث الأحادي. وبالتالي فإن بروتوكول PIM هو "بروتوكول توجيهٍ مستقل أحادي البث" مقارنةً ببروتوكول DVMRP. لاحظ أن بروتوكول PIM مرتبط إلى حد كبير ببروتوكول الإنترنت، فهو ليس بروتوكولًا مستقلًا بالنسبة لِبروتوكولات طبقة الشبكة. يوضّح تصميم الوضع PIM-SM التحديات في بناء شبكات قابلةٍ للتوسّع وكيف تُوضَع أحيانًا قابلية التوسع مقابل نوعٍ من التحسين. من المؤكد أن الشجرة المشتركة قابلة للتوسع أكثر من الشجرة الخاصة بالمصدر، بمعنى أنها تقلل من الحالة الإجمالية في الموجهات لتكون بترتيب عدد المجموعات بدلًا من عدد المرسلين المضروب بعدد المجموعات. ويمكن أن تكون الشجرة الخاصة بالمصدر ضرورية لتحقيق التوجيه الكُفُؤ والاستخدام الفعال لحيز نطاق الرابط التراسلي. البث المتعدد بين النطاقات Interdomain Multicast يعاني الوضع PIM-SM من بعض أوجه النقص المهمة عندما يتعلق الأمر بالبث المتعدد بين النطاقات. فإن وجود نقطة RP واحدة لمجموعةٍ ما يتعارض مع مبدأ أن النطاقات مستقلة. تعتمد جميع النطاقات المشاركة على النطاق الذي توجد فيه نقطة RP بالنسبة لمجموعة بثٍ متعدد معينة. إذا كان هناك مجموعة بثٍ متعددة معينة يتشارك فيها المرسل وبعض المستقبلين بنطاقٍ واحد، فلا يزال يتعين توجيه حركة مرور البث المتعدد مبدئيًا من المرسل إلى المستقبلين عبر أي نطاق يحتوي على نقطة RP لمجموعة البث المتعدد هذه. وبالتالي لا يُستخدَم بروتوكول PIM-SM عادةً عبر النطاقات، ولكن يُستخدَم داخل النطاق فقط. وُضِع بروتوكول اكتشاف مصدر البث المتعدد Multicast Source Discovery Protocol أو اختصارًا MSDP لتوسيع البث المتعدد عبر النطاقات باستخدام الوضع PIM-SM. يُستخدَم بروتوكول MSDP لربط النطاقات المختلفة، حيث يشغّل كلٌّ منها وضع PIM-SM داخليًا، مع نقاط RP الخاصة به، عن طريق توصيل نقاط RP الخاصة بالنطاقات المختلفة. تحتوي كل نقطة RP على واحد أو أكثر من نقاط التقاء MSDP النظيرة peer لها في النطاقات الأخرى. يُجرى توصيل كل زوج من نظراء MSDP عن طريق اتصال TCP الذي يُشغَّل بروتوكول MSDP من خلاله. يشكّل كل نظراء MSDP لمجموعة معينة من البث المتعدد شبكةً واسعة loose mesh تُستخدم كشبكة بثٍ إذاعي broadcast network. تُبَث رسائل MSDP إذاعيًا عبر شبكةٍ من نظراء نقاط RP باستخدام خوارزمية بث المسار العكسي إذاعيًا Reverse Path Broadcast algorithm التي ناقشناها في سياق بروتوكول DVMRP. ما هي المعلومات التي يبثها بروتوكول MSDP إذاعيًا عبر شبكة نقاط RP؟ من المستبعد أن تكون معلومات عضوية المجموعة، لأن أقصى تدفقٍ للمعلومات هو نقطة RP الخاصة بنطاق المضيف المنضَم إلى مجموعة. بل هي معلومات المصدر أي المُرسل متعدد البث. تعرف كلُّ نقطة RP المصادرَ الموجودة في نطاقها الخاص لأنها تتلقى رسالة تسجيل Register كلما ظهر مصدرٌ جديد. تستخدم كلُّ نقطة RP دوريًا بروتوكولَ MSDP لبث رسائل المصدر النشط Source Active إلى نظرائها، مع إعطاء عنوان IP المصدر وعنوان مجموعة البث المتعدد وعنوان IP الخاص بنقطة RP الأصلية. إذا كان لدى نظير نقطة التقاء RP بروتوكول MSDP، والذي يتلقى إحدى رسائل البث الإذاعي هذه، مستقبلين نشطين لمجموعة البث المتعدد هذه، فإنه يرسل رسالة انضمام Join خاصةٍ بالمصدر إلى مضيف المصدر نيابةً عن نقطة RP نفسها، كما هو موضح في القسم (أ) من الشكل السابق. تنشئ رسالة الانضمام فرعًا من الشجرة الخاصة بالمصدر إلى نقطة RP هذه، كما هو موضح في القسم (ب) من الشكل السابق. والنتيجة هي أن كل نقطة RP تمثّل جزءًا من شبكة MSDP ولديها مستقبلون نشطون لمجموعة معينة من البث المتعدد تضاف إلى شجرة المصدر المحددة للمصدر الجديد. تستخدم نقطة RP شجرتها المشتركة لتمرير البث المتعدد إلى المستقبلين في نطاقها عندما تتلقى بثًا متعددًا من المصدر. البث المتعدد المحدد بالمصدر Source-Specific Multicast كان نموذج الخدمة الأصلي لبروتوكول PIM، مثل بروتوكولات البث المتعدد السابقة، نموذج متعدد إلى متعدد. حيث انضم المستقبلون إلى مجموعة، ويمكن لأي مضيف الإرسال إلى هذه المجموعة. ولكن اُعترِف في أواخر التسعينات بأنه قد يكون من المفيد إضافة نموذج واحد إلى متعدد one-to-many. الكثير من تطبيقات البث المتعدد لها مرسلٌ واحد فقط مسموحٌ به، مثل المتحدث في مؤتمرٍ عبر الإنترنت. لقد رأينا بالفعل أن بروتوكول PIM-SM يمكنه إنشاء شجرات بأقصر مسار مُحدَّد بالمصدر مثل تحسينٍ بعد استخدام الشجرة المشتركة في البداية. كان هذا التحسين غير مرئي للمضيفين في تصميم بروتوكول PIM الأصلي، حيث انضمت الموجهات فقط إلى الأشجار المحددة بالمصدر. ولكن تقرَّر جعل قدرة التوجيه المُحدَّد بالمصدر في بروتوكول PIM-SM متاحًا بصورةٍ صريحة للمضيفين، بمجرد إدراك الحاجة إلى نموذج خدمة واحد إلى متعدد. اتضح أن هذا يتطلب بصورة أساسية تغييراتٍ في بروتوكول IGMP ونظيره في الإصدار IPv6، الذي هو بروتوكول MLD، بدلًا من بروتوكول PIM نفسه. تُعرف القدرة المكتشفة حديثًا باسم PIM-SSM، بث PIM المتعدد المحدّد للمصدر PIM Source-Specific Multicast. يقدم بروتوكول PIM-SSM مفهومًا جديدًا، وهو القناة channel، والتي هي مزيج من عنوان المصدر S وعنوان المجموعة G. يبدو عنوان المجموعة G تمامًا مثل عنوان IP متعدد البث العادي، وقد خصص كل من IPv4 و IPv6 مجالاتٍ فرعية من حيز عناوين البث المتعدد لمفهوم SSM. يحدِد المضيف كلًا من المجموعة والمصدر في رسالة تقرير عضوية IGMP إلى موجهه المحلي من أجل استخدام بروتوكول PIM-SSM. يرسل هذا الموجه بعد ذلك رسالة انضمام محددةٍ بمصدر PIM-SM إلى المصدر، وبالتالي يضيف فرعًا لنفسه في الشجرة المحدَّدة بالمصدر، تمامًا كما في بروتوكول PIM-SM "العادي"، ولكن مع تجاوز مرحلة الشجرة المشتركة بأكملها. يمكن فقط للمصدر المحدد إرسال رزمٍ على تلك الشجرة، نظرًا لأن الشجرة التي تظهر نتائجها محددةٌ بالمصدر . قدّم إدخال مفهوم PIM-SSM بعض الفوائد المهمة، نظرًا لوجود طلبٍ مرتفع نسبيًا على البث المتعدد من واحد إلى متعدد one-to-many multicasting، وهذه الفوائد هي: تنتقل رسائل البث المتعدد مباشرةً إلى المستقبلين بصورة أكبر. عنوان القناة هو عنوان مجموعة بث متعدد إضافةً إلى عنوان المصدر. لذلك يمكن لنطاقاتٍ متعددة استخدام نفس عنوان مجموعة البث المتعدد بصورة مستقلة ودون تعارض طالما أنها تستخدمه فقط مع المصادر في النطاقات الخاصة بها، نظرًا لأنه سيُستخدَم مجالٌ معين من عناوين مجموعة البث المتعدد لمفهوم SSM حصريًا. بما أنه يمكن للمصدر المحدد فقط الإرسال إلى مجموعة SSM، فهناك مخاطر أقل للهجمات القائمة على المضيفات الضارة التي تغمر الموجهات أو المستقبلين بحركة مرور متعددة البث وزائفة. يمكن استخدام بروتوكول PIM-SSM عبر النطاقات تمامًا كاستخدامه داخل النطاق، دون الاعتماد على أي شيء آخر كبروتوكول MSDP. لذلك يعد مفهوم SSM إضافةً مفيدة إلى حدٍ ما إلى نموذج خدمة البث المتعدد. الأشجار ثنائية الاتجاه Bidirectional Trees مثل بروتوكول BIDIR-PIM نختم مناقشتنا للبث المتعدد بتحسينٍ آخر لبروتوكول PIM يُعرف باسم PIM ثنائي الاتجاه Bidirectional. بروتوكول BIDIR-PIM هو بروتوكول حديث ومختلف عن بروتوكول PIM-SM وهو مناسب تمامًا للبث المتعدد بنمط متعدد إلى متعدد داخل النطاق، خاصة عندما يكون المرسلين والمستقبلين لمجموعة ما متماثلين، كما هو الحال في مؤتمر الفيديو متعدد الأطراف على سبيل المثال. ينضم المستقبلون المحتملون إلى المجموعات عن طريق إرسال رسائل تقرير عضوية IGMP (والتي يجب ألا تكون محددة المصدر) كما هو الحال في بروتوكول PIM-SM، وتُستخدَم شجرة مشتركة جذرها في نقطة RP لتمرير رزم البث المتعدد إلى المستقبلين. إن الشجرة المشتركة لها أيضًا فروعٌ إلى المصادر، على عكس بروتوكول PIM-SM، حيث لن يكون هذا منطقيًا مع شجرة PIM-SM أحادية الاتجاه unidirectional، أما أشجار BIDIR-PIM ثنائية الاتجاه، فيمكن للموجه الذي يتلقى رزمة بثٍ متعدد من الفرع السفلي تمريرها إلى أعلى الشجرة وأسفل الفروع الأخرى. يذهب المسارُ المتّبع لتسليم رزمةٍ إلى أي مستقبل معين فقط إلى أعلى الشجرة حسب الضرورة قبل النزول أسفل الفرع إلى ذلك المستقبل. شاهد مسار البث المتعدد من الموجه R1 إلى الموجه R2 في القسم (ب) من الشكل الآتي كمثال. يمرر الموجه R4 رزمة البث المتعدد لأسفل الشجرة إلى الموجه R2 بنفس الوقت الذي يمرر فيه نسخةٍ من نفس الرزمة لأعلى الشجرة إلى الموجه R5. أحد الجوانب المدهشة في بروتوكول BIDIR-PIM هو أنه لا داعي لوجود نقطة RP بالفعل. فكل ما هو مطلوب هو عنوان قابل للتوجيه، والذي يُعرف باسم عنوان RP على الرغم من أنه لا يلزم أن يكون هذا العنوان هو عنوان نقطة RP أو أي شيء على الإطلاق. كيف يمكن أن يحدث هذا؟ تُمرر رسالة الإنضمام Join من جهاز مستقبل إلى عنوان نقطة RP حتى يصل إلى موجهٍ له واجهةٌ على الرابط حيث يوجد عنوان RP، وعندها ينتهي الانضمام. يظهر القسم (أ) من الشكل الآتي رسالة Join تبدأ من الموجه R2 وتنتهي عند الموجه R5، ورسالة Join تبدأ من الموجه R3 وتنتهي عند الموجه R6. يتدفق تمرير رزمة البث المتعدد للأعلى نحو عنوان RP حتى تصل إلى موجهٍ له واجهةٌ على الرابط حيث يتواجد عنوان RP، ولكن بعد ذلك يمرر الموجه رزمة البث المتعدد إلى هذا الرابط كخطوة أخيرة للتمرير للأعلى، متأكدًا من أن جميع الموجهات الأخرى الموجودة على هذا الرابط تتلقى هذه الرزمة. يوضح القسم (ب) من الشكل التالي تدفق حركة البث المتعدد الناشئة في الموجّه R1: لا يمكن حتى الآن استخدام بروتوكول BIDIR-PIM عبر النطاقات. ولكن لديه العديد من المزايا التي تتفوق على بروتوكول PIM-SM من أجل البث المتعدد بنمط متعدد إلى متعدد داخل النطاق، وهذه المزايا هي: لا توجد عملية تسجيل registration للمصدر حيث تعرف الموجهات بالفعل كيفية توجيه رزمة البث المتعدد نحو عنوان RP. المسارات مباشرةٌ أكثر من تلك التي تستخدم شجرة PIM-SM المشتركة لأنها تذهب فقط إلى أعلى الشجرة حسب الضرورة، وليس على طول الطريق إلى نقطة RP. تستخدم الأشجار ثنائية الاتجاه حالة أقل بكثير من الأشجار المحدَّدة بالمصدر في بروتوكول PIM-SM لأنه لا توجد أبدًا أية حالةٍ محدَّدةٌ بالمصدر. لكن ستكون المسارات أطول من مسارات الأشجار المحددة بالمصدر. لا يمكن أن تكون نقطة RP عنق زجاجة bottleneck أو نقطة اختناق، وليست هناك حاجة فعلية لنقطة RP. أحد الاستنتاجات الممكن استخلاصها من حقيقة أن هناك العديد من الأساليب المختلفة للبث المتعدد خلال بروتوكول PIM فقط هو أن البث المتعدد يمثل مجالًا لمشكلةٍ صعبة يمكن إيجاد الحلول المثلى فيها. تحتاج إلى تحديد المعايير التي تريد تحسينها (استخدام حيز النطاق التراسلي، وحالة الموجه، وطول المسار وغير ذلك) ونوع التطبيق الذي تحاول دعمه (واحد إلى متعدد، متعدد إلى متعدد وهلم جرا) قبل اتخاذ قرار الاختيار "لأفضل" اوضاع مهمة البث المتعدد. ترجمة -وبتصرّف- للقسم Multicast من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: الإصدار السادس من بروتوكول IP الشبكات الحاسوبية متعددة الوصول Multi-Access Networks البرمجيات المستخدمة في بناء الشبكات الحاسوبية

محرر القصص Story Editor هو نافذة التحرير المستخدَمة لإدخال نص يدويًا ضمن إطار نص، وهدفه الأساسي هو عرض محتوى هذا النص، مع تفعيل بعض ميزات العرض البسيطة فقط. تظهر ضمن محرر القصص التغييرات الخاصة بما يلي: المحاذاة Justification، ولكنه لا يظهِر فواصل التفاف الأسطر الخاصة بالكلمات. لون الخط. تسطير النص Underline. رمز سفلي Subscript. رمز علوي Superscript. شطب النص Strikethrough. ولا تظهِر ضمنه تغييرات ميزات إطار النص التالية: واجهة الخط Font face. حجم الخط Font size. ضبط المسافات بين الأحرف أو "تعقّب يدوي" Kerning. تباعد الأسطر Line spacing. كل الحروف الكبيرة All Caps، أو الأحرف الصغيرة Small Caps. مخطط الحروف Outline. الظل Shadow. الحروف الاستهلالية Drop Caps. كيفية فتح محرر القصص حدّد إطار النص ثم انقر على أيقونة "حرّر النص باستخدام محرّر القصص" من شريط الأدوات، أو باستخدام الاختصار Ctrl+T من لوحة المفاتيح في الإصدار 1.5.7 من برنامج سكريبوس، أو من قائمة تحرير Edit، ثم اختر "حرّر النص باستخدام محرّر القصص، ويتوفر هذا الخيار أيضًا في قائمة السياق، وذلك بالنقر بزر الفأرة الأيمن ضمن الإطار. الخيارات هو العنصر الموجود في أقصى يسار قوائم محرّر القصص Story Editor، ولكنه يحتوي على وظائف العرض الأساسية التي قد تكون مهمةً عند بدء التحرير. انقر على الخيارات Settings ثم اختر الخلفية Background التي تسمح لك بضبط الخلفية، ولكن فقط ضمن شاشة محرر القصص. يمكنك استخدام هذه الخلفية إذا كان النص أبيض أو شاحب للغاية على سبيل المثال، وبالتالي سيؤدي تغيير الخلفية إلى جعلها أوضح (لا يتوفر هذا الخيار في الإصدار 1.5.7 الجديد والداعم للغة العربية من برنامج سكريبوس في محرّر القصص ولكنه يتوفر في الإصدارات الأقدم، ويمكنك تغيير لون خلفية النص من قائمة نوافذ، ثم خصائص المحتوى ثم تبويب "الألوان والمؤثرات"). انقر على "الخيارات" ثم اختر تحديد النص الذكي Smart text selection. السلوك الافتراضي عند النقر المزدوج على كلمة ما، هو تحديد الكلمة وأول مسافة بعدها؛ بينما سيختار التحديد "الذكي" الكلمة فقط، دون الفراغ الذي يليها (لا يتوفر هذا الخيار في الإصدار 1.5.7 الجديد والداعم للغة العربية من برنامج سكريبوس ضمن قائمة الخيارات، ولكنه يتوفر في قائمة تحرير ضمن محرر القصص). انقر على الخيارات ثم اختر الخيار "اعرض الخط" الذي سيغير الخط، ولكن ضمن شاشة محرّر القصص فقط. البداية قد ترغب في كثير من الحالات البدء على الفور في إدخال النص، ولكن لن تظهر غالبًا الميزات التي سيحتوي عليها نصك مثل نوع الخط، وحجمه، وتباعد الأسطر، وما إلى ذلك حتى تحفظ الإدخال ثم تخرج من محرر القصص. قد تكون هذه هي المرة الأولى التي تستخدم فيها برنامج سكريبوس، ولكن ستُعرَض إعدادات النص الافتراضية التي يمكنك تغييرها يدويًا حسب حاجتك. ضع في بالك أنك إن غيّرت الإعدادات -مثل الخط مثلًا-، فسيُطبَّق ذلك فقط على النص الذي ستدخلته لاحقًا، وليس على النص الذي أدخلته بالفعل. إن أردت تغيير ميزات الخط للنص الذي أُدخِل بالفعل، فيجب عليك تحديد النص وذلك من خلال النقر بالفأرة مع السحب، أو باستخدام مفتاح Shift مع الأسهم من لوحة المفاتيح أولًا، ثم تغيير الميزة (أو الميزات) التي ترغب في تغييرها. يمكنك تغيير إعدادات النص الافتراضية من خلال مغادرة محرر القصص، والانتقال إلى قائمة ملف File ثم تفضيلات Preferences ثم أدوات العنصر، ثم النقر على تبويب النص، واتبع المسار إعدادات Settings ثم تفضيلات Preferences ثم أدوات Tools. الأنماط Styles وأنماط الفقرات Paragraph Styles لاحظ أولًا أنه لا توجد أنماط افتراضية في برنامج سكريبوس، فجميعها ينشئها المستخدم. يشير النمط إلى مجموعة من ميزات النص والخط وحجمه وأي إعدادات أخرى يمكنك تغييرها في محرر القصص، وتطبيقها إما قبل إدخال النص أو بعده. سيكون هذا مفيدًا خاصةً عندما تستخدم قائمة من الإعدادات المختلفة بصورة متكررة في النص، مثل استخدام أحد أنماط العناوين أو نمط آخر للنص. يمكنك إنشاء الأنماط الخاصة بك في محرر القصص من قائمة تحرير Edit ثم أنماط Styles، أو ببساطة عن طريق النقر على الموجّه "بلا نمط" الموجود على يمين منطقة إدخال النص ضمن محرر القصص حيث سيظهر لك خيار التحرير، ويمكنك إنشاء الأنماط من النافذة الرئيسية من قائمة تحرير ثم أنماط (اختر أنماط الفقرة)، ثم بالنقر على جديد (أنماط فقرات)، حيث سيحمل هذا النمط الاسم الافتراضي "نمط جديد New Style"، والذي لا بد أنك ستغيّره إلى اسم يصِف هذا النمط. يمكنك إنشاء أي عدد من الأنماط وحفظها في ملف يمكنك استيراده عند تشغيل برنامج سكريبوس لاحقًا. كما ستُحفَظ هذه الأنماط وأسماؤها تلقائيًا في مستند سكريبوس الخاص بك. يُطبَّق هذا النمط على فقرة كاملة كما يوحي اسم التحديد لأنماط الفقرات Paragraph Styles، ثم يعود إلى النمط الذي يليه بعد انتهاء الفقرة. لاحظ نقل النمط الأخير إلى الفقرة التالية حتى تتمكّن من تغييره بمجرد تطبيق النمط ثم الاستمرار في الكتابة، حيث يمكنك بمجرد إنشاء قائمة بالأنماط، أن تركز على كتابة النص دون الاهتمام بالنمط، ثم إصلاح الأنماط عند الانتهاء، وذلك عن طريق النقر على زر النمط الموجود بجوار أزرار المحاذاة في محرر القصص، أو على الموجّه بلا نمط الموجود على يمين نافذة النص، حيث ستظهر قائمة بالأنماط نفسها لتختار من بينها. يمكنك أيضًا تغيير الأنماط في نافذة خصائص النص التي تصل إليها من خلال قائمة نوافذ، ثم خصائص المحتوى، ولكن سيؤدي تغيير النمط إلى تغيير نمط الإطار بأكمله عندما تكون في وضع تحديد العنصر، أي الوضع الافتراضي عند الخروج من محرّر القصص أو بدء برنامج سكريبوس. انقر على وضع تحرير محتويات الإطار لتغيير الفقرات الفردية فقط (حيث يومض المؤشّر)، ويمكنك التأكد من أن التغييرات التي تريدها ستُطبَّق فقط في المكان الذي تريده، من خلال تحديد هذا النص ثم إجراء التغييرات من خلال نافذة "خصائص النص"، حيث ستتمكّن بعد ذلك على الفور من رؤية تغييراتك وتقييمها. كيفية تفعيل الحروف الاستهلالية Drop Caps هذا الخيار موجود في مربع حوار طلب إنشاء / تحرير الأنماط الذي يمكنك الوصول إليه من خلال الانتقال إلى قائمة تحرير ثم أنماط. انقر لإنشاء نمط جديد أو تعديل نمط قديم، ثم انقر على الحروف الاستهلالية، وبعدها يمكنك ضبط عدد الأسطر التي تشغَلها الحروف الاستهلالية، وكذا التباعد الأفقي بينها وبين النص. يمكنك إلى حدٍ ما رفع أو خفض خط أساس الحروف الاستهلالية ولكن مع وجود مشاكل في العرض، كما يمكنك إنشاء حروف استهلالية أكثر تعقيدًا يدويًا. ويمكنك أيضًا في الإصدار 1.5.7 الوصول إلى الحروف الاستهلالية من قائمة نوافذ، ثم اختيار نافذة خصائص المحتوى، بحيث تُظهر نافذة خصائص النص، ثم اختر تبويب "مؤثرات الفقرة"، بعدها اختر حروف استهلالية من القائمة المنسدلة. المسافة البادئة Indentation والمسافة البادئة المعلقة Hanging Indentation توجد في الجزء السفلي من مدير الأنماط عناصر لضبط المسافة البادئة للسطر الأول من كل فقرة ضمن مربع تبويبات وإزاحة، ويمكنك أيضًا وضع مسافة بادئة للأسطر اللاحقة بعد السطر الأول مثل مسافة بادئة معلَّقة (يمنى أو يسرى)، بعدها حرك مؤشرات الأسهم أو اضبط القيم الرقمية. مشكلة سطور الأعمدة غير المتساوية إن وضعت نصًا في إطار مكوَّن من عمودين أو أكثر، فقد تظهر الأسطر في هذه الأعمدة غير متساوية، وخاصةً عند دمج إطار نص مع إطار صورة. ويمكنك أيضًا رؤية ذلك عندما يكون لديك إطاران منفصلان من النصوص جنبًا إلى جنب، إذ تظهر هذه المشكلة مثل ما يوضح الشكل التالي، بحيث يمكنك إظهار الخطوط الموضَّحة في الشكل من قائمة عرض View ثم إطارات النص، ثم بالضغط على "أظهر خط الشبكة الأساسي Show Baseline Grid": يمكن حل هذه المشكلة من خلال تطبيق نمط فقرة، وذلك من خلال فتح مدير الأنماط إما من خلال النقر على نمط الفقرة الافتراضي، أو بالنقر على الزر جديد، ثم حدد نمط الفقرة. سترى داخل مربع المسافات والمحاذاة زرًا يشير افتراضيًا إلى تباعد أسطر ثابت Fixed Linespacing، عندها انقر على هذا الزر وحدد الخيار "حاذ لخط الشبكة الأساسي Align to Baseline Grid"، ثم طبّق هذا النمط على الفقرة (الفقرات) حسب الحاجة، أو يمكنك بدلًا من ذلك تحديد النمط في نافذة خصائص النص، وبالتالي ستُحَل المشكلة السابقة ويظهر الحل مثل الشكل التالي: يمكنك تعيين أو ضبط التباعد في شبكة الخط الأساسي Baseline Grid من قائمة ملف File، ثم تفضيلات Preferences، ثم الأدلة Guides للمستندات المستقبلية؛ أو من قائمة File ثم إعدادات المستند Document Setup، ثم الأدلة Guides للمستند الحالي. حجم الخط Font Size وتباعد الأسطر Line Spacing هناك بعض الخصائص المميزة الخاصة بحجم الخط وتباعد الأسطر، بحيث لن يكون هناك تغيير تلقائي في تباعد الأسطر في محرر القصص عندما تغيّر حجم الخط، لذلك فإن زاد حجم الخط عن نقطة معينة، فستتداخل الأحرف الموجودة في الأسطر المجاورة مع بعضها البعض، وبالتالي ستحتاج بعد ذلك إلى ضبطها يدويًا. ويحدث العكس في النافذة الرئيسية عند استخدام نافذة خصائص النص في وضع تحديد العنصر، إذ يؤدي التغيير في حجم الخط إلى زيادة تلقائية في تباعد الأسطر، وبالطبع سيتغير هذا المعامِل للإطار بأكمله. يمكن ضبط درجة تباعد الأسطر التلقائي من قائمة ملف File ثم تفضيلات Preferences، ثم فنيات الطباعة Typography، بعدها اختيار "تباعد الأسطر تلقائيًا Automatic Line Spacing". سيحدث السلوك ذاته مع محرر القصص عندما تكون في وضع تحرير محتويات الإطار، إذ لن يؤدي تغيير حجم الخط إلى تغيير تباعد الأسطر تلقائيًا، وقد يكون الضبط اليدوي ضروريًا، وإذا أجريت إعداد نمط فقرة، فسترى أن تغيير حجم الخط سيؤدي إلى ضبط تباعد الأسطر. وبالتالي ستحتاج على الأرجح إلى تغيير تباعد الأسطر يدويًا عندما تحاول إنشاء إطار توجد فيه تغييرات في حجم الخط وتباعد الأسطر. يمكنك إلى حد ما تجنب ذلك أو على الأقل تسهيل هذه العملية باستخدام الأنماط. ترجمة -وبتصرّف- للمقال Working with Story Editor لصاحبه Gregory Pittman. اقرأ أيضًا أساسيات تخطيط الصفحات Page Layout في سكريبوس Scribus الطريقة الأساسية لترقيم العناصر تسلسليا في برنامج سكريبوس Scribus كيفية إنشاء أشكال معقدة ذات زوايا دائرية في برنامج سكريبوس Scribus

سنوضح في هذا المقال كيفية إنشاء صفحات تحتوي عناصرًا بسيطةً مرقَّمة تسلسليًا مثل تذاكر اليانصيب، فقد تحتاج أحيانًا إلى طباعة صفحات للمحتوى نفسه باستخدام طريقة ترقيمٍ تسلسلي بسيط، بحيث تكون هذه الطريقة مناسبةً لكل المحتوى. سننشئ باستخدام هذه الطريقة صفحات تتألف كل منها من عشر تذاكر، لأن عملية الترقيم باستخدام عشر تذاكر لكل صفحة أسهل بكثير، لهذا فإن كنت بحاجة إلى أقل من عشرة تذاكر أو أكثر لكل صفحة، فسنناقش هذه الحالة في نهاية هذا المقال. هناك طرق أخرى -أكثر تعقيدًا- متاحة لترقيم العناصر تسلسليًا، لهذا راجع فقرة "طرق أخرى" في نهاية هذا المقال لمزيد من المعلومات. الإعداد افتح برنامج سكريبوس وأنشئ مستندًا جديدًا بالحجم والاتجاه الذي تريده، وسنستخدم في هذا المثال مستندًا بحجم A4 أو بحجم رسالة. اختر قائمة "عرض View" ثم "إظهار الأدلة Show Guides" (إذا كان خيار "إظهار الأدلة" محدّدًا مسبقًا، فلا تحدّده مرةً أخرى). اختر قائمة "صفحة Page" ثم "اتبع الأدلة Snap to Guides" (إن كان الخيار "اتبع الأدلة" محددًا بالفعل، فلا تحدّده مرةً أخرى). اختر قائمة "تحرير Edit" ثم اختر "صفحة رئيسية" ليفتح مربع حوار "أدِر الصفحات الرئيسية"، وسنوضّح سبب استخدام هذه الخطوة لاحقًا. إنشاء الأدلة اختر قائمة صفحة Page ثم إدارة الأدلة أو الدلائل Manage Guides. حدّد التبويب "عمود / صف". ثم نفّذ ما يلي في مربع "أفقي Horizontals" على يمين مربع الحوار: غيّر "العدد" إلى 4. اختر من قائمة "يشير إلى Refer to" الخيار "هوامش Margins". ثم نفّذ ما يلي في مربع "عمودي Verticals" على يسار مربع الحوار: غيّر "العدد" إلى 1. اختر من قائمة "يشير إلى Refer to" الخيار "هوامش Margins". اضغط على زر "تطبيق لكل الصفحات". أغلق مربع الحوار. يجب أن يكون لديك الآن صفحة تشبه الشكل التالي: إنشاء التذكرة الأولى اختر قائمة "إدراج Insert" ثم "إدراج شكل Insert Shape"، ثم اختر "أشكال افتراضية Default Shape" ثم مستطيل Rectangle. ارسم مستطيلًا يبدأ من أعلى يسار هامش الصفحة إلى أول تقاطع بين الهوامش الأفقية والعمودية. وطالما أنك تضع المؤشر بالقرب من البداية والنهاية، فيجب أن ينجذب المستطيل إلى الهوامش والأدلة. اختر قائمة إدراج ثم "إطار نص Text Frame". ارسم إطار النص في النصف العلوي من المستطيل. انقر نقرًا مزدوجًا على إطار النص واكتب نصًا، "تذكرة يانصيب" مثلًا. يمكنك تعديل حجم خط النص الذي أدخلته من خلال على تبويب نص Text من نافذة خصائص في الإصدارات الأقدم من الإصدار 1.5.7، مثل الإصدار 1.4.8. بينما يمكنك تعديل حجم خط النص في الإصدار 1.5.7 الداعم للغة العربية من خلال نافذة "خصائص النص"، والتي يمكنك فتحها من خلال النقر على قائمة "نوافذ" ثم خصائص المحتوى، أو من خلال الضغط على زر "حرّر النص باستخدام محرّر القصص". اختر قائمة إدراج ثم إطار نص مرةً أخرى. ارسم إطار النص في النصف السفلي من المستطيل. انقر نقرًا مزدوجًا فوق إطار النص. اختر قائمة إدراج ثم "حرف Character" ثم "رقم الصفحة Page Number". أضف النص "0" (بدون علامات الاقتباس) بعد "#" الذي يشير إلى رقم الصفحة. عدّل حجم خط النص. يجب أن يكون لديك الآن شيء يشبه الشكل التالي: إنشاء تذاكر متعددة لنكرّر التذكرة الأولى مع إجراء بعض التغييرات الطفيفة بعد الانتهاء من التذكرة الأولى. حدّد المستطيل وكل شيء بداخله. اختر قائمة عنصر Item ثم اختر "مضاعفة/تحويل"، ثم اختر "نسخ مطابقة Multiple Duplicate". حدّد تبويب "بعدد الصفوف والأعمدة By Rows & Columns". اضبط "عدد الصفوف" على القيمة 5. اضبط "عدد الأعمدة" على القيمة 2. اضغط على "موافق" في مربع الحوار. يجب أن تكون لديك الآن صفحة تذاكر تشبه الشكل التالي: التعديلات يجب الآن إجراء بعض التغييرات الطفيفة على التذاكر المكرَّرة الخاصة بك، لهذا انقر نقرًا مزدوجًا على إطار النص "0#" في التذكرة العلوية اليمنى (لا تغير الإطار الأصلي)، وغيّر القيمة الرقمية (بعد #) إلى 1. افعل الشيء نفسه مع كل من التذاكر الأخرى ولكن زِد القيمة الرقمية بمقدار واحد في كل مرة بحيث يكون التغيير الأخير الذي تجريه من "0#" إلى "9#". يجب أن تكون لديك الآن صفحة تذاكر تشبه الشكل التالي: أغلق نافذة تحرير مربع حوار "أدِر الصفحات الرئيسية". إنشاء التذاكر يجب أن تكون صفحتك قد تغيرت الآن لتبدو بالشكل التالي: أما بالنسبة لأرقام التذاكر الأكبر من 19، فكل ما عليك فعله هو إنشاء صفحات جديدة، وهنا عليك باتباع الآتي: اختر قائمة صفحة ثم نسخ Copy. اضغط على "موافق". لقد أنشأت الآن تذاكرًا من الرقم 20 إلى 29، أضِف المزيد من الصفحات لإنشاء المزيد من التذاكر. القيم العليا لكن إن أردت أن تبدأ أرقام التذاكر الخاصة بك بقيمة أعلى فاتبع الخطوات البسيطة التالية: اختر قائمة ملف File ثم إعداد المستند. مرّر للأسفل في قائمة الأيقونات اليمنى حتى تصل إلى "الأقسام Sections" ثم اخترها. أدخل قيمة البداية التي تريدها في خلية "البداية" الموجودة في يسار القسم الأول ضمن الشبكة. إن أردت أن تبدأ أرقام التذاكر من 500، فأدخِل القيمة 50 مثل قيمة بداية، وتذكر أن تقسم قيمة البداية التي تريدها على العدد 10، مع الضغط على زر "موافق". استخدام أقل من عشر تذاكر لكل صفحة يمكنك استخدام طريقة مماثلة كما هو مذكور أعلاه، وذلك لإنشاء صفحات بعدد تذاكر أقل من عشرة لكل صفحة، ولكن انتبه إلى أن كل صفحة ستحتوي فقط على هذا العدد من التذاكر، وبالتالي ستكون هناك فجوات بين بعض التسلسلات. فإن استخدمت ثمانية تذاكر في كل صفحة على سبيل المثال، فستُرقَّم التذاكر بالشكل: 10-17، 20-27، 30-37 وهكذا. وبالتالي ستكون هناك فجوة، فالتذكرتان 18 و19 مفقودتان مثلًا، ولكن ما مدى تأثير ذلك على استخدامها؟ وإن أصدرتَ تذاكرًا فردية، فكيف سيعرف الناس وجود هذه الفجوات؟ وبما أنه لا توجد طريقة لسحب التذكرة التي لم تُصدَر، فمن سيلاحظ ذلك باستثنائك؟ يمكن سحب التذاكر التي جرى إصدارها فقط، لذلك لا توجد حيلة لحل هذه المشكلة، وبالتالي فالأمر متروك لك باستخدام هذه الطريقة أو بعدم استخدامها. استخدام أكثر من عشر تذاكر لكل صفحة ستُرقَّم آخر تذكرتين في الصفحة الأولى بالقيمتين 110 و111 باستخدام هذه الطريقة عند محاولة الحصول على 12 تذكرة لكل صفحة على سبيل المثال، كما ستُرقَّم آخر تذكرتين في الصفحة الثانية بالقيمتين 210 و211 وهكذا. لا يزال يتعيّن عليك إجراء الكثير من التحرير اليدوي بحيث تدخل أرقام التذكرة يدويًا بنفسك من البداية حتى وإن حاولت إعادة ترتيب رقم الصفحة (#) داخل حقل النص، لذلك يُفضَّل الالتزام بعشر تذاكر لكل صفحة لإنه أسهل بكثير. ترجمة -وبتصرّف- للمقال Sequentially Numbered Items - Basic Method. اقرأ أيضًا كيفية إنشاء أشكال معقدة ذات زوايا دائرية في برنامج سكريبوس Scribus أساسيات تخطيط الصفحات Page Layout في سكريبوس Scribus كيفية بدء استخدام برنامج سكريبوس Scribus

الدافعُ وراء تحديد إصدارٍ جديد من بروتوكول IP بسيط هو التعامل مع استنفاد حيّز عناوين IP. ساعد التوجيه بين النطاقات عديم التصنيف Classless Interdomain Routing أو اختصارًا CIDR بصورة كبيرة في احتواء المعدل الذي يُستهلك حيز عناوين الإنترنت فيه، وساعد أيضًا في التحكم في نمو معلومات جدول التوجيه المطلوبة في الموجّهات على الإنترنت، ولكن هذه التقنيات لم تعد كافية. يكاد يكون من المستحيل تحقيق كفاءة استخدام العناوين بنسبة 100%، لذلك اُستهلك حيز العناوين قبل اتصال المضيف الذي رقمه 4 مليارات بالإنترنت. حتى لو تمكنّا من استخدام جميع العناوين التي عددها 4 مليارات، فمن الواضح الآن أن عناوين IP تحتاج إلى إسنادها لأكثر من حاسوبٍ تقليدي فقط، بما في ذلك الهواتف الذكية وأجهزة التلفاز والأجهزة المنزلية والطائرات دون طيار. إن حيّز العناوين ذات 32 بت صغيرٌ جدًا. المنظور التاريخي Historical Perspective بدأت منظمة IETF في النظر في مشكلة توسيع حيز عناوين IP في عام 1991، واُقترحت العديد من البدائل. إن زيادة حجم العنوان يفرض تغييرًا في ترويسة الرزمة نظرًا لأن عنوان IP يُحمَل في ترويسة كل رزمة IP، وهذا يعني إصدارًا جديدًا من بروتوكول الإنترنت. ونتيجة لذلك هناك حاجة إلى برنامج جديد لكل مضيفٍ وموجّه في الإنترنت. من الواضح أن القيام بذلك ليس بمسألة بسيطة، فهي تغييرٌ كبير يجب التفكير فيه بعناية فائقة. كانت الجهود المبذولة لتحديد إصدارٍ جديد من IP يُعرف في الأصل باسم IP Next Generation أو IPng. أُسند رقم إصدار IP رسمي مع تقدّم العمل، لذلك أصبح IPng يُعرَف باسم IPv6. لاحظ أن إصدار IP الذي نوقِش حتى الآن في هذا الفصل هو الإصدار 4 (IPv4). الانقطاع الظاهر في ترقيم الإصدارات هو نتيجة استخدام الإصدار رقم 5 لبروتوكولٍ تجريبي منذ عدة سنوات. تسببت أهمية التغيير إلى إصدار جديد من بروتوكول IP في إحداث تأثيرٍ تراكمي. كان الشعور العام بين مصممي الشبكات أنه إذا كنت ستجري تغييرًا بهذا الحجم، فيمكنك أيضًا إصلاح العديد من الأشياء الأخرى في بروتوكول IP في نفس الوقت. وبالتالي طلبت منظمة IETF من أي شخص مُهتم أن يدخل معلوماتٍ حول الميّزات التي قد تكون مطلوبة في إصدارٍ جديد من بروتوكول IP. تضمنت بعض عناصر قائمة الرغبات الأخرى لإصدار IPng، إضافةً إلى الحاجة إلى استيعاب التوجيه القابل للتوسّع والعنونة، ما يلي: دعم خدمات الوقت الحقيقي. دعم الأمن. الضبط التلقائي Autoconfiguration: أي قدرة المضيفين على ضبط أنفسهم تلقائيًا بمعلومات مثل عنوان IP الخاص بهم واسم النطاق. وظيفة توجيه محسَّنة، بما في ذلك دعم المضيفين المتنقلين. من المثير للاهتمام ملاحظة أنه في حين غياب العديد من هذه الميزات عن الإصدار IPv4 في الوقت الذي صُمِّم فيه الإصدار IPv6، فقد شق دعم جميع هذه الميزات طريقه إلى الإصدار IPv4 في السنوات الأخيرة، ويستخدم غالبًا تقنيات مماثلة في كلا البروتوكولين. يمكن القول بأن حرية التفكير في الإصدار IPv6 كصفحة بيضاء سهّلت تصميم قدراتٍ جديدة لبروتوكول IP والتي عُدِّلت بعد ذلك في الإصدار IPv4. كانت إحدى الميزات غير القابلة للتفاوض على الإطلاق للإصدار IPv6، بالإضافة إلى قائمة الرغبات، هي أنه يجب أن تكون هناك خطة تحوُّل للانتقال من الإصدار الحالي من IP (الإصدار 4) إلى الإصدار الجديد. سيكون من المستحيل تمامًا وجود يومٍ يغلق فيه الجميع مضيفهم والموجّهات الخاصة بهم ثم يثبّتون إصدارًا جديدًا من بروتوكول IP نظرًا لأن الإنترنت كبير جدًا ولعدم وجود تحكم مركزي. توقع المهندسون فترة انتقالية طويلة يشغّل فيها بعض المضيفين والموجهات إصدار IPv4 فقط، والبعض الآخر سيعمل على الإصدارين IPv4 و IPv6، والبعض الآخر سيعمل على الإصدار IPv6 فقط، وتوقعوا اقتراب الفترة الانتقالية من الذكرى الثلاثين لتأسيسها. العناوين والتوجيه أولاً وقبل كل شيء، يوفر الإصدار IPv6 حيز عناوين بطول 128 بت، بدلًا من 32 بت في الإصدار 4. وبالتالي يمكن للإصدار IPv6 معالجة 3.4 × 1038 عقدة بافتراض كفاءة 100%، في حين أن الإصدار 4 يمكن أن يعالج 4 مليارات عقدة إذا وصلت كفاءة إسناد العناوين إلى 100%. كما رأينا وعلى الرغم من ذلك، فإن الكفاءة بنسبة 100% في إسناد العناوين أمرٌ غير محتمل. أظهرت بعضُ التحليلات لمخططات العنونة الأخرى، مثل تلك الخاصة بشبكات الهاتف الفرنسية والأمريكية وكذلك تحليلات الإصدار IPv4، بعضَ الأرقام التجريبية لكفاءة إسناد العناوين. من المتوقع أن يوفر حيز عناوين IPv6، استنادًا إلى أكثر تقديرات الكفاءة تشاؤمًا المستمدة من هذه الدراسة، أكثر من 1500 عنوان لكل قدم مربع من سطح الأرض، وهذا بالتأكيد سيخدمنا جيدًا حتى عندما يكون للأجهزة على كوكب الزهرة عناوين IP. تخصيص Allocation حيز العناوين إن عناوين IPv6 عديمةُ التصنيف classless أيضًا بالاعتماد على فعالية توجيه CIDR في IPv4، لكن حيز العناوين لا يزال مقسمًا بطرق مختلفة بناءً على البتات البادئة. تحدّد البتات البادئة استخدامات مختلفة لعناوين IPv6 بدلًا من تحديد أصناف عناوين مختلفة. يوضح الجدول التالي الإسناد الحالي للبادئات في الإصدار IPv6: table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } البادئة Prefix الاستخدام Use 00…0 (128 بت) غير مخصَّص Unspecified 00…1 (128 بت) عناوين استرجاع Loopback 1111 1111 عناوين بثٍ متعدد Multicast addresses 1111 1110 10 عناوين روابط محلية أحادية البث Link-local unicast كل شيءٍ آخر بث أحادي عالمي Global Unicast يستدعي هذا التخصيص لحيز العناوين القليلَ من المناقشة. أولًا، تُضمَّن الوظيفة الكاملة لأصناف عناوين IPv4 الرئيسية الثلاثة (A و B و C) داخل نطاق "كل شيء آخر". تشبه عناوين البث الأحادي العالمية Global Unicast، كما سنرى قريبًا، إلى حدٍ كبير عناوين IPv4 عديمة التصنيف، ولكنها أطول من ذلك بكثير. هذه هي أهم الأمور المهمة في هذه المرحلة، حيث يتوفر أكثر من 99% من إجمالي حيز عناوين IPv6 لهذا الشكل من العناوين. (تُخصَّص عناوين IPv6 أحادية البث من الكتلة التي تبدأ بـ 001 في وقت كتابة هذا الكتاب، بينما يُحجز حيز العناوين المتبقي، الذي يمثل حوالي 87%، للاستخدام في المستقبل). من الواضح أن حيز عناوين البث المتعدد multicast مخصصة للبث المتعدد. وبالتالي تخدم نفس دور عناوين الصنف D في IPv4. لاحظ أنه من السهل تمييز عناوين البث المتعدد، فهي تبدأ ببايتٍ مكوَّن من واحدات. سنرى كيفية استخدام هذه العناوين في لاحقًا. تكمن الفكرة وراء عناوين استخدام الروابط المحلية في تمكين المضيف من إنشاء عنوان يعمل على الشبكة التي يتصل بها دون القلق بشأن الطابع الفريد عالميًا للعنوان. قد يكون هذا مفيدًا للضبط التلقائي، كما سنرى أدناه. وبالمثل، فإن عناوين استخدام الموقع المحلية site-local use تهدف إلى السماح بإنشاء عناوين صالحة على موقع (شبكة شركة خاصة مثلًا) غير متصلٍ بشبكة الإنترنت الأكبر، فلا يجب أن يكون التفرد العالمي مشكلةً. توجد بعض أنواع العناوين الخاصة المهمة داخل حيز العناوين أحادية البث العالمية. يمكن إسناد عنوان IPv6 متوافق مع IPv4 للعقدة من خلال توسيع عنوان IPv4 المؤلَّف من 32 بتًا إلى 128 بت من خلال إضافة أصفار zero-extending. يمكن إسناد عنوان IPv6 المربوط مع عنوان IPv4 للعقدة القادرة فقط على فهم عناوين IPv4 عن طريق بدء prefixing عنوان IPv4 المؤلَّف من 32 بتًا بـ 2 بايت مؤلفة من واحدات ثم توسيع النتيجة من خلال إضافة أصفار zero-extending إلى 128 بت. يُستخدم هذان النوعان الخاصان من العناوين في الانتقال من IPv4 إلى IPv6. صيغة العنوان Address Notation هناك بعض الرموز الخاصة لصيغة عناوين IPv6 تمامًا كما هو الحال مع عناوين IPv4. التمثيل القياسي هو x: x: x: x: x: x: x: x، حيث يمثّل كلx تمثيلًا ست عشريًا لقطعةٍ مؤلفةٍ من 16 بتًا من العنوان. سيكون على سبيل المثال كما يلي: 47CD:1234:4422:ACO2:0022:1234:A456:0124 يمكن كتابة أي عنوان IPv6 باستخدام هذه الصيغة. هناك بعض الرموز الخاصة التي قد تكون مفيدة في ظروف معينة، نظرًا لوجود بعض الأنواع الخاصة من عناوين IPv6. يمكن كتابة العنوان الذي يحتوي على عدد كبير من الأصفار المتجاورة على نحوٍ مضغوطٍ عن طريق حذف جميع الحقول التي تحوي 0 على سبيل المثال، وبالتالي فإن العنوان التالي: 47CD:0000:0000:0000:0000:0000:A456:0124 يمكن كتابته بالشكل: 47CD::A456:0124 من الواضح أن هذا النوع من الاختزال لا يمكن استخدامه إلا لمجموعة واحدة من الأصفار المتجاورة في العنوان لتجنب الالتباس. يوجد نوعان من عناوين IPv6، يحويان على عنوان IPv4 مضمَّن، لهما صيغةٌ خاصة بهما، مما يجعل استخراج عنوان IPv4 أسهل. يمكن كتابة عنوان IPv6 المربوط mapped مع IPv4 لمضيفٍ عنوان IPv4 الخاص به هو 128.96.33.81 على سبيل المثال بالشكل التالي: ::FFFF:128.96.33.81 أي أن آخر 32 بتًا مكتوبة بصيغة IPv4، بدلًا من كتابة زوجٍ من الأرقام الست عشرية المفصولة بنقطتين. لاحظ أن النقطتين المزدوجتين في المقدمة تشير إلى الأصفار البادئة leading. عناوين البث الأحادي العالمية Global Unicast Addresses إن أهم نوعٍ من العناوين التي يجب أن يوفرها IPv6 هو عنونة البث الأحادي القديم البسيط. يجب أن يحدث ذلك بطريقة تدعم المعدل السريع لإضافة مضيفِين جددٍ إلى الإنترنت وتسمح بإجراء التوجيه بطريقة قابلة للتوسع مع نمو عدد الشبكات الفيزيائية في الإنترنت. وبالتالي توجد خطةٌ في صميم IPv6 لتخصيص عنوان البث الأحادي التي تحدد كيفية إسناد عناوين البث الأحادي لمزودي الخدمة والأنظمة المستقلة والشبكات والمضيفين والموجهات. تشبه خطة تخصيص العناوين المقترحة لعناوين بث IPv6 الأحادي إلى حدٍ بعيد تلك التي تُنشَر مع توجيه CIDR في الإصدار IPv4. يجب تحديد بعض المصطلحات الجديدة لفهم كيفية عملها وكيف توفر قابلية التوسع. يمكننا التفكير بالنظام المستقل الذي ليس نظامًا مستقلًا عابرًا nontransit (أي نظام مستقل جذري Stub AS، أو متعدد طرق الاتصال Multihomed AS) مثل مشترك subscribe، وقد نفكر في النظام المستقل العابر كمزوّد provider. وقد نقسّم مزودي الخدمة إلى قسمين مباشر direct وغير مباشر indirect. النوع الأول متصل مباشرةً بالمشتركين. ويربط النوع الثاني بين مزودين آخرين ولا يرتبط مباشرة بالمشتركين، وغالبًا ما يُعرف باسم الشبكات الأساسية backbone networks*. يمكننا أن نرى من خلال هذه المجموعة من التعريفات أن الإنترنت ليس مجرد مجموعة مترابطة بصورة عشوائية من الأنظمة المستقلة، فلديه بعض التسلسل الهرمي الجوهري. تكمن الصعوبة في الاستفادة من هذا التسلسل الهرمي دون اختراع آليات تفشل عندما لا يجري التقيد بالتسلسل الهرمي بدقة كما حدث في بروتوكول EGP. فعلى سبيل المثال، يصبح التمييز بين مزودي الخدمة المباشرين وغير المباشرين غير واضح، عندما يتصل المشترك بشبكة رئيسية أو عندما يبدأ مزودٌ مباشر بالاتصال بالعديد من المزودين الآخرين على سبيل المثال. إن الهدف من خطة تخصيص عناوين IPv6، كما هو الحال مع توجيه CIDR، هو توفير تجميع معلومات التوجيه لتقليل العبء على الموجّهات داخل النطاق. الفكرة الأساسية هي استخدام بادئة العنوان، والتي هي مجموعة من البتات المتجاورة في النهاية الأعلى أهمية للعنوان، لتجميع معلومات قابلية الوصول إلى عددٍ كبير من الشبكات وحتى إلى عددٍ كبير من الأنظمة المستقلة. الطريقة الرئيسية لتحقيق ذلك هي إسناد بادئة عنوان لمزودٍ مباشر ثم يسند هذا المزود المباشر بادئاتٍ أطول تبدأ بتلك البادئة لمشتركيه، وبالتالي يمكن للمزود الإعلان عن بادئة واحدة لجميع مشتركيه. يكمن العيب في ذلك أنه في حال قرّر موقعٌ ما تغيير مزوّدي الخدمة، فلا بُدّ له من الحصول على بادئة عنوان جديدة وإعادة ترقيم جميع العقد في الموقع. قد تكون هذه المهمةً ضخمة بما يكفي لثني معظم الناس عن تغيير مزودي الخدمة باستمرار. لذلك هناك بحثٌ مستمر حول مخططات العنونة الأخرى، مثل العنونة الجغرافية geographic addressing، حيث يكون عنوان الموقع تابعٌ لمكانه وليس للمزود الذي يرتبط به. ومع ذلك فإن العنونة حاليًا المعتمدة على المزود ضروريةٌ لجعل التوجيه يعمل بكفاءة. نلاحظ بالرغم من أن إسناد عناوين IPv6 يكافئ بصورة أساسية الطريقة التي جرى بها إسناد العناوين في الإصدار IPv4 منذ استخدام توجيه CIDR، فإن IPv6 يتمتع بميزة كبيرة تتمثل في عدم وجود قاعدة كبيرة مثبَّتة من العناوين المسنَدة لتناسب خططها. أحد الأسئلة هو ما إذا كان من المنطقي أن يحدث التجميع الهرمي على مستويات أخرى في التسلسل الهرمي. هل يجب على جميع مزودي الخدمة الحصول على بادئات العناوين الخاصة بهم من داخل بادئة مخصَّصة لشبكة رئيسية يتصلون بها على سبيل المثال؟ يمكن ألا يكون هذا منطقيًا، نظرًا لأن معظم مزودي الخدمة يتصلون بعدة شبكات رئيسية. كما أن فوائد التجميع عند هذا المستوى أقل بكثير، نظرًا لأن عدد المزودين أقل بكثير من عدد المواقع. قد يكون المكان الذي يتم فيه التجميع منطقيًا هو على المستوى الوطني أو القاري. تشكل الحدود القارية تقسيمات طبيعية في مخطَّط الإنترنت. إذا احتوت جميع العناوين في أوروبا مثلًا على بادئةٍ مشتركة، يمكن إجراء قدرٍ كبير من التجميع، عندها ستحتاج معظم الموجّهات في القارات الأخرى فقط إلى مدخلةِ جدول توجيه واحد لجميع الشبكات ذات البادئة الأوروبية Europe prefix. كما سيختار جميع مزودي الخدمة في أوروبا البادئات الخاصة بهم التي تبدأ بالبادئة الأوروبية. ويوضح الشكل الآتي عنوان IPv6 باستخدام هذا المخطط. فقد يكون معرّف المسجل RegistryID وهو معرّف يُسنَد لمسجل عناوينٍ أوروبي، مع معرّفاتٍ مختلفة مُسنَدة لقاراتٍ أو دول أخرى. لاحظ أن البادئات ستكون ذات أطوالٍ مختلفة في ظل هذا السيناريو، فقد يكون لدى مزود الخدمة الذي لديه عدد قليل من العملاء بادئة أطول (وبالتالي حيز عناوين أقل توفّرًا) من مزود به العديد من العملاء على سبيل المثال. قد يحدث موقفٌ صعب عندما يكون المشترك متصلًا بأكثر من مزود. فما هي البادئة التي يجب على المشترك استخدامها لموقعه؟ لا يوجد حل مثالي لهذه المشكلة. افترض، على سبيل المثال، أن أحد المشتركين متصلٌ بمزودَي خدمة هما X وY. إذا أخذ المشترك بادِئته من المزود X، فيجب على المزود Y الإعلان عن بادئة ليس لها علاقة بمشتركيه الآخرين وبالتالي لا يمكن تجميعهم. وإذا كان جزءٌ من أرقام المشترك في النظام المستقل الخاص به مع بادئة المزود X والجزء الآخر مع بادئة المزود Y، فإنه يخاطر بأن يصبح نصف موقعه غير قابل للوصول إذا تعطل الاتصال بمزود. أحد الحلول التي تعمل جيدًا إلى حد ما إذا كان هناك الكثير من المشتركين بين المزودَين X وY، هو أن يكون بينهما ثلاث بادئات: بادئة لمشتركي المزود X فقط، وبادئة لمشتركي المزود Y فقط، وبادئة للمواقع المشتركة في كل من المزودَين X وY. صيغة الرزمة Packet Format إن صيغة ترويسة IPv6 أبسط على الرغم من حقيقة أن IPv6 يوسّع IPv4 بعدّة طرق. ترجع هذه البساطة إلى الجهود المتضافرة لإزالة الوظائف غير الضرورية من البروتوكول، حيث يوضح الشكل الآتي النتيجة. تبدأ هذه الترويسة بحقل الإصدار Version كما هو الحال مع العديد من العناوين، والذي ضُبِط على القيمة 6 للإصدار IPv6. يوجد حقل الإصدار في نفس المكان بالنسبة إلى بداية العنوان مثل حقل الإصدار الخاص بالإصدار IPv4 بحيث يمكن لبرنامج معالجة الترويسة أن يقرر على الفور صيغة العنوان الذي يجب البحث عنه. يرتبط كلا الحقلين TrafficClass وFlowLabel بجودة الخدمة. يعطي حقل PayloadLen طول الرزمة، بدون ترويسة IPv6، مُقاسًا بالبايت. يستبدل الحقل NextHeader بذكاء كلًا من خيارات IP وحقل البروتوكول Protocol من الإصدار IPv4. إذا كانت الخيارات مطلوبة، فستُحمَل في ترويسة خاصة واحدة أو أكثر تتبع ترويسة IP، ويشار إلى ذلك بقيمة الحقل NextHeader. إذا لم تكن هناك ترويسات خاصة، سيكون الحقل NextHeader مفتاح فك تجميع demux، الذي يحدّد بروتوكول المستوى الأعلى الذي يعمل عبر بروتوكول IP (بروتوكول TCP أو بروتوكول UDP مثلًا)، أي أنه يخدّم نفس هدف حقل البروتوكول Protocol في الإصدار IPv4. تُعالَج التجزئةfragmentation الآن كترويسة اختيارية، مما يعني أن الحقول المتعلقة بالتجزئة في IPv4 غير مضمَّنة في ترويسة IPv6. حقل HopLimit هو ببساطة حقل TTL وهو العُمر time to live للإصدار IPv4، وأُعيدت تسميته ليعكس طريقة استخدامه بالفعل. أخيرًا، الجزء الأكبر من الترويسة هو عناوين المصدر والوجهة، حيث يبلغ طول كلٍّ منهما 16 بايتًا (أو 128 بت). وبالتالي يبلغ طول ترويسة IPv6 دائمًا 40 بايتًا. بالنظر إلى أن عناوين IPv6 أطول أربع مرات من عناوين IPv4، فإن هذا يوازَن جيدًا بترويسة IPv4، والتي يبلغ طولها 20 بايتًا في حالة عدم وجود خيارات options. تحسنت الطريقة التي يتعامل بها الإصدار IPv6 مع الخيارات كثيرًا عن الإصدار IPv4. حيث يتعين على كل موجهٍ في IPv4، في حالة وجود أية خيارات، تحليل حقل الخيارات بالكامل لمعرفة ما إذا كان أي من هذه الخيارات ذو صلة. حيث أن جميع الخيارات كانت مدفونة في نهاية ترويسة IP، كمجموعة غير مرتبة من مجموعات (النوع ، الطول ، القيمة) أو (type, length, value). بينما يتعامل IPv6 مع الخيارات كترويسات توسّع extension headers التي يجب، إن وجدت، أن تظهر بترتيبٍ معين. هذا يعني أن كل موجهٍ يمكنه تحديد ما إذا كان أي من الخيارات مناسبًا له بسرعة، وفي معظم الحالات لن تكون كذلك، ويمكن تحديد ذلك عادةً من خلال النظر فقط إلى حقل NextHeader. النتيجة النهائية هي أن معالجة الخيارات أكثر كفاءة في الإصدار IPv6، وهو عاملٌ مهم في أداء الموجّه. بالإضافة إلى أن الصيغة الجديدة للخيارات كترويسات توسّع يعني أنها يمكن أن تكون ذات طولٍ عشوائي، بينما في IPv4 كانت محدودةً بطول 44 بايتًا على الأكثر. سنرى كيف تُستخدَم بعض الخيارات أدناه. كل خيارٍ له نوعٌ خاصٌ به من ترويسة التوسّع. ويُحدَّد نوع كل ترويسةِ توسّعٍ بقيمة حقل NextHeader في الترويسة التي تسبقها، وتحتوي كل ترويسة توسّع على حقل NextHeader لتحديد العنوان الذي يليه. ستُتبع ترويسة التوسّع الأخيرة بترويسةُ طبقة النقل (TCP على سبيل المثال)، وفي هذه الحالة تكون قيمة حقل NextHeader هي نفسها قيمة الحقل Protocol في ترويسة IPv4. وبالتالي يقوم الحقل NextHeader بمهمةٍ مزدوجة، إما أن يحدد نوع ترويسة التوسّع الواجب اتباعها، أو يعمل كمفتاح فك تجميع demux لتحديد بروتوكول الطبقة الأعلى الذي يعمل عبر الإصدار IPv6 في ترويسة التوسّع الأخيرة. افترض مثال ترويسة التجزئة الموضحة في الشكل السابق. توفّر هذه الترويسة وظائفًا مماثلة لحقول التجزئة في ترويسة IPv4، ولكنها موجودة فقط إذا كانت التجزئة ضرورية. على فرض أنها ترويسة التوسّع الوحيدة الموجودة، فإن حقل NextHeader لترويسة IPv6 ستحتوي على القيمة 44، وهي القيمة المُسنَدة للإشارة إلى ترويسة التجزئة. يحتوي حقل NextHeader لترويسة التجزئة نفسها على قيمة تصِف الترويسة التي تليها. فقد يكون العنوان التالي هو ترويسة TCP بافتراض عدم وجود ترويسات توسّعٍ أخرى، مما ينتج عنه القيمة 6 للحقل NextHeader، كما يفعل حقل Protocol في IPv4 تمامًا. إذا لحقت بترويسة التجزئة ترويسةُ استيثاق على سبيل المثال، سيَحتوي حقل NextHeader لترويسة التجزئة عندئذٍ على القيمة 51. إمكانات متقدمة كان الدافع الأساسي وراء تطوير الإصدار IPv6 هو دعم النمو المستمر للإنترنت كما ذُكر في بداية هذا القسم. كان الباب مفتوحًا لمجموعة متنوعة من التغييرات الأخرى بمجرد تغيير ترويسة IP عند تغيير العناوين، لكن يتضمن الإصدار IPv6 العديد من الميزات الإضافية، مثل التنقل والأمن وجودة الخدمة quality-of-service التي سننُاقشها لاحقًا. من المثير للاهتمام أن نلاحظ أنه أصبحت إمكانات الإصدارات IPv4 و IPv6 غير قابلة للتمييز فعليًا في معظم هذه المجالات، بحيث يبقى المحرك الرئيسي للإصدار IPv6 هو الحاجة إلى عناوينٍ أكبر. الضبط التلقائي Autoconfiguration كان نمو الإنترنت أمرًا مثيرًا للإعجاب، ولكن أحد العوامل التي حالت دون قبولٍ أسرع للتقنية هو حقيقة أن الاتصال بالإنترنت يتطلب عادةً قدرًا لا بأس به من الخبرة في إدارة النظام. حيث يحتاج كل مضيفٍ متصلٍ بالإنترنت إلى أن يُضبَط باستخدام حدٍ أدنى معين من المعلومات، مثل عنوان IP صالح وقناع شبكة فرعية subnet mask للرابط الذي يتصل به وعنوان خادم الأسماء name server، وبالتالي لم يكن ممكنًا توصيل حاسوبٍ جديد بالإنترنت دون بعض الضبط المسبق preconfiguration. لذلك يتمثل أحد أهداف الإصدار IPv6 في توفير الدعم للضبط التلقائي، والذي يشار إليه أحيانًا بعملية التوصيل والتشغيل مباشرةً plug-and-play. إن الضبط التلقائي ممكنٌ للإصدار IPv4، لكنه يعتمد على وجود خادمٍ ضُبِط لتوزيع العناوين ومعلومات الضبط الأخرى لعملاء بروتوكول ضبط المضيف ديناميكيًّا Dynamic Host Configuration Protocol أو اختصارًا DHCP. تساعد صيغة العنوان الأطول في الإصدار IPv6 على توفير شكلٍ جديد ومفيد من الضبط التلقائي يسمى الضبط التلقائي عديم الحالة stateless autoconfiguration، والذي لا يتطلب خادمًا. تذكر أن عناوين IPv6 أحادية البث وهرمية، وأن الجزء الأقل أهمية هو معرّف الواجهة interface ID. وبالتالي يمكن تقسيم مشكلة الضبط التلقائي إلى قسمين: الحصول على معرّف واجهةٍ فريد من نوعه على الرابط الذي يرتبط المضيف به. الحصول على بادئة العنوان الصحيحة لهذه الشبكة الفرعية. من الواضح أن القسم الأول سهلٌ إلى حدٍ ما، حيث يجب أن يكون لكل مضيفٍ موجود على رابطٍ عنوانٌ فريد على مستوى الرابط. فجميع المضيفين على شبكة إيثرنت لديهم عنوان إيثرنت فريد مؤلَّفٌ من 48 بتًا. يمكن تحويل هذا العنوان إلى عنوان استخدام رابطٍ محلي صالحٍ عن طريق إضافة البادئة المناسبة من خلال: numref”Table %s <fig-v6tab> (1111 1110 10) واتباعها بأصفار كافية لتشكيل 128 بتًا. قد يكون هذا العنوان مناسبًا تمامًا بالنسبة لبعض الأجهزة مثل الطابعات أو الأجهزة المضيفة على شبكة صغيرة بدون موجّه ولا تتصل بأية شبكات أخرى. تعتمد الأجهزة التي تحتاج إلى عنوانٍ صالح عالميًا على موجّه على نفس الرابط للإعلان دوريًا عن البادئة المناسبة للرابط. من الواضح أن هذا يتطلب أن يُضبَط الموجه باستخدام بادئة العنوان الصحيحة، وأن تُختار هذه البادئة بطريقة توفر مساحة كافية في النهاية 48 بت مثلًا لتُوصَل بعنوان مستوى رابطٍ مناسب. كانت القدرة على تضمين embed عناوين على مستوى الرابط بطول 48 بتًا في عناوين IPv6 هو أحد أسباب اختيار مثل هذا الحجم الكبير للعنوان. لا تسمح 128 بتًا هذه بالتضمين embedding فقط، ولكنها تترك مساحة كبيرة للتسلسل الهرمي متعدد المستويات للعناوين التي ناقشناها سابقًا. التوجيه المباشر من المصدر Source-Directed Routing ترويسة التوجيه routing header هي ترويسة من بين ترويسات توسّع الإصدار IPv6 الأخرى. ويختلف توجيه IPv6 قليلًا عن توجيه IPv4 ضمن توجيه CIDR في حالة عدم وجود هذه الترويسة. تحتوي ترويسة التوجيه على قائمةٍ بعناوين IPv6 التي تمثّل العقد أو مناطق مخطط الشبكة التي يجب أن تزورها الرزمة في مسارها إلى وجهتها. وقد تكون المنطقةُ الهيكلية topological area عبارة عن شبكةَ مزود رئيسية على سبيل المثال. سيكون تحديدُ أن الرزم يجب أن تزور هذه الشبكة طريقةً لتطبيق اختيار المزود على أساس كل رزمة على حدى. وبالتالي يمكن للمضيف أن يقول إنه يريد أن تمر بعضُ الرزم عبر مزودٍ رخيص، والبعض الآخر من خلال مزودٍ يوفر وثوقيةً عالية، والبعض الآخر من خلال مزودٍ يثق به المضيف لتوفير الأمن. يحدّد الإصدار IPv6 عنوان بث اختياري anycast لتوفير القدرة على تحديد الكيانات الهيكلية بدلًا من العقد الفردية. يُسند عنوان بث اختياري لمجموعةٍ من الواجهات، وستنتقل الرزم المرسَلة إلى هذا العنوان إلى "أقرب" واجهةٍ من هذه الواجهات، مع تحديد أقربها بواسطة بروتوكولات التوجيه. فيمكن إسناد عنوان بث اختياري واحد لجميع الموجّهات الخاصة بمزود الشبكة الرئيسية على سبيل المثال، والذي يمكن استخدامه في ترويسة التوجيه. ترجمة -وبتصرّف- للقسم IP Version 6 من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: التشبيك المتقدم Advanced Internetworking في الشبكات الحاسوبية شبكة الإنترنت باستخدام بروتوكول IP الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP

لنفترض أنك تريد إنشاء زوايا دائرية مثل الشكل التالي: يمكن إنشاء شكل حرف L المقلوب بسهولة باستخدام طرق متعددة، ومن بين هذه الطرق لدينا استخدام حرف L كبير جدًا ضمن إطار نص، ثم اختيار "التحويل إلى Convert To" بالنقر على الشكل بزر الفأرة الأيمن، ثم اختيار "مخططات تفصيلية Outlines"، بعدها اقلب ذلك وغيّر حجمه قليلًا، ثم اختر مرةً أخرى "تحويل إلى Convert To"، ثم "إطار نص Text Frame". قد ترغب في استخدام ميزة الزوايا الدائرية Round Corners من تبويب "شكل Shape" المتواجد في نافذة الخصائص، والتي تفتحها من اختيار قائمة "نوافذ" ثم الضغط على "خصائص"، ولكن هذا الخيار لا يعمل عندما يكون لديك شكلٌ معقد. سنعرض في هذا المقال كيفية الوصول إلى هذه النتيجة النهائية الموضّحة في الشكل السابق خطوةً بخطوة باستخدام برنامج سكريبوس Scribus. ابدأ بإطار مستطيل الشكل، حيث يمكن أن يكون إطار نص أو شكل مستطيل -وسنستخدم شكل مستطيل في هذا المثال-، ثم عدّل الخلفية وألوان الخط الافتراضية، بعدها كبّر الشكل إلى الأبعاد التي تريدها، ويفضَّل جعل أبعادك ذات أرقام تامة دون فواصل مع وحدات صفحات صغيرة مثل النقاط أو المليمترات. يمثّل الشكل التالي إطار البداية: بداية التحويل يمكن تدوير الزوايا من تبويب "شكل Shape" في نافذة خصائص، وهذا سيوفر علينا في النهاية تدوير ما بين 3 إلى 6 زوايا يدويًا. انتقل إلى تبويب "شكل"، وطبّق تدوير الزوايا Round Corners بقيمة 25 نقطة أو بالقيمة التي تريدها، ولكن تذكّر هذه القيمة لأننا سنستخدمها قريبًا. حدّد الإطار ثم انقر على تبويب "شكل" ثم تحرير لتظهر لك العقد. نريد أولًا إضافة بعض العقد، بحيث تكون ثمة عقدةٌ على الجانب الأيمن من الإطار، والأخرى في الجزء السفلي. يوضّح الشكلان الآتيان العقد المضافة مع الجزء السفلي من مربع الحوار "عُقد" لتحرير الشكل. تتوافق العقدة ذات اللون الأحمر مع قيم X-Pos وY-Pos الموضّحة في الشكل الآتي (تذكّر أن استخدام أرقام تامة سيسهّل العمل): احذف الآن العقدتين الموجودتين في الزاوية اليمنى السفلية، وبذلك سنتجنّب الحاجة إلى تغييرهما من أجل الوصول إلى الشكل المناسب، بعد ذلك أضف عقدةً جديدةً في أي مكان على طول المسار بين العقدتين اللتين أنشأناهما للتو، ثم انقل هذه العقدة الجديدة الأخيرة إلى X-Pos المقابلة للعقدة الجديدة في الأسفل، وY-Pos المقابلة للعقدة الجديدة على الجانب الأيمن. وبالتالي أصبح لدينا الشكل النهائي الذي نريده مع ثلاثة زوايا دائرية وثلاثة زوايا أخرى يجب تدويرها. تُعَد قيم X-Pos وY-Pos في الشكل السابق هي القيم اللازمة للعقدة الجديدة، لهذا انقر على "موافق" ثم سترى أن قسم تدوير الزوايا غير مفعَّل في تبويب شكل. لندوّر الآن الزوايا الثلاث الأخرى المتبقية. إنشاء أداة تدوير باستخدام مربع يمثّل الشكل الآتي أداة التدوير الخاصة بنا، والمكونة من مربع طول ضلعه 25 نقطة، مع وضع خطوط رأسية وأفقية تتقاطع مع منتصف كل ضلع. يُعَد لون المربع غير مهم، لذلك اختر ألوانًا تتناقض مع بعضها البعض ومع ألوان الإطار. أما الطريقة الأفضل لإنشاء هذه الأداة، فهي استخدام مربع طول ضلعه 12 نقطة ثم نسخه 3 مرات، مع ترك فراغ قدره 1 نقطة بين هذه النسخ. حدّد المربعات الأربعة وانقر على قائمة عنصر Item ثم اختر "أدوات المسار"، ثم "دمج المضلعات Combine "Polygons، واحفظ هذه الأداة في سجل القصاصات Scrapbook من قائمة عنصر، ثم "أرسل إلى" ثم سجل القصاصات، حتى تتمكن من استخدامه مرةً أخرى في المستقبل. تأكّد من أن لون حدّ هذه الأشكال هو "لا شيء"، للحصول على أكبر دقة للقياسات عند إنشائها، وستدرك لاحقًا بأنه يمكنك عمل زوايا دائرية بدون أداة، ولكن ستكون العملية أسرع باستخدام هذه الأداة، للحصول على نتائج متناسقة لكل زاوية. تمثّل الصورتان الآتيتان نفس الصفحة ولكن الثانية مقرَّبة. سنبدأ بتدوير الزاوية الداخلية لأنها قد تبدو أصعب رغم أنها ليست كذلك في الحقيقة، وهنا استخدم أي تكبير للصفحة يساعدك في تنفيذ هذه المهمة بأكبر قدر من الدقة. لاحظ كيف تتوضّع أداتنا بعناية، بحيث تتوافق حوافها مع الحواف التي تشكّل هذه الزاوية الداخلية التي لا يمكنك رؤيتها لأن أداة التدوير فوقها. بما أننا نعرف قيم X-Pos وY-Pos لهذه الزاوية، فيمكننا بسهولة نقل هذه القيم إلى أداة التدوير الخاصة بنا لتوفير الوقت. حدّد الآن الإطار (الإطار الذي نحاول تدوير زواياه) ثم انتقل إلى تبويب شكل ثم تحرير. أنشئ ما تراه في الشكل الآتي، إما عن طريق إضافة عقدتين في زوايا الأداة وحذف العقدة الأصلية، أو بإنشاء إحدى العقدتين ثم نقل عقدة الزاوية الأصلية إلى الموضع الآخر. لاحظ أنه يمكنك ترك أداة التدوير فوق الإطار دون أن تتدخّل بعملية تحرير الشكل. انقر بعد ذلك على زر "تحريك نقاط التحكم" واسحب نقاط التحكم مباشرةً إلى منتصف كل جانب من جوانب أداة التدوير كما ترى في الشكل الآتي، بحيث تحتوي كل عقدة على نقطتَي تحكم، وإن لم تنحنِ الزاوية، فقد اخترت نقطة التحكم الخاطئة، لذلك اتركها ثم اسحب نقطة التحكم الأخرى، ثم أعد العقدة الخاطئة إلى مكانها مرةً أخرى. وبذلك تكون قد نجحت العملية، وما عليك هنا سوى النقر على "موافق"، وسحب أداة التدوير من فوق الإطار لتظهر الزاوية المستديرة كما في الشكل الآتي، وستجد أن هذه الزاوية تتوضّع بدقة مع قوس دائرة نصف قطرها 25 نقطة. النهاية كل ما تبقى هو تدوير الزاويتين الأخريين باستخدام أداة التدوير، ثم يمكنك تحويل الشكل الناتج إلى إطار نص وإضافة النص وإنهاء تخطيطك، أو قد تحوّله إلى إطار صورة. يمكنك الآن باستخدام هذه الطريقة استخدام تبويب "خط Line" أو تبويب "ألوان Color" من نافذة "خصائص" لتغيير الخصائص المختلفة بسهولة، كما يمكنك أيضًا تغيير الحجم بقدر ما تريد، ولكن حاول ألّا تمدّد الشكل باتجاه واحد أكثر من الاتجاه الآخر بكثير، لأنك ستشوّه قوس الزاوية الدائري، وهذا ينطبق أيضًا على الأقواس المُعَدّة باستخدام ميزة الزوايا الدائرية. قد لا ترغب في عمل هذه الزوايا الدائرية لتخطيطك، وبالتالي سيكون ضبط الشكل أسهل بكثير. استخدام أدوات تدوير بأشكال مختلفة يمثّل الشكل السابق أداة تدوير لشكلٍ قياسُ زواياه ليست 90 درجة، بحيث تبدأ هذه الأداة بأربعة مربعات يكون طول كل ضلع مربع 12 نقطة، ويُفصَل بين المربعات بمسافة مقدارها 1 نقطة. يمكنك بعدها أن تنتقل إلى قائمة عنصر، ثم أدوات المسار ثم "دمج المضلعات"، لكن المهمة الأهم بعد ذلك هي القدرة على إمالة Skew الشكل مع المحافظة على ترتيب جميع المكوّنات ترتيبًا صحيحًا. ترجمة -وبتصرّف- للمقال Rounding Complex Shapes. اقرأ أيضًا كيفية بدء استخدام برنامج سكريبوس Scribus أساسيات تخطيط الصفحات Page Layout كيفية التعامل مع الصفحات الرئيسية Master Pages في برنامج سكريبوس Scribus

سنشرح في هذا المقال بعض خيارات تخطيط الصفحات الأساسية، مع تعريف بسيط لبعض المفاهيم مثل: المساحة البيضاء White Space. قراءة الصفحة. توازن الصفحة Page Balance. التحرير Editing. لا يحتوي هذا المقال شرحًا تفصيليًا يوضح لك كيفية عمل تخطيط صفحة، إذ يمكن كتابة كتاب كامل حول هذا الموضوع، كن قد لا يغطي هذا الكتاب نوع التخطيط الذي تحتاجه لمشروعك، لهذا سنعرض أمثلةً أساسيةً متعددة مع نقد قصير لكل منها، بحيث يصبح لديك فهم عام عن مفهوم تخطيط الصفحات Page Layout. النصائح والإرشادات الواردة هنا خاصةٌ بمستندات "عامة" مثل: النشرات الإخبارية Newsletters. المجلات. التقارير. ولا ترتبط هذه النصائح بمستندات مخصَّصة أخرى مثل: قوائم وجبات المطاعم. الملصقات الموسيقية. الكتب. حيث تختلف متطلبات التخطيط لمثل تلك المستندات اختلافًا كبيرًا وهي خارج نطاق موضوعنا الأساسي. ملاحظات تستخدم جميع التخطيطات الواردة في هذا المقال نفس: النصوص. عائلة الخطوط. الصور. الأنماط Styles. سنستخدم نفس النص والأنماط طوال الوقت لإظهار ما يحدث لهذا النص ضمن تخطيطات مختلفة، وستُستخدَم عائلة الخطوط الأساسية Arial/Helvetica حتى لا يُخلَط بين أسلوب الطباعة Typography وتصميم التخطيط، كما ستُستخدم الصور المستطيلة الأساسية التي لم تُعزَل عن خلفياتها، لأنها أكثر أنواع الصور المتاحة شيوعًا، والهدف الأساسي هو إظهار الاختلافات بين تصميمات التخطيط Layout Designs المختلفة، وليس بين تصميمات الصفحات Page Designs المختلفة. يمكنك التفكير في تصميم الصفحة على أنه الطريقة التي تريد أن تظهر بها الصفحة بأكملها في النهاية بما في ذلك الخطوط والألوان والتأثيرات وكل شيء آخر يدخل في إنشاء صفحة كاملة، حيث يتعلق تصميم التخطيط بالبنية الأساسية لكيفية وضع الأشياء على الصفحة. تخطيط معالج النصوص Word إن كنت على دراية ببرنامج Word ثم أتيت لاستخدام برنامج سكريبوس، فإن الشكل الآتي هو نوع التخطيط الذي تعودت رؤيته أو إنتاجه بنفسك، لذا لا تطبّق هذا التخطيط ما لم يُطلَب منك عمل مستندات بهذا الشكل، فهذا التخطيط لن يقدّم لك أو لقرائك أي خدمة، إذ يتّصف هذا النوع من التخطيط بما يلي: مملٌ جدًا للنظر. يحتوي على أسطر نصية طويلة لا تلفت انتباه القارئ. يحتوي على الكثير من المساحات البيضاء التي لا تساعد في التخطيط. قد تلاحظ أيضًا أنه لا يمكن وضع كل النص على الصفحة، إذ يتوقف القسم "Heritage" فجأةً دون أي تحذير، لذلك يجب حل هذه المشكلة باستخدام تخطيطات أخرى. تخطيط المواقع الإلكترونية Website Layout قد تكون معتادًا على رؤية نوع التخطيط في الشكل الآتي إن كنت على دراية بإنشاء مواقع الويب، حيث توجد صورة كبيرة لطيفة في أعلى الصفحة لجذب انتباه القارئ وصورة ثانوية "عائمة" في اليمين لإضافة الجاذبية. قد يبدو ذلك جيدًا، إلا أن صفحة PDF أو الصفحة المطبوعة -على عكس صفحة الويب- لها حجم محدود، لذلك قد يتوقف النص فجأة لأنه لا يتناسب تمامًا مع الصفحة، وتوجد أسطر نصية طويلة تُشعِر القارئ بالملل كما في الحالة السابقة. لنجرّب استخدام تخطيط مكوَّن من عمودين بدلًا من ذلك. تخطيط أساسي مؤلف من عمودين تنشِئ أعمدة النصوص المتعددة سطورًا أقصر تسهل قراءتها وتميل إلى تقليل مقدار المساحة البيضاء "غير المستخدَمة". يوضح الشكل التالي تخطيطًا بسيطًا مؤلفًا من عمودين: يبدو هذا التصميم ممتعًا مع أسطر نصوص أقصر، ولا تزال قراءة الصفحة عملية سهلة جدًا. لاحظ أيضًا وجود كامل النص على نفس الصفحة مع وجود فراغ يمكن استخدامه لشيء آخر مثل صورة أخرى أو اقتباس من النص. يمكنك احتواء كل النص على الصفحة الآن بسبب الطريقة التي تترُك بها الجمل التي لا تصل إلى نهاية السطر مساحة بيضاء في نهاياتها، حيث تضيف "مساحة النهاية" هذه -جملةً بعد جملة- مساحةً لا بأس بها. قد يبدو هذا التخطيط مقبولًا، ولكنه مملٌ وغير جذاب أيضًا، إذ يتكوّن من نص ثم صورة، ثم نص وصورة أخرى، ثم نص وبعدها النهاية، ليشبه التخطيط السابق تمامًا من نواحٍ متعددة، ولكن مع تقليل إهدار المساحات. لنجرّب استخدام تخطيط مكوّن من ثلاثة أعمدة بدلًا من عمودين. تخطيط أساسي مؤلف من ثلاثة الأعمدة يوضح الشكل التالي تخطيطًا أساسيًا مكوّنًا من ثلاثة أعمدة: يبدو هذا التخطيط بالتأكيد أكثر جاذبية، فسطور النصوص قصيرة وسهلة القراءة. لاحظ أيضًا أن وضع الصورة عبر الأعمدة يكسر النص قليلًا. ولكن هناك مشكلة، إذ سيكون الأمر مربكًا بعض الشيء فيما يتعلق بالمكان الذي ستنتقل إليه بعد قراءة الفقرة الأولى، فهل ستنتقل إلى العمود التالي؟ أم ستتخطى الصورة وتتابع القراءة من الفقرة الموجودة أسفل الصورة بحيث تبدو الصورة جميلة في مكانها ولكنها تعترض طريق النص قليلًا؟ يبدو مكان وضع الصور خاطئًا، إذًا لنجرب إزاحة بعض الأشياء قليلًا. تخطيط بديل مؤلف من ثلاثة أعمدة يوضّح الشكل التالي تخطيطًا مختلفًا مؤلَّفًا من ثلاثة أعمدة: يمنحك هذا التخطيط فكرةً أكبر بكثير عن الكيفية التي يُفترَض أن تقرأ بها الصفحة، إلا أنّ به عيبًا وهو أن القارئ لن يرغب بقراءة العمود الأول الموجود على اليسار بعد الآن. يبدو النص مثل النشرة الطبية التي تجدها في علبة الأدوية، أو قد يبدو مشابهًا إلى حد ما لشيء تجده في كتب وصفات الطعام، وهذا ليس جميلًا في كلتا الحالتين. تكمن المشكلة الأساسية هنا في أن زيادة عدد الأعمدة -اعتمادًا على لغتك- قد تقلل من مقدار المساحة البيضاء غير المستخدمة على صفحتك (إلى حد معين)، إلّا أن ذلك يمكن أن يحدّ من جمالية النص إن استخدمته بإفراط. لا توجد قاعدة صارمة تحدّد عدد الأعمدة الصحيح، لذلك عليك فقط أن تجرّب وترى النتائج ثم تقرّر. لكن هل لا يزال بإمكانك استخدام تخطيط ثلاثي الأعمدة مع أخذ كل ما سبق في الحسبان؟ نعم يمكنك ذلك، ولكن عليك أن تختار بذكاء. الصور المستخدَمة في هذه الأمثلة مليئة بالألوان، لذلك فهي تغطي مساحة الصفحة بالكامل، وهذا يجعلها تبدو "أثقل" من النص الذي يحتوي على الكثير من الفراغات الصغيرة بين الأحرف والكلمات. وبما أن الصور أثقل من النص، فيُفضَّل ترتيبها حول الصفحة بحيث لا تكون جميعها في المكان ذاته. يوضّح الشكل التالي تخطيطًا غير متوازن حيث تكون الصور كلها في جانب واحد من الصفحة: لاحظ أن الثلث الأيسر من الصفحة به ألوان أكثر بكثير من الثلثين الآخرين، وبذلك تبدو الصفحة غريبةً بعض الشيء. قد ترغب أحيانًا في الحصول على هذا النوع من التأثير، ولكن يُفضَّل محاولة تجنبه. تخطيط تقارير الشركات يوضّح الشكل التالي تخطيطًا آخر مؤلفًا من ثلاثة أعمدة، وهو نوع التخطيط الذي قد تراه في المستندات التي تنتجها الشركة لإنشاء تقارير المساهمين في نهاية العام. لا تزال هناك ثلاثة أعمدة نصية، ولكن ستكون الطريقة التي يتدفق بها النص بين الأعمدة أسهل بكثير لمعرفة المكان الذي يجب قراءته. لا يُعَدّ هذا التخطيط جميلًا، لكنك لا تضيع لمعرفة الفقرة التالية التي يجب قراءتها. تتواجد جميع نصوص هذا التخطيط في منتصف الصفحة، إلّا أنه ليس سيئًا للغاية، ولكنه ليس جميلًا في الوقت نفسه، إذ يمكن إيجاد تخطيط أفضل منه. تخطيط المجلة يوضح الشكل التالي تخطيطًا آخر ثلاثي الأعمدة، وهو أشبه بشيء قد تراه في مجلة، حيث أن الصور أكبر ولكن لا يزال بإمكانك إبقاء كل النص على نفس الصفحة، كما لا تزال لديك مساحة صغيرة لاستخدامها مع شيء آخر. يمنحك العمود الأيسر المكوَّن من قسمين فكرةً عن كيفية قراءة الصفحة عند عدم وجود عمود نصي كامل، وتُستخدَم إحدى الصور لتقسيم النص ومنحه تدفقًا وتوازنًا أفضل. لا بد أنك لاحظت وجود مساحة أسفل يسار الصفحة في تخطيط المجلة السابق على سبيل المثال، حيث لا يُعَد وجود هذه المساحة هناك خطأ، فجميع النصوص والصور موجودة على الصفحة التي تبدو متوازنة، لذا لا توجد مشكلة هناك. قد تحاول ملء هذا الفراغ، ولكن ليس هناك داعٍ لذلك. إن حاولت ملء كل مساحة على الصفحة، فستظهر مشوَّشة وسيبدو الأمر وكأنك تحاول جاهدًا لملء كل جزء صغير من الصفحة لأسباب اقتصادية. قد يكون ذلك جيدًا في بعض الحالات، ولكن يجب أن تحاول ترك مساحة جيدة دون تعريض محتواك للخطر، وبذلك يمكنك القول أنك وضعت هذه المساحة البيضاء عن عمد. وبالتالي يمكن تعديل النصيحة الأصلية عن المساحات البيضاء لتصبح: "إن كان نصك قابلًا للقراءة جيدًا، وتحقق صورك موازنة الصفحة، فيُحتمَل أن تكون أي مساحة بيضاء متبقية جيدة"، لكن ذلك غير كافٍ، فهذا مجرد تخطيط واحد لنوع محدّد. لا يجبرك برنامج سكريبوس على استخدام أعمدة "مملة" طوال الوقت لحسن الحظ، لأنك قد ترغب في استخدام تخطيطات "غير تقليدية". تخطيط الأعمدة المختلطة يوضح الشكل التالي تخطيطًا يمزج بين أعمدة ذات عرضٍ مختلف لزيادة جاذبية الصفحة: هذا التخطيط ليس مثاليًا بأي حال من الأحوال، فالمساحات البيضاء موضوعةٌ في الأماكن الخاطئة وهناك الكثير منها، لكنها تُظهِر أن استخدام عرض أعمدة مختلف يمكن أن يجعل الصفحة جميلة جدًا مع السماح بتجربة قراءة جيدة. التحرير Editing لقد استَخدمت جميع الأمثلة الواردة في هذا المقال نفس النص والأنماط والخط والصور، لأن الغرض هو إظهار كيفية تأثير التخطيطات المختلفة على المستندات، لكن ليس لديك دائمًا هذه القيود في العالم الحقيقي، فلديك الحرية في تغيير هذه الأشياء للمساعدة في تحسين التخطيط الخاص بك، إلّا في حالة اضطرارك إلى استخدام نص محظور لا يمكن تغييره، أو صور معينة يجب استخدامها بطرق محدّدة. يحتوي القسمان "Economy" و"Culture" في تخطيط الأعمدة المختلطة على مساحة بيضاء كبيرة جدًا أسفلهما على سبيل المثال، بحيث ستبدو الصفحة أفضل مع وجود مزيد من النص في كلا القسمين لتقريب أجزائهما السفلية من أعلى القسم "People". إن لم تتمكّن من تغيير النص، فلا مشكلة في ذلك، ولكن إذا كان بإمكانك تغيير النص، فسيكون ذلك رائعًا. يجب أن يكون تخطيط الصفحة وتصميم الصفحة الأكثر تعقيدًا شيئًا متغيرًا، كما يجب أن يكون المحتوى والتخطيط والتصميم قابلًا للتغيير جماعيًا أو كلًا منها على حدة، فإن أحببت التخطيط ولكن المحتوى لم يناسبك تمامًا مثلًا، إذًا غيّر المحتوى قليلًا، حيث يمكنك اعتماد ما يأتي: أضِف نصًا إضافيًا لا يغيّر المعنى في حالة عدم وجود نص كافٍ لملء الفراغات. إن كانت لديك نصوص كثيرة في التخطيط، فابحث عن أي كلمات يمكن إزالتها أو تغييرها بحيث تتناسب مع المساحة التي خطّطت لها تناسبًا أفضل. لا تخف من تغيير النص أو الصور لتناسب تخطيطك، ولا تجبر نفسك على استخدام تخطيط سيء لمجرد أن المحتوى لا يناسب التخطيط الجيد، بل تأكد بكل الوسائل من أن محتواك صحيح دائمًا، ولا تقدّم أو تغير أو تزيل أي شيء يجعله خاطئًا، وفي نفس الوقت لا تخف من التعديل المناسب لتحصل على مبتغاك. التخطيط غير العمودي ألقِ نظرةً على الشكل التالي الذي يوضح نوع تخطيط يمكن تحقيقه باستخدام نصوص وإطارات صور على شكل شبه منحرف عوضًا عن استخدام أعمدة مستطيلة عادية. قد لا يكون هذا النوع من التخطيط من الأنواع التي تستخدمه كثيرًا -أو قد لا تستخدمه على الإطلاق-، ولكن يجب أن تعرف أنه يمكنك استخدام مثل هذا النوع المختلف. التجربة رأينا كيفية إنشاء تخطيطات متنوعة قد لا تناسب جميع أنواع المستندات أو جميع المقالات الموجودة في تلك المستندات، إذ يمكنك أن تلاحظ بالتجربة أن ما يصلح لمقالٍ ما قد لا يصلح لمقال آخر من نفس النوع، حتى وإن كانا في المستند نفسه. لا يتعلق تخطيط الصفحة بإخبارك بما يجب عليك فعله ثم تنفيذ ما قيل لك، بل يتعلق الأمر بمعرفة الشيء المناسب، حيث لا توجد قواعد صارمة عند تنفيذ التخطيط ولكن يجب أن تضع في حساباتك الأشياء التالية: المساحة البيضاء: لا تدعها تتحكم بتخطيطك، وإنما طوّعها لصالحك. توازن الصفحة: ستعرف أن الصفحة متوازنة جيدًا بحكم التجربة. التحرير: لا تجبر نفسك على الالتزام بما لديك، بل حرّر وعدّل المحتوى عند الضرورة. ترجمة -وبتصرّف- للمقال Page Layout - The Basics. اقرأ أيضًا كيفية بدء استخدام برنامج سكريبوس Scribus كيفية التعامل مع الصفحات الرئيسية Master Pages في برنامج سكريبوس Scribus

سنشرح في هذا المقال ميزات وفوائد الصفحات الرئيسية Master Pages، إلى جانب كيفية إنشاء هذه الصفحات وتطبيقها في برنامج سكريبوس scribus. ميزات الصفحات الرئيسية يُنصَح باستخدام الصفحات الرئيسية Master pages عند التفكير في استخدام كائنات متعددة، مثل الترويسات المشتركة والشعارات والخلفية وأرقام الصفحات وما إلى ذلك، وذلك في نفس الأماكن ضمن مستندك، وبالتالي ستوفّر التعب والوقت غير الضروري باستخدام هذه الطريقة، لكن لا يمكن تغيير الكائنات التي تنتمي إلى الصفحات الرئيسية في وضع التحرير Edit Mode العادي، لأنه يمكن بسهولة نقل أو تغيير شيءٍ ما على الصفحة الرئيسية عن غير قصد أثناء العمل مع مستندٍ ما. تنتمي الصفحة الرئيسية دائمًا إلى مستند، إذ لا يمكن حفظها مثل ملف منفصل، ولكن يمكنك في نفس الوقت إنشاء نموذج ملف يحتوي على صفحات رئيسية مستخدمة استخدامًا متكررًا، وبالتالي يمكن استخدامها مثل مورد لاستيراد الصفحات الرئيسية إلى مستندات سكريبوس Scribus الأخرى. كيفية إنشاء صفحات رئيسية الطريقة الأولى أنشئ مستندًا جديدًا، ثم انتقل إلى قائمة تحرير Edit، ثم اختر صفحات رئيسية Master Pages كما يلي: حينها سيظهر لك مربع حوار فيه العبارة الآتية: "أدِر الصفحات الرئيسية Edit Master Pages"، وذلك من أجل التغيير إلى وضع تحرير الصفحات الرئيسية Master Pages Edit Mode. الصفحة الرئيسية ذات الوضع العادي موجودة دائمًا ولا يمكن حذفها، أي لن يكون زر الحذف هنا مفعَّلًا مثل الشكل السابق عند تحديد الصفحة الرئيسية ذات الوضع "العادي Normal"، وهنا يمكن تحرير الصفحة الرئيسية العادية، ولكن يُفضَّل تركها فارغةً لتتمكن من إدراج صفحات فارغة جديدة. إذا حرَّكتَ الفأرة فوق الأزرار، فسترى بعض التلميحات المفيدة مثل الموجودة في الشكل السابق، وهذه التلميحات هي كما يلي بدءًا من اليمين: صفحة رئيسية جديدة. استيراد صفحات رئيسية. مضاعفة الصفحة الرئيسية. حذف الصفحة الرئيسية. يؤدي النقر على زر "إضافة صفحة رئيسية جديدة" إلى فتح نافذة يمكنك من خلالها تسمية صفحتك كما يلي: انقر على "موافق"، ثم ستظهر لك نافذة تحوي عبارة: "أدِر الصفحات الرئيسية"، مع تحديد صفحتك الرئيسية الجديدة. يمكنك بعد ذلك اختيار صفحة رئيسية من بين قائمة من هذه الصفحات الرئيسية وتحرير كل منها كما تريد. بعدها تعود إلى وضع التحرير العادي في برنامج سكريبوس عندما تغلق نافذة تحرير الصفحات الرئيسية. إذا وجدت أنك بحاجة إلى صفحة رئيسية مشابهة لصفحة حالية، فانقر على "مضاعفة الصفحة الرئيسية المحددة" بدلًا من إعادة بدء صفحة رئيسية جديدة من الصفر، وهو ما يؤدي إلى توفير وقت كبير. يمكنك أيضًا نسخ صفحة رئيسية من مستند آخر، وذلك من خلال النقر على زر "استيراد صفحات رئيسية من مستند آخر"، والذي يفتح نافذة محتواها: "استورد صفحة رئيسية". انقر بعد ذلك على زر "اختر…"، وذلك من أجل البحث عن المستند الذي يحتوي على الصفحة الرئيسية التي ترغب في استيرادها، ثم اختر الصفحة الرئيسية، واضغط على زر "استيراد". الطريقة الثانية يمكنك أيضًا إنشاء صفحات رئيسية جديدة من الصفحة التي تحرّرها في وضع التحرير العادي. وفي هذه الحالة عليك باختيار قائمة صفحة Page، ثم "تحويل إلى صفحة رئيسية" كما في الشكل الآتي، وهذا يؤدي إلى فتح نافذة بعنوان "حوّل الصفحة لصفحة رئيسية"، حيث يمكنك هنا إعطاء هذه الصفحة الرئيسية الجديدة اسمًا، كما يمكنك بعد ذلك العودة إلى قائمة تحرير، ثم الصفحات الرئيسية، حيث ستجد صفحتك الرئيسية الجديدة في نافذة تحت عنوان "أدِر الصفحات الرئيسية". الصفحات المزدوجة Double sided وثلاثية الطيات 3fold ورباعية الطيات 4fold يُذكَر أن هذه الميزة غير متوفرة في الإصدار الجديد 1.5.7 من برنامج سكريبوس الداعم للغة العربية، حيث لا يزال هذا الإصدار في وضعية التطوير؛ بينما تتوفر هذه الميزة في الإصدارات الأقدم له مثل الإصدار الكامل المستقر 1.4.8، ولكنه غير داعم للغة العربية. إن استخدام الصفحات الرئيسية مع هذا النوع من الصفحات مفيد وموفر للوقت. يمكنك تحديد التخطيط الذي تريده عند إنشاء مستند جديد في الإصدار 1.4.8 كما يلي: ثم أنشئ صفحاتك الرئيسية الخاصة، وذلك باستخدام إحدى الطريقتين الموضحتين أعلاه. سنرى فيما يلي سبب ضرورة وضع اسم مختار، وأهميته للصفحة الرئيسية: التخطيط المزودج Double Sided layout. تخطيط ثلاثي الطيات 3fold layout. تخطيط رباعي الطيات 4fold layout. في حين يقتصر الإصدار 1.5.7 على اختيار التخطيط بصفحة واحدة أو صفحات متقابلة. بعد كل هذا حدّد التخطيط الذي تريده عند إنشاء مستند جديد. ثم أنشئ صفحاتك الرئيسية الخاصة باستخدام إحدى الطريقتين الموضحتين أعلاه. تطبيق الصفحات الرئيسية تطبيق الصفحات الرئيسية على صفحات المستند الفارغة اذهب إلى قائمة "صفحة" ثم اختر "استخدم صفحة رئيسية"، أو بالنقر على زر الفأرة الأيمن لتظهر لك قائمة جديدة، يمكنك الضغط منها على خيار "استخدم صفحة رئيسية"، حيث يمكنك تهنا طبيق الصفحة الرئيسية على: الصفحه الحالية. الصفحات الزوجية. الصفحات الفردية. كل الصفحات. ويمكنك تطبيقها على نطاقٍ من الصفحات. حدّد الصفحة الرئيسية المطلوبة من القائمة المنسدلة المعنونة بصفحة رئيسية، ويمكن تحديد الخيار "الصفحات الزوجية" فقط عندما يحتوي المستند على أكثر من صفحة واحدة، بحيث لا يمكن التطبيق على نطاق من الصفحات إلّا عندما تحدد الخيار "كل الصفحات". إضافة صفحة جديدة إن أردت إضافة صفحة جديدة من خلال قائمة صفحة ثم اختيار "إضافة"، فستُفتَح لك نافذة جديدة يمكنك من خلالها اختيار إضافة صفحة واحدة أو أكثر، وكذا اختيار مكان الإضافة، ثم تحديد احتواء هذه الصفحات الجديدة على عناصر صفحات رئيسية. لاحظ أن منطقة الصفحات الرئيسية تتوسع وفقًا للتخطيط المختار، بحيث نرى في الشكل التالي نافذة تحوي إضافة صفحة إلى تخطيط يتكون من صفحات متعددة: استخدم اثنين من هذه الأحرف الخاصة بالنسبة لأرقام الصفحات المكونة من رقمين (10-99)، واستخدم ثلاثة أحرف خاصة لأرقام الصفحات المؤلفة من ثلاثة أرقام 100-999. وإن استخدمت نفس الصفحة الرئيسية لجميع الصفحات في مستند طويل، فيمكنك وضع حرفين أو ثلاثة أحرف من أرقام الصفحات على الصفحة الرئيسية، وهنا سوف يتجاهل برنامج سكريبوس الأرقام الزائدة في الصفحات ذات الأرقام المنخفضة. ترجمة -وبتصرّف- للمقال Working with Master Pages. اقرأ أيضًا كيفية بدء استخدام برنامج سكريبوس Scribus