E-MailRelay
|
A helper class for GSmtp::ServerProtocol that does buffering of data received from the remote peer and apply()s it to the server protocol. More...
#include <gsmtpserverbufferin.h>
Classes | |
struct | Config |
A configuration structure for GSmtp::ServerBufferIn. More... | |
Public Member Functions | |
ServerBufferIn (GNet::EventState, ServerProtocol &, const Config &) | |
Constructor. More... | |
~ServerBufferIn () | |
Destructor. More... | |
void | apply (const char *, std::size_t) |
Called when raw data is received from the peer. More... | |
void | expect (std::size_t) |
Forwards to GNet::LineBuffer::expect(). More... | |
std::string | head () const |
Returns GNet::LineBufferState::head(). More... | |
G::Slot::Signal< bool > & | flowSignal () noexcept |
Returns a signal that should be connected to a function that controls network flow control, typically by adding and removing the socket file descriptor from the event loop. More... | |
ServerBufferIn (const ServerBufferIn &)=delete | |
ServerBufferIn (ServerBufferIn &&)=delete | |
ServerBufferIn & | operator= (const ServerBufferIn &)=delete |
ServerBufferIn & | operator= (ServerBufferIn &&)=delete |
A helper class for GSmtp::ServerProtocol that does buffering of data received from the remote peer and apply()s it to the server protocol.
The original SMTP protocol has a simple request/response setup phase followed by a streaming data transfer phase, so a GNet::LineBuffer can be used with no risk of overflow. The RFC-2920 PIPELINING extension develops this by defining request/response batches with a well-defined batch boundary before the data transfer phase.
RFC-2920 PIPELINING tries to define a size limit for an input batch, but only in terms of the network layer PDU size – which is useless in practice.
Unfortunately the RFC-3030 CHUNKING ("BDAT") extension is underspecified so there is no batch boundary prior to the data transfer phase. That means that in the worst case the remote client can start the data transfer before the setup commands have been fully processed and blow up the input buffer with megabytes of message body data. Therefore we have to use network flow control to limit the amount of buffering:
Definition at line 73 of file gsmtpserverbufferin.h.
GSmtp::ServerBufferIn::ServerBufferIn | ( | GNet::EventState | es, |
ServerProtocol & | protocol, | ||
const Config & | config | ||
) |
Constructor.
Definition at line 26 of file gsmtpserverbufferin.cpp.
GSmtp::ServerBufferIn::~ServerBufferIn | ( | ) |
Destructor.
Definition at line 36 of file gsmtpserverbufferin.cpp.
void GSmtp::ServerBufferIn::apply | ( | const char * | data, |
std::size_t | size | ||
) |
Called when raw data is received from the peer.
Line buffering is performed and complete lines are apply()ed to the ServerProtocol. If the ServerProtocol cannot accept everything then the residue is queued and re-apply()d transparently.
Throws Done at the end of the protocol.
Definition at line 41 of file gsmtpserverbufferin.cpp.
void GSmtp::ServerBufferIn::expect | ( | std::size_t | n | ) |
Forwards to GNet::LineBuffer::expect().
Definition at line 112 of file gsmtpserverbufferin.cpp.
|
noexcept |
Returns a signal that should be connected to a function that controls network flow control, typically by adding and removing the socket file descriptor from the event loop.
Definition at line 122 of file gsmtpserverbufferin.cpp.
std::string GSmtp::ServerBufferIn::head | ( | ) | const |
Returns GNet::LineBufferState::head().
Definition at line 117 of file gsmtpserverbufferin.cpp.