Resumo

  • Depois que o servidor anunciasse PIPELINING em EHLO, o cliente podia enviar um grupo de comandos sem esperar cada resposta, embora cada decisão continuasse separada.
  • A economia de latência dependia de contagem posicional, fronteiras de estado, respostas multilinha corretas, respeito ao fluxo TCP e uma promessa absoluta de não perder entrada já recebida.

O custo morava entre as linhas

Uma sessão SMTP comum alterna ordem e resposta: identificação, espera; remetente, espera; destinatário, espera; pedido para iniciar os dados, outra espera. O RFC 2920 observou que, em enlaces de alta latência, esse vaivém podia dominar a duração da conexão.

O pipelining deixava vários comandos partirem antes da primeira resposta voltar. O servidor ainda julgava cada um; só os intervalos eram sobrepostos. Por isso o ganho trazia uma nova obrigação: várias intenções ficavam simultaneamente pendentes e precisavam conservar seus donos.

No modo passo a passo, há uma pergunta aberta. No lote, a próxima resposta só faz sentido se o cliente mantiver a sequência exata.

Uma palavra declarou capacidade real

TCP entrega bytes em ordem, mas servidores implantados nem sempre preservavam o que liam. O RFC 2920 relata passagem de conexão entre processos que perdia dados pré-lidos, limpeza indevida do buffer TCP depois de um comando falhar e confusão entre o último RCPT TO, o conjunto de destinatários e DATA.

O cliente precisava, portanto, enviar EHLO e receber 250 com PIPELINING. O registro SMTP da IANA mantém a palavra-chave ligada ao RFC 2920 e sem parâmetro.

Ela não informa tamanho de lote, velocidade ou garantia de entrega. O servidor declara que sabe manter a disciplina; o cliente decide se vai usá-la e quantas ordens deixará sem resposta.

A mudança de estado fechava o grupo

RSET, comandos de remetente e RCPT TO podem ficar no meio de um grupo. EHLO, DATA, VRFY, EXPN, TURN, QUIT e NOOP devem encerrá-lo, porque seu resultado muda o estado que o cliente terá de acomodar. NOOP serve, assim, como ponto de sincronização.

A regra separa paralelismo de dependência. Vários destinatários podem aguardar decisões independentes; o cliente não pode agir como se DATA já tivesse aberto a próxima fase. Extensões posteriores podem definir outros limites, mas ausência de regra não é permissão.

Código e texto não diziam de quem era a resposta

Num exemplo construído, um remetente, três destinatários e DATA geram cinco decisões pendentes. Códigos podem se repetir e textos variam. O RFC 2920 proíbe usar qualquer dos dois para descobrir a correspondência.

O cliente deve contar cada resposta separada e associá-la à posição do comando emitido. Precisa verificar todas. Mesmo que todos os destinatários falhem, não pode presumir a rejeição de DATA. Se o servidor aceitar por engano, o cliente envia apenas o ponto final, não uma mensagem sem destinatário.

Respostas SMTP também podem ocupar várias linhas. O hífen depois do código identifica linhas intermediárias; a final não o traz. Contar linhas como decisões desloca toda a sequência. O significado explica o resultado depois que seu dono foi identificado; não identifica o dono.

Ordem TCP não era garantia de progresso

Um cliente não bloqueante pode ler respostas enquanto uma escrita anterior ainda está pendente. Um cliente bloqueante deve garantir que o grupo inteiro caiba na janela TCP disponível. Caso contrário, pode esperar terminar a escrita enquanto o servidor espera que ele leia as respostas já produzidas.

O RFC 2920 mencionava historicamente uma janela geralmente, mas nem sempre, de 4K octetos. Isso não é ajuste universal moderno. A regra durável é fazer o lote caber no fluxo real ou ler e escrever em paralelo.

O PIPELINING aumenta a intenção sem confirmação. Concorrência gera vazão; um limite verificável preserva a capacidade de avançar.

O servidor não podia apagar o que recebeu

Ao anunciar PIPELINING, o servidor deve responder na ordem, não pressupor comandos futuros e liberar respostas pendentes quando seu buffer TCP local esvaziar. Sob nenhuma circunstância pode limpar ou perder o conteúdo da entrada.

Falhar um destinatário não autoriza apagar o comando seguinte. Transferir uma conexão entre processos não transforma bytes pré-lidos em rascunho descartável. O fluxo já é evidência da intenção do cliente.

Algumas respostas comuns podem ser agrupadas, mas não as dos comandos que encerram o lote nem as de comandos desconhecidos. Eficiência não pode esconder o momento em que o cliente precisa mudar de rumo.

O documento mudou; o mecanismo permaneceu

O RFC 1854 apresentou a extensão em 1995. O RFC 2197 o substituiu em 1997, declarando apenas mudanças editoriais. O RFC 2920 tornou-se STD 60 em 2000. O RFC 5321 ainda descreve SMTP como propositalmente passo a passo, salvo extensões mutuamente acordadas como essa.

PIPELINING não autentica pares, aceita remetentes ou destinatários, reserva recursos, entrega a mensagem ou prova apoio no próximo retransmissor. Autoriza uma concorrência limitada nesta sessão.

Seu valor histórico foi tornar parte da espera opcional somente onde os programas em execução preservavam a prova necessária. Publicar a norma nunca virou prova automática de adoção.

Fontes e limites

A sequência normativa está no RFC 1854, RFC 2197 e RFC 2920. O quadro SMTP vem do RFC 5321, e o registro atual da IANA. Essas fontes não medem adoção atual, ganho de desempenho, padrão de fornecedor ou taxa de falha.