Subject: smap.c , solaris 2.6, and timeout

From: Rude Yak <[email-masked]>
Date: Wed, 17 May 2000 15:34:31 -0700 (PDT)

It looks like setting smap's timeout in Solaris does some very interesting
things to the read() system call.  Specifically, it looks (at least to us here)
as if the alarm() call that results in SIGALRM to be sent also causes the next
call to read() to return EINTR and thus cause smap to fail when crlfgets()
calls ferror(fd).  Has anyone else run into this?  Typically, the symptom
should be seeing lots of mysterious "smap: SMTP QUIT with no message" errors in
the fwtk log for relatively large file transfers.  
  Looking through the source, Joe Yao (have to give credit where credit is due)
made some comments a while back that led me to believe that this problem has
been reviewed before but possibly not patched.  We're taking Joe's advice here
and considering implementing the timeout feature in a slightly different way -
I was wondering if anyone else has done anything similar (see attachment). 
Note that calling alarm() inside every invocation of crlfgets() has grave
performance implications: the overhead between running/resetting alarm() every
time through the loop versus once in 10 times was over 200% (26 seconds for a
1.8MB file vs. < 7 seconds on average).

  Any comments from the gallery?  

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

---

From: Ted Keller <[email-masked]>
Date: Wed, 17 May 2000 19:40:50 -0400 (EDT)

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

Rude,

I also run on a Solaris sytem - and implemented timeout functions quite a
bit different than the original smap.

As I remember, stock smap timeout procesing is based around recieving a
block of data within timeout period.  It then calls the ringring routine
which either exits - or returns to the code for one last try.  I decided
that that was too complicated (feeble brain here).

I took the approach of bracketing crlfgets with....

	alarm(timeout);
	crlfgets(....);
	alarm(0);

This allows me to have reasonable timeout periods - and not timeout on
large file transfers within a mail message.

Note - with this method, the livetim logic disappears - and the ringring
routine can simply unlink the file and exit.

My mods are quite significant - so I can't easily supply the diffs (they
would probably be larger than the original smap).  I can supply my version
if you are interested in reviewing it.

ted keller

---

From: Ken Blinco <[email-masked]>
Date: Thu, 18 May 2000 10:32:29 +1000

Rude Yak wrote:
Hi,

Yes we discovered the exact same problem with smap.  Our solution was to
just increase the timeout setting in netperm-table, but if you do get
round to rewriting this part of the code, I'd be interested in having a
look.

Ken

>   ------------------------------------------------------------------------
>                    Name: smapdiffs
>    smapdiffs       Type: application/x-unknown
>                Encoding: base64
>             Description: smapdiffs

-- 
-----------------------------------------------------------
Ken Blinco              E-Mail: [email-masked]
Unix Support Group      Phone: +61 7 322 76970

CITEC,  GPO Box 297     Brisbane, Queensland 4001 Australia