-----Original Message----- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jan P. Kessler Sent: Saturday, 31 August 2013 12:21 AM To: postfix-users@postfix.org Subject: Re: newbie check Was [Re: port 25 submission settings sanity check]
>> As attachments get larger, and end users use email rather than ftp for file >> transfer for convenience sake, a UDP implementation, perhaps using UDP as a >> data >streaming channel could become a very useful configuration, and the >> transfer speed over high latency links (think satellite etc) could improve >> immensely. > >Not necessarily. SMTP is not DNS or SNMP. A SMTP communication requires far >more than two ip packets (question/answer). So, as some others already >>mentioned, for reliable submission the software has to ensure correct >integrity and order of the submitted ip packets - even over unreliable and >asynchronous >media. To be in advantage over smtp/tcp those checks have to be >faster than the highly optimised ones in your tcp stack. Embedding sequence and CRC into the UDP packet as part of the data stream (at the application layer) will take care of the integrity and packet order, the lack of requirement for ACK will speed up the transfer over high latency links like satellite (typical RTT of 800-1300ms) Only packets that fail CRC or don’t arrive need retransmission. I have done testing with file transfers using both TCP and UDP, and the results are very surprising. I was thinking 10-15% improvement however, real world testing shows 50-70% improvement. There is no stop-wait-start with UDP, and if the data integrity is taken care of at the application layer then I suspect it will work fine. Implementing this as a data-channel that can negotiated during standard SMTP/Submission negotiation, maybe as an extension to ESMTP, eg: UPIPE, then that UDP connection us used to stream the MIME bulk. This could work, and if implemented well would be backward compatible too. T ===[Disclaimer]=== This electronic transmission, including any attachments, is confidential, may contain privileged information and should be read or retained only by the intended recipient. If you received this message in error, please delete it from your system and notify the sender immediately. Any review, dissemination or other use of this information by persons or entities other than the intended recipient is strictly prohibited. ===[End]===
