«اولین پیامی که از طریق اینترنت ارسال شد «LO» بود»

اصل ماجرا

در ۲۹ اکتبر ۱۹۶۹، چارلی کلین در آزمایشگاه UCLA سعی کرد با تایپ LOGIN به سرور استنفورد وصل شود. پس از ارسال «L» و «O»، سیستم مقصد خراب شد و پیام «LO» اولین بسته ارسالی بر روی ARPANET شد. این شکست اولیه نشان داد که شبکه‌ها باید برای قطع‌اتصالات و خطاهای میانی آماده باشند.

متن کامل ترجمه‌شده

اولین پیام هرگز از طریق شبکه ای که به اینترنت تبدیل شد، “سلام، جهان” نبود. این یک اعلامیه بزرگ نبود. این دو نامه بود که قبل از سقوط سیستم به صورت تصادفی ارسال شد: LO. این بسته دو نامه پیشگام هر دستگاه متصل شده، هر سنسور IoT و هر درخواست وب است که امروز اجرا می شود. داستان چگونگی آن اتفاق افتاد همچنین یک درس مفید برای هر کس است که در حال حاضر سیستم های متصل شده و دستگاه های متصل شده را بسازد. آنچه در واقع در 29 اکتبر 1969 در شب 29 اکتبر 1969 اتفاق افتاد، یک برنامه نویسی به نام چارلی کلین در یک پایان نامه در آزمایشگاه لیونارد کلینروک در UCLA نشسته بود. کار او در کاغذ ساده بود: به یک کامپیوتر دورانی در موسسه تحقیق استنفورد (SRI)، حدود 350 مایل دور، بر روی یک شبکه تجربیاو یک همکار در تلفن در پایان استنفورد برای تایید هر نامه رسید. او وارد L. استنفورد تایید: “Got the L.” او وارد O. استنفورد تایید: “Got the O.” او وارد G - و سیستم SRI سقوط کرد. بنابراین اولین پیام هرگز ارسال شده از طریق ARPANET “LO” بود. همانطور که Kleinrock بعدا دوست داشت به ذکر, آن را یک تصادفی اما مناسب اولین کلمه: “LO” به عنوان در “lo و ببینید.” حدود یک ساعت بعد آنها اشتباه را اصلاح کرده و کامل ثبت نام کامل، اما اولین بسته تاریخی در حال حاضر خارج شده بود، دو نامه در یک زمان. چرا یک تصادف داستان اصلی کامل است آن را به عنوان یک یادداشت زیبا خواندن شگفت انگیز است. آن را بیشتر از آن است. اولین چیزی که اینترنت هرگز انجام داد در بخشی از یک معامله - و سیستم به اندازه کافی ساختهبسته ها به طور ناگهانی می آیند یا نه. شبکه هایی که ما بر روی فرزندان ARPANET ساخته ایم، این شکستها را حذف نکردند؛ آنها یاد گرفتند که آنها را منتظر بمانند و به صورت مهربان بازگردانند. اگر تا به حال نرم افزار نصب شده برای یک دستگاه متصل شده نوشته اید، شما این را در استخوان های خود می دانید. راه خوشبخت - جایی که Wi-Fi ثابت است، بروکر بالاست و هر پیام شناخته می شود - 20 درصد آسان است. کار واقعی 80 درصد دیگر است: وقتگذاری، بازگرداندن، بازخورد عمیق و عملیات idempotent که می تواند یک لحظه “LO” بدون وضعیت فاسد زنده بماند. این برای سازندگان IoT امروز چه معنایی دارد. هر محصول متصل قوی، به معنای طولانی، پاسخ به سوالی است که در سال 1969 مطرححافظه محلی، تأیید تحویل، و بازگرداندن به طور ایمن برای تکرار. - ایجاد شکست ناپذیر. تیم 1969 موفق به جزئیات زیرا آنها می توانستند “Got the L, got the O” را ببینند. تلسمی خوب و ثبت نام در یک دستگاه در حال توسعه است معادل مدرن - شما نمی توانید آنچه که شما نمی بینید را اصلاح کنید. - شناخت، سپس عمل کنید. پروتکل هایی مانند MQTT وجود دارد دقیقا به این دلیل است که آتش و فراموش کردن برای دستگاه ها در زمینه کافی نیست. سطح کیفیت خدمات فقط یک نسخه رسمی از “بگو به من شما O” است. زاویه فیلیپین برای تیم های ساخت IoT در اینجا در فیلیپین - آیا این یک شبکه سنسور کشاورزی در استان ها یا یک پروتکل تئوری در یک دانشگاه مترو مانیل است - این اعتماد به ذهنیک محصول متصل است که فرض می کند یک لینک کامل به خوبی در بانک کار می کند و در زمینه شکست می کند. یکی که در اطراف واقعیت “LO” طراحی شده است - انتظار معامله نیمه تمام شده و از آن بهبود می یابد - یکی است که از توسعه واقعی زنده می ماند. این جدایی بین “کار در آزمایشگاه” و “کار در جهان” دقیقا جایی است که ما زمان خود را صرف می کنیم. اگر شما یک ایده نرم افزار متصل را به چیزی تبدیل می کنید که باید بدون نظارت اجرا شود، بگذارید در مورد ساخت خود صحبت کنیم. اینترنت با سقوط آغاز شد. محصول شما مجبور نیست.

چرا مهمه؟

اولین پیام اینترنتی به‌صورت نیمه‌کامل قطع شد؛ این نشان داد که هر ارتباطی ممکن است در میانه‌اش از کار بیفتد. مهندسان سخت‌افزارهای متصل و توسعه‌دهندگان IoT تحت تأثیر این واقعیت قرار می‌گیرند، چون محصولشان باید بدون قطع کامل کار کند. خواننده باید به این خبر اهمیت بدهد چون اصولی که از این حادثه استخراج شد، پایه‌گذار روش‌های بازگشت‌پذیری، ثبت لاگ و تایید دریافت در سامانه‌های امروز است.

به درد کی می‌خوره؟

• مهندسان سخت‌افزارهای متصل • توسعه‌دهندگان IoT • طراحان firmware • مدیران پروژه‌های فناوری اطلاعات

تو عمل چی کار کنیم؟

با خواندن این خبر، می‌توانید طراحی محصول خود را به‌گونه‌ای تنظیم کنید که در صورت قطع Wi‑Fi یا سقوط سرور، پیام‌ها در حافظه محلی ذخیره شوند و پس از بازگشت اتصال دوباره ارسال شوند. همچنین می‌توانید لاگ‌گیری دقیق‌تری برای تشخیص نقطه شکست پیاده کنید و از پروتکل‌های تأیید دریافت مثل MQTT استفاده کنید.

نظر Blue IT News

پیشنهاد ما این است که قبل از انتشار محصول، تست‌های استرس شبکه را در شرایط واقعی انجام دهید؛ این کار جلوی مشکلات «LO» در میدانی را می‌گیرد.