mainGnuTLS - Support: sr #107763, Running GnuTLS in non-blocking...

 
 

sr #107763: Running GnuTLS in non-blocking mode.

Submitter:  Bjørn Christensen <cybear>
Submitted:  Wed 03 Aug 2011 07:01:37 AM UTC
   
 
Category:  Core library Priority:  5 - Normal
Severity:  3 - Normal Status:  Duplicate
Privacy:  Public Assigned to:  nmav
Open/Closed:  Closed Operating System:  Microsoft Windows
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 03 Aug 2011 05:00:02 PM UTC, comment #1: 

Unfortunately there is not much we can do. This is indeed a duplicate of #107660. The solutions discussed in:
https://savannah.gnu.org/support/?107660#comment3
should be applicable to your case. Note however that the quick fix (1) using gnutls_transport_set_lowat(), is not applicable in gnutls 3.0.0 that doesn't have this function.

Because operating system sockets and gnutls sessions operate on different context the convenient usage of select was mostly a hack that became expensive to maintain. A solution is to wrap select with a function that will also poll gnutls_record_check_pending(). If the interface of the latter function is not sufficient feel free to send suggestions and/or improvements.

regards,
Nikos

Nikos Mavrogiannopoulos <nmav>
Group administrator
Wed 03 Aug 2011 07:01:37 AM UTC, original submission:  

I think this is a variant of #107660.


I have just updated from version 2.10.1 to 2.12.7 and my application has stopped working.

I am running one thread to handle all the socket communication both secure through GnuTLS and unsecure on sockets.

All sockets have been set into non-blocking mode.


The main loop in the work thread defines which sockets  to check for ready for read and write and then suspends on the select() call.

When returned from the select() call I will read from the socket which has data to read.

This strategy worked fine with version 2.10.1 but is broken in version 2.12.7.

Because: (as far as I can debug)

I sent from the client 231 bytes of data 115 bytes of header and 116 bytes of data (my protocol)

I call gnutls_record_recv and ask for 115 bytes, because I want to read my  header and determine what to do after that.
Then I again mark the socket so select() will check it for new data (ready for read on the raw socket) waiting for my 116 byte of data. And the work thread suspends on the select() call.


But in version 2.12.7 no new data arrives on the socket because it was read and buffered on the first call to gnutls_record_recv. SO my work thread grinds to a halt on the socket gnutls buffers data.

Yes I can see there is a call to the gnutls_record_check_pending() but this will cause that the way of reading will be different between secure and unsecure communication.

And the comments in the code on gnutls_record_recv clearly indicates that the intention is for the function to work like recv().







 




Bjørn Christensen <cybear>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Posted a comment)
  • -email is unavailable- added by cybear (Submitted the item)
  • -email is unavailable- added by cybear
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-08-08 nmav Open/ClosedOpen Closed
    2011-08-03 nmav StatusNone Duplicate
        Assigned toNone nmav
    2011-08-03 cybear Carbon-Copy- Added cybear

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code