Thorild Selen wrote:
[quoting draft-ietf-ldapext-ldapudp-00:]
> [...] A server implementing reuse of messageIDs is required to > maintain a cache (the size of which should be annonced in the > rootDSE-object; see below) of recent result-codes for each > source port and address. Consequently a client using this > mechanism must bind to the local port before issuing requests so > that a particular client process can be identified by the > server. The client must not issue more operations at a time than > the cachesize.
This approach has a few drawbacks:
* The server is not stateless; it has to keep track of some data for
each client. This means that it won't be as lightweight as CLDAP,
from the server's point of view.
Granted but that is hardly an issue with modern servers.
* The client is required to keep track of the cache size of theI am not sure about that but even if it is true most clients start life by asking
server. This makes it less lightweight in another way; you have to
start your communications with asking about the cache size.
Avoiding this would be more useful, in my opinion. The big win withAgain I don't agree that this is the point (if indeed there is a point) to this
connectionless LDAP ought to be that it is even more lightweight than
LDAP over TCP; no unneeded packages going back and forth, no extra
state to maintain for the server. If that isn't so important, then you
could just as well use LDAP over some connection-oriented protocol,
such as TCP, instead.
Cheers Leif
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext