یادداشت · شاهد از کپچر
یک کپچر GOOSE چه چیزی را اثبات می‌کند و چه چیزی را نه
کپچر بسته، تنها سندِ چیزی است که واقعاً از سیم گذشته. در کار پست هم همان چیزی است که بیش از همه ادعا می‌شود: خیلی‌ها «کپچر داریم» را با «نتیجه داریم» یکی می‌گیرند. این یادداشت آن دو را جدا می‌کند.
آخرین به‌روزرسانی: ۲۳ آبان ۱۴۰۵
چرا کپچر تنها شاهد است
فایل پیکربندی، نیت را ثبت می‌کند. صفحهٔ دستگاه، تفسیر را. فقط سیم، رفتار را ثبت می‌کند: بایت‌ها، به ترتیب، با زمان. برای همین هر ادعای جدی دربارهٔ شبکهٔ یک پست، سرانجام به یک کپچر می‌رسد — و برای همین ابزاری که نمی‌تواند کپچر بخواند، دربارهٔ سیستمی حرف می‌زند که آن را ندیده است.
خطا یک قدم بعد شروع می‌شود. کپچر اثبات می‌کند چیزی رخ داده؛ اثبات نمی‌کند آن چیز درست بوده، کامل بوده، یا علتش همان است که فکر می‌کنید.
کپچر GOOSE چه چیزی را اثبات می‌کند
اگر فیلد به فیلد خوانده شود، کپچر به مجموعهٔ مشخصی از پرسش‌ها بدون هیچ تفسیری جواب می‌دهد:
| پرسش | کدام بخش فریم جواب می‌دهد |
|---|---|
| پیام واقعاً منتشر شده؟ | وجود فریم، با زمان ثبت |
| کدام جریان است؟ | آدرس MAC مقصد، APPID، شناسه و اولویت VLAN |
| کدام بلوک کنترل و کدام نسخه؟ | gocbRef، datSet، confRev |
| وضعیت تازه است یا بازفرست؟ | stNum و sqNum |
| ناشر ریتم اعلام‌شده را نگه می‌دارد؟ | فاصله‌ها در برابر timeAllowedToLive |
| فریم با پیکربندی می‌خواند؟ | مقایسهٔ فیلدها با SCD، نه با حافظه |
هیچ‌کدام از این ردیف‌ها تأیید استاندارد لازم ندارد. مشاهده‌اند، و نفر دومی با همان فایل می‌تواند بازبینی‌شان کند.
کپچر چه چیزی را اثبات نمی‌کند
این فهرست مهم‌ترین بخش یادداشت است، چون هر موردش جایی به‌عنوان «با کپچر اثبات شده» ارائه شده:
- انطباق با استاندارد. کپچر یک تبادل را نشان می‌دهد، نه پایبندی به الزامات. انطباق، آزمون در برابر الزامات است، معمولاً توسط آزمایشگاه دارای اعتباربخشی.
- اینکه ناشر چرا آن را فرستاد. فریم، خروجی وضعیت داخلی‌ای است که دیده نمی‌شود؛ می‌توان استنتاج کرد، نمی‌توان دانست.
- اینکه چیز دیگری خراب نیست. کپچر یک پنجره دارد. رفتار بیرون آن دیده نشده، و «خطایی در فایل نبود» یعنی «خطایی نبود» نیست.
- اینکه پیاده‌سازی خودِ ما تعامل‌پذیر است. کپچرِ طرف مقابل، طرف مقابل را نشان می‌دهد؛ دربارهٔ اینکه encoder ما همان چیزی را می‌نویسد که او می‌پذیرد، چیزی نمی‌گوید.
- اینکه چه کسی آن را گرفته. تا وقتی فایل، نام محصول و نسخه را نگوید، بایت‌های بی‌نام است — سودمند، ولی قابل‌انتساب نه.
- هیچ چیز دربارهٔ پروتکل دیگر. زمان‌بندی GOOSE دربارهٔ نمونه‌برداری SV چیزی نمی‌گوید، و یک خواندن MMS دربارهٔ مدار قطع چیزی نمی‌گوید.
پنج چیزی که باید همراه هر کپچر ثبت شود
کپچری که این سرصفحه را ندارد، تا یک هفته تبدیل به خاطره می‌شود. سرصفحه پنج دقیقه وقت می‌خواهد:
| فیلد | چرا مهم است |
|---|---|
| چه کسی گرفته | نام محصول و نسخه؛ «یک رله» منبع نیست |
| چه زمانی و چه مدت | پنجرهٔ ثبت، بخشی از شاهد است |
| چطور گرفته شده | پورت میرور، TAP یا کپچر روی هاست — هر کدام نقطهٔ کور دارند |
| منبع ساعت | زمان‌ها فقط با ساعت معلوم قابل مقایسه‌اند |
| قرار بود چه اتفاقی بیفتد | نیت آزمون، تا «قبول» تعریف داشته باشد |
کپچر ناشناس‌شده هم شاهد است. کپچر بی‌سرصفحه، یک شنیده با checksum است.
همان موردی که روش آزمون ما را عوض کرد
در پروژه‌ای که این یادداشت از آن می‌آید، آزمون‌های پروتکل متقارن بودند: encoder ما بایت می‌ساخت، decoder ما همان را می‌خواند و آزمون سبز می‌شد. پنج نقص سیم‌فرمت از این چیدمان جان سالم بردند، چون هر دو طرف یک اشتباه مشترک داشتند.
| نقص | آزمون متقارن چه می‌گفت | بایت غریبه چه نشان داد |
|---|---|---|
| شناسه به‌جای VisibleString با OCTET STRING نوشته می‌شد | سبز | طرف منطبق نوع دیگری می‌خواند |
| آزادسازی با تگ‌های اشتباه | سبز | آزادسازی بی‌صدا شکست می‌خورد |
| تگ‌های سرویس فهرست نام‌ها یکی بالاتر | سبز | درخواست شناخته نمی‌شود |
| خواندن مشخصات دسترسی از فیلد اشتباه | سبز | فهرست خالی، بدون خطا |
| رد شدن لایه‌های Session/Presentation/ACSE | سبز | هیچ پیوندی برقرار نمی‌شود |
درس، «آزمون بیشتر بنویس» نیست. درس این است که آزمونی که از خروجی یک پیاده‌سازی نوشته شود، اشتباه همان پیاده‌سازی را پیدا نمی‌کند. راه‌حل، بستن assertion روی بایت‌های یک پیاده‌سازی دیگر بود.
چطور یک کپچر به شاهد تبدیل می‌شود
چهار قاعده، به ترتیب. اگر یکی جا بیفتد، شاهد ضعیف می‌شود:
- assertion باید پیش از اصلاح شکست بخورد. وگرنه رفتار فعلی را توصیف کرده‌اید، نه نقص را پیدا.
- بایتی که رویش assertion نوشته می‌شود باید از پیاده‌سازی دیگری باشد. خروجی خودتان آزمون رگرسیون است، نه شاهد.
- فایل هش می‌شود و می‌ماند. نتیجه‌ای که نتوان دوباره روی همان بایت‌ها اجرا کرد، خاطره است.
- محدودیت‌ها نوشته می‌شوند. آنچه کپچر پوشش نمی‌دهد، باید کنار آنچه پوشش می‌دهد بیاید.
در عمل چه معنایی دارد
برای مهندس: وقتی کسی کپچر را دستتان می‌دهد، پیش از تحلیل، سرصفحه‌اش را بخواهید. برای فروشنده: اگر صفحه‌ای ادعای تعامل‌پذیری می‌کند، بپرسید با کدام طرف، کدام نسخه، و اینکه آیا آن طرف هرگز درخواست شما را پذیرفته است. جواب معمولاً کوتاه‌تر از صفحه است.
در ابزاری که در همین سایت معرفی شده، این موضع عمدی و ناراحت‌کننده است: کپچرِ طرف مقابل، اثبات اینکه درخواست‌های خودِ ما پذیرفته می‌شوند نیست. برای همین ادعای تعامل‌پذیری هنوز باز است و صفحهٔ شواهد همان را با کلمات ساده می‌نویسد.
کپچر، شاهد یک لحظه است، نه حکم دربارهٔ یک سامانه. تفاوت همین دو، کل انضباط کار است.