Fw: Re: [Help-gnutls] gnutls_write semantics

[Nikos Mavroyanopoulos]

On Mon, 29 Oct 2001 22:20:09 -0600 Jon Nelson <address@hidden> wrote:

> > This is valid (for gnutls_write() only). This is not a bug.
> > If a write() is interrupted (eg. may have sent the half of the data),
> > then gnutls 
> > will have to send the rest, or abort. What is the problem in your case
> > with that?
> I'm not sure I entirely understand.  Assume I am using non-blocking
> sockets.  I write, say, 300 bytes via gnutls_write(..).
> The underlying write() gets an EAGAIN.
> What should I do, and what would the return code be?
The return code would be GNUTLS_E_AGAIN. However the underlying
write() might get EAGAIN after writing 100 bytes to the peer.
In that case you should also get GNUTLS_E_AGAIN.
 In both cases you should call again gnutls_write() with the
same parameters, until you get success. 

 This does not mean that you cannot do anything until gnutls_write() 
succeeds, you may initialize other connections, or use gnutls_write()/read 
in other connections. 

> Incidentally, the 'serv' example prints garbage to the screen
> when run in http mode, and one does a 'refresh' after loading
> the initial screen.  The garbage is printed in the PRINT_DH
> macro/function, but I haven't yet been able to diagnose the
> specific problem.
> 0.2.4 worked fine in that area.
Yes, i've done some nasty changes in the session resuming code. You
may try getting gnutls_session.c and gnutls_db.c from the cvs, or
disable session resuming (do not set the name of the resume db).

> -- 
> Jon Nelson                \|/ ____ \|/   Gort,
> address@hidden    "@'/ ,. \`@"   Klaatu
> C and Python Programmer   /_| \__/ |_\   barada
> Motorcycle Enthusiast        \__U_/      nikto.
> 


-- 
Nikos Mavroyanopoulos
mailto:address@hidden