[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Bugfix: ldap_result() fails on large results



> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Patrick Dreyer,
SY-UCP

> Hi
> 
> Finaly I found the bug but need some more information from you guys to
> solve the problem the right way:
> 
> 1. Format of incoming data
> The code of ber_get_next() doesn't give me enough information 
> about the
> format of the incoming data. I'm sure you can tell me in which chapter
> of which RFC I can find the information necessary - otherwise 
> I have to
> search all through myself :-(

I don't think the ASN.1 BER is in any IETF RFC. Try starting here:
http://www.itu.int/ITU-T/studygroups/com17/languages/index.html

> 2. Reading performance
> There is a significant change in how the data from the socket is read
> between the two versions 1.38.4.9 and 1.70.2.10 of liblber/io.c. In
> 1.38.4.9 only as much data is read as needed and in 1.70.2.10 as much
> data as possible is read.
> Why did you change the way of reading and what's the advantage of the
> new solution?

Fewer system calls, less overhead, less memory-to-memory copies.

> Ah yeah, by the way. The bug is, that, if the data length could not be
> read because there is not enougth data available, just LBER_DEFAULT is
> returned  without setting errno either to EWOULDBLOCK or EAGAIN.

Since the library doesn't use non-blocking sockets we don't expect to
encounter this situation. I think the quickest fix will be to issue a second
read in this case, and let it block until more data arrives. (yuck.)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support 

<<attachment: winmail.dat>>