CALM/arwiki huggingface dataset:
تتراوح أبعاد المدارج بحيث يبدأ طولها من وعرضها للمطارات الصغيرة ذات الطيران العام (general aviation) إلى مدارج ذات طول وعرضها للمطارات الدولية التي تستوعب الطائرات النفاثة المدنية الضخمة.
تحديد المدارج وتقاربها.
يصنف مدرجين بنيا بنفس الإتجاه بالمزدوجة أو المتوازية حسب المنطقة الفاصلة بينهما. بعض الدول لديها قوانين طيران يلزم باستخدام مدرج واحد في ظروف معينة (كالظروف الجوية السيئة) عندما يكون المدرجين متقاربين لبعضهما بشكل قوي.
طول المدرج.
على الرغم من أن طول المدرج قد حاز على الاهتمام الأكاديمي، من حيث قابليتها للاستخدام في خطوط شركات الطيران، فالمدرج الذي لايقل طوله عن فهو مهيأ للطائرات ذات الحمولة أقل من . أما الطائرات ذات البدن الواسع مثل (البوينغ: 747، 767، 777، 787; والإيرباص: A310، A330، A340، إيرباص ايه 350 أكس دبليو بي (لا تزال في طور التصميم)، A380; والماكدونال دوغلاس DC-10 أو MD-11 وترايستار إل-1011 والتي تحتاج عادة إلى مدرج لايقل طوله عن عند مستوى سطح البحر، وأحيانا أكثر في حالة المطارات المرتفعة. وتلك الطائرات تحتاج بالرحلات الدولية إلى مدرج للهبوط لايقل طوله ولمدى إقلاع طوله +.
يعتبر المدى مناسب جدا عند مستوى سطح البحر، لكي يوائم جميع أنواع الطائرات. فعلى سبيل المثال: عندما تهبط طائرات في مطار أوهير بشيكاغو بنفس الوقت على المدارج 22R و27L أو الموازي 27R، يكون من المعتاد للقادمين من الشرق الأقصى توجيههم إلى 22R وطوله أو 27R وطوله . وقد يعطى لهم مدرج 27L عند الطلب فطوله فهو بالتأكيد يستوعب ذلك وإن كان يتأخر بعض المرات.
وبشكل عام كلما ارتفع المطار عن سطح البحر فإنه يحتاج لمدرج طائرة أطول منه عند مستوى البحر، وذلك بسبب قلة كثافة الهواء كلما ارتفعنا، مما يضعف كمية الرفع وقدرة المحرك التي تحتاجها الطائرة. مثال على ذلك، مطار جون كينيدي يكون بمستوى سطح البحر ومطار دنفر يرتفع 5,000 قدم عن سطح الأرض، لذلك فنفس الطائرة وبنفس الحمولة ستحتاج في مطار دنفر لمدرج أطول منه عن مطار نيويورك وبجو أكثر سخونة وكثافة. معظم الطائرات المدنية تحتوي على جداول من المصنع تبين التضبيطات المطلوبة لدرجة الحرارة المعطاة.
بنية المدارج صلبة وقوية جدا، وعادة تتألف من الأسفلت أو ألواح خرسانية.
المنارات الضوئية.
تكون في اتجاه واحد في شكل خط طويل من بعيد، تستعمل لكي تتم رؤية المدرج بسهولة أثناء الليل، أو عندما تكون الأحوال الجوية سيئة مثل الأمطار أو الضباب وأيضا تقوم بمساعدة بصرية عند الهبوط (مؤشر نهج المسار). إضافة إلى ذلك فإن تنصيبها يلزم نظام إذاعي للمنارات لأجهزة التعقب الآلية المدمجة في طائرات النقل (نظام الهبوط).
تصميم المدارج.
تستخدم معظم المدارج لعمليتي الهبوط والإقلاع. وهذا يعني تزامن تنظيم وسلاسة حركة الطائرات. عندما يتلقى المطار حركة مرور كثيفة، يتم بناء مدارج في مجموعات من إثنين، وتكون متوازية فيما بينها، وذلك لفصل حركتي الإقلاع والهبوط. يمكن لكل مدرج أن تقع فيه هاتان الحركتان دقيقة ونصف تقريبا، وقد يكون أكثر من ذلك بسبب اضطرابات قد تحدث للطائرة عند الإقلاع. تكون المدارج عادة موجهة لاتجاه الريح السائدة، ذلك لأن تيارات الهواء تكون في صالح الطائرات وتساعد على الإقلاع، إضافة إلى التحسين في عملية الكبح عند الهبوط. وتكون الطائرات دائمًا عكس الرياح.
برنامج البروغ أو progdvb
برنامج مجاني لمشاهدة القنوات الفضائية في أجهزة الحاسوب عن طريق كرت الساتلايت و يعتبر أكثر البرامج شعبية لوجود عدة ميزات به و سهولة الاستخدام.
موقع البرنامج
بروتوكول رسائل التحكم في الإنترنت للإصدار الرابع من بروتوكول الإنترنت هو بروتوكول مساعد للإصدار الرابع من بروتوكول الإنترنت وجزءٌ مدمج فيه. يُعرِّف البروتوكول عدداً من رسائل التحكم الَّتي تُغلَّف داخل رزم الإصدار الرابع من بروتوكول الإنترنت، وتنقل عبر الشبكة بهذا الشكل. طُوِّر البروتوكول بالتوازي مع تطوير الإصدار الرابع من بروتوكول الإنترنت، ووصف في وثيقة طلب التعليقات RFC 792.
تُصنَّف رسائل التحكم إلى صنفين: رسائل الأخطاء ورسائل الاستعلام. أَمَّا رسائل الأخطاء فهي تُرسل لمصدر رزمة بيانات نتيجةً لحصول خطأ ما في أثناء معالجة الرزمة، وقد يُرسلها المُضيف الوجهة أو أي موجه يُعالِج الرزمة في أثناء عبورها للمسار بين المصدر والوجهة. وأمَّا رسائل الاستعلام فهي تقسم إلى مجموعتين أيضاً: رسائل الطلب ورسائل الرد. وأمَّا رسائل الطلب فيُرسلها مُضيفٌ لوجهةٍ ما يطلب فيها الحصول على معلوماتٍ مُحددةٍ، مثل عنوان المُوجِّه المتصل مع الشبكة، وأَمَّا رسائل الردّ فهي ردُ تلك الوجهة على رسالة الاستعلام، ولكل رسالة طلب استعلامٍ رسالة ردٍ مُتوافِقة معها.
عرَّف المعيار الرسمي للبروتوكول عدداً من الرسائل، أهمها رسالة توليد الصدى والرد عليها ورسالة إعادة التوجيه ورسالة تعذُّر بلوغ الوجهة. وأضيفت إليها لاحقاً عدداً من الرسائل لأداء وظائِفَ مُختلِفة، مثل الاستعلام عن قناع الشبكة، ولكن أغلب الرسائل المضافة وبعض الرسائل المُعرَّفة في المعيار الرسمي أبطلت فيما بعد لأسباب متنوعة ولم تعد مُستخدمةً.
اعتماداً على رسالة توليد الصدى والرد عليه، بنيت أداتان لتشخيص الأخطاء في الشبكة وتعقبها هما أداة التحقق من الاتصال، المشهورة باسم بينغ ، وأداة تتبع المسار. ليس هناك معيارٌ محدد لتنفيذ هاتين الأداتين، ولذلك فقد تنوعت أساليب تنفيذهما في أنظمة التشغيل المختلفة مثل نظام ويندوز الخاصّ بمايكروسوفت وأنظمة التشغيل الخاصَّة بسيسكو وغير ذلك.
كانت رسائل البروتوكول سبباً في تطوير عدد من الهجمات الَّتي يمكن تصنيفها ضمن ثلاثة أنواع رئيسة هي: هجمات الغمر، مثل هجوم السنافر، والهجمات الانفجارية مثل هجوم أمر التحقق من الاتصال المميت، وهجمات تسريب المعلومات مثل شكل خاص من هجوم الوسيط طُوِّر اعتماداً على رسائل إعادة التوجيه التي يُعرِّفها البروتوكول.
طُوِّر بروتوكول رسائل التحكم في الإنترنت بالتوازي مع تطوير الإصدار الرابع من بروتوكول الإنترنت، وطُرح أول معيار له شهر أبريل من العام 1981 في وثيقة طلب التعليقات RFC 777، ثُمَّ طُرحت وثيقة أخرى بعد 5 أشهر في سبتمبر من العام نفسه وهي وثيقة طلب التعليقات RFC 792، وهي المعيار الرسمي للبروتوكول حتى اليوم.
احتوى المعيار الرسميّ للبروتوكول توصيفاً مُقتضباً لإحدى عشرة رسالة تحكُّمٍ، تلا ذلك شرحٌ مُفصَّل عن كيفية عمل البروتوكول ومتى يَلزم إِرسال الرسائِل وتفاصيلُ دقيقةٌ أخرى صدرت في وثيقتين منفصلتين، الأولى موجهة لتوصيف عمل مُضيفي الإصدار الرابع من بروتوكول الإنترنت، وهي وثيقة طلب التعليقات RFC 1122 المعنونة:"متطلبات مُضيفي الإنترنت -- طبقات الاتصال" والَّتي صدرت في شهر أوكتوبر من العام 1989م، والثانية مُخصصةٌ لتوصيف عمل المُوجِّهات، وهي الوثيقة RFC 1812 المُعنونة:"مُتطلبات مُوجِّهات الإصدار الرابع من بروتوكول الإنترنت" والتي صدرت في شهر يونيو من العام 1995.
في السنوات اللاحقة لإصدار المعيار الرسميّ، وُسِّع البروتوكول تتابعاً بحسب ما اقتضاه التطور التقنيّ. فعلى سبيل المثال، في أغسطس من العام 1985م، صدر معيار تجزئة الشبكة، وعرَّف نوعاً جديداً من رسائِل التحكم هي رسائِل القناع، وتشمل نوعين من الرسائِل هُما رسالة طلب القناع ورسالة الردِّ على طلب القناع. وأيضاً في شهر سبتمبر من العام 1991، أي بعد قرابة 10 سنوات من اعتماد البروتوكول معياراً رسميّاً، صدرت الوثيقة RFC 1256 التي أضافت نوعاً جديداً من الرسائل هي رسائل اكتشاف الموجه، وتضمُّ رسالتين هما رسالة إِعلان المُوجِّه ورسالة التماس المُوجِّه. ولكنَّ أغلب هذه الرسائل أُبطلت في وقت لاحق لأسبابٍ مُختلفةٍ ولم تعد مُستعملة.
في عام 1995م، طُوِّر الإصدار السادس من بروتوكول الإنترنت، وبالتوازي مع هذا التطوير جرى العمل على إصدار جديد من بروتوكول رسائل التحكم متوافق مع الإصدار السادس، وُسمِّي بروتكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت ووصف في وثيقة طلب التعليقات RFC 1885، طُوِّر معيار هذا البروتوكول لاحقاً,عُدِّل تباعاً، وأمَّا المعيار الأحدث فهو مَوصُوفٌ بالوثيقة RFC 4443.
يُقدِّم بروتوكول رسائل التحكم للإصدار الرابع من بروتوكول الإنترنت الخدمات التالية: الإبلاغ عن الأخطاء وآليةً للاستعلام عن المعلومات في الشبكة وآليَّةً لإعادة التوجيه على مستوى المُوجِّه الأول المُتَّصِل مع مصدر رزم البيانات. لتحقيق ذلك، يُعرِّف البروتوكول عدداً من الرسائل التي يجري تبادلها عبر الشبكة بين مصدر رزم البيانات ووجهتها أو بين المصدر وعقد الشبكة الموجودة على المسار نحو الوجهة.
إِنَّ الإصدار الرابع من بروتوكول الإنترنت غير موثوق، ولا يَهدف استعمال بروتوكول رسائل التحكم إلى إضافة الموثوقية إليه، ولكن بروتوكول رسائل التحكم يعمل على إيصال رسائل تبليغ عن وقوع أخطاءٍ في الشبكة، أو عن حصول أحداثٍ مُعيَّنة تتطلب انتباهاً من مُشرفي الشبكة. وفقاً لنموذج الربط البيني للأنظمة المفتوحة، فإنَّ رسائل هذا البروتوكول توَّلد على مستوى طبقة الشبكة حيث يعمل، أو على مستوى طبقة النقل، أو حتى على مستوى طبقة التطبيق حيث تنشط تطبيقات المستخدمين.
تُغلَّف رزم بروتوكول رسائل التحكم داخل رزم الإصدار الرابع من بروتوكول الإنترنت. أي عند التغليف، يُعامل بروتوكولُ الإنترنت بروتوكولَ رسائل التحكم معاملة بروتوكول طبقة أعلى، ولكن بروتوكول رسائل التحكم هو جزءٌ مُدمَجٌ من بروتوكول الإنترنت، ويجب أن يُدعم في أي موقع يدعم بروتوكول الإنترنت. إذا كانت رزمة بروتوكول رسائل التحكم مُغلَّفة داخل رزمة بروتوكول الإنترنت، فإن قيمة حقل البروتوكول في ترويسة بروتوكول الإنترنت يجب أن تُضبط إلى القيمة 1.
تُصنَّف رسائل التحكم إلى صنفين وفقاً لآلية توليد الرسالة. الصَّنف الأول هو رسائل الأخطاء، وهي تُرسل من نتيجة لحصول خطأ في معالجة رزمة بيانات ما، وهي تُرسَل من المضيف الوجهة للرزمة أو من أحد المُوجِّهات على مسارها، إلى مصدر رزمة البيانات، ولا يُردّ أبداً على رسالة خطأ. أمَّا رسائل الاستعلام، فتُرسل من مُضيف، إلى مُضيف آخر أو إلى موجه، ويمكن أن تستخدم لطلب معلومات مُحددة، مثل عنوان موجه أو قناع الشبكة، ولكل رسالة طلب رسالة ردٍّ مُتوافِقة معها من حيث النُّوع والبِنية، ويَلزم الردّ على كُلّ رسالة طلب ٍبرسالة الرد المُتوافِقة معها.
بنية الترويسة.
تتكون ترويسة بروتوكول رسائل التحكم من مجموعتين من الحقول، أوَّلها هي الحقول الدائمة، وتوجد في ترويسات رسائل البروتوكول كُلِّها، بغض النظر عن نوع الرسالة، وثانيها هي حقول المُحتوى، وتتغير في العدد والبنية وفقاً لنوع الرسالة، ويمكن وصف حقول الرسالة وفقاً لما يأتي:
تُصنف رسائل التحكم إلى نوعين وفقاً لوظيفتها، فهي إمَّا رسائل استعلام أو رسائل إبلاغ عن خطأ، وفيما يأتي رسائل البروتوكول الَّتي ما تزال قيد الاستعمال:
هناك العديد من الرسائل التي طُوِّرت لأغراض معينة، بعضها استعمل لفترة، وبعضها لم يتجاوز المرحلة التجريبية. وفيما يأتي سرد بهذه الرسائل المُبطلة مرتبةً وفقاً لقيمة حقل النوع فيها:
الإبلاغ عن الأخطاء.
تُرسل رسائل الأخطاء نتيجةً لحصول خطأ ما في أثناء معالجة رزمة بيانات. يكون مصدر الرسالة وجهة الرزمة أو أحد المُوجِّهات التي تُعالِجُها في أثناء عبورها الشبكة نحو وجهتها. يجب أن تحتوي رسالة الخطأ على نسخة من ترويسة بروتوكول الإنترنت الخاصّة بالرزمة التي حصل الخطأ فيها بالإضافة لنسخة من أول ثمانية بايتات من حمولة الرزمة. يمكن أن تستخدم بعض رسائل الأخطاء لاكتشاف الأخطاء في الشبكة بهدف تصحيحها، مثل رسالتي إعادة التوجيه وتعذُّر بلوغ الوجهة.
تُحدد وثيقة طلب التعليقات RFC 1812 بعض الحالات التي لا يجب أن تُرسل رسائل الأخطاء فيها، وهي كالتالي:
تعذُّر بلوغ الوجهة.
تُرسل هذه الرسالة إلى المُضيف المَصدر الذي أرسل رزمة بياناتٍ ما نحو مضيف وجهة، ولكن لسببٍ ما، تحدده هذه الرسالة تعذَّر إيصال الرزمة إلى وجهتها. وقد يكون مُرسِل هذه الرسالة مُوجِّهاً يُعالِج الرزمة في أثناء عبورها المسار نحو المضيف الوجهة الذي قد يكون هو نفسُه مرسل الرسالة في بعض الأحيان. تُرسل هذه الرسالة في الحالات التالية:
1. من مُوجِّه يُعالج الرزمة:
2. من المُضيف الوجهة:
إعادة التوجيه.
تُرسل رسالة إعادة التوجيه من مُوجِّه مُتصِلٍ بشكلٍ مباشر مع شبكة المضيف المصدر لرزمة بيانات من أجل إبلاغه باستحسان أن يُرسل رزم البيانات الموجهة لوجهة مُحددة إلى مُوجِّه آخر متصل بشكل مباشر مع الشبكة المحليَّة نفسها. أفضل لرزمة بيانات سبق وأرسلها. في هذه الحالة يكون هناك مُوجِّهان على الأقل مُتصِلان مع الشبكة المحلية حيث يُوجد المُضيف، وليكونا مثلاً R1 وR2. يُولِّد المُضيف رزمة بيانات نحو وجهة ما، ولتكن X، وأفضل مسار لبلوغ هذه الشبكة هو عبر الموجه R2، ولكن المُضيف يُرسلها نحو الموجه R1، وهنا يوجهها هذا الموجه نحو الموجه R2، ثُمَّ يُرسل رسالة إعادة توجيه للمضيف الذي ولد الرزمة، يبلغه فيها بتوجيه الرزم المستقبلية التي تكون وجهتها هي X نحو الموجه R2.
يُلزَم كُلُّ مُضيفٍ بتحديث جدول التوجيه خاصَته للتفاعل مع رسائل إعادة التوجيه التي يستقبلها، ويُستُثنى من ذلك الحالات التي يكون عنوان المُوجِّه فيها في شبكة جزئية أخرى مغايرة للشبكة الجزئية التي ينتمي عنوان المُضيف إليها. في هذه الحالة فقط، يُهمل المضيف رسالة إعادة التوجيه.
في رسالة إعادة التوجيه تكون قيمة حقل النوع 5 دائماً، وهناك 4 قيم مُمكِنة لحقل الرمز يُبيُّنها الجدول التالي:
نفاد الزمن.
تُرسَل هذه الرسالة في حالتين اثنتين، تحصل الأولى بعد معالجة رزمة بيانات في مُوجِّه ما، فإذا وجد المُوجِّه أن قيمة حقل زمن حياة الرزمة في ترويسة الإصدار الرابع من بروتوكول الإنترنت مُساوٍ للصفر، فإنَّه يتخلص من الرزمة مباشرةً ويُرسِل رسالة نفاد الزمن إلى مَصدرها. أمَّا الحالة الثانيَّة، فتحصل عند تجميع قطع رزمة بيانات في الوجهة، فإذا نفد مُؤقِّت التجميع ولمّا تصل كل القطع بعدُ، فإِنَّ المُضيف الوجهة يتخلَّص من القطع التي جمعها كلِّها، ويُرسِل رسالة نفاد الزمن إلى مصدرها.
تكون قيمة حقل النوع في رسالة نفاد الزمن هي 11 دائماً، أما قيمة حقل الرمز فتكون إما 0 أو 1 وفقاً للجدول التالي:
مشكلة في محدِد.
قد يصادف مُضيف وجهة أو مُوجِّه في أثناء معالجة رزمة بيانات ما مُشكلةً في أحد حقول ترويسة الإصدار الرابع من بروتوكول الإنترنت، ومثالها أن تحتوي حقول الترويسة على قيمةٍ غير صحيحةٍ، أو غير مَدعُومةٍ في الوجهة. إذا مَنعت هذه المشكلة استمرار معالجة الرزمة، فلا بد عندها من التخلُّص مِنها ثُمَّ إرسال رسالة مُشكلةٍ في مُحدِد إلى مصدرها. تحتوي الرسالة على حقلٍ يُسمَّى حقل المُؤشِّر، يستعمله مُولِّد الرسالة للإشارة إلى موقع البايت الذي سبب المشكلة في ترويسة الرزمة، بالإضافة إلى نسخة عن الترويسة التي سببت المُشكلة.
يجب أن يولد كل مُوجِّه رسالة مُشكلةٍ في مُحدد من أجل أي خطأ معالجة غير مَشمُول برسائل الإبلاغ عن الأخطاء الأُخرى الخاصّة بالبروتوكول. في هذه الرسالة تكون قيمة حقل النوع 12 دائماً، أمَّا قيمة حقل الرمز فتكون إمَّا 0 أو 1 وفقاً للجدول التالي:
الاستعلام.
توليد الصدى والصدى.
يجري تبادل هاتين الرسالتين بين مُضيفين اثنين لعنوانين من الإصدار الرابع من بروتوكول الإنترنت، يُرسِل الأول رسالة توليد الصدى إلى الآخر الذي يرد، بعد استقبالها، بإرسال رسالة الصدى. تحتوي رسالة توليد الصدى على عدد من البايتات التي تُمثِّل حمولة الرسالة، ويجب على رسالة الصدى أن تحمل نفس حمولة رسالة توليد الصدى. هناك حقلان في ترويسة الرسالة هما رقم التتابع والمُعرِّف، ويمكن أن يُستخدما من قبل مُرسل رسالة توليد الصدى للمساعدة في مطابقة رسالة الصدى القادمة مع رسالة توليد الصدى المُرسلة، في حال أُرسلت أكثر من رسالة توليد في الوقت نفسه.
يجب أن تكون عناوين المصدر والوجهة في رسالتي توليد الصدى والصدى مُتعاكسة، أي يكون عنوان المصدر في رسالة التوليد هو عنوان الوجهة في رسالة الصدى، وعنوان الوجهة في رسالة التوليد هو عنوان المصدر في رسالة الصدى.
تكون قيمة حقل النوع هي 8 في رسالة توليد الصدى و0 في رسالة الصدى. أمَّا قيمة حقل الرمز، فهي 0 دائماً في كلتا الرسالتين.
اكتشاف الموجه.
رسائل اكتشاف المُوجه هي توسِعة لبروتوكول رسائل التحكم للإصدار الرابع من بروتوكول الإنترنت، وهي تُمكِّن مضيفين متصلين بشبكات تدعم البثَّ المجموعاتي أو البثَّ العامّ اكتشاف عنوان بروتوكول الإنترنت الخاصّ بالمُوجِّهات الجيران. صدرت هذه التوسِعة بشكل مُستقلٍ ووصفت في وثيقة طلب التعليقات RFC 1256.
تُعرِّف هذه التوسعة رسالتي استعلام، هما رسالة إعلان المُوجِّه ورسالة التماس المُوجِّه. يرسل كُلُّ مُوجِّهٍ يدعم البثَّ المجموعاتي رسالة بثٍّ مجموعاتيّ هي إعلان الموجه بشكل دوريَّ عبر كل منفذ يدعم البثّ المجموعاتيّ فيه، وتتضمن الرسالة التي تُبثُّ عبر كل منفذ، عناوين البثّ المجموعاتيّ المَدعُومة فيه، ويُمكن للمضيفين أن يَكتشفوا المُوجِّهات الجيران بالاستماع إلى هذه الإعلانات. ويُمكن أيضاً لمُضيف عنوان بثّ مجموعاتيّ أن يُرسِل رسالة التماس، وهي رسالة بثٍّ مجموعاتي تطلب من أيّ مُوجِّه يستقبلها أن يُرسل مباشرةً رسالة إعلان على المنفذ الذي استقبلت منه، اي أنها تُعرِّف آليَّةً يمكن للمضيفين من خلالها طلب المعلومات من الموجهات عند الحاجة عوضاً عن انتظار رسائل الإعلان. تتضمَّن رسائِل الإعلان حقلاً هو زمن الحياة، وهو يُحدد المدة العظمى التي تكون العناوين المُعلَن عنها صالحةً للاستعمال، ويبدأ أي مضيف يستقبل رسالة الإعلان بتشغيل مُؤقِّت تنازلي تُضبَط قيمته العليا وفقاً لقيمة زمن الحياة في رسالة الإعلان، ويُعيد المُضيف ضبط هذا المؤقت إلى قيمته العُليا كلما استقبل رسالة إعلانٍ جديدة، فإذا بلغت قيمة المؤقت الصفر، فإنَّ العناوين المَوجُودة في رسالة الإعلان تُصبح غير صالحةٍ للاستعمال. وسبب استعمال هذا المؤقت هو ضمان أن يمتلك المُضيفون آليَّةً لاكتشاف إخفاق المُوجِّهات.
تُرسل رسائل الإعلان بشكل دوريٍّ بفواصل زمنيَّة تتراوح بين 7 و10 دقائق، وتكون مدة زمن الحياة هي 30 دقيقة افتراضيَّاً.
الوسمة الزمنية.
الوسمة الزمنية هي عدد طوله 32 بت يعبر عن الزمن المنقضي بأجزاء ألفيَّة من الثانية منذ منتصف الليل وفقاً للتوقيت العالمي. تؤمن رسائل الوسمة الزمنية آلية لقياس الزمن المنقضي بين زمن إرسال الرسالة من مصدرها وزمن وصولها إلى وجهتها وزمن إرسال الرد عليها، وهذه الأزمنة هي حقول في رسالة الوسمة الزمنية والرد عليها. يملأ المضيف المصدر حقل وسمة الإرسال الزمنية في رسالة الوسمة، وينسخ المضيف الوجهة قيمة هذا الحقل إلى رسالة الرد ثُمَّ يضيف إليها وسمتي الاستقبال وإعادة الإرسال ويُرسلها إلى مصدر رسالة الوسمة. هناك حقلان إضافيان في الرسالة هما رقم التتابع والمُعرِّف، ويمكن أن يُستخدما من قبل مُرسل رسالة الصدى للمساعدة في مطابقة رسالة الصدى مع رسالة توليد الصدى، في حال أُرسلت أكثر من رسالة توليد تتابعاً.
تكون قيمة حقل النوع في رسالة الوسمة الزمنية هي 13 وفي رسالة الرد عليها 14، أمَّا قيمة حقل الرمز فهي 0 دائماً في الرسالتين.
أمر التحقق من الاتصال.
أمر التحقق من الاتصال هو أمر برمجي مدعوم في شبكات البيانات التي تُشغِّل حزمة بروتوكولات الإنترنت، يهدف إلى التحقق مِن القدرة على الاتصال مع مضيف لعنوان من الإصدار الرابع من بروتوكول الإنترنت عن طريق تبادل رسائل توليد الصدى والصدى معه. تُرسل رسالة توليد الصدى إلى المضيف الهدف، فإذا ردّ برسالة الصدى فإن هناك إمكانيَّة لإنشاء اتصال معه.
طُوِّرت هذا الأمر أساساً في على يد مايك موس في عام 1983م، وقد سمُيَّ بهذا الاسم كنايةً عن صوت السونار عندما ترتطم أمواجه الصوتيَّة بجسم ما وترتد بعد ذلك عائدةً إلى المصدر، وهذا هو مبدأ عمل هذا الأمر.
لاحقاً، دعمت أشهر أنظمة التشغيل هذا الأمر ومنها على سبيل المثال: لينكس وويندوز وسيسكو.
أمر تتبع المسار.
أمر تتبع المسار هو أمر برمجيٌّ مَدعُومٌ في شبكات البيانات التي تُشغِّل حزمة بروتوكولات الإنترنت، يهدف إلى تعقب المسار الذي تسلكه رزم البيانات عند انتقالها من مصدرها إلى وجهتها. يُقدِّم الأمر بياناتٍ عن عدد القفزات على طول المسار والزمن الذي استغرقه كل منها.
جرت محاولات لجعل هذه الأداة جزءاً من الإصدار الرابع من بروتوكول الإنترنت من خلال تعريف خيارٍ خاصٍّ بها حمل مُعرِّفه الرقم 82، وإضافته إلى خيارات الإصدار البروتوكول، بالإضافة لتعريف رسالة استعلام إضافيَّة لبروتوكول رسائل التحكم، مع قيمة مُميَّزة لحقل النوع هي 30، ولكن المحاولات السابقة ظلت تجريبية ولم تُطبَّق على نطاقٍ واسِع، ثم أُبطلت في وقت لاحق.
نتيجةً لذلك، طُوِّر هذا الأمر انطلاقاً من بروتوكول رسائل التحكم بشكل منفصل وبطرق متنوعةٍ في أنظمة التشغيل المختلفة، ومنها نظام لينكس وويندوز ووسيسكو.
المُشكلات.
تُصنَّف المُشكلات التي تنتج عن استعمال البروتوكول تحت ثلاث أنواع: الغمر ، والهجوم الانفجاري وتسريب البيانات . أمَّا الغمر فهو شكل من أشكال هجوم حجب الخدمة، وفيه تُوَلَّد كمية كبيرة من البيانات لغمر الشبكة بها بحيث يتعذَّر استعمال الشبكة. وأمَّا الهجوم الانفجاري، فهو يستهدف إيقاف عمل وحدة البروتوكول من خلال إرسال رسالةٍ ذات بنيةٍ مُحددةٍ تسبب معالجتها خطأً في الوحدة. وأَمَّا تسريب البيانات، فهو لا يُلحق ضرراً بحدة ذاته، لكنَّه يكشف عن بيانات يمكن أن تُستعمل في هجمات أخرى.
في ما يأتي، تصنيفٌ للهجمات التي يمكن شنها باستعمال البروتوكول وفقاً لنوع الرسالة:
أولاً: رسالتا توليد الصدى والصدى:
ثانياً: رسالة إعادة التوجيه:
هناك أيضاً وثيقة طلب التعليقات تصفُ الهجمات التي يمكن أن تُشن على بروتوكول التحكم بالنقل باستعمال بروتوكول رسائل التحكم، هي الوثيقة ذات الاسم الرمز RFC 5927.
. يُمكن تبيُّن العلاقة الوثيقة مع الإصدار الرابع بروتوكول الإنترنت بتتبع الأسماء الرمزية للمعايير الرسمية، فقد حمل معيار الإصدار الرابع من بروتوكول الإنترنت الاسم الرمزي RFC 791، وتلاه مباشرةً معيار بروتوكول رسائل التحكم في الإنترنت الذي حمل الاسم الرمزي RFC 792.
. العنوان الأَصل هو: .
. يُمكن تبين العلاقة الوثيقة بين بروتوكول رسائل التحكم والإصدار السادس من بروتوكول الإنترنت بتتبع الأسماء الرمزية للمعايير الرسمية، فقد حمل المعيار الأول للإصدار السادس من بروتوكول الإنترنت الاسم RFC 1883، في حين خُصصت الوثيقة RFC 1884 للعنونة باستعمال هذا الإصدار، وتلاهما معيار بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت الذي حملت وثيقته الاسم الرمزي RFC 1885.
. كانت إدارة الازدحام من وظائف هذا البروتوكول أيضاً عند تطويره، وذلك عن طريق رسالة تهدئة المصدر. ولكن هذه الرسالة أُبطلت لاحقاً، ولم يعد البروتوكول يدعم هذه الوظيفة.
. الصدى لغةً هو الصوت المجيب من الجبل ونحوه على صوت المنادي. وفي هذا السياق، فالرسالة الأولى تمثل صوت المنادي والرسالة الثانية العائدة هي الصدى. في المعيار الأصلي، سُميت الرسالة الأولى بالصدى والثانية بالرد على الصدى ، أما عند التعريب، فقد عُكست الأسماء لتتماشى مع المعنى في العربية.
. عند تطوير هذا البروتوكول، كان الإصدار الخامس من البروتوكول تجريبياً، وكان يجري العمل على تطوير إصدار محسن منه، ظنَّ مطور البروتوكول أنه سيحمل الرقم 6، لذلك اختار الرقم 7 بشكل استباقي، ولكن العمل توقف في تطوير الإصدار الخامس ، ثم طُوِّر الإصدار السادس بشكل منفصل بعد عدة سنوات.
. انظر خيار المسار المُقيَّد بالمصدر في الإصدار الرابع من بروتوكول الإنترنت.
. بخصوص مفهوم الأحقية، انظر حقل جودة الخدمة في ترويسة الإصدار الرابع من بروتوكول الإنترنت.
. في زمن تطوير البروتوكول كانت خدمة التوقيت في الإنترنت تحت إشراف مختبرات كومسات .
. السنفور هو شخصية خيالية صغيرة الحجم، زرقاء اللون، وتعيش في غابة في أوروبة في العصور الوسطى، ابتكرها الرسام البلجيكي بيير كوليفور في العام 1958م، وسبب تسمية الهجوم هو كناية عن صغر حجم الرسائل المستعملة في هذا الهجوم مع كثرة عددها.
"الكتب "
"وثائق طلب التعليقات "
الاقتناص الفضائي أو التنزيل العشوائي هي عملية اقتناص وتنزيل عشوائي لمجموعة كبيرة جدًا من الصور والبرامج وجميع أنواع الملفات من بعض الأقمار الصناعية التي توفر خدمة الإنترنت الفضائي عن طريق كرت الساتلايت وإحدى برامج الاقتناص مثل السكاي غرابر أو السكاي نت.
برامج الاقتناص العشوائي.
يوجد عدة برامج أهمها السكاي نت والسكاي غرابر ويمكن تحديد نوع الملف وحجم الملف المراد تنزيلهما فقط ولا يمكن تحديد الاسم.
أدوات الاقتناص العشوائي.
لاجراء عملية الاقتناص يجب توفر جهاز حاسوب وكرت الساتلايت ودش موجه لأحد الأقمار المتوفر بها قنوات الداتا.
ـقمار الاقتناص العشوائي ومحطات الداتا.
من أهم اقمار الاقتناص يوتلسات w3 7.0 ويوتلسات 10.0 ويوتلسات 21.0
مخاطر الاقتناص.
بالإضافة لتنزيل الملفات يحمل أيضا عدد كبير جدًا من الفيروسات مما يشكل خطرًا على الحاسوب,وأيضًا المحتويات الإباحية من أجل تجنبها ينصح بتنقيح الملفات وإزالة علامة صح على كل من صيغ الصور والفيديوهات.
تتبع المسار برنامج إنترنت يقوم بتسجيل ورسم خط بياني للطريق المستخدم وللوقت المطلوب لحزم البيانات للانتقال من حاسب المستخدم إلى مضيف بعيد.
في الحوسبة، يُعد تتّبع المسار وترسرت tracert أمرين لتشخيص شبكة الكمبيوتر لعرض المسارات (المسارات) المحتملة وقياس تأخير عبور الحزم عبر شبكة بروتوكول الإنترنت (IP). يتم تسجيل تاريخ المسار كأوقات ذهاب وإياب للحزم المتلقاة من كل مضيف متتالي (عقدة بعيدة) في المسار (المسار)؛ مجموع متوسط الأوقات في كل قفزة هو مقياس للوقت الإجمالي الذي يقضيه في إنشاء الاتصال. يستمر مسار التتبع ما لم يتم فقد جميع الحزم المرسلة (عادة ثلاثة) أكثر من مرتين؛ ثم يتم فقد الاتصال ولا يمكن تقييم المسار. من ناحية أخرى، يحسب بينج (أمر) أوقات الرحلة النهائية فقط من نقطة الوجهة.
بالنسبة بروتوكول الإنترنت (الإصدار السادس) (IPv6)، تحمل الأداة أحيانًا اسم تتبع المسار6 وترسرت6 tracert6.
يتوفر الأمر تتبع المسار في العديد من أنظمة التشغيل الحديثة. في الأنظمة المشابهة لـ يونكس مثل فري بي إس دي وماك آو إس ولينكس، يتوفر كأداة لسطر الأوامر. يمكن الوصول إلى تتبع المسار أيضًا بيانياً في نظام ماك آو إس ضمن مجموعة أدوات الشبكة.
يوفر مايكروسوفت ويندوز ورياكت أو إس "ReactOS" برنامجًا يسمى "tracert" ترسرت يؤدي نفس وظيفة تتبع المسار. توفر أنظمة التشغيل المستندة إلى ويندوز إن تي أيضًا باثبينج "PathPing" بوظائف مماثلة. تم تطوير نسخة رياكت أو إس بواسطة جد ميرفي وتم ترخيصها بموجب رخصة جنو العمومية GPL.
في أنظمة التشغيل المشابهة لـ يونكس، يرسل تتبع المسار، افتراضيًا، سلسلة من بروتوكول حزم بيانات المستخدم (UDP)، بأرقام منافذ الوجهة تتراوح من 33434 إلى 33534؛ تتضمن تطبيقات تتبع المسار المشحونة مع لينكس، فري بي إس دي، نت بي إس دي، أوبن بي إس دي، ، وماك آو إس خيارًا لاستخدام حزم ICMP Echo Request (-I)، أو أي بروتوكول عشوائي (-P) مثل UDP أو TCP باستخدام حزم بروتوكول التحكم بالنقل أو ICMP.
في ويندوز، يرسل tracert حزم طلب ارتداد ICMP، بدلاً من إرسال تتبع حزم بروتوكول حزم بيانات المستخدم افتراضيًا.
تُستخدم تي تي إل (TTL)، والمعروفة أيضًا باسم حد القفزة، في تحديد أجهزة التوجيه الوسيطة التي يتم اجتيازها باتجاه الوجهة. يرسل تتبع المسار حزمًا بقيم تي تي إل التي تزداد تدريجيًا من حزمة إلى أخرى، بدءًا من تي تي إل بقيمة واحدة. تقلل أجهزة التوجيه قيم تي تي إل للحزم بمقدار واحد عند التوجيه وتجاهل الحزم التي وصلت قيمة تي تي إل الخاصة بها إلى الصفر، مما يعيد رسالة خطأ ICMP تجاوز وقت ICMP. بالنسبة للمجموعة الأولى من الحزم، يتلقى الموجه الأول الحزمة، ويقلل من قيمة تي تي إل ويسقط الحزمة لأنها تحتوي على قيمة تي تي إل عندئذٍ صفر. يرسل جهاز التوجيه رسالة ICMP Time Exceeded إلى المصدر. يتم إعطاء المجموعة التالية من الحزم قيمة تي تي إل من اثنين، لذلك يقوم الموجه الأول بإعادة توجيه الحزم، لكن الموجه الثاني يسقطها ويرد مع تجاوز وقت ICMP. بالمضي قدمًا بهذه الطريقة، يستخدم تتبع المسار رسائل تجاوز وقت ICMP التي تم إرجاعها لإنشاء قائمة بأجهزة التوجيه التي تعبر الحزم، حتى يتم الوصول إلى الوجهة وإرجاع رسالة ICMP Destination Unreachable إذا تم استخدام حزم بروتوكول حزم بيانات المستخدم أو رسالة ICMP Echo Reply إذا كان ICMP Echo الرسائل قيد الاستخدام.
قيم الطابع الزمني التي يتم إرجاعها لكل جهاز توجيه على طول المسار هي قيم التأخير (زمن الوصول كمون)، ويتم قياسها عادةً بالمللي ثانية لكل حزمة.
يتوقع المرسل الرد خلال عدد محدد من الثواني. إذا لم يتم التعرف على الحزمة خلال الفاصل الزمني المتوقع، يتم عرض علامة النجمة. لا يتطلب بروتوكول الإنترنت أن تسلك الحزم نفس المسار نحو وجهة معينة، وبالتالي قد يكون المضيفون المدرجون مضيفين اجتازتهم الحزم الأخرى. إذا لم يرد المضيف في hop #N، يتم تخطي القفزة في الإخراج.