I have a pice of C code where I want to perform the action

out("150\r\n");

every 30 seconds which will cause a SMTP connection to be kept alive
until I get some output from the following command:

qmail_close(&qq)

i.e. in psudo c code

char *qqx;
while( (qqx = qmail_close(&qq)) == empty )
{
sleep(30);
out("150\r\n");
}

in short form

while (command has not returned)
{
yield 30 seconds;
perform keep alive action;
continue loop;
}

I have one solution (which however seams overly complicated to me)
using pthreads to perform the work and yield while qmail_close has not
returned. Is this the only possible way ? or can I just fork the
process and have the parent perform the keep-alive event until the
child continues from its block ? (i.e. receives output from
qmail_close).

I do not expect a full blown solution just some hints to get on.


Thanks in advance.

[ Post a follow-up to this message ]

lroland@gmail.com wrote:
> I have a pice of C code where I want to perform the action
>
> out("150\r\n");
>
> every 30 seconds which will cause a SMTP connection to be kept alive
> until I get some output from the following command:
>
> qmail_close(&qq)
>
> i.e. in psudo c code
>
> char *qqx;
> while( (qqx = qmail_close(&qq)) == empty )
> {
>   sleep(30);
>   out("150\r\n");
> }
>
> in short form
>
> while (command has not returned)
> {
>  yield 30 seconds;
>  perform keep alive action;
>  continue loop;
> }
>
> I have one solution (which however seams overly complicated to me)
> using pthreads to perform the work and yield while qmail_close has not
> returned. Is this the only possible way ? or can I just fork the
> process and have the parent perform the keep-alive event until the
> child continues from its block ? (i.e. receives output from
> qmail_close).
>
> I do not expect a full blown solution just some hints to get on.
>
>
> Thanks in advance.
>

Try looking at the alarm(2) man page.

--

Fletcher Glenn

[ Post a follow-up to this message ]

<lroland@gmail.com> wrote in message
news:1136996615.836340.16000@f14g2000cwb.googlegroups.com...
> I have a pice of C code where I want to perform the action
>
> out("150\r\n");
>
> every 30 seconds which will cause a SMTP connection to be kept alive
> until I get some output from the following command:
>
> qmail_close(&qq)
[snip]
> in short form
>
> while (command has not returned)
> {
>  yield 30 seconds;
>  perform keep alive action;
>  continue loop;
> }

This shouldn't be too hard to do with another process (or thread, probably,
but I don't know much about that). However, I think you are wasting your
time trying to keep the connection alive. You presumably don't have control
over the client - maybe it will timeout despite your 150 responses. Also,
you shouldn't need to keep the client waiting long enough for it to be an
issue in the first place (*that* is the problem you should be solving, if
indeed it is a problem). In addition, although I think what you propose is
in accordance with the RFC, it may break some (badly written) clients that
don't expect 1xx responses.

Alex

[ Post a follow-up to this message ]

I do agree with you - we are however facing a problem where customers
require scanning of very large emails. If the email is say 500MB it may
very well be that before I can send 250 OK to the sending mail server
(which I will first do when I have delivered the email to the next hop
server) the sending server may have timed out before that.

Thus if the customer (for whatever insane reason) wants scanning of
these large emails (people really should dump large attachments on a
server and send the link) the only way I can ensure that this will go
OK is to keep the smtp session alive.

Crap - I know - but working for one the largest emails providers does
not give me (or us - if the customer is big enough) very much choice.
They want virus/spam scanning of everything, and they want to send
large emails. According to RFC2821 this is the only safe thing I can
come up with that is even remotely RFC compliant (I could also choose
to answer 250 OK after I have received the email (prior to
scanning/delivery) but that would leave us valuable to raid/fs
crashes).

Anyway the alarm thing did work beautifully

[ Post a follow-up to this message ]

<lroland@gmail.com> wrote in message
news:1137016851.506173.267880@f14g2000cwb.googlegroups.com...
> I do agree with you - we are however facing a problem where customers
> require scanning of very large emails. If the email is say 500MB it may
> very well be that before I can send 250 OK to the sending mail server
> (which I will first do when I have delivered the email to the next hop
> server) the sending server may have timed out before that.
>
> Thus if the customer (for whatever insane reason) wants scanning of
> these large emails (people really should dump large attachments on a
> server and send the link) the only way I can ensure that this will go
> OK is to keep the smtp session alive.

You don't have to "keep the smtp session alive". You just have to ensure it
completes - keeping it alive by sending 1xx responses is not the only
answer. (In fact, as I said, it may not be any answer at all.)

You could spool the message to disc and scan it after accepting it (which
you should be able to do promptly). It is probably desirable to do this only
for "large" messages (ie where the delay is likely to be an issue).

Alternatively, you could do the scanning (and maybe forwarding) in a
pipeline, ie scan the message as you receive it. This would have the effect
of distributing the delay you currently have between the client terminating
the message and the server's response throughout the message transmission
(the delay may even be absorbed due to available client->server bandwidth).

Alex

[ Post a follow-up to this message ]