[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:1.9.1.16) Gecko/20110505 Icedove/3.0.11 |
Hello,
/* My ref: http://bugs.bitlbee.org/bitlbee/ticket/938 */
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():
DESCRIPTION
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.
Cheers,
Wilmer van der Gaast.
--
+-------- .''`. - -- ---+ + - -- --- ---- ----- ------+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org |
| lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net |
+--- -- - ` ---------------+ +------ ----- ---- --- -- - +
- gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data,
Wilmer van der Gaast <=