Re: Objections to draft-ietf-ldapext-psearch-01.txt

[Scott Isaacson <SISAACSON@novell.com>]

My comments below are preceded by SAI> for Scott Isaacson

************************************************************
Scott A. Isaacson
Corporate Architect
Novell Inc., M/S PRV-C-121 
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: sisaacson@novell.com
web: http://www.novell.com
************************************************************


>>> Mark Smith <mcs@netscape.com> 08/14 6:02 PM >>>
>Ed Reed wrote:
>> ...
>> Considerable industry experience with client-side
>> caching of message stores and associated address
>> book information suggests that for those kinds of
>> human interface applications, a poll cycle on the
>> order of minutes is adequate, and that with even
>> reasonable design, random variations in the period
>> of poll attempts by the clients will result in a smoothing
>> of traffic and cpu loads on servers.  If the client
>> already is holding an authenticated connection open
>> to deal with queries, the poll can easily be inserted
>> into the query queue without doubling the connections
>> (and authentication operations) on the server, and
>> without imposing serious state-ful management
>> issues on the server tracking who wants what sent
>> where.
>
>There seems to be some confusion here:  Persistent Search does not
>require a dedicated TCP/IP connection.  Clients are free to perform
>other LDAP operations on the same connection.  If a client is keeping an
>open LDAP connection for other reasons (and I believe most active
>clients will) Persistent Search feels like a natural, low-overhead
>mechanism for change notification.

SAI> The problem is not "another TCP connection" but many idle,
SAI> connections not doing anything but taking up server buffers and
SAI> state management resources with nothing happening.  This
SAI> approach is valid, as you indicate, "If the client is keeping an
SAI> open LDAP client for other reasons", but the worry is over
SAI> those potentially many clients that are not.

>> ... For the portable client, a periodic poll for changes (the
>> very search that would be performed by the psearch)
>> leaves coordination of who needs what where it
>> should be - with the clients who care, and not with
>> the server.
>
>The client implementors I have talked to hate the idea of polling.  They
>will poll if that is all we support, but they'd rather have something
>better.

SAI> Agreed, polling is bad. However, so are persistent connections.
SAI> So the best approach would be a intermediary (some call a channel,
SAI> some call a notification service, etc.) that can offload the server
SAI> of maintaining connections for every client.  The clients can use that
SAI> same LDAP connection they are using for other things, register
SAI> interest using LDAP semantics and syntax, and then let some listener
SAI> wait for async notifcation reports to come back. The server forwards
SAI> the subscription onto the channel which can quench, filter, route, etc.
SAI> The LDAP server is not forced to do these things.  These optimization
SAI> mechanisms are independent of semantics and therefore can be 
SAI> reused by the channel for all notificaiton applications, not just LDAP.
SAI> If LDAP, Print (IPP), WEBDAV, CalSched, PIPR, SWAP, etc all had their
SAI> own event filtering and routing code, then a server running all of these
SAI> services would be swamped with duplicated code, unneeded connections,
SAI> duplicate state management, inconsistent filters and routing algortihms, 
SAI> etc.  
SAI>
SAI> Defining the abstraction of some intermediary, does not force an
SAI> LDAP server to not implement that abstraction, however, the big win is,
SAI> neither does it force it to implement that abstraction. 
SAI>

>-- 
>Mark Smith
>Directory Architect / Netscape Communications Corp.
>My words are my own, not my employer's.  Got LDAP?
>

Scott Isaacson