openldap-devel November 2007

openldap-devel@openldap.org

17 participants
31 discussions

Re: commit: ldap/servers/slapd connection.c daemon.c proto-slap.h syncrepl.c
by Howard Chu 28 Nov '07

28 Nov '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > connection.c 1.410 -> 1.411 > daemon.c 1.414 -> 1.415 > proto-slap.h 1.743 -> 1.744 > syncrepl.c 1.370 -> 1.371 > > Log Message: > Streamlined Winsock connection management This patch eliminates all the #ifdef WINSOCK special cases in connection.c, and hides most of the dependencies in daemon.c. Winsock's select() implementation is pretty non-optimal. Unfortunately using the Microsoft-recommended asynchronous functions would implicitly set all the sockets to non-blocking, and stuff like OpenSSL doesn't behave well with non-blocking sockets. For reference, the peak throughput with back-null on the previous code was only 7,800 auths/sec (with 8 client threads). With this patch it's 11,140 auths/sec. In both cases the throughput declines as more client threads are used. (Compare to 35,553 auths/sec for the same machine running Linux, and no drop in throughput all the way up to hundreds/thousands of connections.) Peak throughput on the new code with back-hdb is 7,972 auths/sec (with 12 client threads). With the previous code it was 6,252 auths/sec (with 8 client threads). (The 7,972 figure is also after setting processor affinities for the threads, forcing the listener to use core #0 and forcing the worker threads to use cores #1-7. Without that tweak, the peak is only 7,717/sec.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 6

Please test RE_24
by Quanah Gibson-Mount 27 Nov '07

27 Nov '07

I've sync'd it up with everything I'm aware of as being pending in preparation for getting 2.4.7 out this week. Please test. Thanks! --Quanah

3 2

Re: Empty DN ("") String Value?
by Marc Boorshtein 27 Nov '07

27 Nov '07

Well, based on the discussion I am going to change toString() to return an empty String (""). I think its bad form for an instantiated object to have 'null' for its string representation anyway. Marc

1 0

Dynamic syntax support
by Howard Chu 27 Nov '07

27 Nov '07

Here's a project for someone fairly ambitious: The goal is to be able to dynamically add support for new syntaxes to slapd simply by feeding in their specifications. Typically this would mean feeding in an ABNF description from an IETF document, though it may also mean feeding in ASN.1 documents. E.g., we want to be able to insert (using ldapmodify) the ABNF into an LDAP entry somewhere and have it automatically converted into an executable parser. There are a couple of tools out there for working with ABNF. The IETF actually uses this one http://www.coasttocoastresearch.com/Apg5_0/Apg5_0_description.htm for validating IETF drafts. There's also this one http://www.2p.cz/en/abnf_gen I don't think either of these are suitable as they exist, because they don't generate output that is embeddable and directly executable. I guess you could feed the generated C code into an embedded C interpreter, but that seems like a ridiculously wasteful solution. Most of these existing tools will analyze a grammar and spit out source code to recognize it, but we don't want the source code, we just want the recognition action. I think a more practical route will involve embedding a Forth engine into the OpenLDAP code. There's already been a fair amount of work done with BNF in Forth, so it shouldn't be too hard to get started: http://www.zetetics.com/bj/papers/bnfparse.htm http://www-personal.umich.edu/~williams/archive/forth/strings/index.html http://www-personal.umich.edu/~williams/archive/forth/strings/expr.html The nice thing about Forth is that the core language is tiny, it's extremely portable, it's extremely extensible, and any implementation is inherently both an interpreter and a compiler. As interpreted languages goes, it beats pretty much every other common scripting language for memory and CPU efficiency. It ought to be straightforward to convert a grammar into a set of Forth words to recognize the grammar, for a slapd syntax validator. I'm not sure yet what we would do for Prettifiers or Normalizers, nor what to do for Matching rules. We could simply accept them as Forth source code. Personally I haven't written Forth in over 20 years but it seems to me that a TIL is the most suitable type of language for the job. On the whole it doesn't seem like new syntaxes pop up in LDAP specs very often. Some may say this is because they're not really needed. I believe they've been sorely needed, and people have just avoided them because they required too much work to properly support in existing implementations. We can fix that. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 5

Re: Empty DN ("") String Value?
by Hallvard B Furuseth 26 Nov '07

26 Nov '07

Emmanuel Lecharny wrote: > This is starting to be confusing. The initial question was : Uh, right... I was halfway answering the question which is too short, halfway Michael. > "Should the toString() method of a class that represents a DN return > null or an empty string?" If a class represents a DN, toString() sounds like it should return that DN's string representation as described in RFC 4514. If you mean to ask what to return when a class instance represents an _empty_ DN, then the string representation is "". toString() not returning a string sounds strange to me whatever the object represents, but maybe that's because I don't know java. But NULL ought to mean "no dn", not "the empty dn". -- Regards, Hallvard

1 0

Re: Empty DN ("") String Value?
by Michael Ströder 26 Nov '07

26 Nov '07

Emmanuel Lecharny wrote: > Hallvard B Furuseth wrote: >> Michael Ströder writes: >> >>> It really depends on what you want to express. Note that "" represents >>> the rootDSE or root naming context. So "" would reference something >>> existing or well-defined. IMHO NULL (or None in Python) would better >>> signal something undefined or none-existing. >> >> Yes. There is one case in the LDAP ASN.1 grammar (in rfc 4511) where >> you need to distinguish between an absent DN and an empty DN: The LDAPDN >> field ModifyDNRequest.newSuperior, which is 'OPTIONAL'. There may be >> others in LDAP extensions defined elsewhere. >> > This is starting to be confusing. The initial question was : > > "Should the toString() method of a class that represents a DN return > null or an empty string?" This can't be answered consistently without knowing what this returned value is used for. But I'll try: If you just created an object instance of the DN class without assigning any real DN to it method toString() should return NULL instead of "". > But if the question is : > "How do I represent a DN in a structure when I do a toString() on this > structure", then the answer would be : > - null if the DN member is null I guess with "DN member" you're referring to the class' attribute for storing the DN. So I guess this is the case I described above. > - "" if the DN does not hold any value. I doubt that this is right or maybe I misunderstood "does not hold any value". Again: "" refers to the rootDSE or is the root naming context in search requests with scope!=base. If you pass "" to any other method (e.g. for a modify request) then it has a specific meaning (e.g. modifying the rootDSE). Well, not being a Java programmer I will stay out of further discussion because I don't know what's common in the Java world. Ciao, Michael.

1 0

Re: commit: ldap/doc/man/man8 slapindex.8
by Hallvard B Furuseth 22 Nov '07

22 Nov '07

hyc(a)OpenLDAP.org writes: > slapindex.8 1.28 -> 1.29 > Document truncate mode Please clarify the doc of this. I mean, I had no idea slapindex had a non-truncate mode. Does slapindex by default not delete old indexes, or does is mean something else? When should one _not_ use truncate mode? -- Hallvard

3 4

ITS#5069, syncrepl on demand
by Howard Chu 21 Nov '07

21 Nov '07

Another approach that may be worthwhile would be to add the list of queued runqueue tasks to back-monitor. (Currently it only displays runqueue tasks that are actually executing at the time you look.) Then do an ldapmodify on back-monitor to change the scheduled time of the task. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: OpenLDAP Roadmap - What do we want to see in 2.5.x?
by Gavin Henry 21 Nov '07

21 Nov '07

<quote who="Michael Ströder"> > Gavin Henry wrote: >> Thought I'd start the thread. > > Gavin, do you really think it's already time for this? Umm, yeah. There's been an ITS for the very out of date one on our site for ages now. It doesn't have to be soley for 2.5.x, 2.4.x as well. > > I'd rather be curious to know what items in doc/devel/todo will be done > in 2.4. Re docs, just the empty or "LATER" sections to complete. > Personally I'd like to see (optional) support for DIT structure > rules and name forms. ok, then that's a start. That could be part of the roadmap for 2.4, as there isn't anything for 2.4.x/2.5.x > But I'm not a C programmer. I can only help with > testing. And docs! ;-) It would be much appreciated if anyone would pick up a Overlay and/or backend section. They don't take long. I'm currently working on the Replication sections. Thanks, Gavin.

1 0

OpenLDAP Roadmap - What do we want to see in 2.5.x?
by Gavin Henry 21 Nov '07

21 Nov '07

Thought I'd start the thread. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel November 2007