gnutls_record_check_pending() issue in GNUTLS 3.0.3 ??
Nikos Mavrogiannopoulos
nmav at gnutls.org
Tue Nov 8 15:51:23 CET 2011
It could be that gnutls_record_check_pending() returns zero. That
would be if you have already read all pending data before calling it.
This means that you use a large buffer that is enough to store the
whole data packet(s) sent by the peer. However, you cannot rely on
that being true with any peer. If you want to test if it is working
just reduce your read buffer.
regards,
Nikos
On Tue, Nov 8, 2011 at 3:31 PM, <frank.krout at eurorscg.com> wrote:
>
> Thanks for the reply, Nikos.
>
> I do get that point. What I'm seeing is that for my gnutls secure sessions the function
> gnutls_record_check_pending() never returns a value > 0.
> When I remove the gnutls_record_check_pending call from my app and let the code issue the SMTP commands to send an email (after handshake)
> and then go right into the receive response logic, calling gnutls_record_recv all most immediately, it all works. I successfully deliver emails.
>
> For some reason the gnutls_record_check_pending() call never finds any data.
>
> The example I quote, cli.c, is because given that code as a base, I can't be sure that gnutls_record_check_pending()
> is working there for a secure session. I've seen gnutls_record_recv() work off of a select on the same socket. Not correct
> coding, I get that.
>
> I'm wondering if I have an environment issue possibly...
> c01z0047:~/projects/MassMailer/MassMailer_Linux_Release_4_0_0/MassMailer> gcc -v
> Using built-in specs.
> Target: s390x-suse-linux
>
> library issue ... I'm linking in all of these -lgnutls -lgnutlsxx -lgnutls-extra
>
> Just not quite sure what's going on...
>
> I'm reviewing all my code but I got to a point where I'm looking for thoughts?
> Regards, Frank Krout
>
> 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.
> _____________________________________________________________________________________________________
>
>
>
>
> Nikos Mavrogiannopoulos <nmav at gnutls.org>
> Sent by: n.mavrogiannopoulos at gmail.com
>
> 11/08/2011 06:57 AM
>
> To
> frank.krout at eurorscg.com
> cc
> help-gnutls at gnu.org
> Subject
> Re: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ??
>
>
>
>
>
>
> Hi,
> Please check the documentation for gnutls_record_check_pending() at:
> http://www.gnu.org/s/gnutls/manual/html_node/Core-functions.html#gnutls_record_check_pending
>
> This function checks for data in the gnutls buffers, not for received network data. As you notice in the example you quote, for network data select() is being used.
>
> regards,
> Nikos
>
> On Mon, Nov 7, 2011 at 11:37 PM, <frank.krout at eurorscg.com> wrote:
> Hello,
>
> Using gnutls_record_check_pending() to check for received data in a function that sleeps a few times if no data present:
>
> ie.
> if (esmtpInfo.gnutls.ringBuffer.currentIndex == 0){//ringbuffer empty, look for more data
> int count = 0;
> int loop = 0;
> do { //add sleep function call here
> loop++;
> sleep( INTERNET_DEFAULT_TIMEOUT_SECONDS );
> count = gnutls_record_check_pending( esmtpInfo.gnutls.session );
> //count = esmtpInfo.gnutls.session->internals.record_buffer.byte_length;
> }while ( count <= 0 && loop < 3 );
> if (count > 0) return NMQ_SUCCESS;
> if ( count == 0) return NMQ_NET_TIMEOUT;
> }
>
> Using this in multi-threaded mailer... problem is gnutls_record_check_pending() fails EVERY time.
> That is, it never indicates any data has been received.
>
> If I remove the check completely and just go to the receive logic after sending an ESMTP command and call gnutls_record_recv()
> all works fine. I successfully deliver complete emails.
>
> Looking at gnutls_record_check_pending()'s use in cli.c I see it's really inconclusive... the select might detect the incoming data...
> static int check_net_or_keyboard_input(socket_st* hd)
> {
> int maxfd;
> fd_set rset;
> int err;
> struct timeval tv;
>
> do
> {
> FD_ZERO (&rset);
> FD_SET (fileno (stdin), &rset);
> FD_SET (hd->fd, &rset);
>
> maxfd = MAX (fileno (stdin), hd->fd);
> tv.tv_sec = 0;
> tv.tv_usec = 500 * 1000;
>
> if (hd->secure == 1)
> if (gnutls_record_check_pending(hd->session))
> return IN_NET;
>
> err = select (maxfd + 1, &rset, NULL, NULL, &tv);
> if (err < 0)
> continue;
>
> if (FD_ISSET (hd->fd, &rset))
> return IN_NET;
>
>
> if (FD_ISSET (fileno (stdin), &rset))
> return IN_KEYBOARD;
> }
> while(err == 0);
>
> return IN_NONE;
> }
>
> FYI, I'm linking in all of these -lgnutls -lgnutlsxx -lgnutls-extra
> I'm going to need to implement a timeout so threads don't hang,
> I suppose I could do it on the gnutls_record_recv() call, but will that block on no data received?
>
> Any thoughts?
> Regards,
> Frank
>
> System info:
> c01z0047:~/projects/MassMailer/MassMailer_Linux_Release_4_0_0/MassMailer> gcc -v
> Using built-in specs.
> Target: s390x-suse-linux
> Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix= --enable-version-specific-runtime-libs --without-system-libunwind --with-tune=z9-109 --with-arch=z900 --with-long-double-128 --host=s390x-suse-linux
> Thread model: posix
> gcc version 4.1.2 20070115 (SUSE Linux)
>
> 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.
> _____________________________________________________________________________________________________
>
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnutls
>
>
More information about the Gnutls-help
mailing list