[JDEV] Bug in the SSL I/O layer + fix

[Daniel Veillard]

On Thu, Jan 17, 2002 at 09:22:28AM -0600, Thomas Muldowney wrote:
> Hrm.... is this against the latest cvs?

  yes, jabber2 module from anonymous cvs. updated before making the patch.

> I can't reproduce this,

  Hum, get a Jabber client on a conference sending a 20KB block of XML
data to another client on that conference, and run tcpdump :-)

> but maybe I'm doing something wrong.  Do you have a test script?

  No it requires quite a bit of code, in that case XML-RPC calls
over SSL/Jabber

> Just want to test it
> out a bit before I commit a change.

  understandable. But I think the explanation is pretty clear.
select() cannot "guess" that there is data left in the SSL decoder.
You have to ask it directly after the SS_read() or guess it in some ways.

Daniel

> ----- Original Message -----
> From: "Daniel Veillard" <veillard at redhat.com>
> To: <jdev at jabber.org>
> Sent: Thursday, January 17, 2002 8:00 AM
> Subject: [JDEV] Bug in the SSL I/O layer + fix
> 
> 
> > Symptoms:
> >    a large write from an SSL client gets blocked/delayed for
> >    a long time in jabberd.
> >
> > Bug:
> >    the select() mechanism is not able to detect that there is some
> >    data left in the SSL buffers
> >
> > Explanation:
> >    The client sends a really large chunk of data (anything > 8KB will do)
> >    The SSL decryption layer ends up generating an input buffer which
> >    is larger than the read done by the mail loop following the select
> >    (the read is limited to 8K and usually less due to the karma computing.
> >    The main loop does the read which fills up the buffer, is then
> >    passed to the parser, and return in select(). The fact that the
> >    read() may not consume all data is usually not a problem because
> >    the leftovers will retrigger the exit from select. But for SSL
> >    (and any layer with an intermediate buffer) there may be data left,
> >    and select won't detect it. The data simply stalls in the buffer
> >    until something else triggers the read on that selector again.
> >
> > Fix:
> >    The enclosed patch provides an approximation of the correct solution.
> >    The SSL read simply checks that SSL_read() filled the input buffer
> >    and if yes request the main loop to iterate over the read on that
> >    selector. It might not be a complete solution since the read may
> >    be exactly the size of the buffer. The best is to ask the SSL layer
> >    if there is some data left at the end of SSL_read() but I didn't
> >    found the right API for this. This should be fixed at the end of
> >    _mio_ssl_read() by replacing "if (ret == count) {" with code asking
> >    the SSL layer.
> >
> > Extra question:
> >    Is there an easy way to simply disable all Karma checks ? Or change
> >    them all to something more in line for distributed computing needs.
> >
> > Daniel
> >
> > --
> > Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
> > veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
> > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
> >
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/