Кратко
- RFC 1179 описывала LPD как уже существующую практику: TCP-daemon на порту 515 принимал команды для именованной очереди печати, включая команду начать печать ожидающих заданий.
- В
Receive jobdaemon сначала подтверждал подкоманду файла; клиент нулевым октетом отмечал, что передал заявленную последовательность байтов; затем требовалось второе подтверждение. Эта цепочка говорит о приёме файла, но не о напечатанной странице.
У одного задания было несколько разных хозяев состояния
Задание не переходит из приложения на бумагу одним событием. Клиент просит, daemon принимает очередной шаг протокола, очередь удерживает ожидающую работу, процесс может быть запущен, управляющий файл задаёт толкование файла данных, и только затем устройство может создать физический результат. У каждого перехода свой исполнитель и свой предмет доказательства.
RFC 1179 была опубликована в августе 1990 года как информационное описание уже употреблявшегося протокола сервера печати, а не как Internet Standard. Она определяет команды, форматы файлов и ответы line printer daemon. Сетевой ответ не превращается в ней в заключение о бумаге, форматировании, работоспособности устройства или физической выдаче.
LPD работает поверх TCP, daemon слушает порт 515. Для каждой команды daemon создаётся новое соединение. За бинарным кодом следует ASCII-имя очереди и, при необходимости, другие операнды. RFC просит понимать названия команд как распоряжения daemon. Пришедшее распоряжение и наступивший результат — разные факты.
Команда Print any waiting jobs показывает это особенно ясно. Она запускает печатающий процесс, если он ещё не работает. Она не сообщает, что выбран конкретный job, что формат понятен, что в устройстве есть бумага или что появилась страница. Это распоряжение о запуске между приёмом файлов и наблюдением вывода.
Приём файла имел две точки подтверждения
После Receive job клиент может отправлять подкоманды для управляющего файла и файла данных. После подкоманды он обязан ждать подтверждения daemon. Октет из нулевых битов положителен, любой другой шаблон отрицателен. Первый ответ относится к очередному шагу обмена, а не ко всему заданию.
Затем появляется граница файла. Подкоманда содержит число байтов и имя файла. Клиент посылает это количество по тому же TCP-соединению и после завершения отправляет нулевой октет, объявляя переданный файл полным. После этого требуется второй уровень подтверждения. Та же схема действует для файла данных с указанной длиной.
Здесь нельзя подменять три записи одним успехом. Первое подтверждение касается подкоманды. Ноль клиента — утверждение о завершении заявленной последовательности. Второе подтверждение — реакция daemon после границы. Вместе они позволяют проследить приём, но не измеряют печать.
Количество байтов не толкует документ. RFC разрешает в файле данных любые 8-битные значения и возлагает его интерпретацию на соответствующий управляющий файл. Совпавший счётчик не доказывает пригодный формат, успешный rendering или превращение данных в лист бумаги.
Управляющий файл был инструкцией, а не удостоверением личности
Управляющий файл мог содержать хост, идентификатор пользователя, имя исходного файла, формат и просьбу прислать почту после печати. Это входные данные для daemon. Они не доказывают личность человека, право собственности на документ или доставку уведомления. Номер задания различает записи в ограниченной модели очереди, но не становится мировой постоянной идентичностью.
Тем же пределом ограничено администрирование очереди. LPD мог выдать состояние очереди и принять удаление заданий с указанием очереди, агента, имён или номеров. RFC ограничивает удаление чужих работ для агента, не являющегося root. Это правило локальной команды, а не полный ответ на вопрос, кто прочитал, выдал или получил документ.
Историческая ценность LPD в том, что она называет проверяемые промежуточные факты. Можно сказать, что daemon принял подкоманду, клиент объявил байты завершёнными, daemon ответил после этого, а очереди велели начать работу. О печати, вручении или дальнейшем эффекте можно говорить лишь при наличии отдельного свидетельства следующего участка.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
