>>>>> "John" == John Dalbec <jpdalbec@???> writes:
John> On Linux (Red Hat kernel 2.4.9-31), exim 3.34 deadlocks when
John> sending SMTP messages of 1448 or 2896 bytes (including
John> headers) to VM/ESA 2.4 SMTP. Exim uses the write() call to
John> send SMTP DATA. If all packets in the write() are of the
John> maximum size, the Linux kernel does not set the PUSH bit on
John> the last packet. The VM/ESA TCP/IP stack buffers data up to
John> 4096 bytes, so if only one or two packets are sent, the data
John> never reaches the SMTP application. Eventually the
John> connection times out and VM/ESA resets it.
John> Red Hat claims that the RFCs do not require it to send a
John> PUSH bit on the last packet of a write() to a socket. IBM
John> seems to feel that the RFCs do not require that the
John> *receiving* TCP not buffer data indefinitely. AFAICT
John> they're both right. However (RFC 1122):
John> An application program is logically required to
John> set the PUSH flag in a SEND call whenever it needs to force
John> delivery of the data to avoid a communication deadlock.
John> However, a TCP SHOULD send a maximum-sized segment whenever
John> possible, to improve performance (see Section 4.2.3.4).
John> According to the man page, the results of write() to a
John> special file are not portable, so IMO exim should not assume
John> that write() sends a PUSH bit and should take additional
John> steps to ensure that a PUSH bit is sent.
Check out this thread :
http://zaphod1.grc.nasa.gov/tcp-impl/list/archive/0165.html
which has an interresting discussion about exactly this problem - the
conclusion seems to indicate a sender problem, not setting the PSH
bit. BUT I haven't figured out how one is supposed to set the PSH bit
from an application and some of the discussion indicates that this is
a kernel problem because there is no interface for setting the PSH bit
from an application.
And check out this :-
http://www.unixguide.net/network/socketfaq/2.11.shtml
From this :-
Therefore, data passed to a write() call must be delivered to the
peer within a finite time, unless prevented by protocol
considerations.
This bascially means that this is a kernel issue not an exim one.
Sincerely,
Adrian Phillips
--
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now? [OK]
