Searched +hist:2 +hist:a07f70b (Results 1 - 5 of 5) sorted by relevance
| /Couchbase_C_Client_v3.0/cmake/Modules/ | ||
| H A D | ConfigureDtrace.cmake | 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 D | GenerateConfigDotH.cmake | 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 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 D | GetVersionInfo.cmake | diff 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 D | CMakeLists.txt | 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> |
| /Couchbase_C_Client_v3.0/ | ||
| H A D | CMakeLists.txt | diff 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