html تهريب البايتات وتأطير SLIP في الاتصال التسلسلي - FCTELE
                                   +8618758069661 [email protected]
البحث عن المنتجات دليل: مسافة = AND (و)، | = OR (أو)، ! = NOT (ليس)

ماذا لو احتوت البيانات التسلسلية على علامة النهاية؟ شرح تهريب البايتات

هل لديك أي أسئلة؟ اتصل بنا اليوم!

+8618758069661

أو اترك لنا رسالة

رسالة عبر الإنترنت

ماذا لو احتوت البيانات التسلسلية على علامة النهاية؟ شرح تهريب البايتات

المشاهدات: 14 +9المحتوى الأصلي من إعداد FCTELEالمؤلف: الفريق التقني لدى FCTELE

تهريب البايتات في الاتصال التسلسلي

كيف يمكن أن يكون المحدِّد بيانات أيضًا؟

يرى المستقبل التسلسلي محارف، بينما يجب على التطبيق تحديد الرسائل. يهرّب SLIP قيمتي C0 وDB في الحمولة باستخدام تسلسلات من بايتين، بحيث تتمكن علامة END غير المُهرَّبة من تحديد حدود الحزمة. يعكس المستقبل هذا التحويل مع الحفاظ على حالته عبر عمليات القراءة. هذه القيم المحددة تخص SLIP ولا توفر تلقائيًا التحقق من الأخطاء أو الأمان.

01

المحرف مقابل الحزمة

A character boundary alone does not identify an application message.UARTMessage

حدود المحرف وحدها لا تحدد رسالة التطبيق.

02

تهريب قيم البيانات الخاصة

SLIP represents special payload bytes with two-byte sequences.C0DB DCDBDB DD

يمثل SLIP بايتات الحمولة الخاصة بتسلسلات من بايتين.

03

الاحتفاظ بالحالة

A parser must retain its escape state even when a read ends after DB.normal + DC → DCafter DB + DC → C0

يجب على المحلِّل الاحتفاظ بحالة التهريب حتى عندما تنتهي عملية قراءة بعد DB.

01 حدِّد

حدِّد نقطتي النهاية والنطاق.

02 افحص

تأكّد من البروتوكول والإعدادات الفعلية.

03 تحقَّق

اختبر باستخدام بيانات غير ضارة ومصرّح بها.

قائمة تحقق للاختيار والتحقق — توسيع

تأكد من البروتوكول وطبقة الالتقاط؛ واختبر البايتات العادية والخاصة؛ وتحقق من القراءات المجزأة والعلامات المكررة ومعالجة الأخطاء في بيئة مصرح بها.

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

جهاز تسلسلي وخادم يوضحان حدود محارف UART وحدود الرسائل
الشكل 1: رسم توضيحي عام بمساعدة الذكاء الاصطناعي، وليس بروتوكولًا لمنتج محدد.

المحارف الصحيحة لا تشكل حزمة تلقائيًا

تستخدم الواجهة التسلسلية غير المتزامنة الشائعة بت بدء وبتات بيانات وبتات توقف لتحديد المحرف. وبعد وصول المحارف إلى البرنامج، تشكل تسلسلًا من البايتات. ولا يعرف المستقبل تلقائيًا أين تبدأ قراءة درجة الحرارة وأين تنتهي. فتحديد حدود المحارف وتحديد حدود الرسائل الكاملة مسألتان منفصلتان.

يمكن لبروتوكول التطبيق استخدام طول ثابت أو حقل طول أو التوقيت أو علامات خاصة لتحديد حدود الرسائل. ولكل منها شروط ومفاضلات. تستخدم هذه المقالة SLIP، وهو مثال بسيط على التأطير التسلسلي، لشرح العلامات والتهريب. ولا تعني أن كل بروتوكول تسلسلي يستخدم SLIP أو أنه ينبغي تغيير بروتوكول قائم دون تمحيص.

يوفر خادم الأجهزة التسلسلية FCT-1100-F1S1 من Feichang، ذو المنفذ الواحد وثلاثة في واحد، سياقًا واقعيًا للربط بين الاتصال التسلسلي والشبكة. ولا تكتسب البايتات التي تُمرَّر عبر واجهة أو شبكة معنى تشغيليًا جديدًا تلقائيًا. ولا تستنتج هذه المقالة بروتوكول التأطير الداخلي للمنتج؛ راجع الوثائق والإعدادات لمعرفة إمكاناته الفعلية.

لماذا يمكن لعلامة واحدة أن تؤدي دورين؟

لنفترض أن الطرفين يتفقان على أن بايتًا معينًا يشير إلى النهاية. عند استقباله، يسلّم المحلِّل البيانات السابقة المخزنة مؤقتًا. وتشبه الفكرة علامة ترقيم تحدد نهاية الجملة. لكن المحتوى الثنائي قد يتضمن أي قيمة بايت؛ فلا توجد قيمة مختارة يُضمن تلقائيًا غيابها عن الحمولة.

قد يتضمن سجل قياس القيمة نفسها المستخدمة لعلامة النهاية. هل ينبغي للمحلِّل اعتبار هذا الظهور بيانات أم حدًا فاصلًا؟ لا تستطيع القيمة وحدها الإجابة عن السؤالين. يحتاج المرسل والمستقبل إلى قاعدة مشتركة تغيّر طريقة تمثيل القيم الخاصة على خط الاتصال.

إن مجرد حظر قيمة ما يقيّد ما يمكن للبيانات الأصلية التعبير عنه، وقد يغيّر القياسات دون تنبيه. كما أن استبدال النحاس بالألياف لا يزيل الالتباس: فالتحويل الضوئي يغيّر وسيط النقل، لا تفسير بروتوكول التطبيق. ويجب التحقق من جودة الوصلة وقواعد الترميز كلٍّ على حدة.

التهريب يغيّر التمثيل، لا البيانات

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

في مثال SLIP الموصوف في RFC 1055، تمثل القيمة الست عشرية C0 علامة END وتمثل DB علامة ESC. وتتحول C0 داخل الحمولة إلى DB DC؛ وتتحول DB داخل الحمولة إلى DB DD. أما C0 غير المُهرَّبة فتحدد حد النهاية الفعلي. وتخص هذه القيم المحددة هذا المثال، لا جميع البروتوكولات التسلسلية.

لماذا تُهرَّب DB أيضًا؟ لأنها تستدعي تفسيرًا خاصًا للبايت التالي. فإذا أُرسلت DB أصلية دون تمييز، فقد تُفهم القيمة العادية التالية خطأً على أنها لاحقة تهريب. إن حماية كلٍّ من المحدِّد وبادئة التهريب تتجنب إنشاء التباس جديد.

يرمّز SLIP القيمة C0 في الحمولة إلى DB DC والقيمة DB إلى DB DD
الشكل 2: يعرض المثال علامتي END في البداية والنهاية؛ وقد تختلف البروتوكولات الأخرى.

تتبّع مثالًا قصيرًا من المرسل إلى المستقبل

لنأخذ الحمولة الأصلية 11 C0 22 DB 33. لا يمكن وضع القيمتين الخاصتين مباشرة في التدفق المؤطَّر كمحتوى عادي. ينتج عن الترميز 11 DB DC 22 DB DD 33؛ وتحدد علامات END الفعلية حدود النتيجة ليتمكن المستقبل من التمييز بين الأدوار التحكمية والبيانات المستعادة.

يضع هذا الرسم C0 قبل الحزمة وبعدها. ويناقش RFC 1055 إرسال END في البداية كوسيلة للتخلص من الضوضاء المتراكمة؛ ويجب ألا تُسلَّم نتيجة بطول صفري ناجمة عن علامات متتالية على أنها حزمة IP عادية. ولا تستخدم البروتوكولات الأخرى بالضرورة علامات متطابقة عند الطرفين.

بعد فك الترميز، تعود C0 وDB في الحمولة إلى كونهما بيانات عادية. ولا تكون المحدِّدات نفسها جزءًا من المحتوى المُسلَّم. وقد يزيد الترميز عدد البايتات على خط الاتصال. ويمكن أن تختلف عدادات الخادم التسلسلي والبيانات الملتقطة والأطوال لدى التطبيق عند قياسها في طبقات مختلفة، دون أن يثبت ذلك فقدان البيانات.

يجب على المستقبل تذكّر حالته الحالية

لا يستطيع المحلِّل دائمًا تحديد كيفية التعامل مع كل بايت بمعزل عن غيره. ويجب عليه على الأقل التمييز بين القراءة العادية وانتظار لاحقة بعد بادئة التهريب. في الحالة العادية، تحدد END حد الحزمة؛ أما DB فتغيّر الحالة إلى انتظار اللاحقة بدلًا من إخراج DB فورًا كبيانات أصلية.

في حالة الانتظار، يطبق المستقبل التحويل المتفق عليه ويعود إلى الحالة العادية. وتحافظ حالة المحلِّل على العلاقة بين البايتين؛ وليس من الضروري أن يصلا ضمن عملية القراءة البرمجية نفسها. فإذا انتهت قراءة بـ DB وبدأت التالية بـ DC، وجب على المستقبل الاحتفاظ بالحالة وإكمال التحويل.

يحتاج التنفيذ الفعلي أيضًا إلى قواعد للواحق غير الصالحة وحدود المخزن المؤقت والحزم الفارغة والانقطاعات. ولا تفرض هذه المقالة استراتيجية موحدة لمعالجة الأخطاء. فإذا أعاد البرنامج ضبط حالة التحليل عند كل قراءة من الشبكة، أو افترض أن كل قراءة هي رسالة، فقد يفشل التأطير رغم أن وسيلة النقل سلّمت جميع البايتات.

ينتج البايت DC نتائج مختلفة بحسب حالة المستقبل
الشكل 3: مثال عام لحالة المستقبل؛ تستمر الحالة عبر عمليات القراءة.

تحديد الحدود ليس فحصًا للأخطاء ولا ضمانًا للأمان

يزيل التهريب الالتباس في التمثيل. لكنه لا يضيف تلقائيًا كشف الأخطاء أو إعادة الإرسال أو المصادقة أو التشفير. ولا يثبت تقسيم التدفق إلى حزم أن كل حزمة صحيحة أو أن مرسلها موثوق. ويوفر SLIP نفسه خدمات محدودة، ولا ينبغي التعامل معه على أنه بروتوكول أمان عام للتحكم الصناعي.

يمكن للبروتوكولات المختلفة أيضًا تطبيق الفحوص والتهريب في مراحل مختلفة. فتأطير PPP الشبيه بـ HDLC له قواعده الخاصة بعلامة الفصل وشفافية البيانات وفحص الإطار؛ وهذه التفاصيل ليست مطابقة لـ SLIP. وقد يؤدي الخلط بين قيم العلامات أو لواحق التهريب أو مراحل الفحص إلى استقبال الطرفين للبايتات دون أن يقبل أي منهما حزمة.

حدّد مواضع بيانات التطبيق الأصلية والترميز والنقل المادي أو الشبكي وفك الترميز والتحقق لدى التطبيق. وعند تقصي الأخطاء، حدد طبقة الرصد قبل مقارنة المحتوى المتوقع. فقد تؤدي المقارنة المباشرة، بايتًا ببايت، بين حركة البيانات المرمَّزة وحقول التطبيق بعد فك الترميز إلى إظهار عطل غير موجود.

تحقق من القواعد المتفق عليها باستخدام عينات صغيرة قابلة للتكرار

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

ثم اختبر القراءات المجزأة والقراءات المجمَّعة وانقطاع الاتصالات حيث يتعين على التنفيذ التعامل معها. استخدم بيانات غير ضارة في بيئة مصرح بها، ولا تستخدم بايتات الأمثلة كأوامر في بيئة الإنتاج الفعلية. وإذا كان الطرفان يستخدمان بروتوكولين مختلفين، فحدد مَن ينفذ التحويل قبل تكرار تغيير معدلات البود.

تذكّر الطبقات: تحدد UART المحارف، وتحدد قاعدة التأطير الرسائل، ويمنع التهريب الخلط بين قيم الحمولة الخاصة وعلامات التحكم. ويساعد الفصل بينها على تفسير كيف يمكن لمنفذ استقبال البايتات بينما يظل التطبيق عاجزًا عن إعادة بناء رسالة كاملة.

المراجع الأساسية

RFC 1055: SLIP، يونيو 1988، وليس معيارًا للإنترنت؛ RFC 1662: PPP ضمن تأطير شبيه بـ HDLC، يوليو 1994. سياق المنتج: خادم الأجهزة التسلسلية FCT-1100-F1S1؛ وهذا لا يعني الادعاء بأنه يستخدم SLIP.

مترجم عن المقال التقني الصيني: اقرأ المقال الصيني الأصلي.

أسئلة عملية شائعة

هل يحدد استقبال المحارف التسلسلية الحزمة تلقائيًا؟

لا. استقبال المحارف عبر UART وتأطير التطبيق أمران منفصلان؛ ويحتاج الطرفان إلى قواعد التأطير نفسها.

كيف يهرّب SLIP قيمتي C0 وDB في الحمولة؟

تتحول C0 في الحمولة إلى DB DC، وتتحول DB في الحمولة إلى DB DD؛ وتشير END غير المُهرَّبة إلى حد فاصل. وقد تستخدم البروتوكولات الأخرى قواعد مختلفة.

هل يحل تهريب البايتات محل فحوص سلامة البيانات أو التشفير؟

لا. إنه يزيل الالتباس بين علامات التحكم وقيم الحمولة؛ ولا يوفر تلقائيًا كشف الأخطاء أو إعادة الإرسال أو المصادقة أو التشفير.

النطاق وقراءات إضافية

مثال عام لتأطير SLIP، وليس ادعاءً بشأن منتج محدد أو بيانات مقاسة.

الإغلاق النصفي في TCP والردود التسلسلية · أحمال الوحدة وميزانية دائرة القيادة في RS485

مشاركة هذا المقال