skip to content

For an RFC 4533 content synchronization session, when does refreshOnly fit a replica better than refreshAndPersist?

level: seniorimportance: must knowfreq 40%

answer

  1. poll, or stay connected
  2. mode picks the session shape
  3. refreshOnly ends, refreshAndPersist does not
  4. Sync Done Control carries the cookie
  5. opaque cookie resumes the content

basics

~20 s

refreshOnly fits a replica that cannot hold a connection open: it converges, receives a new syncCookie in the Sync Done Control, and disconnects, resuming later from that cookie. refreshAndPersist fits a replica with a stable link that should learn of each change as it happens.

solid answer

~40 s

The RFC 4533 Sync Request Control carries a `mode` of either `refreshOnly` or `refreshAndPersist`, plus an optional `syncCookie` from last time. With `refreshOnly` the server brings the client's copy up to date and then finishes: the search ends with a Sync Done Control carrying a fresh `syncCookie`, the connection can drop, and the client polls again whenever it next has a link. With `refreshAndPersist` the same refresh happens, but the search never completes — the server holds it open and emits a Sync State Control on each subsequent change, with Sync Info Messages carrying new cookies along the way. A vessel that is reachable only when it docks wants `refreshOnly`; a shore replica on a stable link wants `refreshAndPersist`, because the staleness window then becomes the replication latency rather than the polling interval.

code

asn1 · 9 lines
asn1
-- Sync Request Control (1.3.6.1.4.1.4203.1.9.1.1)
syncRequestValue ::= SEQUENCE {
     mode ENUMERATED {
          -- 0 unused
          refreshOnly       (1),
          -- 2 reserved
          refreshAndPersist (3) },
     cookie     syncCookie OPTIONAL,
     reloadHint BOOLEAN DEFAULT FALSE }

go deeper

for a junior

Recall that a replica asks a server for changes rather than being pushed everything, and that it keeps a marker so the next request starts where the last one stopped.

for a middle

Explain that the Sync Request Control's mode picks poll or stream, that refreshOnly ends with a Sync Done Control carrying a fresh cookie, and that the cookie is opaque client-held state.

for a senior

Show the operational reasoning: match the mode to the link, recognise a reconnect storm as the wrong mode rather than a short timeout, and state the staleness window each mode actually produces.

for a principal

Decide the estate's default and its exceptions, knowing each held persist session is server state and each poll interval is a promise about currency you will be held to.

## The Sync Operation, in one paragraph RFC 4533's content synchronization operation is an ordinary LDAP search with a Sync Request Control attached. The client names a base DN, a scope and a filter — that fragment of the tree is the **content** it wants to hold a copy of — and the server answers with the entries, each carrying a Sync State Control that names the entry's `syncUUID` and what happened to it. The whole point of the operation is that the second run should not resend everything, and the `syncCookie` is what makes that possible. ## refreshOnly: converge, then stop `refreshOnly` runs one refresh stage and terminates. 1. The client sends the search with the Sync Request Control, `mode` `refreshOnly`, and the `syncCookie` it kept from last time (omitted on a first run, which means "send me everything"). 2. The server sends what has changed since that cookie, and tells the client what has gone. 3. The search completes. The Sync Done Control on the result carries a **new** `syncCookie` and a `refreshDeletes` flag saying how deletions were expressed. A Sync Info Message may also carry an interim cookie during a long refresh. 4. The client stores the cookie and may disconnect. The replica is then exactly as current as its last poll, and no more. The staleness window is the polling interval plus the transfer. ## refreshAndPersist: stay connected and be told `refreshAndPersist` runs the same refresh stage and then **does not finish**. The search stays open; there is no Sync Done Control, because the operation has not ended. As changes are applied on the server, it sends further Sync State Controls for the affected entries, and Sync Info Messages carrying fresh cookies so the client can checkpoint without restarting. The staleness window is now the replication latency — normally sub-second — but the client is holding a long-lived connection and an open operation on the server, and it must handle the connection dying as a normal event rather than an error. ## Choosing between them | | `refreshOnly` | `refreshAndPersist` | |---|---|---| | Session shape | refresh, then the search ends | refresh, then stays open | | How the session ends | Sync Done Control with a cookie | connection loss, or the client stops | | Staleness window | the polling interval | replication latency | | Server cost | one burst per client per poll | one held operation per client | | Suits | intermittent links, batch windows, many quiet replicas | stable links, small change-propagation targets | | What you must build | a scheduler and cookie storage | reconnection with cookie resume | The practical rule: **pick `refreshOnly` when the connection is the scarce resource, and `refreshAndPersist` when currency is.** A vessel whose satellite link is up for an hour in port is the first case exactly; polling is not a weaker design there, it is the only design that matches the link. ## The syncCookie is the whole trick - It is **opaque**. The client stores the octets and returns them unaltered; it must not parse them, compare them for ordering, or share them between sessions with different content parameters. - It is **per-content**. A cookie was issued for a particular base, scope and filter. Handing it back on a session covering a different fragment of the tree is meaningless. - It is **state the client owns**. Lose it and the next session is a full refresh of the content; the server does not remember the client. - It is **not a credential**. The new connection's authentication state comes from its own LDAP Bind operation, and the cookie confers nothing. ## The failure that teaches the distinction A replica is configured with `refreshAndPersist` on a link that drops several times an hour. Each drop ends the operation, the client reconnects and re-runs the refresh stage, and the pattern reads in the logs as a storm of full synchronizations. The material fix is not a bigger timeout: it is recognising that the link is intermittent, switching to `refreshOnly` with a poll, and treating each poll as a complete, cheap, cookie-resumed session. The inverse error is equally common — a shore replica left on a fifteen-minute poll while someone wonders why a crew change signed off ashore takes a quarter of an hour to be visible.

  • What exactly is in a syncCookie, and what may a client do with it?
    Nothing a client is entitled to know. The value is opaque octets whose meaning belongs to the server that issued it. A client stores it and returns it unmodified on the next session over the same content. Parsing it, ordering two of them, or reusing one across a different base, scope or filter are all mistakes.
  • Under refreshAndPersist there is no Sync Done Control — so how does the client checkpoint?
    Through Sync Info Messages, which the server sends during and after the refresh stage carrying new cookies. The client stores the latest one, so a dropped connection resumes from there rather than from the cookie it started the session with.
  • Why is a first synchronization run different from every later one?
    Because there is no cookie to present, so the server has no idea what the client already holds and sends the whole content. That first transfer is also what LDIF is often used for instead: seeding a new replica in bulk offline, then starting a synchronization session from the cookie that follows it.
  • Does refreshAndPersist make the replica writable?
    No. It is a search that stays open, so it only carries content from the server to the client. A write still has to reach a server holding a writable copy of that naming context, by referral or by chaining, whichever the deployment uses.

saying these in an interview costs you the question

  • Thinks refreshAndPersist lets the replica write back to the server
  • Parses or compares syncCookie values instead of storing them opaquely
  • Calls refreshOnly a full resend of the content every time
  • Assumes RFC 4533 is part of the LDAPv3 core and always supported
  • Reuses one cookie across sessions covering a different base or filter
  • Treats a dropped persist connection as an error rather than a normal event