Home

Page 129
Page 129
background image

не смог до конца передать ранее, при этом клиент должен начать передавать 
сообщение не с начала, а с той точки, которую указал сервер в отклике 355. 
Рассмотрим пример из RFC1845:

S: <wait for connection on TCP port 25>
C: <open connection to server>

S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu

S: 250-dbc.mtview.ca.us says hello
S: 250 CHECKPOINT

C: MAIL FROM:<ned@ymir.claremont.edu> TRANSID=<12345@claremont.edu>
S: 250 <ned@ymir.claremont.edu>... Sender and TRANSID ok

C: RCPT TO:<mrose@dbc.mtview.ca.us>
S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok

C: DATA
S: 354 Send checkpointed message, ending in CRLF.CRLF

<some amount of message data transmitted>
<session is interrupted and TCP connection is broken>

Some time later a new connection is established:

S: <wait for connection on TCP port 25>
C: <open connection to server>

S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu

S: 250-dbc.mtview.ca.us says hello
S: 250 CHECKPOINT

C: MAIL FROM:<ned@ymir.claremont.edu> TRANSID=<12345@claremont.edu>
S: 355 6135 is the transaction offset

C: DATA
S: 354 Send previously checkpointed message starting at octet 6135

C: <message data minus first 6135 octets sent>
C: .

S: 250 OK
C: QUIT

S: 221 Goodbye

Очевидно,   важнейшим   является   вопрос   о   том,   как   долго   серверу   стоит 

хранить кусок не до конца переданного сообщения в ожидании того, что клиент 
его докачает. Серверу рекомендуется хранить такую часть сообщения 48 часов, 
никакого   способа   для   сервера   сообщить,   сколько   сервер   намерен   хранить 
частично переданное сообщение в  RFC  не предусмотрено, хотя это, вероятно, 
имело   бы   смысл.   Таким   образом,   статус   рассмотренного   нами  RFC  – 
экспериментальный, современные почтовые сервера (в частности и  MS  IIS) не 
поддерживают данного расширения и области применения данного расширения 
сомнительны. 

Переходим   к   рассмотрению   следующего   расширения   протокола  SMTP. 

Проанализируем, как много задержек имеет место при обмене данными в рамках 
протокола  SMTP. Проанализируем некий типичный трафик – небольшое письмо 
отправляется 3 получателям (to_3.cap).

Как видно, клиент передает серверу подряд целый набор команд:  EHLO, 

MAIL, RCPT, RCPT, RCPT, DATA и ожидает ответа на КАЖДУЮ команду. При этом, 
если,   к   примеру,   задержка   в   сети   составляет   около   200   мс,   то   суммарное 
потерянное время на ожидания клиента составляют около 1,2 секунды, при том, 
что на самом деле передается всего 700 байт данных. Т.е., какой бы ни была 
пропускная способность канала связи клиента с сервером, фактическая
достижимая пропускная  способность при передаче данного письма составляет 
около   4700   бит/с!   С   одной   стороны  SMTP  пользуется   транспортом  TCP,   с   его 
механизмом управления потоком с помощью скользящего окна, с другой стороны 


Copyright © 2022 Файлообменник files.d-lan.dp.ua

Использование любых материалов сайта возможно только с разрешения автора.