Кратко

  • NETRJS превращал удалённый узел в виртуальный пакетный терминал для IBM 360/91 центра UCLA-CCN.
  • Консоль, карточный ввод и вывод использовали отдельные каналы; RFC также фиксируют проблемы преобразования символов и доставки результата.

Результат мог прийти после отключения

Пакетное задание могло завершиться уже после того, как пользователь отключился. NETRJS позволял отправить его из удалённого узла в Campus Computing Network при UCLA, выйти из системы, а затем вернуться за результатом. ARPANET доставляла входные данные к машине и возвращала вывод пользователю. Практической единицей был весь круг задания, а не момент открытия соединения.

Виртуальный терминал подключил пакетную работу к сети

RFC 740 1977 года называет NETRJS частным протоколом UCLA-CCN для пакетной отправки заданий на IBM 360 Model 91. Та же система RJS обслуживала настоящие карточные терминалы и по прямым линиям связи. Это была конкретная вычислительная услуга с несколькими путями доступа, а не доказательство того, что все задания ARPANET выполнялись в UCLA.

Работа завершалась только после доставки вывода

Удалённая сторона представлялась как Virtual Remote Batch Terminal: виртуальный считыватель карточек принимал задания, принтер и перфоратор возвращали результат, а операторская консоль обрабатывала вход, команды, состояние и ошибки. Задание передавалось последовательностью карточных образов длиной до 80 символов с языком управления заданиями. Сервер помещал его в очередь пакетной системы согласно приоритету и отправлял печатный или перфолентный вывод обратно тому же терминалу. Пользователь мог ждать или вернуться позднее.

Управление и данные шли отдельно. Консоль использовала полнодуплексное Telnet-соединение; считыватель, принтер и перфоратор — каждый свой симплексный канал. Между процессами пользователя и сервера могло быть до пяти соединений. Каналы данных требовалось открывать только на время работы, а ввод, печать и перфорация могли выполняться одновременно. Удалённый узел управлял моделью пакетных устройств, а не интерактивным терминальным сеансом.

NETRJS существовал до документа 1977 года. RFC 88 описал его в 1971-м; RFC 599 обновил в 1973-м; RFC 740 заменил RFC 189 и RFC 599. Обновление 1973 года сохраняет редкий эксплуатационный срез: за октябрь UCLA-CCN принял через NETRJS 1 373 задания; 1 105 были напечатаны, ни одно не перфорировано. Зафиксированы 49 400 прочитанных карточек, 822 900 строк, 18 907 страниц и 393,6 часа соединения. Это показатель одного сервиса за один месяц, а не всей ARPANET. Среднее задание с 360 входными строками («карточками») и 745 выходными строками на 17,1 страницы названо достаточно типичным.

Но эти числа не гарантировали доставку результата. RFC 599 описывает сбой «squish»: из-за буферизации NCP пакетный компьютер мог удалить короткий печатный файл ещё до получения первой строки удалённым узлом. Сбой удалённой машины или отмена пользователем могли лишить его единственной копии. Исправление заставляло NETRJS ждать подтверждение RFNM конца данных, прежде чем просить RJS удалить вывод. Завершение пересекало две границы: вычисление и доставку.

Наборы символов были ещё одной границей. IBM 360 в UCLA работал с EBCDIC, а некоторые удалённые клиенты — с ASCII. В 1972 году пользователи RAND, Utah и Illinois указали на недостатки исходного преобразования; UCLA изменила таблицу и добавила ещё одну. RFC 740 позволял виртуальному терминалу выбрать EBCDIC, ASCII-68 или ASCII-63, а сервер при необходимости преобразовывал карточный ввод и печатный вывод.

NETRJS показывает Интернет, который мог переносить запланированную вычислительную работу, а не только диалог в реальном времени. Пользователь отправлял структурированное задание, служба выбирала время запуска, отдельные каналы возвращали продукт. RFC описывают практический контракт: вход, карточный поток, получение результатов, совместимость символов и подтверждение перед удалением. Сеть обеспечивала доступ к машине; услуга делала пригодным весь цикл.

Первичные источники