From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel,gmane.comp.encryption.gpg.gnutls.devel Subject: Re: Testing the gnutls support Date: Fri, 08 Oct 2010 08:45:58 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87r5g0x0fd.fsf@lifelogs.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1286545591 31007 80.91.229.12 (8 Oct 2010 13:46:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Oct 2010 13:46:31 +0000 (UTC) Cc: gnutls-devel@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 08 15:46:30 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P4DHJ-0007Xj-Cp for ged-emacs-devel@m.gmane.org; Fri, 08 Oct 2010 15:46:29 +0200 Original-Received: from localhost ([127.0.0.1]:41321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P4DHJ-0005LR-0F for ged-emacs-devel@m.gmane.org; Fri, 08 Oct 2010 09:46:29 -0400 Original-Received: from [140.186.70.92] (port=47907 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P4DH8-0005Kt-Ke for emacs-devel@gnu.org; Fri, 08 Oct 2010 09:46:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P4DH2-0004vh-FP for emacs-devel@gnu.org; Fri, 08 Oct 2010 09:46:18 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:42026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P4DH2-0004vG-4U for emacs-devel@gnu.org; Fri, 08 Oct 2010 09:46:12 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P4DH0-0007R6-JE for emacs-devel@gnu.org; Fri, 08 Oct 2010 15:46:10 +0200 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Oct 2010 15:46:10 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Oct 2010 15:46:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 57 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:HrypqrC9gdH/LhSc+OEfaaexErI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:131494 gmane.comp.encryption.gpg.gnutls.devel:4608 Archived-At: On Thu, 07 Oct 2010 23:42:40 +0200 Lars Magne Ingebrigtsen 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