[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnutls_record_check_pending() returning non-0 but gnutls_record_recv() g

From: Wilmer van der Gaast
Subject: gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data
Date: Sat, 07 Apr 2012 14:46:09 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110505 Icedove/3.0.11


/* My ref: */

I seem to have a problem with GnuTLS 3.0.x, from what I can see this is a bug (but please correct me if I'm wrong).

I have a function that receives data from a HTTPS server. This is all done with async and non-blocking I/O. Before returning from the read event handler, gnutls_record_check_pending() is called to check if there's any more unencrypted data waiting.

When trying to query some servers (in this case MSN Messenger HTTPS servers), gnutls_record_check_pending() will return a non-0 number (goes all the way up to 8KB at times), but when I try to read this data I get -28 which seems to be GNUTLS_E_AGAIN.

From what I know, that error code means "I would block but this is a non-blocking socket, so come back later".

This seems to be a violation of what is promised in the manpage of gnutls_record_check_pending():

       This  function checks if there are unread data in the gnutls
       buffers. If the return value is non-zero the next call to
       gnutls_record_recv() is guarranteed not to block.

Is this a known issue? Am I using it the wrong way/do I need to set a new flag from GnuTLS 3.x to get the behaviour I want? I could work around this by not even calling check_pending() if I was just returrned E_AGAIN because it seems that this condition fixes itself when more data comes in, but this seems like a risky assumption to me as well (and it doesn't work all the time, possibly):

pending = 5792
gnutls_record_recv = -28
pending = 5792
gnutls_record_recv = -28
pending = 8688
gnutls_record_recv = -28
pending = 8688
gnutls_record_recv = -28
pending = 8688
gnutls_record_recv = 2048
pending = 8758
gnutls_record_recv = 2048
pending = 6710
gnutls_record_recv = 2048
pending = 4662
gnutls_record_recv = 2048
pending = 2614
gnutls_record_recv = 2048
pending = 566
gnutls_record_recv = 566
pending = 0
gnutls_record_recv = -9

In fact, looking at these numbers it's not really clear to me at all why I suddenly can read data even though the number of pending bytes didn't change, but I suppose that's because some control frame came in that didn't deliver any useful data for my stream.


Wilmer van der Gaast.

+-------- .''`.     - -- ---+  +        - -- --- ---- ----- ------+
| wilmer : :'  : |  | OSS Programmer |
| lintux `. `~' |  | Full-time geek |
+--- -- -  ` ---------------+  +------ ----- ---- --- -- -        +

reply via email to

[Prev in Thread] Current Thread [Next in Thread]