Искусство программирования для Unix

S: .
С: DELE 2
S: +OK message 2 deleted
С: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
C: <клиент разрывает соединение>

В то же время существует несколько отличий. Наиболее очевидным из них является то, что в протоколе POP3 используются маркеры состояния вместо трехзначных кодов состояния, применяемых в SMTP. Несомненно, семантика запросов различна, однако "семейное сходство" (которое более подробно будет описано далее в настоящей главе при рассмотрении общего метапротокола Internet) очевидно.

5.3.3. Учебный пример: IMAP, протокол доступа к почтовым сообщениям

Чтобы завершить рассмотрение примеров с протоколами прикладного уровня Internet, рассмотрим протокол IMAP (Internet Message Access Protocol — протокол доступа к почтовым сообщениям в Internet). IMAP — другой почтовый протокол, спроектированный в несколько ином стиле. Как и в предыдущих примерах, строки, начинающиеся с С:, отправляются клиентом, а строки, начинающиеся с 5:, отправляются почтовым сервером. Текст, выделенный курсивом, представляет собой комментарии и не является частью реальной транзакции.

Пример 5.9. IMAP-сеанс

С: <клиент подключается к служебному порту 143>
S: * OK example.com IMAP4rev1 V12.264 server ready
С: А0001 USER "frobozz" "xyzzy"
S: * OK User frobozz authenticated
C: A0002 SELECT INBOX
S: * 1 EXISTS
S: * 1 RECENT
S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
S: * OK [UNSEEN 1] first unseen message in /var/spool/mail/esr
S: A0002 OK [READ-WRITE] SELECT completed
C: A0003 FETCH 1 RFC822.SIZE получение размеров сообщений
S: * 1 FETCH (RFC822.SIZE 2545)
S: A0003 OK FETCH completed
C: A0004 FETCH 1 BODY[HEADER] получение заголовка первого
 сообщения
S: * 1 FETCH (RFC822.HEADER {1425}
<сервер отправляет 1425 октетов полезной нагрузки сообщения>
S: )
S: А0004 OK FETCH completed
С: А0005 FETCH 1 BODY[TEXT] получение тела первого
 сообщения
S: * 1 FETCH (BODY[TEXT] {1120}
<сервер отправляет 1120 октетов полезной нагрузки сообщения>
S: )
S: * 1 FETCH (FLAGS (\Recent \Seen))
S: А0005 OK FETCH completed
С: A0006 LOGOUT
S: * BYE example.com IMAP4rev1 server terminating connection
S: A0006 OK LOGOUT completed
C: <клиент разрывает соединение>

В IMAP полезная нагрузка ограничивается несколько иначе. Вместо завершения блока полезной нагрузки с помощью точки перед ним отправляется его длина. Это несколько увеличивает накладные расходы на сервере (сообщения должны быть скомпонованы заранее, их невозможно просто установить в поток после того, как отправка инициирована), однако упрощает работу клиента, поскольку предоставляет возможность заранее определить объем пространства, которое необходимо выделить в целях буферизации сообщения для его обработки в целом.

Кроме того, следует заметить, что каждый ответ маркируется последовательной меткой, передаваемой в запросе. В данном примере такие метки имеют форму A000n, однако клиент может генерировать любой маркер в данном поле. Данная особенность позволяет направлять серверу поток IMAP-команд, не ожидая ответов. Конечный автомат клиента может затем просто интерпретировать ответы и блоки полезной нагрузки по мере их возвращения. Данная методика сокращает задержку.

Протокол IMAP (который был разработан для замены POP3) является превосходным образцом продуманной и мощной конструкции прикладного протокола в Internet, примером, достойным изучения и подражания.

5.4. Метаформаты протоколов прикладного уровня

Подобно тому, как были усовершенствованы метаформаты файлов данных, чтобы упростить сериализацию для хранения этих данных, метаформаты протоколов прикладного уровня были усовершенствованы, чтобы упростить сериализацию для передачи данных через сети. Правда, ввиду того, что полоса пропускания сети является более дорогой, чем устройства хранения, экономичность транзакций приносит больший выигрыш. Однако преимущества прозрачности и способности к взаимодействию текстовых форматов являются достаточно устойчивыми, поэтому большинство проектировщиков не поддались искушению оптимизировать производительность ценой читабельности.

5.4.1. Классический метапротокол прикладного уровня в Internet

RFC 3117 Маршала Роуза (Marshall Rose), "On the Design of Application Protocols" [54] представляет исключительный обзор вопросов проектирования протоколов прикладного уровня в Internet. В данном документе проясняются несколько черт классических протоколов прикладного уровня Internet, которые были отмечены выше при изучении SMTP, POP и IMAP, а также предоставляется информативная классификация таких протоколов. Данный документ входит в число рекомендуемой литературы.

54

Документ RFC 3117: <ftp://ftp.frc-editor.org/in-notes/rfc3117.txt>.

Классический метапротокол Internet является текстовым. В нем используются однострочные запросы и ответы, за исключением блоков полезной нагрузки, которые могут содержать множество строк. Блоки полезной нагрузки отправляются либо с предшествующей длиной, выраженной в октетах, либо с ограничителем, который представляет собой строку ".\r\n". В последнем случае полезная нагрузка заполняется байтами. Все строки, начинающиеся с точки, дополняются впереди еще одной точкой, а получатель отвечает за опознание ограничителя и удаление заполнения. Строки ответов состоят из кода состояния, за которым следует удобочитаемое сообщение.

Абсолютным преимуществом данного классического стиля является то, что его просто расширять. Структура синтаксического анализа и конечного автомата не нуждается в серьезных изменениях, для того чтобы приспособиться к новым запросам. И поэтому очень просто можно программировать реализации, которые способны осуществлять синтаксический анализ неизвестных запросов и возвращать ошибку или игнорировать их. Все протоколы SMTP, POP3 и IMAP за время их существования довольно часто незначительно расширялись с минимальными проблемами взаимодействия. В противоположность им, примитивно спроектированные двоичные протоколы печально известны как неустойчивые.