Loading ...
Sorry, an error occurred while loading the content.

Re: Why Postfix always complain "unexpected EOF" with my own tcp_table program?

Expand Messages
  • Zhang Huangbin
    ... Thanks Wietse, and John. I think this is the root cause, will try a network sniffer later. ... My program closes the connection immediately.
    Message 1 of 7 , Jul 28, 2013
    • 0 Attachment
      On Sunday, July 28, 2013 at 8:24 PM, Wietse Venema wrote:

      >
      > 1) Use a network sniffer to see what Python actually sends. You may
      > assume that your program sends \n, but Postfix does not receive \n.


      Thanks Wietse, and John.
      I think this is the root cause, will try a network sniffer later.
      > 2) Unrelated to this bug: closing the connection after one request
      > is inefficient.


      My program closes the connection immediately.
    • Wietse Venema
      ... Caution: it is not a good idea to close a connection immediately after writing data to it. Some TCP/IP implementations may discard unsent data when a
      Message 2 of 7 , Jul 28, 2013
      • 0 Attachment
        Zhang Huangbin:
        > On Sunday, July 28, 2013 at 8:24 PM, Wietse Venema wrote:
        >
        > > 1) Use a network sniffer to see what Python actually sends. You may
        > > assume that your program sends \n, but Postfix does not receive \n.
        >
        > Thanks Wietse, and John.
        > I think this is the root cause, will try a network sniffer later.
        > > 2) Unrelated to this bug: closing the connection after one request
        > > is inefficient.
        >
        > My program closes the connection immediately.

        Caution: it is not a good idea to close a connection immediately
        after writing data to it. Some TCP/IP implementations may discard
        unsent data when a connection is closed.

        In Postfix, I avoid "write-close" bugs by keeping a connection open
        until the receiver closes it (with of course a time limit that
        forces the connection to be closed when things take too long).

        Wietse
      • King Cao
        You can enable the debug mode of postfix smtp daemon ( http://www.postfix.org/DEBUG_README.html). Then you can see the request and response which postfix
        Message 3 of 7 , Jul 28, 2013
        • 0 Attachment
          You can enable the debug mode of postfix smtp daemon (http://www.postfix.org/DEBUG_README.html). Then you can see the request and response which postfix talked with your tcp_table script.

          PS:
            From the postfix source code, it seems postfix has not received any response from your tcp_table.  However postfix will retry 10 times for such scenario (sleep 1 sec before each retry).


          2013/7/28 Wietse Venema <wietse@...>
          Zhang Huangbin:
          > On Sunday, July 28, 2013 at 8:24 PM, Wietse Venema wrote:
          >
          > > 1) Use a network sniffer to see what Python actually sends. You may
          > > assume that your program sends \n, but Postfix does not receive \n.
          >
          > Thanks Wietse, and John.
          > I think this is the root cause, will try a network sniffer later.
          > > 2) Unrelated to this bug: closing the connection after one request
          > > is inefficient.
          >
          > My program closes the connection immediately.

          Caution: it is not a good idea to close a connection immediately
          after writing data to it.  Some TCP/IP implementations may discard
          unsent data when a connection is closed.

          In Postfix, I avoid "write-close" bugs by keeping a connection open
          until the receiver closes it (with of course a time limit that
          forces the connection to be closed when things take too long).

                  Wietse

        Your message has been successfully submitted and would be delivered to recipients shortly.