Искусство программирования для Unix - Реймонд Эрик Стивен
Шрифт:
Интервал:
Закладка:
5.3.1. Учебный пример: SMTP, простой протокол передачи почты
В примере 5.7. иллюстрируется транзакция SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты), который описан в спецификации RFC 2821. В данном примере строки, начинающиеся с С:, отправляются почтовым транспортным агентом (Mail Transport Agent — МТА), который отправляет почту, а строки, начинающиеся с 5:, возвращаются агентом (МТА), принимающим ее. Текст, выделенный курсивом, представляет собой комментарии и не является частью реальной транзакции.
Так почта передается между Internet-машинами. Следует отметить ряд особенностей: формат команд и аргументов запросов, ответы, содержащие код состояния, за которым следует информационное сообщение, и то, что полезная нагрузка команды DATA ограничивается строкой, содержащей одну точку.
Пример 5.7. SMTP-сеанс
С: <клиент подключается к служебному порту 25>
С: HELO snark.thyrsus.com отправляющий узел
идентифицирует себя S: 250 OK Hello snark, glad to meet you подтверждение получателя С: MAIL FROM: <esr®thyrsus.com> идентификация отправляющего
пользователя
S: 250 <esr®thyrsus.com>... Sender ok подтверждение получателя С: RCPT TO: [email protected] идентификация целевого
пользователя
S: 250 root... Recipient ok подтверждение получателя
С: DATA
S: 354 Enter mail, end with "." on a line by itself С: Звонил Scratch. Он хочет снять с нами С: комнату в Balticon.
С: . отправляется окончание
многострочной записи S: 250 WAA01865 Message accepted for delivery
С: QUIT отправитель отключается
S: 221 cpmy.com closing connection получатель отключается
С: <клиент разрывает соединение>
SMTP один из двух или трех старейших протоколов прикладного уровня, которые до сих пор используются в Internet. Он прост, эффективен и выдержал проверку временем. Особенности, описанные здесь, часто повторяются в других Internet-протоколах. Если существует какой-либо один образец того, как выглядит хорошо спроектированный протокол Internet-приложения, то им, несомненно, является SMTP.
5.3.2. Учебный пример: РОРЗ, почтовый протокол 3-й версии
Другим классическим Internet-протоколом является РОРЗ (Post Office Protocol — почтовый протокол 3-й версии). Он также используется для транспортировки почты, но если SMTP является "толкающим" протоколом с транзакциями, инициированными отправителем почты, то РОРЗ является протоколом "тянущим", а его транзакции инициируются получателем почты. Internet-пользователи с непостоянным доступом (например, по коммутируемым соединениям) могут накапливать свою почту на почтовом сервере, а затем, подключившись к РОРЗ-серверу, получать почту на персональные машины.
В примере 5.8. показан РОРЗ-сеанс. В данном примере строки, начинающиеся с С:, отправляются клиентом, а строки, начинающиеся с S:, почтовым сервером. Необходимо отметить множество моментов, сходных с SMTP. Протокол РОРЗ также является текстовым и строчно-ориентированным. В данном случае, так же как в случае SMTP, отправляются блоки полезной нагрузки сообщений, ограниченные строкой, содержащей одну точку, за которой следует ограничитель строки, и даже используется такая же команда выхода — QUIT. Подобно SMTP, в протоколе РОРЗ каждая клиентская операция подтверждается ответной строкой, которая начинается с кода состояния и включает в себя информационное сообщение, понятное человеку.
Пример 5.8. РОРЗ-сеанс
С: <клиент подключается к служебному порту 110>
S: +ОК РОРЗ server ready <1896.697l®mailgate.dobbs.org>
С: USER bob
S: +0K bob
C: PASS redqueen
S: +0K bob's maildrop has 2 messages (320 octets)
C: STAT
S: +OK 2 320
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
C: RETR 1
S: +0K 120 octets
S: <P0P3-сервер отправляет текст сообщения 1>
S: .
С: DELE 1
S: +0К message 1 deleted
С: RETR 2
S: +0K 200 octets
S: <P0P3-сервер отправляет текст сообщения 2>
S: .
С: DELE 2
S: +ОК message 2 deleted
С: QUIT
S: +0K dewey РОРЗ server signing off (maildrop empty)
С: <клиент разрывает соединение>
В то же время существует несколько отличий. Наиболее очевидным из них является то, что в протоколе РОРЗ используются маркеры состояния вместо трехзначных кодов состояния, применяемых в SMTP. Несомненно, семантика запросов различна, однако "семейное сходство" (которое более подробно будет описано далее в настоящей главе при рассмотрении общего метапротокола Internet) очевидно.
5.3.3. Учебный пример: IMAP, протокол доступа к почтовым сообщениям
Чтобы завершить рассмотрение примеров с протоколами прикладного уровня Internet, рассмотрим протокол IMAP (Internet Message Access Protocol — протокол доступа к почтовым сообщениям в Internet). IMAP — другой почтовый протокол, спроектированный в несколько ином стиле. Как и в предыдущих примерах, строки, начинающиеся с С:, отправляются клиентом, а строки, начинающиеся с 5:, отправляются почтовым сервером. Текст, выделенный курсивом, представляет собой комментарии и не является частью реальной транзакции.
Пример 5.9. IMAP-сеанс
С: <клиент подключается к служебному порту 143>
S: * ОК example.com IMAP4revl V12.264 server ready
С: А0001 USER "frobozz" "xyzzy"
S: * OK User frobozz authenticated
C: AO002 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
С: A0003 FETCH 1 RFC822.SIZE получение размеров сообщений
S: * 1 FETCH (RFC822.SIZE 2545) S: A0003 OK FETCH completed
C: AO004 FETCH 1 BODY[HEADER] получение заголовка первого
сообщения
S: * 1 FETCH (RFC822.HEADER {1425}
<сервер отправляет 1425 октетов полезной нагрузки сообщения> S: )
S: АО004 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 IMAP4revl server terminating connection S: A0006 OK LOGOUT completed С: <клиент разрывает соединение>
В IMAP полезная нагрузка ограничивается несколько иначе. Вместо завершения блока полезной нагрузки с помощью точки перед ним отправляется его длина. Это несколько увеличивает накладные расходы на сервере (сообщения должны быть скомпонованы заранее, их невозможно просто установить в поток после того, как отправка инициирована), однако упрощает работу клиента, поскольку предоставляет возможность заранее определить объем пространства, которое необходимо выделить в целях буферизации сообщения для его обработки в целом.
