Home
last modified time | relevance | path

Searched +hist:2 +hist:a07f70b (Results 1 - 5 of 5) sorted by relevance

/Couchbase_C_Client_v3.0/cmake/Modules/
H A DConfigureDtrace.cmakediff 2a07f70b Tue Nov 25 21:21:13 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Replace CMAKE_BINARY_DIR with PROJECT variants

This allows other (CMake) projects to include ourselves as a dependency within
CMake itself.

Change-Id: I6b37fed4050f4167455e016bed1f7fd9528bf2f3
Reviewed-on: http://review.couchbase.org/43630
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
diff 2a07f70b Tue Nov 25 21:21:13 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Replace CMAKE_BINARY_DIR with PROJECT variants

This allows other (CMake) projects to include ourselves as a dependency within
CMake itself.

Change-Id: I6b37fed4050f4167455e016bed1f7fd9528bf2f3
Reviewed-on: http://review.couchbase.org/43630
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
H A DGenerateConfigDotH.cmakediff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support

This adds DNS SRV lookups for bootstrapping. This is provided in two
forms:

1. When there is only a single hostname with no port. This is called
implicit lookup
2. When the scheme `couchbase+dnssrv://` is used. This is an explicit
mode and is considered internal to the library.

In both cases the input hostname will be selected and attempted for a DNS SRV
query. If it succeeds, then the hosts use for the query will be
returned. If the query fails, implicit mode will continue, using the
hostname as a couchbase node, whereas explicit mode will fail. Explicit
mode is useful for debugging the dns srv feauture itself.

Currently support depends on either Windows (which works "out of the
box") and libbind/libresolv, which come bundled with glibc on both OS X
and Linux. This may fail to function on very ancient systems; in which
event these routines are stubbed out with no-op equivalents.

Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80
Reviewed-on: http://review.couchbase.org/46177
Reviewed-by: Brett Lawson <brett19@gmail.com>
Tested-by: buildbot <build@couchbase.com>
diff 2a07f70b Tue Nov 25 21:21:13 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Replace CMAKE_BINARY_DIR with PROJECT variants

This allows other (CMake) projects to include ourselves as a dependency within
CMake itself.

Change-Id: I6b37fed4050f4167455e016bed1f7fd9528bf2f3
Reviewed-on: http://review.couchbase.org/43630
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
diff 2a07f70b Tue Nov 25 21:21:13 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Replace CMAKE_BINARY_DIR with PROJECT variants

This allows other (CMake) projects to include ourselves as a dependency within
CMake itself.

Change-Id: I6b37fed4050f4167455e016bed1f7fd9528bf2f3
Reviewed-on: http://review.couchbase.org/43630
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
H A DGetVersionInfo.cmakediff fadbd4d1 Wed Sep 22 16:11:06 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.2.2

Change-Id: If697f9cb0f6d387928d935a6786f86ab064225a3
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/162115
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff f463b2ef Mon Apr 26 14:30:23 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.1.2

Change-Id: I709a7ff749e34f327bbc3b73a22af0ce61620eff
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/152097
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff f4e34625 Wed Jun 10 06:28:11 UTC 2020 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.0.2

Change-Id: Id9170909dc7b229191e2c1ed7dcc72eaf9b16e9f
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/130180
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 150aa4ad Mon Dec 23 06:27:11 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.0.0-beta.2

Change-Id: Iebefffb066e501e5231e04f549a516b7748e067f
Reviewed-on: http://review.couchbase.org/119707
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 4e6095a7 Thu May 02 14:52:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.0.0-alpha.2

Change-Id: Id35592751cd75406a5b218f0142cea4ac396a320
Reviewed-on: http://review.couchbase.org/108591
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 6b3f760e Fri Nov 23 11:37:43 UTC 2018 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 2.10.2

Change-Id: I87e6e14a722cce140b12cc714da9562b5f118d4a
Reviewed-on: http://review.couchbase.org/102062
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 2bf296af Fri Sep 21 05:54:48 UTC 2018 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 2.9.5

Change-Id: Iefc3dc55b6faada8f08d8fa77a615ed8c9b75130
Reviewed-on: http://review.couchbase.org/99840
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0f7cb6fe Fri Jun 22 12:49:57 UTC 2018 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta 2.9.2

Change-Id: I0c7c1bd9be2e3f107c1715bb429058fa0c8f8d8e
Reviewed-on: http://review.couchbase.org/96000
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 5b8d57a3 Tue Oct 17 19:39:01 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 2.8.2

Change-Id: Ifea1e0cde3bb8d0b3c33b99cb39a6f07873ccaf4
Reviewed-on: http://review.couchbase.org/84505
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Build Bot <build@couchbase.com>
diff 2f655ce4 Thu Aug 31 09:50:24 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 2.8.0

Change-Id: If26b6ab7c5f5cc8d830f46768efc52367d4d06cd
Reviewed-on: http://review.couchbase.org/82958
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
/Couchbase_C_Client_v3.0/tests/
H A DCMakeLists.txtdiff 2a07f70b Tue Nov 25 21:21:13 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Replace CMAKE_BINARY_DIR with PROJECT variants

This allows other (CMake) projects to include ourselves as a dependency within
CMake itself.

Change-Id: I6b37fed4050f4167455e016bed1f7fd9528bf2f3
Reviewed-on: http://review.couchbase.org/43630
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
diff 2a07f70b Tue Nov 25 21:21:13 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Replace CMAKE_BINARY_DIR with PROJECT variants

This allows other (CMake) projects to include ourselves as a dependency within
CMake itself.

Change-Id: I6b37fed4050f4167455e016bed1f7fd9528bf2f3
Reviewed-on: http://review.couchbase.org/43630
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
/Couchbase_C_Client_v3.0/
H A DCMakeLists.txtdiff fadbd4d1 Wed Sep 22 16:11:06 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.2.2

Change-Id: If697f9cb0f6d387928d935a6786f86ab064225a3
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/162115
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff f463b2ef Mon Apr 26 14:30:23 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.1.2

Change-Id: I709a7ff749e34f327bbc3b73a22af0ce61620eff
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/152097
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 9249c3cf Wed Jun 13 09:11:35 UTC 2018 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-943: Implement option to dump TCP packets

This change introduces new cmake option, which will
force library to report all incoming/outgoing TCP packets on
TRACE log level. It renders the bytes in Base64 encoding.

Also there is simple extraction tool, which beautifies
packet traces, and could be used like this:

cbc cat -vvv foo bar 2>&1 | tools/extract-packets.rb

Change-Id: I9c65a1932b80438d49739b9d4983a8f8e4f72cf7
Reviewed-on: http://review.couchbase.org/95544
Reviewed-by: Ellis Breen <ellis.breen@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 2ffd3ec1 Wed Nov 23 16:24:17 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> SDKRFC-13/CCBC-752: Implement error map support

This implements error map support. The error map is a mapping of more
specialized errors to more generic attributes within the server. The
error map would therefore allow the server to return more detailed error
codes without worrying that a client has a special implementation to
handle that specific code.

The following features have been added:

- Send the XERROR flag on HELLO
- Load and parse the error map
- LCB_CNTL_ENABLE_ERRMAP and/or enable_errmap to enable this feature.
- Update to new Mock which supports the error map and XERROR

Note that the error map functionality is disabled by default, since
sending the XERROR flag tells the server we know how to handle the error
map entirely (including disconnects and retries). Error map will become
the default once the proper behaviors have been defined.

Change-Id: I3c5fbad983d3304eff9396ed7f9939d477720ce4
Reviewed-on: http://review.couchbase.org/70872
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Mark Nunberg <mark.nunberg@couchbase.com>
diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support

This adds DNS SRV lookups for bootstrapping. This is provided in two
forms:

1. When there is only a single hostname with no port. This is called
implicit lookup
2. When the scheme `couchbase+dnssrv://` is used. This is an explicit
mode and is considered internal to the library.

In both cases the input hostname will be selected and attempted for a DNS SRV
query. If it succeeds, then the hosts use for the query will be
returned. If the query fails, implicit mode will continue, using the
hostname as a couchbase node, whereas explicit mode will fail. Explicit
mode is useful for debugging the dns srv feauture itself.

Currently support depends on either Windows (which works "out of the
box") and libbind/libresolv, which come bundled with glibc on both OS X
and Linux. This may fail to function on very ancient systems; in which
event these routines are stubbed out with no-op equivalents.

Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80
Reviewed-on: http://review.couchbase.org/46177
Reviewed-by: Brett Lawson <brett19@gmail.com>
Tested-by: buildbot <build@couchbase.com>
diff 2acd7da3 Tue Aug 30 18:29:16 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> CCBC-718: add SUBDOC_F_MKDOCUMENT and GET_COUNT

This adds the GET_COUNT and MKDOC options. `GET_COUNT` retrieves the
number of items in an array or dictionary; MKDOC is another flag (like
MKDIR_P) which will create the document if it does not exist.

This commit also includes tests for the features, alongside an upgrade
to a newer CouchbaseMock version

Change-Id: I1fd5a9a910d37f9933f80b0297864683e9572bbd
Reviewed-on: http://review.couchbase.org/67213
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Brett Lawson <brett19@gmail.com>

Completed in 84 milliseconds