{"id":1567,"date":"2014-12-16T19:24:27","date_gmt":"2014-12-16T19:24:26","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=1567"},"modified":"2025-06-13T23:50:17","modified_gmt":"2025-06-14T06:50:17","slug":"couchbase-net-sdk-20-development-series-part-1-1-server-configuration","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/couchbase-net-sdk-20-development-series-part-1-1-server-configuration\/","title":{"rendered":"Couchbase DOTNET SDK 2.0 Development Series: Part 1-1: Server Config"},"content":{"rendered":"

In the introduction to this series<\/a>, I discussed some of the motivation for rewriting .NET SDK, the goals, objectives and the major features of the upcoming 2.0 release, and we examined the high-level architecture (10000 feet view) of a Couchbase Server Client SDK. In this post we will go over the design and development of one of the core configuration components of a Couchbase SDK: Server Configuration.<\/p>\n

Introduction<\/h1>\n

A Couchbase SDK client requires configuration from two sources: the Client Configuration, which defines the IP of the cluster to connect to, number of connections to use and other important information regarding how the client will interact with the cluster and the Server Configuration, which defines the current state of the cluster (e.g. number of nodes, buckets that are available, etc.), thus driving the internal state of a client (Cluster Map<\/a>)<\/p>\n

This post will only discuss the Server Configuration aspects and will largely revolve around implementing several well-defined interfaces or contracts.<\/p>\n

HTTP Streaming Configuration<\/h2>\n

Currently, most clients use a \u201cbootstrapping\u201d technique via client configuration and a \u201cStreaming Configuration\u201d exposed by the Couchbase REST API<\/a>. This is supported by versions of Couchbase from 2.2 and back. The usual approach is as follows:<\/p>\n

\n
    \n
  1. Within the \u201curis\u201d element of a Client Configuration (semantics very per client), a URL is defined for which to start the bootstrapping process<\/a>:
    \nhttps:\/\/[SERVER]:8091\/pools<\/li>\n
  2. The response is then parsed and the a request is made to get the buckets configuration<\/a>:
    \nhttps:\/\/[SERVER]:8091\/pools\/default?uuid=[UUID]<\/li>\n
  3. This response is parsed and another request is made to get streaming URL<\/a> from:
    \nhttps:\/\/[SERVER]:8091\/pools\/default\/buckets?v=[VERSION]&uuid=[UUID]<\/li>\n
  4. Finally, the streaming URL connection is made which is long-lived and raises events in the client with respect to changes in the cluster:
    \nhttps:\/\/[SERVER]:8091\/pools\/default\/bucketsStreaming\/default?bucket_uuid=[UUID]<\/li>\n
  5. The client will then change its internal state to match that of the current server configuration.<\/li>\n<\/ol>\n<\/div>\n

    There are some problems with this approach, among others:<\/p>\n