Re: Patch to work around flaky pop3 server behaviour

[Carlos Morgado <chbm chbm nu>]

On Sat, Jun 09, 2001 at 06:17:29PM +0100, Brian Stafford wrote:
> 
> On 2001.06.09 12:06:49 +0100 Carlos Morgado wrote:
> 
> I haven't looked at the patch in too much detail so I can't really
> comment on that except to say that sleep() isn't reliable in threaded

that too. :)

> is OK in the traditional single thread Un*x program but even then the
> technique here is better.
> 
agreed

> I personally would much prefer to see code that looks like this rather
> than that in either of the patches.  For a start, the safe_read_char()
> method is very inefficent, since it causes an overhead of 3 system calls
> per *character* read.
> 
right

> Incidentally there should be no problem reading more than one character
> at a time even with blocking sockets.  read() preserves packet boundaries
> when reading from a socket.  Since the last characters in the packet

no it doesn't. it usually does, but you can get short reads that won't turn
up an error. revc and especially read don't garantee packet boundries. you
can play with RECV_LOW_WATERMARK but even that doesn't garantee anything. 

> during command response exchanges will be the \r\n, there is no need
> to read input a character at a time scanning for the line termination.

now you're making assumptions about silly stuff like line MTU and server
side smartness. this is will break (it always does) eventually and 
noone will be able to figure out why without throwing tcpdump at it.

> This is a property of protocols such as POP, IMAP, SMTP etc.
> 
don't forget there's tcp and ip and ppp and hdlc and lots of assorted
nastiness underneath that

> In fact, unless the POP server supports PIPELINING and the client uses
> it, there is no possibility of a blocking read() trying to read beyond
> the end of the line.  Reading a socket for lock step protocol exchanges

unless the server says so.

> is not the same problem as reading a tty which really must be done
> character by character (unless using half-delay mode which sockets don't
> have).
> 

half-delay ? you mean the nagle(humm .. i think that's it) tcp buffering
protocol ?

> You've probably guessed that I've a bee in my bonnet when it comes to
> pipelining protocols and you'd be right.  The next libESMTP release
> finally solves the deadlock problem.  Since this involves non blocking
> sockets poll() and fcntl(), I feel I'm on home ground here.
> 
good

> While on the topic of libESMTP, it might be worth considering the use
> of the socket buffering in siobuf.c for reading and writing in Balsa's
> POP client.  (Perhaps I should add a POP client to libESMTP :)
> 

actually, balsa should use glib io channel stuff. it's all neatly integrated
into gtk main loop and saves us the trouble of doing select/poll ourselfs.
otoh, it makes everything socket related be handled by callbacks which is an
heap of extra work itself

> A few other points:
> 
> > i like select/poll with timeouts better than signals and much better than
> > fnctl tricks
> 
> Firstly, fcntl() is not a trick.  This is the standard way of getting
> a non blocking socket, or indeed any type of non blocking file

i meant pingponging the descriptor from block to nonblocking. that's a dirty
and costly trick. (read the original patch)

> 
> Secondly, poll() should be used in preference to select() in Posix code.
> Select(), IMO, is an appalling piece of design.
> 
works well for small sets and exists everywhere. i see no very compeling
reason to use poll unless you're writting a ftp server.

> Finally, use of non blocking reads and especially writes is the only
> way to avoid a potential deadlock when buffering or pipelining command
> response protocols.  I don't think this applies here.  However when coding
> to avoid this deadlock, fcntl() and non-blocking sockets are not an
> alternative to poll() with timeouts.  The two techniques must be used
> in tandem.
> 
agreed, see the pingpong comment above

> Footnote: on the topic of signals, they can't be avoided either,
> SIGPIPE must be caught or ignored in all robust socket applications.
> If the remote closes its socket and the local host tries to write,
> the process will be delivered a SIGPIPE which is normally fatal.
> 

of course. see the pingpong comment above


-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A 
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
[sig in cold storement]