Re: Testing the gnutls support

[Ted Zlatanov]

On Thu, 07 Oct 2010 23:42:40 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> I've done some testing of the gnutls support, and it pretty consistently
LMI> seems to fail if I request a lot of data.

LMI> For instance, if I do a header retrieval in a Gmail IMAP group, I end up
LMI> with this:

LMI> * 19 FETCH (UID 45 RFC822.SIZE 215416 BODYSTRUCTURE ((("TEXT" [...] 
("CREATION-DATE" "M
LMI> Process *nnimap*<1> connection broken by remote peer

LMI> That's after receiving 15496 characters.

LMI> So something isn't quite working as it should do...

LMI> This works, though:

LMI> (let ((process
LMI>        (open-gnutls-stream "http" (current-buffer)
LMI>                       "www.google.com" "https")))
LMI>   (process-send-string process "GET / HTTP/1.0\r\nServer: 
www.google.com\r\n\r\n"))

LMI> It seems related to the length of the text we receive.  Are there any
LMI> buffers in the gnutls library that needs flushing or anything?  

Not that I'm aware of.  All the examples just read the data and there
are no "flush" functions in the API.  You can see how they prep a socket
in the examples, nothing unusual is going on:

http://www.gnu.org/software/gnutls/manual/html_node/Helper-function-for-TCP-connections.html

...and then the clients just use the gnutls_{read,write}() functions.

Can you check what gnutls_record_get_max_size() returns for you?  That's
negotiated.  Also is there an error in that session (if you turn up
logging)?

I don't think it's related to gnutls_record_set_max_size() because the
max size is 4K and you're getting errors around 16K.  But being so close
to 16K is very suspicious and indicates a buffer issue.  Does the error
happen on send, receive, or both?  Is there a 16K threshold or does that
number vary a lot?

emacs_gnutls_write() does "fsync (STDOUT_FILENO)" after each write.
This is a leftover from Simon's original patch:

  printf("wrote %d bytes\n", bytes_written);
  fsync(STDOUT_FILENO);

and I forgot to take it out.  Can you remove it?  I can't push that
commit currently, sorry.  If that turns out to be the trigger...

If not we can try playing with
gnutls_transport_set_{push,pull}_function() I guess.  But I can't see
why the default {send,recv}() call is inadequate.

Ted