« فصل سوم فصل پنجم »

فصل چهارم

۴- سرازیر شدن در بیت‌ها

روز سال نو ۱۹۶۹، آخرین باری بود که گروه فرانک هارت توانست برای مدتی استراحت کند. هفته بعد، قرارداد ساخت اولین پردازنده پیام رابط رسما آغاز شد. با کمی بیش از ۱ میلیون دلار، BBN چهار IMP می‌ساخت. اولین مورد در UCLA و در روز کارگر و پس از آن هر ماه تا دسامبر یکی ساخته می‌شد. قرار بود در دوازده ماه شبکه با چهار پایگاه آنلاین راه اندازی و بالا بیاید. تیم BBN قبلا کارهای زیادی در ارائه این طرح تحقیقاتی انجام داده بود. اکنون که به آینده نگاه می‌کردند، حداقل هشت ماه دیگر شب بیداری و کار فشرده مهندسی را می‌دیدند. هنوز چالش‌های ناشناخته بسیاری وجود داشت، نکته‌ای که توسط BBN در طرح‌شان تاکید شده بود. علاوه بر این، اعضای تیم هارت هر کدام ایده‌های متفاوتی در مورد دشواری ساخت IMP داشتند.

هارت با تعداد زیادی از افراد بدبین مواجه شد (اغلب کارکنان شرکت تلفن و دانشگاهیان) که باور نداشتند یک شبکه سوئیچینگ بسته کار کند. آنها استدلال می‌کردند که ساخت سخت‌افزار قسمت سخت کار نیست بلکه در عوض، ساختن همه اینها با هم (بخش سیستم) پیچیده خواهد بود. برخی معتقد بودند، حتی اگر بتوانید تمام سخت‌افزار و نرم‌افزار را ادغام کنید و امکان‌پذیری یک شبکه کامپیوتری را نشان دهید، باز هم هیچ سودی برای شرکتی مانند AT&T یا IBM به عنوان یک پیشنهاد تجاری، وجود ندارد. چه کسی جز چند کارمند دولتی یا دانشمند کامپیوتر از شبکه کامپیوتری استفاده خواهد کرد؟ محاسبات بازار انبوهی مانند شبکه‌های تلویزیونی یا شرکت تلفن نداشت. در طول هفته‌های قبل از برنده شدن در مناقصه، بزرگترین شک BBN این بود که آیا آرپا این کار را به چنین شرکت کوچکی واگذار می‌کند یا خیر. اعضای تیم BBN می‌دانستند که اکنون چیزهای زیادی روی دوش آنها سوار است. اگر IMPها کار نمی‌کردند، شبکه‌سازی و سوئیچینگ بسته‌ها در معرض فراموشی آزمایش‌های ناموفق قرار می‌گرفت. برخی از مردم (اکثرا سایر مناقصه گران) از اینکه BBN کوچک این قرارداد را برنده شده است ابراز شگفتی کردند. یکی از رقبا می‌گوید: ((به نظر نمی‌رسید که همچین کار بزرگی به عهده BBN قرار بگیرد.))

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

مورد بعدی قطعی مدار بود، به‌ویژه آنطور که آرپا تصور می‌کرد، آزمایش با چهار نود شروع و در کل قاره گسترش می‌یافت. یک نقطه آب و هوایی بد، یک طوفان و رعد و برق در غرب میانه یا یک کولاک در نیوانگلند باعث از بین رفتن خدمات در یک خط تلفن که ترافیک داده شبکه را حمل می‌کرد، می‌شد. وقفه‌های مختصر در سرویس قابل جلوگیری نبود و باید توسط IMPها رسیدگی می‌شد. علاوه بر آن، در بهترین شرایط، ماتریس بسیار پیچیده‌ای از مشکلات مسیریابی وجود داشت که باید حل شوند. تیم هارت باید از گردش بی‌پایان پیام‌ها (پیام از نودی به نود دیگر بدون رسیدن به مقصد نهایی خود پیش برود) در شبکه جلوگیری می‌کرد. در نهایت، تیم باید امکان پارازیت در بافرهای حافظه را نیز در نظر می‌گرفت. پیام‌ها می‌توانستند حداکثر ۸۰۰۰ بیت باشند. IMPها قرار بود چنین پیام‌هایی را به دنباله‌ای از بسته‌ها با حداکثر اندازه ۱۰۰۰ بیت تقسیم کنند. یک بسته شامل حدود ۱۲۵ کلمه می‌شد.

سیستم باید بسته‌ها و پیام‌ها را در مدت زمانی که رابرتز تعیین کرده بود تحویل می‌داد (نیم ثانیه برای ارسال پیام از هر مبدا به مقصد از طریق زیرشبکه IMP.) این به معنای پردازش داده‌ها با سرعتی در حدود صد پیام در ثانیه بود، که مطمئنا امکان پذیر بود، اگرچه همگام سازی همه چیز باهم دشوار خواهد بود.

گویی چالش‌های فنی کافی نبودند، برنامه زمان‌بندی پروژه شبکه آرپا به شدت سریع بود؛ برنامه تعیین شده توسط رابرتز با چرخه بودجه و مسائل سیاسی پیش روی او در واشنگتن، گره خورده بود. هشت ماه برای کسی کافی نبود تا بتواند شبکه‌ای عالی بسازد. همه آن را می‌دانستند. اما کار BBN محدود به این بود که نشان دهد، مفهوم شبکه می‌تواند کار کند. هارت به اندازه کافی تجربه داشت که بداند برای انجام هر کاری به این بزرگی و به موقع، سازش لازم است. با این حال، تنش بین کمال گرایی هارت و میل او برای رسیدن به ددلاین تعیین شده، همیشه همراه او بود و گاهی برای دیگران به صورت یک تناقض آشکار و حل نشده نمایان می‌شد.

BBN با مسائل بیشمار دیگری نیز روبرو شد که دیگر مناقصه‌گران را از رقابت خارج کرده بود و حالا تمام این مشکلات متعلق به فرانک هارت بود.

شروع شدن

باب کان گفت: ((این که وقتی یک سیم را به پریز دیوار وصل می‌کنید، الکترون‌ها جریان می‌یابند، یک چیز است ولی اینکه بفهمی هر الکترون چه جهتی می‌گیرد، چیز دیگری است.)) طبق نظر کان، این خلاصه‌ای از دشواری ساخت شبکه‌ای بود که باید به صورت پویا، بسته‌های بیت‌ها را سوئیچ کند. کان اطلاعات کمی در مورد طراحی سخت‌افزارها داشت. او دانشمندی بود که عمدتا روی مفاهیم طراحی سیستم و معماری آن کار کرده بود. از آنجایی که او روی جنبه‌های مفهومی، کمی عمیق‌تر از همکارانش، فکر کرده بود، بیشتر نگران پیچیدگی ساخت شبکه بود. در نظر کان، این شبکه بیشتر یک موجود کامل و انتزاعی بود تا برای سایر اعضای تیم که در برنامه‌نویسی و سیم‌کشی واقعی بخش‌های مختلف آن مشغول بودند.

مفهوم سوئیچینگ بسته، درهای جهانی غنی را باز کرد که در آن یک مهندس نظری و آموزش دیده مانند کان می‌توانست طیف وسیعی از سناریوهای فرضی را بررسی کند. تحلیل‌های کان به شکل‌گیری پروژه شبکه آرپا کمک کرده بود. کان به طور آزادانه برای لری رابرتز ایده‌هایی ارائه کرده بود و از او خواسته بود تا آزمایش شبکه آرپا را در مقیاس وسیع با استفاده از خطوط راه دور تلفن، راه اندازی کند. بقیه افراد نظرشان این بود که یک آزمایش در مقیاس کوچک برای شروع خوب است، اما کان نگران این بود که از یک آزمایش کوچک، هیچ چیز معنا داری نمی‌توان آموخت. رابرتز موافقت کرد و تصمیم به ساخت یک شبکه کشوری با حداقل نوزده نود گرفت.

اگر بخواهید، به حتم می‌توانید یک شبکه آزمایشگاهی بسازید. در این زمان، بالاخره به دونالد دیویس اجازه داده شد و مقداری بودجه برای انجام این کار در آزمایشگاه ملی فیزیک لندن، با استفاده از خطوط کوتاه، حداکثر صد یارد(معادل تقریبا ۹۲ متر)، به دست آورد. کان مطمئن بود که یک آزمایش شبکه کوچک، حداقل از نظر عملی، نمی‌تواند چیزی را نشان دهد. او استدلال کرد که لینک‌های کوتاه در یک آزمایشگاه هیچ وقت، همان نرخ خطا و مشکلات دنیای واقعی را مانند خطوط طولانی مورد استفاده در سیستم تلفن، ندارند. هدف نهایی کار این بود که دانشمندان کامپیوتر و در نهایت سایر کاربران کامپیوتر در سراسر کشور را به هم پیوند بزنند. بنابراین یک شبکه واقعی باید هزاران مایل را پوشش می‌داد و باید طوری طراحی می‌شد که بتواند بسته‌ها را مدیریت کند و خطاهای خطوط تلفن را خنثی کند و تمام این‌ها باید با سرعتی بسیار بالاتر از یک شبکه کوچک انجام می‌شد.

به نظر می‌رسید رابرتز به قضاوت کان اعتماد داشت. قبل از اینکه درخواست طرح تحقیقاتی به طور علنی مطرح شود و BBN وارد مناقصه شود، این دو مرد گهگاه با هم صحبت می‌کردند. هنگامی که کان برای مشارکت در تلاش BBN استخدام شد، او شبانه روز تا ساعات اولیه صبح، گهگاه در اتاق نشیمن سورو اورنشتاین کار می‌کرد و به طراحی سیستم برای طرح BBN کمک می‌کرد. کار نتیجه داد، BBN برنده قرارداد شد و کان از قبل تصمیم گرفته بود پس از کریسمس به کار تحقیقاتی خود بازگردد.

اما با فرا رسیدن سال جدید، کان فکر دیگری به ذهنش رسید. مسائل فنی پیچیده بود. شاید او باید برای اجرا پروژه می‌ماند. ضرری که نداشت. علاوه بر این، کان مشتاق بود تا در مورد جنبه سخت‌افزاری چیزها از اورنشتاین اطلاعات بیشتری کسب کند.

جری الکیند، مردی که هم هارت و هم کان به او گزارش می‌دادند، از کان خواست تا به گروه IMP بپیوندد، زیرا هارت اکنون یک قرارداد در BBN دارد که به طور خاص به شبکه اختصاص داده شده است. اگرچه او همچنان به الکیند گزارش می‌داد، اما تصمیم گرفت به گروه سیستم‌های هارت برود. به زودی خودش را در حالی دید که وسایلش را برمی‌دارد و از روی پل بین دو بخش BBN رد می‌شود و از پناهگاه علمی بولت می‌گذرد و وارد انبار بازسازی شده‌ای می‌شود، که گروهی از مردان جوان که اکنون خود را (( بچه‌های IMP IMP Guys )) می‌نامیدند، به سختی مشغول بودند. (مطابق با هنجارهای آن زمان، به استثنای منشی هارت، افرادی که شبکه آرپا را طراحی و ساختند، همگی مرد بودند. تعداد کمی از زنان در علوم کامپیوتر کار می‌کردند. همچنین همسر هارت، جین، شغل برنامه‌نویسی خود را برای بزرگ کردن سه فرزندشان ترک کرده بود.)

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

اکنون کارکرد مهم بود، نه ظرافت یا زیبایی. برخلاف مثلا ساعت‌سازان خوب سوئیسی، که مهندسی و هنرشان در یک ساعت ۴۰,۰۰۰ دلاری جدایی ناپذیر است، تیم هارت به طور کامل هنر را از صنعت ساخت یک کامپیوتر قابل اعتماد جدا کرده بودند. با نگاه کردن به بخش‌ها، مهندسان کمتری را می‌دیدید که سعی کنند با استفاده از هنر یا خلق چیزهای پر ظرافت، خودنمایی کنند. قدرت درونی تیم هارت، تسلط بر خود و پختگی آنها بود. اینجا جایی برای امضاهای هنری نبود. والدن، اولین برنامه‌نویسی که هارت استخدام کرد، گفت: ((بی‌شمار راه برای اشتباه کردن وجود داشت، و تعداد مشخصی راه درست. وظیفه یک مهندس خوب پیدا کردن یکی از آن راه‌های درست است.))

سیستم‌های راداری بلادرنگ، سیستم‌های تشخیص لرزه‌ای آزمایش‌های بمب اتمی و زلزله‌ها، و سیستم‌های دیگری که هارت، اورنشتاین، کروتر و والدن روی آنها در آزمایشگاه لینکلن کار کرده بودند، همگی‌شان پیچیده‌تر از IMP بودند. سال‌ها بعد، برخی از مردم احتمالا می‌گویند که IMP چیزی جز یک دستگاه ورودی-خروجی بزرگ و بسیار ساده نبوده. برای کاربر، IMP باید به سادگی یک پریز برق یا یک کلید دیواری باشد که بدون جلب توجه کار خود را انجام می‌دهد. و چالش کار دقیقا همین بود؛ ساخت IMP با عملکرد خوب و بدون مزاحمت مانند یک پریز یا سوئیچ خانگی.

تیم نرم‌افزار از زمان شروع طرح تحقیقاتی، همکاری نزدیکی با هم داشتند. هر یک از اعضا نقش خاصی داشتند. کروتر روی ارتباطات IMP-به-IMP، والدن روی مسائل IMP-به-میزبان و کوسل روی ابزارهای توسعه و دیباگ کار می‌کرد.

ویلی کروتر سی و دو ساله، ساکت اما متفکر، روح تیم بود. در چند هفته اول سال ۱۹۶۹، کروتر مدت زیادی را از چارچوب دفترش آویزان بود. همه اطرافیان او، این رفتار را به عنوان روشی برای تمرکز کردن ویلی پذیرفته بودند. این به تقویت دستان او برای صخره نوردی کمک می‌کرد، اما به نظر می‌رسید که بیشتر از آن، به فکر کردن او کمک می‌کند. سبک کروتر برای باقی اعضای تیم شناخته شده بود؛ روزها به نظر می‌رسید که او هیچ کاری نمی‌کند یا فقط بارفیکس می‌رود اما در نهایت مانند سیلی از کلمات، هر چیزی را که در ذهنش شکل می‌گرفت، روی کاغذ می‌آورد.

اگر کروتر و همکارانش در مورد برنامه‌نویسی و طراحی نرم‌افزار خود مطمئن بودند، اورنشتاین نیز به همان اندازه در مورد کارهای سخت‌افزاری مطمئن بود. او مسئول طراحی دستگاه‌های ورودی-خروجی پرسرعت بود که BBN قصد داشت آن‌ها را به هانیول ۵۱۶اضافه کند. تلاش قابل توجهی که او از قبل برای تهیه پیش‌نویس انجام داده بود، او را جلو انداخت. پس از انجام تنها چند اصلاح و کارهای تکمیلی، تیم آماده بود تا وارد مراحل ساخت سخت‌افزار و برنامه‌نویسی پروژه شود. اولین وظیفه اورنشتاین این بود که طراحی سخت‌افزار را به نقطه‌ای برساند که بتواند با مجموعه‌ای از تغییرات دقیق در ۵۱۶ به شرکت هانیول برود. پس از آن، هانیول شروع به ساخت دستگاه‌های ورودی-خروجی تخصصی مورد نیاز IMP برای برقراری ارتباط با میزبان‌ها و سایر IMPها می‌کرد.

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

تا شروع فوریه، BBN قرارداد خود را با هانیول برای خرید DDP-516 منعقد کرد. ظرف چند روز، هانیول اولین کامپیوتر ۵۱۶ را در اتاقی در مجتمع خیابان مولتون BBN تحویل و نصب کرد. این دستگاه نسخه اصلاح‌شده و نظامی سفارشی نبود، بلکه یک ۵۱۶ وانیلی رنگ ساده بود. یک دستگاه تستی بود که برنامه‌نویسان هنگام کار، می‌توانستند آن را آزمایش کنند. برنامه نویسان معمولا مایل نیستند (یا نمی‌توانند) تا زمانی که سخت‌افزار اصلی در دسترس نباشد، برای یک رایانه خاص کدنویسی کنند. اورنشتاین به تازگی فرآیند کار روی جزئیات نهایی رابط‌های ورودی-خروجی تخصصی را آغاز کرده بود. شاید هفته‌ها طول بکشد تا هانیول بتواند آن رابط‌ها را برای انجام آزمایش‌ها در دسترس آنها قرار دهد.

مانند تقریبا همه رایانه‌های هم عصر خود، دستگاه هانیول هیچ دیسکی نداشت؛ نه هارد و نه فلاپی (فلاپی‌ها هنوز اختراع نشده بودند) بلکه از حافظه هسته مغناطیسی Magnetic-core memory استفاده می‌کرد؛ ماتریس متراکمی از سیم‌های مسی نازک به ضخامت تار مو و حلقه‌ها یا هسته‌های فریت مغناطیسی که هر کدام به اندازه یک دانه خردل است. اندازه کل حافظه سفارش داده شده (۱۲کیلوبایت) با استانداردهای امروزی بسیار ناچیز بود. مقدار حافظه یک کامپیوتر رومیزی اواسط دهه ۱۹۹۰، اگر قرار بود از هسته‌های فریت تشکیل شود، تقریبا به اندازه یک زمین فوتبال مساحت اشغال می‌کرد.

یکی از مزیت‌های جالب حافظه هسته مغناطیسی، ماهیت غیرفرار آن است. اگر در میانه کار روی چیزی، دستگاه را خاموش می‌کردید، اطلاعات خود را از دست نمی‌دادید و دوباره از همان جایی که متوقف شده بود به کار خود ادامه می‌داد. تیم هارت یک ویژگی راه اندازی مجدد خودکار نیز طراحی کرد؛ اگر برق قطع بشود و دستگاه به طور کامل متوقف می‌شد. به کمک حافظه هسته مغناطیسی، با وصل شدن برق دستگاه مجددا راه اندازی می‌شد. تنها زمانی نیاز به بارگذاری مجدد برنامه بود که نسخه جدیدی از برنامه منتشر شود یا برخی از اشکالات سخت‌افزاری یا نرم‌افزاری باعث بازنویسی حافظه شود. در این موارد، برنامه IMP از طریق نوارخوان paper tape reader (دستگاهی الکترومکانیکی که نور را از یک لامپ رشته‌ای به نوار کاغذی‌ای که روی خطی از فوتوسل‌ها کشیده می‌شود، می‌تاباند) بارگذاری مجدد می‌شود. IMP اقدامات دیگری نیز برای کنترل اتوماتیک داشت که یکی از آنها تایمر ((watchdog)) نام داشت. هارت توضیح داد، ((اگر برنامه هنگ کند))، یک تایمر کوچک در دستگاه به صفر می‌رسد (اما یک برنامه سالم به طور مداوم آن را ریست می‌کند). اگر تایمر به صفر برسد، فرض بر این است که IMP به مشکل خورده است. سپس یک رله، نوارخوان را روشن می‌کند، مدتی به آن زمان می‌دهد تا گرم شود و سپس برنامه را دوباره راه اندازی می‌کند. BBN هر دستگاه را با یک کپی از نوار ارسال می‌کرد که سه نسخه از کل برنامه عملیاتی IMP را پشت سرهم روی خودش داشت و به هر IMP این فرصت را می‌داد تا قبل از اینکه نیاز باشد اپراتور دوباره نوار را بپیچد، سه بار خودکار، مجدد راه اندازی شود. بعدا، طرحی مبتکرانه‌تر توسط BBN ابداع شد تا IMP‌های به مشکل خورده را از نزدیک‌ترین همسایه، ریست کند و سیستم از نو شروع به کار کند. در آن زمان، اینها همه ویژگی‌هایی غیرعادی بودند.

بچه‌های IMP شروع به نوشتن کد کردند، و با حدود شش هزار کلمه به پایان رسید. به قول هارت: ((یک برنامه کوچولو.)) آنها تمام برنامه‌نویسی خود را به زبان ((اسمبلی)) هانیول ۵۱۶ انجام دادند.

رایانه‌ها مکانیسم‌هایی هستند که تنها دستورالعمل‌ها را دنبال می‌کنند. برنامه‌نویسی به زبان اسمبلی مستلزم تفکر در تعداد زیادی از قدم‌های کوچک و سپس نوشتن دستورالعمل برای اجرای آنها است. به عنوان مثال، فرض کنید می‌خواهید آسانسور را پیدا کنید. در یک زبان سطح بالا، احتمالا مجموعه دستورالعمل‌های شما، چیزی شبیه به این باشد: ((از در بیرون بروید، به راست بپیچید، از کنار آبنما عبور کنید، اکنون آسانسور در سمت چپ شما است.))

معادل آن در زبان اسمبلی به همچین چیزی شبیه است: ((پای چپ خود را پیدا کنید. پای راستت را پیدا کن. پای چپ خود را جلوی پای راست خود قرار دهید. حالا پای راست خود را در مقابل پای چپ قرار دهید. این کار را ده بار تکرار کنید. متوقف شدن. نود درجه به راست بپیچید و….))

برنامه‌نویسی به زبان اسمبلی یعنی تمرکز دیوانه وار روی مکانیسم‌ها. برنامه نویسان به سادگی از هدف اصلی منحرف می‌شدند و نوشتن برنامه‌های کوتاه و اقتصادی دشوار بود. کد برنامه نویسان ناوارد اغلب بی‌هدف و سرگردان پایان می‌یافت، مانند حرکت در یک کولاک در قطب شمال.

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

نوشتن نرم‌افزار IMP در دفاتر اعضای تیم برنامه‌نویسی آغاز شد، جایی که هر کدام کد را روی یک تله تایپ مدل۳۳، ​​در یک ((ویرایشگر)) PDP-1 تایپ می‌کردند. پس از ایجاد کد در PDP-1، کد از طریق نوار کاغذی به کامپیوتر هانیول منتقل می‌شد و در آنجا توسط برنامه‌ای به نام اسمبلر، به صفر و یک‌هایی تبدیل می‌شد که هانیول۵۱۶ آنها را می‌فهمید. برای مدتی برنامه نویسان سعی کردند از اسمبلری که با هانیول ۵۱۶ عرضه شده بود استفاده کنند، اما آنقدر ناکارآمد بود که به زودی آن را کنار گذاشتند؛ والدن و کوسل در یک آخر هفته چهارده ساعت را صرف کد اسمبلی سیستم IMP کردند، و تقریبا از نیم مایل(۸۰۵ متر) نوار استفاده کردند.

اندکی پس از آن، کوسل اسمبلر بهتری را روی کامپیوتر PDP-1 موجود در انتهای سالن BBN، نوشت. و این امکان را برای PDP-1 فراهم کرد تا نوارهایی به زبان ماشین را برای هانیول۵۱۶ تولید کند. از آن زمان به بعد، نوشتن و ویرایش کد IMP تحت سیستم اشتراک زمانی PDP-1 انجام می‌شد. زمانی که برنامه نویس از فرآیند برنامه راضی بود، به PDP-1 دستور می‌داد تا کد را روی یک نوار کاغذی پانچ کند، سپس نوار را به آزمایشگاهی که ۵۱۶ در آن قرار داشت، می‌برد. او نوار را در ۵۱۶ قرار می‌داد، آن را اجرا می‌کرد و منتظر می‌ماند تا نتیجه را ببیند. معمولا هر برنامه‌ای یکسری باگ‌ها داشت بنابراین این روند تکرار می‌شد. به طور معمول، هنگامی که یکی از برنامه نویسان با اجرای یک کد جدید روی ۵۱۶، اتفاق جالب یا عجیبی را مشاهده می‌کرد، اعضای تیم به سمت این اتفاق جذب می‌شدند و در اطراف هانیول می‌ایستادند و درباره آن صحبت می‌کردند.

اکثر بچه‌های IMP در نزدیکی کمبریج زندگی می‌کردند و رفت و آمد به آزمایشگاه در هر ساعت برای آنان آسان بود. رستوران چینی سرآشپز جویس چن Joyce Chen در مجاورت BBN قرار داشت و برای زمانی که اعضای تیم تا دیروقت کار می‌کردند، که اغلب همینطور بود، به کار می‌آمد. کوسل و والدن مقدار زیادی کوکاکولا می‌نوشیدند تا بتوانند ادامه دهند. کروتر هرگز به این خوراکی‌ها دست هم نمی‌زد. او در سختگیری غذایی معروف بود (گذاشتن هر چیزی فراتر از یک ساندویچ ساده جلوی او، ریسک بود) که او را به یک مهمان شام دشوار تبدیل می‌کرد.

در اوایل پروژه، از BBN خواسته شد تا گزارشی مختصر به گروهی از آرپا و پرسنل نظامی سطح بالا در پنتاگون، ارائه کند. کروتر از جمله کسانی بود که قرار بود از طرف بچه‌های IMP این کار را انجام دهد. هارت تنها با فکر کردن به اینکه کروتر در این جلسه، چه خواهد پوشید، عصبی شده بود. هارت با خودش فکر می‌کرد که مردم مطمئنا متوجه پاهای او می‌شوند. تنها زمانی که کسی می‌تواند به یاد داشته باشد که کروتر کفش‌هایی پوشید که می‌توانست آن‌ها را برق بیندازد، روز ازدواجش بود. هارت نزد اورنشتاین رفت و از او خواست که به کروتر بگوید در پنتاگون کتانی نپوشد. اورنشتاین نیز انجام داد.

- ویلی، فرانک می‌گوید در این جلسه بهتر است کفش‌های کتانی‌ات را نپوشی.

سکوتی طولانی در انتهای خط حاکم بود. و سپس صدای آرام کروتر.

- به فرانک بگو قبلا در جلسات JSAC ( کمیته مشاوره خدمات مشترک Joint Services Advisory Committee ) کفش‌های ورزشی من را دیده‌اند و مشکلی ندارد.

کروتر و اورنشتاین از وفادارترین کارکنان هارت بودند. اما همیشه منتظر فرصتی برای شوخی با رئیسشان بودند. اورنشتاین: ((فرانک همه چیز را خیلی جدی می‌گرفت.))

اورنشتاین از مخالفان صریح جنگ ویتنام بود. در سال ۱۹۶۹، بسیاری از افرادی که هرگز مشارکت خود را در پروژه‌های تحقیقاتی تحت حمایت پنتاگون زیر سوال نبرده بودند، شروع به تفکر درباره آن کردند. اورنشتاین همیشه سنجاقی به لباسش می‌زد که روی آن نوشته شده بود RESIST(مقاومت کردن) و در کنارش علامت مقاومت الکتریکی کشیده شده بود؛ یک نماد ضد جنگ محبوب برای مهندسان برق. یک روز، قبل از یکی از جلسات پنتاگون، اورنشتاین استفاده جدیدی برای سنجاقش در نظر گرفت. در جلسات پنتاگون، برای مردان دور میز غیرعادی نبود که کاپشن های خود را در بیاورند و آستین های پیراهن خود را بالا بزنند. اورنشتاین به هارت گفت که می‌خواهد در حالی که هیچکس حواسش نیست، سنجاق خود را به ژاکت ژنرال بزند. اورنشتاین گفت: ((فکر می‌کنم فرانک واقعا نگران بود که این کار را انجام دهم.)) (اورنشتاین این کار را نکرد، اما سنجاق خود را در جلسه به لباس خودش زده بود.)

همانطور که بچه‌های IMP برنامه‌های خود را در واشنگتن ارائه می‌کردند، آشکار شد که در واقع شبکه آرپا ترکیبی از ایده‌های باران و دیویس است. شبکه آرپا از یک طرح مسیریابی تطبیقی ​​استفاده می‌کرد که بچه‌های IMP به تنهایی ایجاد کرده بودند، اما بسیار شبیه ایده اولیه باران بود. با این حال، برخلاف شبکه نظری باران، شبکه آرپا تقریبا سطح افزونگی یا پیوندهای مشابه در هر نود نداشت. در طرح BBN به طور معمول، نودها به دو نود همسایه و در برخی مواقع به یک یا سه نود دیگر متصل بودند. همانطور که اکنون واضح بود، تنها قطع شدن دو لینک می‌توانست شبکه را به بخش‌های مجزا تقسیم کند. پل باران گفته بود که شبکه‌ای با تعداد زیادی لینک‌های اضافی می‌تواند از قطعات ارزان قیمت ساخته شود؛ اگر قطعه‌ای خراب می‌شد، دیگران آماده پشتیبانی از آن خواهند بود. سطح پایین افزونگی در شبکه آرپا به طرح دیویس نزدیک‌تر بود. رویکرد هارت این بود که هر بخش از شبکه را تا حد امکان قوی و قابل اعتماد کند.

در طول دوره تحقیقاتی، کروتر و والدن کارهای بسیار مهمی را انجام داده بودند که نتایج شگفت انگیزی به همراه داشت. اول، آنها راهی برای کارآمد کردن مسیریابی تطبیقی ​​پیدا کردند. آنها همچنین کشف کرده بودند که می‌توانند سیستم را بسیار سریع‌تر از آنچه که هر کس تصور می‌کرد، اجرا کنند. ناظران گفتند کد آنها کار نخواهد کرد؛ کروتر و والدن می‌دانستند که کار خواهد کرد. آنها در نوشتن ((هسته)) برنامه خود (به قول کروتر: ((بخش بسیار کوچکی که تنها آن، اهمیت دارد)) )، متوجه شده بودند که در برنامه نرم‌افزاری چقدر دستورات کمی برای وارد کردن بسته‌ها به داخل IMP، مشخص کردن مقصدشان و ارسال‌شان، لازم است.

کار کروتر و والدن روی الگوریتم‌های حیاتی (قوانین اساسی برای پردازش بسته‌ها و مشکلات مسیریابی) آنها را به این نتیجه رساند که برای پردازش یک بسته از طریق یکی از IMPها فقط صد و پنجاه خط کد لازم است. با این حال تا آزمایش آن با یک سیستم واقعی، باید منتظر ماند. اما آنها احساس خوبی داشتند که IMP کار خواهد کرد.

یک کار کلیدی که هارت نگران آن بود، اما مجبور به مدیریت آن نبود، قرارداد فرعی با AT&T بود. این مسئولیت لری رابرتز بود که فراهم شدن خطوط ۵۰ کیلوبیتی (قابلیت انتقال حدود دو صفحه متن در ثانیه) را برای هر پایگاه میزبان تا تاریخ آماده شدن IMPها، ترتیب دهد. رابرتز کار را به یکی دیگر از آژانس‌های پنتاگون سپرد تا با AT&T بر روی شرایط نصب و اجاره خطوط مناسب، مودم‌ها و سایر تجهیزات ارتباطی لازم برای ایجاد پیوندهای شبکه، صحبت کند. اتصال فیزیکی IMPها به دفتر تلفن محلی باید با سیم تلفن معمولی (دو جفت سیم مسی پیچ خورده در یک کابل حاوی حدود هزار جفت سیم پیچ خورده دیگر) و تجهیزات ویژه در هر دو سر برای پشتیبانی از داده‌ها انجام می‌شد. خطوط اختصاصی و سایر تجهیزات باید تا زمان ورود اولین IMP در پاییز، در پایگاه‌های کالیفرنیا مستقر شوند. هارت می‌دانست که شرکت تلفن باید هرچه سریع‌تر شروع به انجام تعهداتش کند، و خوشحال بود که نظارت بر همکاری AT&T مشکل او نبود.

رابرتز یک نیروی دور اما مداوم بود که برای پروژه حیاتی بود. سبک او این بود که بیشتر اوقات از سر راه محققان اصلی دور باشد. ولی هر وقت که خودش را به پروژه‌ای تزریق می‌کرد، هرگز وقت کسی را تلف نمی‌کرد. او همیشه نظر خود را بیان می‌کرد و پیش می‌رفت. مردم در جامعه رو به رشد کامپیوتر به رابرتز بسیار احترام می‌گذاشتند.

روزها برای دفتر تکنیک‌های پردازش اطلاعات در آرپا عالی می‌گذشت. با وجود تیلور و رابرتز، بودجه تحقیقات محاسباتی در حال رشد بود، حتی زمانی که بقیه بودجه آرپا، به دلیل افزایش هزینه‌های جنگ ویتنام کاهش می‌یافت. مدیران IPTO می‌توانستند برای اولویت‌های انتخابی خود پول خرج کنند. و اگر همکاری مورد نظرشان‌ را از پیمانکاران دریافت نمی‌کردند، می‌توانستند به راحتی قرارداد را لغو کنند.

اعطای اختیارات فراوان به افرادی مانند رابرتز نمونه‌ای از سبک مدیریتی آرپا بود که به روزهای اولیه آن باز می‌گشت و ریشه در اعتماد عمیق به دانشمندان و مهندسان حاضر در لبه‌ی علم داشت. دوایت آیزنهاور در بستر مرگش در سال ۱۹۶۹ از یکی از دوستانش در مورد ((دانشمندان من)) پرسید و گفت، آنها ((یکی از معدود گروه‌هایی بودند که من در واشنگتن با آنها برخورد کردم و به نظر می‌رسید آنجا هستند تا به کشور کمک کنند، نه به خودشان.)) در واقع، بسیاری از بهترین دانشمندان کشور، از جمله رابرتز، کار در آژانس را به عنوان یک مسئولیت مهم، برای خدمت تلقی می‌کردند.

اما مدیران آرپا دستمزد خوبی نداشتند. اورنشتاین یک بار در خارج از شهر، رابرتز را دید که در حال رانندگی با یک ماشین کرایه‌ای کوچک است. اورنشتاین از او پرسید که چرا چنین چیزی را اجاره کرده است؟ و رابرتز درباره اینکه اورنشتاین قوانین و هزینه‌های دولت را درک نمی‌کند، چیزی زمزمه کرد. اورنشتاین گفت: ((من همیشه فکر می‌کردم که او به راحتی این میلیون‌ها دلار را پخش می‌کند. هرگز به ذهنم خطور نکرده بود که او در واقع با بودجه بسیار محدودی زندگی می‌کند. افرادی مانند لری برای مدتی خود را فدا کردند تا بتوانند کنترل اتفاقات بزرگ را به دست بگیرند.))

با رابرتز از بسیاری جهات به گونه‌ای رفتار می‌شد که انگار یکی از اعضای تیم BBN است، حتی اگر در واشنگتن بود. او اغلب به کمبریج سفر نمی‌کرد، با این حال حضور او دائما احساس می‌شد. از آنجایی که تنها چند نفر در BBN روی این پروژه کار می‌کردند، رابرتز هنگام بازدید، در کنار بقیه می‌نشست. این بازدیدها از صحبتهایی غیررسمی در مورد پیشرفت کار شروع می‌شد تا جلساتی طولانی مدت و سطح بالا. فرانک هارت به عنوان محقق اصلی و مدیر گروه، نقطه تماس اصلی رابرتز با BBN بود. رابرتز همچنین با کان نیز در ارتباط نزدیک بود.

هر پایگاه مسئول ایجاد یک رابط سفارشی بین میزبان و IMP بود. از آنجایی که رایانه‌هایی با ساختار‌های متفاوت درگیر بودند، هیچ رابط واحدی برای همه پایگاه‌ها کار نمی‌کرد. و این مستلزم یک پروژه توسعه سخت‌افزار و نرم‌افزار جداگانه در هر پایگاه هست و چیزی نبود که تیم‌های میزبان بتوانند یک شبه دور هم جمعش کنند.

بچه‌های IMP باید دستورالعمل میزبان-به-IMP را قبل از اینکه میزبان‌ها شروع به ساخت هر چیزی کنند، می‌نوشتند. فوری‌ترین دستور کاری هارت تکمیل طراحی BBN از دستورالعمل میزبان-به-IMP بود تا افراد در UCLA بتوانند به موقع شروع به کار کنند تا به برنامه زمانی رابرتز برسند. هارت از قبل بد قولی پایگاه‌های میزبان را پیش‌بینی می‌کرد. او می‌دانست که محققان اصلی تا چه اندازه به دانشجویان فارغ‌التحصیل تکیه می‌کنند، و هارت نگران بود که پروژه ممکن است به دلیل بی‌توجهی یک دانشجوی فارغ‌التحصیل در وقت‌شناسی، از مسیر خارج شود.

روزهای صرف شده برای بحث در مورد دستورالعمل میزبان-به-IMP به هفته‌ها تبدیل شد. بدیهی بود که اگر کسی در تیم هارت وظیفه نوشتن آن را بر عهده نمی‌گرفت، صحبت بیشتر و نوشتن کمتر می‌شد. کان تهیه پیش‌نویس آن را بر عهده گرفت. در نظر هارت، کان بهترین نویسنده‌ای است که این گروه دارد، بنابراین عقب ایستاد و به کان اجازه داد دستورالعملی را ارائه کند که به گزارش BBN 1822 معروف شد.

برخی از مردم فکر می‌کردند که هارت بیش از حد نگران شکست‌های احتمالی مهندسی است. وقتی صحبت از مهندسی به میان می‌آمد، او یک آدم بسیار محتاط بود. هارت دقت و احتیاط در مهندسی را از استاد خود در آزمایشگاه لینکلن، جی فارستر Jay Forrester ، مخترع حافظه هسته مغناطیسی، آموخته بود. فارستر قابلیت اطمینان را در سر مهندسان MIT پایه گذاری کرد. بالاتر از هزینه، عملکرد یا هر چیز دیگری، قابلیت اطمینان اولویت اصلی آنها است؛ طراحی کنید، بسازید، برای بدترین شرایط آماده شوید و مهم‌تر از همه، دستگاه خود را در موقعیتی قرار ندهید که از کار بیفتد. هارت با جادویش از همان ابتدا به هزاران روش، قابلیت اطمینان را در IMP ایجاد کرد.

تولیدکنندگان رایانه در ماست مالی کردن سیستم‌ها به منظور رقابت بر سر قیمت و ساخت به موقع ماشین‌های جدید، شهرت داشتند. آنها تقریبا همیشه مقداری بها برای نرخ خرابی بالاتر (باگ‌ها و خرابی رایانه) می‌پرداختند، اما این، شهرت آنها را از بین نمی‌برد. از رابرتز و هارت تا پایین‌ترین بچه‌های IMP، در این پروژه انتظار استاندارد بالاتری داشتند. شبکه‌ای که بیست و چهار ساعته کار می‌کند، مطمئنا از IMP‌های ساخته‌شده توسط BBN عملکرد قابل‌توجهی می‌خواست. یک ضرورت پذیرفته شده این بود که IMPها تمام تلاش خود را برای ارائه دقیق هر پیام انجام دهند. یک لینک ممکن است خراب شود، حتی یک ماشین میزبان نیز ممکن است خراب شود، اما IMPها نه. قابلیت اطمینان، اصل اساسی شبکه بود. شبکه آرپا نمایش شخصیت پایدار فرانک هارت بود.

اورنشتاین در سختگیری شهرت داشت و به عنوان یک بازرس فنی بسیار موثر بود. جمله معروف او این است: ((من فقط یک مرد سخت‌افزاری احمق هستم، مرا متقاعد کن!)) تا زمانی که توضیحتان برایش معنا پیدا نمی‌کرد، رهایتان نمی‌کرد. بیشتر اوقات، نقاط آسیب پذیر پنهان سیستم را او کشف می‌کرد.

بسیاری از جلسات برنامه ریزی در BBN، در اتاق واینر برگزار می‌شد، یک اتاق کنفرانس با سقفی بلند و یک میز مربعی بزرگ، به همراه تخته سیاه‌های فراوان. این اتاق در تقاطع راهروی جداکننده بخش‌های BBN، بین اتاق کامپیوتر ۵۱۶، اتاق نهار و دفتر هارت قرار داشت. اتاق واینر، محل تجمع مشخص بچه‌های IMP بود. تیم IMP به اندازه کافی کوچک بود، دفاتر آنها به اندازه کافی نزدیک بود، و تماس بین اعضای تیم به اندازه کافی مکرر بود که بررسی رسمی طراحی نیازی نباشد. آن‌ها در راهروها صحبت می‌کردند، در دفتر یکدیگر می‌نشستند، بحث می‌کردند و دائما ایده‌هایشان را به اشتراک می‌گذاشتند. در اتاق واینر، گچ آزادانه و اغلب برای توضیح، نمودار، طرح کلی، استدلال و آموزش استفاده می‌شد. اورنشتاین از این اتاق برای برگزاری یک سلسله سخنرانی غیررسمی در مورد جزئیات نرم‌افزار و سخت‌افزار سیستم استفاده می‌کرد و گاهی نیز افراد برای صحبت در مورد موضوعات فنی وارد آن می‌شدند. کل تیم اطلاعات را به اشتراک می‌گذاشتند. به قول کروتر: ((همه، همه چیز را می‌دانستند.))

اعضای تیم همچنین یک سری یادداشت‌های فنی غیررسمی شماره‌دار می‌نوشتند که بین‌شان پخش می‌شد. یادداشت‌ها فرمت خاصی نداشتند اما همیشه با عنوان ((یادداشت بچه‌های IMP)) شروع می‌شدند. آنها ایده‌های خود را می نوشتند، آن را رد و بدل می‌کردند و سپس معمولا دور هم جمع می‌شدند تا درباره آنها بحث کنند. این یادداشت‌ها همچنین راهی بودند برای نظارت هارت بر روند کار.

بررسی و بازبینی این پروژه در زمان تکمیل، اصلا مانند بازبینی‌های سنتی نبود. بازبینی طراحی، یک رویداد مهم در طول یک پروژه مهندسی است. یک تیم مهندسی ممکن است هفته‌ها کار کند تا یک طرح را برای بازبینی آماده کنند، سپس آن را ارائه کنند و در نهایت، زیر نظر همکاران و مهندسان ارشد آن را توضیح دهند و در موردش بحث کنند. بازبینی‌های هارت معمولا به صورت تصادفی و مداوم بودند، که این به معنای آسانی آن‌ها نبود. برنی کوسل، عیب‌یاب بی‌همتا نرم‌افزار تیم، به یاد می‌آورد: ((یک امتحان شفاهی توسط فردی با توانایی‌های روانی. چیزی که تبدیل به بدترین کابوس شما می‌شد. او می‌فهمید روی کدام بخش‌های طراحی کمتر اطمینان دارید و کجاها را کمتر درک می‌کنید یا سعی می‌کنید از آن‌ها طفره بروید، در عین حال تقریبا بخش‌هایی را که درست انجام داده بودید و به آن‌ها افتخار می‌کردید را نادیده می‌گرفت.))

کوسل گفت: ((مانند جلسات کم‌تکرار با رابرتز، بازبینی‌های طراحی هارت در عبور از قسمت‌های سخت کار، کمک کننده بود.)) هارت برای کارهایی که مهندسانش به خوبی انجام داده می‌دادند احترامی ضمنی قائل بود. اما در تمجید و تعریف، احتیاط می‌کرد. به نظر می‌رسید نگرش او این است که چرا زمان را با آن تلف کنیم؟ مهندسان جوان‌تر و کم تجربه‌تر ممکن است در نبود بازخورد مثبت از طرف هارت ویران شوند، اما بچه‌های IMP یک گروه کارکشته، درهم تنیده و با اعتماد به نفس بودند که به خوبی به روش‌های هارت عادت داشتند.

به دلیل اصرار هارت بر قابلیت اطمینان و تحلیل اولیه کان روی این موضوع، تعداد زیادی مکانیسم کنترل خطا در سیستم طراحی شد. هر سیستم ارتباطی مستعد خطاهایی در انتقال ناشی از نویز در مدارهای ارتباطی است. صداهایی که از تلفن‌ها عبور می‌کنند، یک انتقال آنالوگ هستند و می‌توانند مخدوش یا مبهم شوند؛ مانند زمانی که صداهای ((س)) و ((ف)) اشتباه گرفته می‌شوند. انتقال دیجیتال نیز می‌تواند مخدوش شود: ممکن است یکی از ((۱))ها، ((۰)) شود یا بالعکس. خطاها به صورت انفجاری رخ می‌دهند. اگر یک بیت معین به خطا بر بخورد، احتمال اینکه بیت‌های اطراف نیز دچار خطا شوند، بسیار بیشتر از حالت عادی است. با وجود این مشکلات، تکنیک‌های خوبی برای تشخیص و حتی تصحیح خطاهای دیجیتال وجود دارد و IMPها باید بر آنها تکیه کنند.

ایده اصلی تصحیح خطای دیجیتال مبتنی بر (( چک‌سام checksum (تستی مبتنی بر عملیات جمع) )) است، یک عدد نسبتا کوچک که از داده‌ها در مبدا محاسبه می‌شود، سپس همراه با داده‌ها منتقل می‌شود و در مقصد دوباره محاسبه می‌شود. اگر عدد اولیه و دوباره محاسبه شده با هم یکسان نباشند، در انتقال خطایی رخ داده است، مگر اینکه شاید خود سخت‌افزار محاسبه کننده به اشتباه خورده باشد، که یک اتفاق بسیار بعید است.

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

اگر محصولی اسکن شود و کامپیوتر بوق نزند، به این معنی است که محاسبات به جواب درست نرسیده. اگر رایانه راهی برای تصحیح خطا داشته باشد، هر بار بوق می‌زد و در زمان صرفه جویی می‌کرد. اما تکنیک‌های تصحیح خطا هزینه‌ای را به سیستم اضافه می‌کنند، بنابراین مسئول پیشخوان باید دوباره بارکد را اسکن کند، شاید دو یا سه بار تا زمانی که کد بدون خطا ارسال شود.

بچه‌های IMP با مشکل مشابهی روبرو شدند: اگر چک‌سام، یک خطا را در شبکه شناسایی کرد، چگونه باید با آن برخورد کرد؟ آیا IMP فرستنده باید بسته را دوباره ارسال کند یا سخت‌افزار IMP دریافت کننده باید به گونه‌ای تقویت شود که بتواند خطا را اصلاح کند؟ در یک شبکه، تصحیح خطا، فضای مدارهای ارتباطی را می‌بلعد و هزینه سخت‌افزاری را در تجهیزات سوئیچینگ بالا می‌برد. در نتیجه، تیم BBN تصمیم گرفت که اگر یک IMP خطایی را در یک بسته تشخیص داد، بسته را بدون ارسال تاییدیه، دور بیندازد. IMP مبدا که تاییدیه را دریافت نمی‌کند، دوباره بسته را ارسال می‌کند.

قبل از صدور درخواست پیشنهادات توسط رابرتز، باید در مورد نوع چک‌سام IMPها تصمیم می‌گرفت. چند بیت باید به آن اختصاص داده شود و چقدر باید پیچیده باشد؟ تعیین نیاز دقیق، بر اساس میانگین تعداد خطاها در خطوط تلفن، دشوار بود زیرا هیچ اطلاعات دقیقی در مورد میزان خطا در خطوط پرسرعتی که قرار بود داده‌ها از طریق آنها ارسال شود، وجود نداشت. با این حال، واضح است که چک‌سام ۱ بیتی هرگز عملی نخواهد بود. ۲بیتی یا حتی ۸ بیتی هم کافی نیست. حتی چک‌سام ۱۶ بیتی نیز ممکن است، جواب ندهد.

کان قبلا مکتوب کرده بود که چک‌سام ۱۶ بیتی ممکن است برای رسیدن به سطح مطلوبی از قابلیت اطمینان در شبکه، به اندازه کافی قدرتمند نباشد، به ویژه با توجه به عدم قطعیت در عملکرد خطای خطوط پرسرعت. کان برخی از محاسبات تقریبی را با رابرتز در میان گذاشت؛ او به شدت چک‌سام ۲۴ بیتی را پیشنهاد می‌کرد و اشاره کرد که ۸ بیت اضافی هزینه بسیار کمی را به سخت‌افزار تحمیل می‌کند. تعداد بیت‌های چک‌سام در درخواست پروپوزال نوشته شد. کان سپس همین بحث را با کروتر و دیگران مطرح کرد، و بچه‌های IMP روی چک‌سام ۲۴ بیتی به عنوان یکی از بخش‌های حیاتی سیستم کنترل خطا، به توافق رسیدند.

مهندسان BBN در انتخاب اینکه کدام مسائل را به سخت‌افزار و کدام را به نرم‌افزار بسپرند، درک خوبی داشتند. منطقی بود که محاسبه چک‌سام را به سخت‌افزار IMP بسپارند، زیرا محاسبه به صورت نرم‌افزاری بسیار کند خواهد بود. طرح نهایی تشخیص خطا IMP-به-IMP، ترکیبی هوشمندانه از تکنیک‌های مهندسی شناخته شده و سایر روش‌های نوآورانه‌ خود تیم BBN بود. همانطور که کروتر می‌گوید: ((ما از هر جایی ایده‌ها را می‌دزدیم، اما بیشتر اوقات مجبور بودیم ایده‌های خودمان را مطرح کنیم.))

در روز ولنتاین سال ۱۹۶۹، کمبریج غرق برف شد. حدود بیست نفر در یک جلسه تمام وقت در BBN حضور داشتند. این اولین ملاقات بین تیم هارت و محققان و دانشجویان فارغ التحصیل از پایگاه‌های میزبان بود.

از دید چشمان محتاط هارت، آن‌ها انبوهی از دانشجویان فارغ التحصیل بودند که گرسنه دست زدن به IMPها بودند. او نگران بود که وقتی آرپا تصمیم گرفت IMPها را در پایگاه‌ها قرار دهد، محققان شروع به بازی با آنها کنند. او تصور می‌کرد که آنها از IMP برای هر چیزی استفاده خواهند کرد؛ برای بازی شطرنج یا محاسبه مالیات بر درآمدشان. هارت به یاد می‌آورد: ((من بسیار سفت و سخت برخورد کردم. آنها نباید به آن دست می‌زدند و نباید به آن نزدیک می‌شدند. این یک جعبه بسته بود که هیچ کلیدی برایش در دسترس نبود.))

کان هنوز به سختی روی دستورالعمل‌ها رابط میزبان-به-IMP کار می‌کرد، بنابراین برای اعضای تیم پایگاه‌ها مشخص نبود که دقیقا چه چیزی باید بسازند. برخی از افراد حاضر در جلسه در مورد آن از BBN پرس و جو کردند، اما بچه‌های IMP هنوز بین خودشان تصمیمی نگرفته بودند و در این جلسه چیز زیادی مشخص نشد.

دانشجویان فارغ التحصیل تصمیم گرفتند طرحی را که برای چک‌سام سراسری پایگاه‌ها طراحی کرده بودند، با BBN به اشتراک بگذارند. این یک لایه حفاظتی اضافی در برابر خطاها در ارتباطات میزبان-به-میزبان فراهم می‌کرد و برای تشخیص خطاهای مختلف، از جمله مونتاژ اشتباه بسته‌های پیام توسط IMPها طراحی شده بود.

هارت از این ایده خوشش نیامد، زیرا باعث کاهش سرعت پایگاه‌ها و در نتیجه کند شدن کل سیستم می‌شد. همچنین این بحث که IMPها ممکن است بسته‌های آسیب‌دیده را به میزبان ارسال کنند، اصلا برای او قابل قبول نبود. دانشجویان استدلال کردند که چک‌سام ۲۴ بیتی BBN، مسیر IMP به کامپیوترهای میزبان را پوشش نمی‌دهد و بیت‌ها بین دو ماشین، بدون پوشش حرکت می‌کنند. هارت بدون استدلال واضحی، به همه اطمینان داد که چک‌سام IMP قابل اعتماد خواهد بود. باید به مرور زمان دید، حق با دانشجویان بود یا هارت. اما با اعتماد به نفسی که هارت به نمایش گذاشت، پایگاه‌های میزبان، برنامه‌ی خود را برای گنجاندن یک چک‌سام در پروتکل‌های میزبان، کنار گذاشتند.

مشکل بزرگ‌تر، ایده اتصال چندین کامپیوتر میزبان در هر پایگاه به یک IMP بود. هنگامی که رابرتز برای اولین بار شبکه را طراحی کرد، ایده او این بود که یک و تنها یک کامپیوتر میزبان را به هر IMP متصل کند. با این حال، در جلسه روز ولنتاین، نمایندگان پایگاه‌ها به وضوح اعلام کردند که می‌خواهند بیش از یک کامپیوتر میزبان را به هر IMP متصل کنند. هر مرکز تحقیقاتی چندین کامپیوتر داشت و در صورت امکان، تلاش برای اتصال بیش از یک دستگاه در هر پایگاه منطقی است. رابرتز به کمبریج خبر داد که BBN قرار است IMP را به گونه‌ای طراحی کند که حداکثر اتصال چهار میزبان را عملی کند. والدن، کروتر و کوسل روشی هوشمندانه برای انجام آن اختراع کردند.

بعد از روز ولنتاین، کار بچه‌های IMP شدت بیشتری گرفت و مجبور شدند تا دیروقت کار کنند. هارت، که در شهر روستایی لینکلن زندگی می‌کرد، سعی می‌کرد تا به موقع به خانه و شام برسد، اما اغلب موفق نمی‌شد. برای بقیه راحت‌تر بود که برای شام به خانه بروند و بعد از آن دوباره سر کار برگردند یا اصلا به خانه نروند. اغلب شب‌ها کروتر آنقدر پشت ترمینال خود می‌نشست تا به خواب می‌رفت.

اکنون اما فشار واقعی روی کان بود. او بیشتر دو ماه آینده را با افراد در پایگاه‌های میزبان به صورت تلفنی صحبت می‌کرد و دستورالعمل‌های رابط‌ها را بررسی می‌کرد. کان به نقطه اصلی ارتباطات BBN با تیم‌های تحقیقاتی پایگاه‌ها تبدیل شد. محققان مرتب برای بررسی اتفاقات، زمان‌بندی کار یا صرفا انتقال ایده‌های جدید با او تماس می‌گرفتند.

در اواسط آوریل، کان دستورالعمل‌ها را به پایان رساند، یک سند ضخیم که توضیح می‌داد چگونه یک کامپیوتر میزبان باید با یک سوئیچ بسته یا IMP ارتباط برقرار کند. والدن می‌گوید: ((این سند تا حد زیادی با در نظر گرفتن آنچه که میزبانان از ما خواسته بودند و آنچه که قرار بود پیاده‌سازی شود، نوشته شد.)) کمیته‌ای از نمایندگان پایگاه‌های میزبان آن را بررسی کردند و نقد‌هایشان را به BBN گفتند. دستورالعمل تا رسیدن به یک طرح قابل قبول، چندبار بازنگری شد. پایگاه‌های میزبان اکنون چیزی برای ساختن داشتند. تیم UCLA که اولین خواهد بود، کمتر از پنج ماه فرصت داشت تا برای ورود IMP خود آماده شود.

هارت مرز مشخصی بین آنچه که IMPها انجام خواهند داد و آنچه میزبانان انجام خواهند داد ترسیم کرد. کروتر گفت: ((در همان ابتدا، فرانک تصمیمی بسیار عاقلانه گرفت و مرز مشخصی بین مسئولیت‌های میزبان و مسئولیت‌های شبکه ایجاد کرد.)) هارت و تیمش تصمیم گرفتند ((حداکثر جدایی منطقی)) را بین IMP و میزبان قرار دهند. این مرز جلوی به هم ریختگی یا شلوغ شدن عملکردهای IMP را می‌گرفت، همچنین ساخت IMPها را قابل مدیریت‌تر می‌کرد؛ همه IMPها می‌توانستند یکسان طراحی شوند، نه اینکه برای هر پایگاه، سفارشی شوند. همچنین باعث می‌شد BBN در وسط قرار نگیرد و مجبور نشود در میان پایگاه‌های میزبان از طریق پروتکل‌های شبکه نقش رابط را بازی کند.

BBN با رابرتز توافق کردند که IMPها هیچ عملکرد میزبان-به-میزبانی را انجام ندهند. این یک مشکل فنی بزرگ بود. هیچ استاندارد زبانی یا چیزی که ارتباط بین میزبان‌ها را تسهیل کند وجود نداشت. حتی تولیدکنندگان خصوصی، مانند Digital، فقط تعدادی کامپیوتر کاملا ناسازگار ساختند.

آخرین چیزی که BBN می‌خواست سردرد اضافی حل مشکلات میزبان-به-میزبان بود. علاوه بر این، رابرتز نمی‌خواست به BBN یا هر پیمانکار دیگری کنترل زیادی روی طراحی شبکه دهد. رابرتز مصمم بود که مسئولیت‌ها را به طور مساوی تقسیم کند. وظایف بین رابرتز و BBN از قبل مشخص شده بود: IMP به عنوان یک پیام رسان ساخته شود، یک دستگاه پیچیده ذخیره و ارسال، نه چیزی بیشتر و وظیفه آن، حمل بیت‌ها، بسته‌ها و پیام‌ها خواهد بود؛ جداسازی پیام‌ها، ذخیره بسته‌ها، بررسی خطاها، مسیریابی بسته‌ها، و ارسال تاییدیه برای بسته‌هایی که بدون خطا می‌رسند. سپس بسته‌های دریافتی را مجددا در پیامی گرد آوری کند و آنها را به ماشین‌های مقصد ارسال کند. همه با یک زبان مشترک.

IMPها برای خواندن فقط ۳۲ بیت اول هر پیام طراحی شدند. این بخش از پیام که در ابتدا (( رهبر leader )) نامیده می‌شد (و بعدا به (( هدر header )) تغییر یافت)، مبدا یا مقصد را مشخص می‌کرد و شامل برخی اطلاعات کنترلی اضافی بود. این ۳۲ بیت حاوی حداقل داده‌های مورد نیاز برای ارسال و پردازش یک پیام بود. این پیام‌ها سپس در IMP اولیه، به بسته‌هایی شکسته می‌شدند. بار خواندن محتوای پیام‌ها بر عهده خود میزبان‌ها خواهد بود.

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

IMP شماره 0

` `در یک روز بهاری، یک کامیون حمل مرسوله از هانیول به سمت خیابان مولتون پیچید. داخل آن اولین دستگاه ۵۱۶ ساخته شده با مشخصات BBN بود. کامپیوتر با اندازه‌ای همانند یخچال از کامیون خارج شد و روی یک رمپ بارگیری در پشت ساختمان بخش سیستم‌ها، قرار گرفت و سپس به اتاق بزرگی که به زودی به عنوان اتاق IMP شناخته خواهد شد، در مجاورت محل بارگیری قرار گرفت. این تیم با اضافه کردن یک کف کاذب، نور فلورسنت روشن و تهویه مطبوع، یک انبار را به فضایی برای آزمایش IMPها تبدیل کرد. این اتاق بدون پنجره جایی بود که جوانترین فرد تیم، بن بارکر Ben Barker بیست و دو ساله، به زودی زمان زیادی را در آن باید سپری می‌کرد.

بارکر دانشجوی کارشناسی بود و درخشش او در یکی از کلاس‌هایی که اورنشتاین در هاروارد تدریس می‌کرد، اورنشتاین را به سمت او جلب کرد. زمانی که BBN قرارداد آرپا را دریافت کرد، هارت به بارکر پیشنهاد شغلی داد و بارکر برای پذیرش آن مجبور به گرفتن مرخصی شد. بارکر، مانند اورنشتاین، یک مهندس سخت‌افزار بود و نشانه‌های تبدیل شدن به یک دیباگر قهار را می‌شد در او دید؛ کسی که هر وقت نیاز می‌شد، می‌توانست پروژه‌ای را نجات دهد. او مسئول راه اندازی هر IMP تحویلی هانیول و دیباگ سخت افزاری آن، قبل از خروج از BBN شد.

اولین ماشین، یک نمونه اولیه (IMP شماره ۰) بود، یک ۵۱۶ مقاوم سازی نشده که شامل اجرای اولیه رابط‌های BBN توسط هانیول بود. دستگاه در وسط اتاق بود، بارکر برق را به کامپیوتر وصل کرد و آن را روشن کرد.

بارکر یک تستر ساخته بود و چند کد دیباگ نوشته بود. او مشتاقانه منتظر بود تا اشکالات دستگاه را برطرف کند. بدون شک چیزی وجود خواهد داشت که نیاز به تعمیر دارد، زیرا همیشه وجود داشته است. اشکالات بخشی از فرآیند طبیعی طراحی کامپیوتر بودند. هارت و کل تیم مشتاقانه منتظر بودند تا بدانند کدام بخش از طراحی IMP کار می‌کند و کدام یک نیاز به توجه بیشتری دارد.

بارکر سعی کرد اولین برنامه را در دستگاه بارگذاری کند. او هر کار کرد نتوانست آن را به کار بیندازد. بنابراین کد دیگری را بارگذاری کرد و آن هم کار نکرد. بارکر چند چیز دیگر را نیز امتحان کرد و متوجه شد که هیچ چیز کار نمی‌کند. او گفت: ((ماشین به انجام کار مفید حتی نزدیک نیز نشد.)) تا اینجای کار، اولین IMP یک سیستم خراب بی‌مصرف بود.

از قبل از پروژه IMP، BBN و هانیول به طور معمول با هم تعامل داشتند و روابط دوستانه‌ای داشتند. در روزهای منتهی به پروژه IMP، حس کارگروهی بین دو شرکت بسیار افزایش یافت. هانیول از همان روز اول یک گروه سیستمی ویژه برای کار بر روی قرارداد BBN اختصاص داد. به درخواست BBN، هانیول یکی از تکنسین‌های خود را به طور اختصاصی به مدیریت دقیق پروژه گماشت.

این غیرعادی بود. به طور کلی، تولیدکنندگان مینی کامپیوترها مانند هانیول چندان به درخواست‌های ویژه مشتریان پاسخ نمی‌دادند. هارت می‌گوید: ((بیشتر شرکت‌های کامپیوتری اصلا محصولات سفارشی نمی‌سازند. یا حتی اگر بسازند، تحت فشار زیاد.)) هیچ کس در کسب و کار مینی کامپیوتر توجه چندانی به مشتری نداشت.

در پی شکست فاحش IMP شماره ۰، اورنشتاین، رئیس بخش سخت‌افزار BBN، شروع به بررسی طراحی با تیم هانیول کرد. او متوجه شد که به نظر می‌رسد هیچکس در هانیول نمی‌داند که رابط‌های طراحی شده توسط BBN چگونه باید کار کنند. او از اینکه تکنسین‌هایی که اولین رابط را ساخته بودند، واقعا هیچ درکی از نقشه‌ها نداشتند، شگفت زده شد. هانیول هیچ تلاشی برای تست طراحی نکرده بود. صرفا تلاش کرده بود تا یک پیاده‌سازی وفادار از فلوچارت‌ها و نمودارهایی که اورنشتاین ترسیم و BBN در طرح تحقیقاتی خود گنجانده بود، تولید کند. مشکل این بود که در مجموعه نقشه‌هایی که به هانیول داده شده بود، BBN فرض کرده بود که آشنایی و تخصص هانیول با ماشین‌های خود به آنها این امکان را می‌دهد تا هرگونه مشکل عجیبی که در تغییرات درخواستی BBN در مدل ۵۱۶ هست را پیش‌بینی کنند. اما هانیول به‌جای بررسی جزئیات اساسی در نقشه‌ها، دستگاه BBN را بدون تایید اینکه آیا رابط‌های طراحی‌شده BBN، با مدل پایه ۵۱۶ کار می‌کنند، ساخته بود.

البته، نه BBN در ترسیم نقشه‌ها و نه هانیول در اجرای طرح، هیچکدام ابزارهای لازم برای ایجاد یک نمونه اولیه IMP کاملا کارآمد را در اولین تجربه نداشتند. به گفته بارکر، در ساخت رایانه‌های جدید، فرض عملیاتی این است که شما چیزی را طراحی کنید که فکر می‌کنید کار می‌کند، نمونه اولیه را آماده کنید، آزمایش کردن را شروع کنید، سپس به تدریج خطاهای طراحی را برطرف کنید تا زمانی که دستگاه تمامی آزمایش‌ها را پشت سر بگذارد. اگر دستگاه در همان بار اول به خوبی کار می‌کرد، یک معجزه مهندسی بوده است. اما حتی برای اولین تجربه نیز وضعیت این دستگاه نمونه اولیه، غیرقابل قبول بود.

اگر اورنشتاین در مورد عملکرد هانیول تنها نگران بود، بارکر کاملا عصبی بود. او به عنوان مدیر دیباگ سیستم، مسئول به کار انداختن دستگاه بود. او گفت که در این مرحله از پروژه IMP، رابط‌های ۵۱۶ ((حتی اگر هانیول آن‌ها را به درستی پیاده‌سازی می‌کرد، درست کار نمی‌کردند.))

بارکر به هفته‌ها کار متمرکز پیش رو فکر می‌کرد. او احساس کرد که وزن برنامه ناگهان سنگین‌تر شده است. اگر تیم سخت‌افزار BBN قصد داشت به زودی نسخه‌ای از هانیول ۵۱۶ اصلاح‌شده را به تیم برنامه‌نویسی BBN تحویل دهد تا کروتر، والدن و کوسل برای دیباگ نهایی کد عملیاتی خود زمان داشته باشند، در این صورت متخصصان سخت‌افزار باید سخت‌تر از قبل کار می‌کردند. اکنون بارکر باید با کمک اورنشتاین، چیزهایی را که هانیول ساخته بود، بردارد و بفهمد که چگونه می‌تواند کاری کند که ماشین وظیفه‌اش را به درستی انجام دهد.

نمونه اولیه IMP یک شکست واقعی بود. و حالا اصلاح مسیر به زمان نیاز داشت، چیزی که بزودی مقدار زیادی از آن باقی نمی‌ماند.

بارکر مجهز به اسیلوسکوپ و ابزارهای فنی موردنیاز، شانزده ساعت در روز به تنهایی روی دستگاه کار می‌کرد. مدار کامپیوتر متکی به pin blocks یا wire-wrapped boards بود که به عنوان نقاط اتصال مرکزی صدها سیم و هدایت آنها، عمل می‌کردند. تعداد زیادی کانکتور سی و چهار پین وجود داشت که بردهای منطقی به آنها وصل می‌شدند. بارکر پس از فهمیدن اینکه هر سیم دقیقا به کجا باید برود، مجبور شد هر سیم که به جای اشتباه وصل شده را از پین آن باز کند. پین‌ها در هر بلوک حدود یک اینچ طول داشتند و با فاصله نزدیک (۲۰/۱ اینچ) در یک ماتریس مربعی، کنار هم قرار داشتند. هر بلوک شبیه یک بستر مینیاتوری از میخ‌ها بود که سیم‌هایی شبیه مار به آن داخل و خارج می‌شدند. بارکر پس از مشخص کردن مکان صحیح سیم‌ها، باید دوباره آنها را به هم وصل می‌کرد و هر سیم را با دقت روی پین صحیح خود می‌پیچید. این یک فرآیند طولانی، پر زحمت و ظریف بود.

ضعف جزئی دستان بارکر، اوضاع را از این نیز پیچیده‌تر می‌کرد. کار با سیم پیچ‌کن نیاز به یک دست ثابت و متمرکز داشت. فاصله نزدیک پین‌ها، وزن سیم پیچ‌کن و اندازه نازل آن که باید روی یک پین در میان جنگل کوچکی از پین‌ها پایین می‌رفت، همگی علیه او بودند. ریسک کار در قرار گرفتن سیم روی پین اشتباه یا خم شدن و یا شکستن یک پین بود. اگر مراقب نبودید، می‌توانستید بسیاری از کارهای درست دیگر را از بین ببرید. بنابراین لرزش دستان بارکر، هنگامی که دستانش را به سمت بلوک‌های پین داخل IMP می‌برد، صدای دیگر بچه‌های IMP را در آورده بود.

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

بارکر ماه‌ها صرف دیباگ دستگاه کرد. اورنشتاین بر اصلاحات طراحی در نمونه اولیه نظارت می‌کرد و مطمئن می‌شد که مهندسان هانیول آن را متوجه شوند. ماشین بعدی که هانیول قرار بود تحویل دهد، اولین ۵۱۶ مقاوم سازی شده، خواهد بود که تمام اشکالات طراحی آن برطرف شده باشد؛ IMP شماره یک به مقصد UCLA. بارکر می‌گوید: ((تمام تلاش ما این بود که طرح‌ها را به موقع برای ارسال آماده کنیم.)) تابستان در راه بود.

احتیاط هارت در مقابل انبوهی از دانشجویان فارغ التحصیل کنجکاو، BBN را به سمت اقدامات محافظتی بیشتر سوق داد. با گذشت زمان، یکی از خلاقانه‌ترین کارهایی که تیم هارت انجام داد، ابداع روش‌هایی برای به دست آوردن داده‌های عملیاتی حیاتی از IMPهای شبکه (خواندن علائم حیاتی ماشین‌ها) بدون نیاز به حضور فیزیکی و از راه دور بود. هارت می‌خواست بتواند در یک ترمینال در کمبریج بنشیند و ببیند یک IMP در لس آنجلس، سالت لیک سیتی یا هر مکان دیگری چه می‌کند. پیاده‌سازی کامل ابزارهای عیب‌یابی از راه دور و قابلیت‌های دیباگ BBN، بعدها به یکی از دارایی‌های بزرگ پروژه تبدیل شد. هنگامی که شبکه کامل شد، کنترل از راه دور، BBN را قادر می‌ساخت تا کل سیستم را از یک مرکز عملیات، نظارت و نگهداری کند و داده‌ها را تحت شرایط مختلف جمع‌آوری کرده و مشکلات پیش آمده را عیب‌یابی کند. به طور دوره‌ای، هر IMP یک گزارش فوری از وضعیت خود (مجموعه‌ای از داده‌ها در مورد شرایط عملیاتی IMP) به کمبریج می‌فرستد. همچنین تغییرات جزئی و عمده در شبکه قابل تشخیص می‌شد. دورنمای گروه هارت اشراف کامل به سراسر شبکه بود.

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

آرپا در درخواست اصلی‌اش به صراحت استفاده از مسیریابی پویا را بیان می‌کرد، اما هیچ خبری از نحوه ساخت آن نبود. تا اینکه کروتر راهی برای انجام آن پیدا کرد. او در حال ساخت سیستمی از جداول مسیریابی پویا بود که هر چند ثانیه یا زودتر بروز شوند. این جداول به IMPها می‌گفتند که هر بسته‌ای که هنوز به مقصد خود نرسیده است را در کدام جهت ارسال کنند. در جداول مسیریابی، شرایط شبکه مانند خرابی و شلوغی خطوط منعکس می‌شد و در نتیجه بسته‌ها به سریع‌ترین مسیر ممکن هدایت می‌شدند. درست کردن چنین طرحی یک کار به شدت دشوار به نظر می‌رسید. تا اینکه کروتر با مجموعه‌ای ساده و کامل از کدها، از راه رسید. همانطور که اورنشتاین استعداد غیرعادی و شهودی کروتر را توصیف می‌کند: ((همیشه ذهنش درست لابه‌لای بیت‌ها بود.))

الگوریتم مسیریابی پویا کروتر قطعه شعری در دنیای برنامه‌نویسی بود. والدن توصیف کرد: ((فوق‌العاده ساده و به طرز شگفت‌انگیزی کارا بود.)) کروتر در بین همکارانش به عنوان شخصی از برنامه‌نویسان ۱ درصد برتر جهان شناخته می‌شد. گاهی اوقات مینیمالیسم کدهای کروتر برای کنترل پیچیدگی سیستم‌های دنیای واقعی کافی نبود و برنامه‌نویسان دیگر باید آنچه را که کروتر ایجاد کرده بود را تصحیح می‌کردند. اما ایده‌های اصلی او اغلب درخشان بودند. والدن: ((بیشتر ما با رسیدگی به جزئیات ناشی از استفاده ویل از مغزش، زندگی خود را می‌گذراندیم.))

کنترل جریان یکی دیگر از چالش‌های برنامه‌نویسی بود. هنگامی که کان به کد کروتر نگاه کرد و دید چگونه کنترل جریان بسته‌ها را از یک طرف شبکه به سمت دیگر برده است، نگران شد. قرار بود پیام‌های بین میزبان‌ها توسط زیرشبکه‌ها و از طریق ((لینک‌های)) منطقی منتقل شوند. زیرشبکه هر بار تنها یک پیام را از لینک داده شده می‌پذیرفت. پیام‌هایی که منتظر ورود به زیر شبکه بودند، در یک بافر حافظه (منطقه انتظار در داخل دستگاه) و در یک صف ذخیره می‌شدند. پیام بعدی تا زمانی که IMP فرستنده، تاییدیه‌ای (چیزی شبیه به رسید برگشتی) مبنی بر دریافت بدون خطای پیام در مقصد، دریافت نکرده است، در صف انتظار می‌ماند. هنگامی که یک لینک آزاد شد و پیام جدیدی آماده ارسال می‌شد و زیرشبکه به وسیله یک سیگنال کنترلی ویژه که مهندسان BBN آن را ((آمادگی برای پیام بعدی)) یا RFNM Ready for Next Message (راف-نام تلفظ می‌شد) نامیدند، به IMP ارسال کننده اطلاع می‌داد. پیام‌های موجود در بافرهای میزبان ارسال کننده، در انتظار خالی شدن لینک‌ها، مانند مشتریانی بودند که در رستوران منتظر میز هستند و RFNMها معادل اعلان ((میز شما آماده است)) بودند.

این بدین خاطر بود که ارسال یک جریان مداوم از پیام‌ها بر روی یک لینک، غیرممکن بود. RFNM یک استراتژی کنترل تراکم است که برای محافظت از IMPها در برابر جریان پیام‌ها، طراحی شد، اما به قیمت کاهش خدمات به میزبان. کان حتی قبل از شروع پروژه شبکه آرپا، روی مشکل کنترل تراکم، مطالعه کرده بود. واکنش او به راه حل کروتر این بود که لینک‌ها و RFNMها همچنان اجازه ورود این تراکم ویرانگر را به شریان‌های شبکه می‌دهند. طبق نظر او، بافرهای IMP پر می‌شوند و سیستم پر می‌شود از پیام‌های ناقصی که در IMPها در انتظار رسیدن بسته‌ی نهایی‌شان نشسته‌اند تا پیام کامل شود ولی جایی برای رسیدن بسته‌ها وجود ندارد.

سناریوی تراکم شبکه کان را می‌توان به شیوه‌ای ملموس توضیح داد. فرض کنید که یکی از نمایندگی‌های تویوتا در ساکرامنتو، مجموعه‌ای از بسته‌های سیلندر و پیستون را از انباری در یوکوهاما سفارش می‌دهد. هر دو مورد برای کاری که فروشنده می‌خواهد انجام دهد، ضروری هستند. در بندر یوکوهاما، کشتی‌ها در حال بارگیری کانتینرهای بزرگ، هم اندازه و پر از محصولات مختلف هستند. جعبه‌های سیلندر و پیستون‌ها در کشتی‌هایی مجزا ارسال می‌شوند. هنگامی که کانتینر جعبه‌های سیلندر به سانفرانسیسکو می‌رسد، در انباری از محموله‌های دیگر که همگی منتظر رسیدن سایر قطعاتشان قبل از ارسال به مقصد هستند، تخلیه می‌شود: قطعات دستگاه‌های تلویزیون، کلید‌های پیانو و غیره. وقتی کشتی باری با پیستون می‌رسد، انبار دیگر پر است. هر کشتی بعدی نیز همین مشکل را دارد؛ هیچ کس نمی‌تواند بارش را تخلیه کند. و هیچ چیز نمی‌تواند از انبار خارج شود. بن بست. راه حل؟ بندر یوکوهاما موافقت می‌کند که دفعه بعد قبل از ارسال، فضا برای همه کانتینرهایی که به هم مربوط هستند را رزرو کند. اگر فضا در دسترس نباشد، صبر می‌کند تا تمام فضا در دسترس باشد.

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

کان و کروتر به طور طولانی در مورد ترافیک شبکه بحث کردند. این دیدگاه‌های تئوری کان، در تضاد آشکار با مسیر عمل‌گرایانه بقیه بچه‌های IMP قرار گرفته بودند و اختلاف نظر گسترده‌ای را بین آنها ایجاد کرده بود. بقیه اعضای تیم فقط می‌خواستند شبکه را طبق برنامه راه اندازی کنند. با رشد شبکه، آنها زمان لازم برای بهبود عملکرد، حل مشکلات و تکمیل الگوریتم‌ها داشتند.

اما کان بر حل این مشکلات اصرار داشت. او گفت: ((اینها برای من نقص‌های آشکاری بودند. بدیهی‌ترین مورد این بود که شبکه می‌تواند در همین بن بست‌ها، به طور کامل قفل شود.)) کان مطمئن بود که شبکه قفل خواهد شد و نظرش را فورا به هارت و دیگران گفت. آن‌ها با او بحث کردند. کروتر گفت: ((باب به تئوری اشیا theory of things و ریاضیات علاقه‌مند بود، اما واقعا علاقه‌ای به اجرای عملی نداشت.)) کروتر و کان مدام در مورد آن بحث و گفتگو می‌کردند. طرح کنترل جریان آنها برای یک شبکه بزرگ طراحی نشده بود و کروتر فکر می‌کرد، این طرح صرفا برای تعداد کمی نود کار خواهد کرد.

هارت فکر می‌کرد که کان بیش از حد نگران اتفاقات بسیار بعید در شبکه است. رویکرد او منتظر ماندن و دیدن بود. برخی دیگر در این عقیده بودند که کان بسیاری از مشکلاتی را که آنها با آن دست و پنجه نرم می‌کنند را درک نمی‌کند. اورنشتاین گفت: ((بعضی از چیزهایی که او پیشنهاد می‌کرد کاملا غیرقابل تصور بودند.)) کان می‌خواست ترافیک شبکه را روی صفحه نمایش شبیه‌سازی کند. او می‌خواست برنامه‌ای داشته باشد که بسته‌ها را در حال حرکت در شبکه نشان دهد. اما بسته‌ها هرگز با سرعت قابل مشاهده توسط انسان حرکت نمی‌کردند؛ آنها در یک میلی ثانیه یا حتی میکروثانیه منتقل می‌شدند. دیگر بچه‌های IMP به کان احترام می‌گذاشتند، اما برخی معتقد بودند که او در مسیر اشتباهی حرکت می‌کند و با گذشت زمان کمتر به او توجه کردند. اورنشتاین گفت: ((بیشتر ما در گروه سعی می‌کردیم دیگر کمتر به کان توجه کنیم.))

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

با اوج گرفتن تابستان، یک مشکل نگران کننده ظاهر شد؛ BBN هنوز در انتظار تحویل اولین IMP تولیدی توسط هانیول با تمام اصلاحات مورد نیاز BBN بود. اما تیم برنامه‌نویسی انتظار را رها کرده و با بارگذاری یک سیستم توسعه درجه پایین همراه با یک برنامه شبیه‌سازی برای شبیه‌سازی عملیات‌های IMP و رابط های ورودی-خروجی، به کار خود ادامه می‌داد. با این حال، ترجیح همه، آزمایش نرم‌افزار بر روی یک ماشین واقعی بود. و هر زمان که دستگاه وارد می‌شد، بارکر ابتدا باید آن را دیباگ می‌کرد. زمان باقی مانده رو به کاهش بود. در اواخر تابستان، دستگاه هنوز وارد محل بارگیری BBN نشده بود.

باگ

سرانجام، هانیول، حدود دو هفته قبل از روز کارگر، اولین IMP 516 تقویت شده را با عجله به کمبریج رساند. به محض ورود دستگاه به BBN، بارکر آماده کار بر روی آن شد. او IMP شماره یک را در اتاق پشتی روشن کرد.

بارکر کد تست IMP را بارگذاری کرد. وقتی سعی کرد آن را اجرا کند، هیچ اتفاقی نیفتاد. دستگاه جواب نداد. در بررسی دقیق‌تر، مشخص شد که دستگاه دریافتی BBN، آن چیزی نیست که سفارش داده است. این ۵۱۶ تعداد کمی از تغییراتی را که بارکر و اورنشتاین در نمونه اولیه انجام داده بودند را داشت. در واقع، درست مانند نمونه اولیه، ناکارآمد سیم کشی شده بود. با به پایان رسیدن ددلاین، بارکر تنها یک راه حل داشت؛ آن را در BBN تعمیر کنید. حداقل این بار از قبل می‌دانست که هر سیم باید کجا برود. در حالی که دستگاه در وسط اتاق بزرگ نشسته بود، بارکر برای اجرای تمام تغییرات لازم برای تبدیل آن به یک IMP کارآمد، دست به کار شد.

در عرض چند روز، بارکر دستگاه را زنده کرد. او موفق شد رابط‌های IMP را فعال کند (که پس از آن، کامپیوتر در فواصل زمانی تصادفی شروع به کرش کرد.) تصادفی بودن کرش‌ها بسیار غیرعادی بود. IMP از دوازده تا چهل ساعت به طور متوالی کار می‌کرد، سپس می‌مرد و و همانطور می‌ماند. چه باید کرد؟ اورنشتاین به یاد آورد: ((ما نمی‌توانستیم بفهمیم چه اتفاقی دارد می‌افتد.))

با نزدیک شدن به روز کارگر، آنها بر IMP فشار آوردند و آن را تا حد امکان تحت آزمایش‌های سخت قرار دادند. ممکن بود بیست و چهار ساعت به خوبی کار کند، سپس به طور غیرقابل توضیحی متوقف شود. بارکر به دنبال سرنخی می‌گشت، آنچه را که به نظر می‌رسید مشکل است تعقیب می‌کرد، آن را برطرف می‌کرد، و باز هم دستگاه دوباره خراب می‌شد. در حالی که تنها چند روز تا پایان مهلت تحویل باقی مانده بود، به نظر می رسید که دستگاه قصد ندارد درست شود.

IMP دارای ساعتی بود که توسط سیستم عامل برای حفظ زمان در دستگاه استفاده می‌شد. این سیستم زمان را برحسب میکروثانیه(یک میلیون پالس در ثانیه) حفظ می‌کرد. برای آن موقع، سریع بود اما تقریبا صد برابر کندتر از رایانه‌های شخصی امروزی. این ساعت فریم‌ورکی را ارائه می‌داد که IMP عملیات‌هایش را در آن انجام می‌داد و بسیاری از عملکردهای سیستم را هماهنگ می‌کرد. در یک سیستم ارتباطی، پیام‌ها بدون اطلاع قبلی می‌رسند؛ سیگنال‌ها به طور ناهماهنگ وارد دستگاه می‌شوند. مانند یک تماس تلفنی در وسط شام، یک بسته دریافتی طبق برنامه خود به IMP می‌رسد و می گوید: ((حالا مرا ببر.))

رایانه دارای سیستم پیچیده‌ای برای مدیریت وقفه‌های ورودی بود تا عملکرد هماهنگ سیستم مختل نشود. چنین سینکرونایزر‌هایی(هماهنگ کننده) اگر به درستی طراحی نشده باشند، می‌توانند توسط سیگنال ورودی که درست در لحظه اشتباه وارد می‌شود، به مشکل بخورند. چنین باگ‌هایی نادر هستند، اما هنگامی که رخ دهند، سینکرونایزر به درستی به یک وقفه پاسخ نمی‌دهد و عواقب آن به شدت برای عملکرد کلی دستگاه مخرب است. شاید بتوان آن را یک فروپاشی عصبی نامید با این حال دانشمندان کامپیوتر اصطلاح دیگری برای آن دارند: سینکرونایزر وارد یک وضعیت (( شبه پایدار metastable )) می‌شود. اورنشتاین گفت: ((در چنین شرایطی، ماشین دائما در یک حالت گیج‌کننده عجیب به مشکل می‌خورد، هر بار متفاوت از قبل.))

اورنشتاین به خوبی با باگ‌های سینکرونایزر آشنایی داشت. او با این مشکل در کامپیوتری که چند سال قبل همراه با وس کلارک در سنت لوئیس ساخته بود، برخورد کرده بود. اورنشتاین نویسنده برخی از اولین مقالات منتشر شده در این زمینه بود و یکی از معدود افرادی در جهان بود که تجربه مواجهه با این گرملین‌ها موجوداتی افسانه‌ای که با شل کردن پیچ‌ها یا غیره، به ماشین‌ها و دستگاه‌ها صدمه می‌زنند را داشت.

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

این مشکلی بود که اورنشتاین و بارکر باید حلش می‌کردند. اما چه کسی می‌دانست با چه چیزی روبه‌رو هستند و الان باید چیکار کنند؟ هانیول ۵۱۶هرگز به عنوان یک سیستم سوئیچینگ بسته استفاده نشده بود. یک ماشین سریع بود و بچه‌های IMP برای قابلیت‌های ورودی-خروجی‌اش آن را انتخاب کرده بودند. احتمالا هیچکس دیگری در یک برنامه معمولی به این مشکل بر نمی‌خورد. اورنشتاین گفت: ((اگر دستگاه آنها سالی یک بار هم قطع شود، هرگز متوجه نمی‌شوند. ریستارتش می‌کنند و بدون مشکل ادامه می‌دهند.)) اما کار بچه‌های IMP بسیار پرفشار بود. جریان بسته‌ها به داخل و خارج از IMP سریع‌تر از آنچه طراحان هانیول پیش‌بینی کرده بودند اتفاق می‌افتاد. به نظر نمی‌رسید دستگاه ۵۱۶ قادر به مدیریت چنین ترافیکی باشد. شاید BBN بیش از حد خوشبین بوده است. اورنشتاین و بارکر به هانیول رفتند و اصرار کردند که سازنده و طراح کامپیوتر ۵۱۶ را به اتاق پشتی ببرند. او یک مرد بسیار باهوش بود، اما در ابتدا از پذیرفتن این که حالت شبه پایدار در دستگاه امکان پذیر است، امتناع کرد. او هرگز مقالات اورنشتاین را نخوانده بود و هرگز چنین مشکلی ندیده بود. اورنشتاین گفت: ((اگرچه پر از ناباوری بود، اما حداقل متوجه شد که ما چه می‌گوییم)).

در شرایط عادی، ۵۱۶ سال‌ها بدون مشکل سینکرونایزر کار می‌کرد. با این حال، تحت شرایط شبکه سوئیچینگ بسته آرپا، دستگاه هر روز، یک بار از کار می‌افتاد. حال چگونه می‌توان چنین چیزی را به فرانک هارت، مردی که فقط با قابلیت اطمینان زندگی می‌کند، گفت؟

اورنشتاین و بارکر آماده شدند. مشکل سینکرونایزر در IMP فقط یک حدس بود. برای آزمایش این فرضیه، اورنشتاین یک (( تشدیدکننده aggravator )) طراحی و آماده کرد که عمدا درخواست‌های داده را با آنچه بارکر آن را ((نرخ تشدید)) می‌نامید، تولید کند. این کار احتمال ایجاد وقفه‌ای که مشکل را آشکار کند، افزایش می‌داد. تشدید کننده یک پیچ داشت که مانند تیونر کار می‌کرد. با استفاده از این پیچ، اورنشتاین و بارکر می‌توانستند زمان‌بندی درخواست‌ها را به گونه‌ای تنظیم کنند که سیگنالی را کاملا خارج از چرخه‌ی کلاک دستگاه و در بدترین زمان ممکن، وارد کنند. سپس با استفاده از یک اسیلوسکوپ، ((ضربان قلب)) دستگاه و سایر عملکردهای داخلی آن را مشاهده می‌کردند.

گروه دیباگ کارشان را شروع کردند. الگوهایی که آنها در اسیلوسکوپ به دنبال آن بودند به قدری کمرنگ بودند که فقط در یک تاریک‌خانه قابل مشاهده بود. بنابراین با خاموش کردن تمام چراغ‌های اتاق IMP و استفاده از تمامی تجهیزات تشخیصی موجود، هانیول را روشن و در حالی که با تشدید کننده کار می‌کردند، منتظر ماندند. ردپایی که آن‌ها روی صفحه دیدند، روشن، منظم و با سرعت ثابت بود، تمامی نشانه‌های حیاتی یک دستگاه سالم.

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

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

در حالی که بارکر و اورنشتاین به طور منطقی مطمئن بودند که مشکل برطرف شده است، آنها هیچ راهی برای اطلاع دقیق نداشتند مگر اینکه دستگاه برای چند روز متوالی بدون خرابی کار کند. و آنها چند روز فرصت نداشتند. هارت از قبل، ارسال اولین IMP به کالیفرنیا را در روز بعد تایید کرده بود. IMP شماره یک فردا باید ارسال می‌شد.

« فصل سوم فصل پنجم »