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
--
Christian Hollstein, CEO
TeraCortex GmbH, HRB 208395
Hopfenbrede 2
D-49179 Ostercappeln, Germany
Phone: 0049 5473 9933