Hello together!
Please see below my submission abstract for a 45 minute talk.
Improvements of LDAP protocol and transaction protocol
The talk focuses on two fields:
* Asynchronous request mode. Servers receiving asynchronous request bundles have to send an immediate response for every request because they do not know, whether the client synchronously waits for a response or will continue sending requests asynchronously. Not sending it could create a deadlock if the client is in synchronous mode. You can enforce shortest response time with TCP_NODELAY (disable Nagle). Then you have a bad TCP packet utilization. In particular LDAP responses are very short (except for search results), tending to waste most of the available packet size. Or you have the TCP Nagle algorithm enabled, have efficient packet utilization but bad response times. A solution for this is the LDAP queue length control issued by the client and telling the server how many responses are expected. The server can then send all responses in just a single TCP packet despite TCP_NODELAY enabled. This leads to a two sided agreement about the length of the asynchronous queue and optimized usage of TCP packets.
* RFC 5805 improvements. The specification requires an extended request / response sequence for the transaction begin. Because of the server generated transaction identifier (TID) this communication must be synchronous and completed before the client starts sending the transactional requests. In environments where client requests travel a long distance the synchronous transaction begin is a throughput delimiter. Instead clients could also issue a TID on their own, omit the transaction begin extended request / response and use their TID with the usual transaction control. The server could detect the begin of a transaction with the first transaction control arriving. As long as it separates different client sessions by other means (TCP socket number, server side session ID, client credentials, ...) than the TID it will not puzzle different parallel transactions. Next thing: Once in transaction the server needs no reminder about this fact. The client may omit the transaction control for all requests (except the first one) that are part of the transaction. Instead it could send a "not part of transaction control" for those requests that should be handled outside of the transaction. Instead of flagging transaction membership for the majority of requests it flags non - membership for a small minority of requests. This saves network bandwidth because it avoids the redundant transmission of the same transaction control with every request. The improvements do not violate the ACID paradigm. The transaction end sequence is still needed and not affected. The server may advertise support for this extension by means of "supportedExtension" in the root object. It detects client side agreement to the changed protocol by receiving a request with transaction control without having received an extended transaction begin request before.
The presentation visualizes the mentioned problems and the proposed solutions by means of graphical sequence diagrams surrounded by written explanations. Further it contains graphs of experimental verifications of the throughput improvements. The experiments are carried out once in the Amazon cloud using intercontinental connections with long latency and once using the same equipment locally within the same sub net.
Biography
My name is Christian Hollstein. I am the CEO and founder of TeraCortex, a start up company developing LDAP technology since end of 2012. Our main product is DVTDS, a high speed LDAP directory server. I presented the server already at the LDAPCon 2013 in Paris. This talk is not going to focus on this product. Instead it is aiming to share some of the things that make the server so fast.
From 2006 I worked more than six years as LDAP data model designer for T-Mobile / DTAG mobile subscriber management. I was responsible for some of the main components (HLR / LTE) as well as for a number of mass data migrations in a distributed directory of 100 servers.
Before T-Mobile I spent my professional life in various long term projects in DTAG and Siemens, most time as developer and / or data base and system administrator.
Since 1985 I hold a degree in communications engineering from Fachhochschule Osnabrück, Germany.
Best regards
Christian Hollstein