Home
last modified time | relevance | path

Searched +hist:0 +hist:fb123d8 (Results 1 - 11 of 11) sorted by relevance

/Couchbase_C_Client_v3.0/cmake/Modules/
H A DGenerateConfigDotH.cmakediff 0ec214f1 Mon Aug 07 14:52:34 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-816: Fix DNS SRV support on Fedora 26 and FreeBSD

Change-Id: I0cbb54b615f5c71c75e91a02145def0df031633d
Reviewed-on: http://review.couchbase.org/82000
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.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 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>
/Couchbase_C_Client_v3.0/src/
H A Dhostlist.hdiff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format

Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106
Reviewed-on: http://review.couchbase.org/107219
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.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 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>
H A Dconnspec.ccdiff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format

Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106
Reviewed-on: http://review.couchbase.org/107219
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0e6ccebf Mon Dec 11 20:53:22 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-880: implement SSL client certificate authentication

Change-Id: I796e21454b4feac3de934c193fc8d7db66a1e710
Reviewed-on: http://review.couchbase.org/87015
Reviewed-by: Ellis Breen <ellis.breen@couchbase.com>
Tested-by: Build Bot <build@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 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>
H A Dconnspec.hdiff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format

Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106
Reviewed-on: http://review.couchbase.org/107219
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0e6ccebf Mon Dec 11 20:53:22 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-880: implement SSL client certificate authentication

Change-Id: I796e21454b4feac3de934c193fc8d7db66a1e710
Reviewed-on: http://review.couchbase.org/87015
Reviewed-by: Ellis Breen <ellis.breen@couchbase.com>
Tested-by: Build Bot <build@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 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>
H A Dinstance.ccdiff 0a2a74f5 Thu May 06 18:15:24 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-861: purge pipelines on lcb_destroy

Change-Id: I8dcab68e420f97f4cd994144a2e2051c310315f3
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/153041
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Brett Lawson <brett19@gmail.com>
diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format

Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106
Reviewed-on: http://review.couchbase.org/107219
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0e6ccebf Mon Dec 11 20:53:22 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-880: implement SSL client certificate authentication

Change-Id: I796e21454b4feac3de934c193fc8d7db66a1e710
Reviewed-on: http://review.couchbase.org/87015
Reviewed-by: Ellis Breen <ellis.breen@couchbase.com>
Tested-by: Build Bot <build@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 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 0be6d6b4 Fri Dec 16 17:59:51 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> remove mc_SERVER typedef

All components needing to access lcb::Server are now in C++, so there is
no need for a C compat layer

Change-Id: I2836b58faa49070a3ef52432eec4cc1e28f00b31
Reviewed-on: http://review.couchbase.org/71064
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Brett Lawson <brett19@gmail.com>
diff 0ffba2c0 Fri Jul 17 16:19:12 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-624: Allow histogram for n1qlback (1/3)

This change decouples the histogram information from the instance
itself, allowing external consumers.

Change-Id: I38ae7980da7433df555c1687fb73f76c6b69abad
Reviewed-on: http://review.couchbase.org/53340
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com>
diff 0ca95f98 Mon Sep 22 19:33:10 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Stylistic enhancements for durability

This is one of the oldest parts in the codebase. This commit tries to
bring the header comments and source code formatting/styling up to sync
with the rest of the code.

Change-Id: I1e7a5849b0b402c656daa467552895dc5d5f1b47
Reviewed-on: http://review.couchbase.org/41613
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0ac7fc4b Tue Jul 29 16:56:58 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Clarify bootstrap API layout

This removes all the helper macro entry points into
lcb_bootstrap_common() and replaces them with direct calls. Additionally
it creates a new file called bootstrap.h which contains a more detailed
description of how bootstrap actually works, and is now indexed by
Doxygen via `make doc-internal`.

Change-Id: Ice53f3b34524ffb41ee0cb58897098ceaefc5206
Reviewed-on: http://review.couchbase.org/40014
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Brett Lawson <brett19@gmail.com>
diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access

==19659== General Protection Fault
==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127)
==19659== by 0x4E90ACA: relocate_packets (instance.c:523)
==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583)
==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964)
==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3)
==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320)
==19659== by 0x4E982B4: lcb_wait (wait.c:112)

Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b
Reviewed-on: http://review.couchbase.org/22691
Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access

==19659== General Protection Fault
==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127)
==19659== by 0x4E90ACA: relocate_packets (instance.c:523)
==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583)
==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964)
==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3)
==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320)
==19659== by 0x4E982B4: lcb_wait (wait.c:112)

Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b
Reviewed-on: http://review.couchbase.org/22691
Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access

==19659== General Protection Fault
==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127)
==19659== by 0x4E90ACA: relocate_packets (instance.c:523)
==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583)
==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964)
==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3)
==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320)
==19659== by 0x4E982B4: lcb_wait (wait.c:112)

Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b
Reviewed-on: http://review.couchbase.org/22691
Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access

==19659== General Protection Fault
==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127)
==19659== by 0x4E90ACA: relocate_packets (instance.c:523)
==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583)
==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964)
==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3)
==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320)
==19659== by 0x4E982B4: lcb_wait (wait.c:112)

Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b
Reviewed-on: http://review.couchbase.org/22691
Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access

==19659== General Protection Fault
==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127)
==19659== by 0x4E90ACA: relocate_packets (instance.c:523)
==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583)
==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964)
==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3)
==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320)
==19659== by 0x4E982B4: lcb_wait (wait.c:112)

Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b
Reviewed-on: http://review.couchbase.org/22691
Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access

==19659== General Protection Fault
==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127)
==19659== by 0x4E90ACA: relocate_packets (instance.c:523)
==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583)
==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964)
==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3)
==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320)
==19659== by 0x4E982B4: lcb_wait (wait.c:112)

Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b
Reviewed-on: http://review.couchbase.org/22691
Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
diff 86585753 Tue Nov 20 22:21:30 UTC 2012 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-104 Fix illegal memory access

==19659== General Protection Fault
==19659== at 0x4E93216: ringbuffer_write (ringbuffer.c:127)
==19659== by 0x4E90ACA: relocate_packets (instance.c:523)
==19659== by 0x4E90E5E: lcb_update_serverlist (instance.c:583)
==19659== by 0x4E91B83: vbucket_stream_handler (instance.c:964)
==19659== by 0x60B7599: event_base_loop (in /usr/lib64/libevent-1.4.so.2.1.3)
==19659== by 0x5EB0320: lcb_io_run_event_loop (plugin-libevent.c:320)
==19659== by 0x4E982B4: lcb_wait (wait.c:112)

Change-Id: I6d8657433665b74ec5700f7665103f346bcfd46b
Reviewed-on: http://review.couchbase.org/22691
Tested-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
H A Dinternal.hdiff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format

Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106
Reviewed-on: http://review.couchbase.org/107219
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.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 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 0be6d6b4 Fri Dec 16 17:59:51 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> remove mc_SERVER typedef

All components needing to access lcb::Server are now in C++, so there is
no need for a C compat layer

Change-Id: I2836b58faa49070a3ef52432eec4cc1e28f00b31
Reviewed-on: http://review.couchbase.org/71064
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Brett Lawson <brett19@gmail.com>
diff 0ffba2c0 Fri Jul 17 16:19:12 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-624: Allow histogram for n1qlback (1/3)

This change decouples the histogram information from the instance
itself, allowing external consumers.

Change-Id: I38ae7980da7433df555c1687fb73f76c6b69abad
Reviewed-on: http://review.couchbase.org/53340
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com>
diff 0ca95f98 Mon Sep 22 19:33:10 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Stylistic enhancements for durability

This is one of the oldest parts in the codebase. This commit tries to
bring the header comments and source code formatting/styling up to sync
with the rest of the code.

Change-Id: I1e7a5849b0b402c656daa467552895dc5d5f1b47
Reviewed-on: http://review.couchbase.org/41613
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0ac7fc4b Tue Jul 29 16:56:58 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Clarify bootstrap API layout

This removes all the helper macro entry points into
lcb_bootstrap_common() and replaces them with direct calls. Additionally
it creates a new file called bootstrap.h which contains a more detailed
description of how bootstrap actually works, and is now indexed by
Doxygen via `make doc-internal`.

Change-Id: Ice53f3b34524ffb41ee0cb58897098ceaefc5206
Reviewed-on: http://review.couchbase.org/40014
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Brett Lawson <brett19@gmail.com>
diff 0a7576ad Wed Dec 21 12:01:21 UTC 2011 Trond Norbye <trond.norbye@gmail.com> Update copyright year

Change-Id: I6655c26cca406c7d6d383b2716f2ba83cc658cbf
Reviewed-on: http://review.couchbase.org/11790
Reviewed-by: Trond Norbye <trond.norbye@gmail.com>
Tested-by: Trond Norbye <trond.norbye@gmail.com>
/Couchbase_C_Client_v3.0/tests/basic/
H A Dt_connstr.ccdiff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format

Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106
Reviewed-on: http://review.couchbase.org/107219
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.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 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>
/Couchbase_C_Client_v3.0/cmake/
H A Dconfig-cmake.h.indiff 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 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 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>
H A Dsource_files.cmakediff 0b67f157 Wed Sep 04 14:20:37 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Remove CAS durability polling

Change-Id: I114eceff5918262a9ee5eaebf245afd69629853f
Reviewed-on: http://review.couchbase.org/114246
Reviewed-by: Brett Lawson <brett19@gmail.com>
Tested-by: Build Bot <build@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 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>
/Couchbase_C_Client_v3.0/
H A DCMakeLists.txtdiff 31bd2afa Mon Jul 19 13:06:29 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.2.0

Change-Id: I0af9154473a5ba2fa30326475ff9b39ff27d3d94
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/157772
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff ed8b57e7 Wed Mar 03 07:31:38 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.1.0

Change-Id: I55e7e823d2a1ae4a47be86bc477f54b7b3b50e5a
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/147552
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0fb5c84a Thu Dec 20 10:55:05 UTC 2018 Sergey Avseyev <sergey.avseyev@gmail.com> Fix subdoc tests against real cluster

Change-Id: Ie79a789054290185793d82a06429e832c0110aab
Reviewed-on: http://review.couchbase.org/103083
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 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 0dc3fd13 Fri Sep 15 08:41:11 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> Allow to defer rebalance for node failover

Change-Id: Ibe7e357d6de95ab0ffef9623dce608d8e5f58898
Reviewed-on: http://review.couchbase.org/83424
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 7c4988d0 Tue May 02 22:33:01 UTC 2017 Mark Nunberg <mnunberg@haskalah.org> CCBC-774: Update subdoc protocol for Spock

- This adds new doc-level flags, manifested as `LCB_CMDSUBDOC_F_` ...
- Allow full-doc get/set with `LCB_SDCMD_SET_FULLDOC` and
`LCB_SDCMD_GET_FULLDOC`
- Update to CouchbaseMock 1.5.0:
This also required a minor change to add a new attribute to the list of
known error map attributes. Otherwise it results in a parse failure.

Change-Id: I34f5c2a0180204133690d5a73638f85c78dfffa5
Reviewed-on: http://review.couchbase.org/77376
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.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 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>
/Couchbase_C_Client_v3.0/include/libcouchbase/
H A Dcouchbase.hdiff 0c4213b9 Wed Jul 21 17:36:20 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-1429: fixed positional parameters for query/analtyics

* reverts behaviour `lcb_cmdquery_positional_param` and
`lcb_cmdanalytics_positional_param` to append single JSON-encoded value
to arguments array.

* introduces new functions `lcb_cmdquery_positional_params` and
`lcb_cmdanalytics_positional_params` that accept all positional
arguments at once as JSON-encoded array.

* document, that old functions will emit compiler warning since 3.3.0
release and will be removed later.

Change-Id: Ia49c74e096682378c00ed4bf37b978a4514ac3fa
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/158001
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Brett Lawson <brett19@gmail.com>
diff 0c4213b9 Wed Jul 21 17:36:20 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-1429: fixed positional parameters for query/analtyics

* reverts behaviour `lcb_cmdquery_positional_param` and
`lcb_cmdanalytics_positional_param` to append single JSON-encoded value
to arguments array.

* introduces new functions `lcb_cmdquery_positional_params` and
`lcb_cmdanalytics_positional_params` that accept all positional
arguments at once as JSON-encoded array.

* document, that old functions will emit compiler warning since 3.3.0
release and will be removed later.

Change-Id: Ia49c74e096682378c00ed4bf37b978a4514ac3fa
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/158001
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Brett Lawson <brett19@gmail.com>
diff 5fb53793 Tue Nov 19 15:23:56 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-1123: migrate exists function to GET_META(0xa0)

Change-Id: I590d5583ca9112b395ca84ff8308b70453a16972
Reviewed-on: http://review.couchbase.org/118140
Reviewed-by: Ellis Breen <ellis.breen@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Brett Lawson <brett19@gmail.com>
diff 0b0310e1 Wed Apr 03 07:33:33 UTC 2019 Sergey Avseyev <sergey.avseyev@gmail.com> Reformat sources with clang-format

Change-Id: I6d9cdc0ca66b7cd7b75a5e064b64fe0adbc0b106
Reviewed-on: http://review.couchbase.org/107219
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 0e6ccebf Mon Dec 11 20:53:22 UTC 2017 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-880: implement SSL client certificate authentication

Change-Id: I796e21454b4feac3de934c193fc8d7db66a1e710
Reviewed-on: http://review.couchbase.org/87015
Reviewed-by: Ellis Breen <ellis.breen@couchbase.com>
Tested-by: Build Bot <build@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 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 810ae36b Tue Feb 02 20:31:20 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> CCBC-667: Allow get-and-touch with an expiry of 0

Change-Id: I03f9a890a7e7cfff6db160d6cb21a945cdc74189
Reviewed-on: http://review.couchbase.org/59479
Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com>
Tested-by: Mark Nunberg <mark.nunberg@couchbase.com>
diff 0ffba2c0 Fri Jul 17 16:19:12 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-624: Allow histogram for n1qlback (1/3)

This change decouples the histogram information from the instance
itself, allowing external consumers.

Change-Id: I38ae7980da7433df555c1687fb73f76c6b69abad
Reviewed-on: http://review.couchbase.org/53340
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com>
diff 13b0e7fe Sat Nov 08 16:48:42 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Undocument internal legacy structures from headers

- make some older definitions fit in a single line, because
they are no longer used internally and are intended for back compat with
older code.
- Undocument older `lcb_create_st` member structures
- Mode `lcb_configuration_callback` stuff to the `deprecated.h` file and
deprecate the callback accessors. These functions should not be used
in newer code - rather the alternative `lcb_set_bootstrap_callback`
should be used.
- Undocument internal `IOCREATEOPTS` members. Code should either
explicitly create one from external code, or use the builtin struct
variant.

We should really move a lot of these definitions outside of the header
files, but we need to be compatible with code as early as 2.0.0 (two
years ago).

Change-Id: I75619795e7d4a16248465dd580c3d43d6228f8e6
Reviewed-on: http://review.couchbase.org/43025
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>

Completed in 203 milliseconds