gnutls_record_check_pending() issue in GNUTLS 3.0.3 ??

[frank.krout at eurorscg.com]

I'm integrating secure email support into an existing mailer app that 
functions essentially as a mail client.
So, in sending emails, the processing of SMTP command responses may be 
delayed while waiting for a particular server.
The legacy code handles this delay using the socket select() call to check 
for input and timeout if nothing is coming back from a server.

So it is in the client side  that I am using the 
gnutls_record_check_pending()

Unless I'm missing something, with gnutls I need to emulate socket 
select() with something like:

                        do { //add sleep function call here
                                loop++;
                                sleep( tv.tv_sec );
                                count_pending = 
gnutls_record_check_pending( session );
                   }while ( count_pending <= 0 && loop < whatever);

hence, my reasoning for the need to sleep. 
In theory if I can't get gnutls_record_check_pending() working, then I'd 
need to do the sleep unconditionally after every command.

gnutls_record_recv() blocks if it has no data, yes??

Thanks,
Frank


Nikos Mavrogiannopoulos <nmav at gnutls.org> 
Sent by: n.mavrogiannopoulos at gmail.com
11/09/2011 06:56 AM

To
frank.krout at eurorscg.com
cc
GnuTLS mailing list <help-gnutls at gnu.org>
Subject
Re: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ??








On Tue, Nov 8, 2011 at 10:16 PM, <frank.krout at eurorscg.com> wrote:
This is weird, I reduced my receive calls to 
peekLen = (long) gnutls_record_recv (esmtpInfo.gnutls.session, 
esmtpInfo.gnutls.ringBuffer.data, 8); 
Yes, 8 bytes at a time ....  gnutls_record_check_pending()still does not 
work. It gets called after every complete line of response is received. 
Again, runs fine without it. 
I would hate to have to put a mandatory sleep after every smtp command, 
prior to looking for a response. 

I don't fully understand your issue. Why do you have to put a sleep? 
Moreover I don't know your code, thus I cannot understand why you see that 
behavior. Try doing the following:
client: gnutls_record_send(1024 bytes)

server: gnutls_record_recv(4 bytes)
gnutls_record_check_pending() should return 1020.
 
(please keep the mailing list in CC)

regards,
Nikos



Frank Krout Senior Software Engineer
Office Euro RSCG 4D, 372 Danbury Rd, Wilton, Connecticut 06897
Tel 203.563.3314  Fax 203.563.3434  Web 
eurorscg.com

 
     
________________________________________________________________________________
____________________________________
The views and opinions expressed in this e-mail and any accompanying 
attachment, are those of the author and do not 
necessarily represent the views or opinion of Euro RSCG Worldwide, Inc.
To learn more about Euro RSCG, please visit our website at www.eurorscg.com

Please consider the environment before printing this email. 
________________________________________________________________________________
_____________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111109/c445b53f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2098 bytes
Desc: not available
URL: </pipermail/attachments/20111109/c445b53f/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1491 bytes
Desc: not available
URL: </pipermail/attachments/20111109/c445b53f/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1287 bytes
Desc: not available
URL: </pipermail/attachments/20111109/c445b53f/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1472 bytes
Desc: not available
URL: </pipermail/attachments/20111109/c445b53f/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1131 bytes
Desc: not available
URL: </pipermail/attachments/20111109/c445b53f/attachment-0004.gif>