> -----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>>