Re: balsa no-thread crash detected

[Brian Stafford <brian stafford uklinux net>]

On 2001.08.23 19:15:11 +0100 Timothy Alan Chandler wrote:

> Non-threaded version crashes when multiple POP3 mailboxs are checked, works
> fine if you only specify a single POP3 mailbox to be checked.  Threaded
> version doesn't work at all here, the main process detaches and everything
> hangs.  Sending via SMTP works fine in both non-threaded and threaded
> versions.

libESMTP was developed from scratch and avoids the use of glib/gtk/gnome
etc etc. so the threading specific stuff in it is entirely under my control.
I guess I must know what I'm doing in threaded code after all :)

> IMHO the ability to use the local sendmail binary to send mail should be
> put back in.

We've been through all this before....

> There are circumstances where it is desirable to favor it
> over SMTP.  For instance if the primary mail server on your network uses
> the qmail MTA, workstations can have a null mailer installed (mini-qmail)
> and be setup to use qmail's QMQP protocol which on a large network I've
> found to be more efficient than SMTP.

Most SMTP clients are very poorly implemented, failing to provide adequate
socket buffering and the PIPELINING extension.  The socket buffering is easy
and its omission is inexcusable.  PIPELINING is much harder to implement
in a client so its lack is more understandable.

The SMTP clients I have reviewed will typically call write() or send() several
times in one SMTP command.  Since on a TCP SOCK_STREAM socket, write() preserves
packet boundaries this leads to many round trips on-the-wire.  Round trip time
can affect network performance dramatically, especially on the wide area.
Failing to PIPELINE commands leads to round trips at the protocol level.
Since server responses are sent in the opposite direction a protocol round trip
delay is layered over at least 2 TCP round trips.  They all mount up.
This effect can be seen on any graphical network monitor, the SMTP session is
going as fast as it can but the network bandwidth is barely being used.

When I designed libESMTP, I was determined it would not suffer these problems.
libESMTP implements both buffering and pipelining.  The elimination of round
trips achieved with the buffering alone seems to have a beneficial effect.
PIPELINING gives a substantial improvement also.  Feedback I've had from
libESMTP users suggests significant or dramatic improvements in SMTP performance
compared to their previous solution.

QMTP eliminates the round trip problem by batching a message and its envelope
into a netstring and writing that with a single call to write(), at least for
small messages.  This is why it is efficient.

In short, the problem is not SMTP, it is your experience of poor client
implementations (and there are many).  Qmail supports PIPELINING so it
should interoperate efficiently with libESMTP.

>  I still use an older version of
> balsa for that reason.

I'd suggest trying out libESMTP enabled balsa with qmail before dismissing it
based on experience of other SMTP clients.

Brian Stafford