From willem at nlnetlabs.nl Thu Apr 2 21:26:49 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 02 Apr 2015 23:26:49 +0200 Subject: [getdns-users] getdns 0.1.7rc2 pre-release Message-ID: <551DB419.1020606@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We have a second release candidate for getdns version 0.1.7. This release candidate has minor fixes and additions, for which it would be a shame to let them wait until the next release. Though, we do want to provide opportunity to respond to these changes before release. getdns_address() now schedules AAAA query before the A query. They were and are queried for simultaneously, but before, the request for the A was put on the wire before the request for the AAAA. Now this order is flipped. Besides this fix, we have heeded the suggestions from Scott Hollenbeck on the getdns-api list. Both a setter and getter for an "on update of context" callback, with an user argument, are provided: getdns_context_set_update_callback() and getdns_context_get_update_callback(). A message on the getdns API list to suggest these functions to replace the compeer without the user argument in the API will follow. Also, a better method to get the associated text with an getdns error or response code is provided: getdns_get_errorstr_by_id(). The prototype for the function that was previously used for this goal, getdns_strerror(), has moved to the getdns_extra.h so that getdns.h contains API prototypes only. Please review this candidate carefully. If no issues arise the actual 0.1.7 release will follow over six days on Wednesday the 8th of April 2015. link : https://getdnsapi.net/dist/getdns-0.1.7rc2.tar.gz md5 : c914fe832ab5024ddddac859b03cf98f sha1 : 190877d23dd0b2b09a9e9aa27df6d689d2ea8166 pgp sig: https://getdnsapi.net/dist/getdns-0.1.7rc2.tar.gz.asc ChangeLog ========= * 2015-0?-??: Version 0.1.7 * Individual getter functions for context settings * Fix: --with-current-date function to make build deterministically reproducible (i.e. the GETDNS_COMPILATION_COMMENT define from getdns.h contains a date value). Thanks Ond?ej Sur? * Fix: Include m4 dir in distribution tarball * Fix: Link build requirements in tests too. Thanks Ond?ej Sur? * Fix: Remove executable flags on source files. Thanks Paul Wouters * Fix: Return "just_address_answers" only when queried for addresses * Eliminate ldns intermediate wireformat parsing * The CSYNC RR type * Fix: canonical_name in response dict returns the canonical name found after following all CNAMEs * Implementation of the section 6 and 7 version of draft-ietf-dnsop-cookies-01.txt for stub resolution. Enable with the --enable-draft-edns-cookies option to configure. Use it by setting the edns_cookies extension to GETDNS_EXTENSION_TRUE. * Pretty printing of lists with: char *getdns_pretty_print_list(getdns_list *list) * Output to json format with: char *getdns_print_json_dict(const getdns_dict *dict, int pretty); char *getdns_print_json_list(const getdns_list *list, int pretty); * snprintf style versions of the dict, list and json print functions. * Better random number generation with OpenBSD's arc4random * Let getdns_address schedule the AAAA query first. This results in AAAA being the first in the just_address_answers sections of the response dict. * New context update callback function to also return a user given argument along with the context and which item was changed. Thanks Scott Hollenbeck. * Demotivate use of getdns_strerror and expose getdns_get_errorstr_by_id. Thanks Scott Hollenbeck. * A getter for context update callback, to allow for chaining update callbacks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVHbQZAAoJEOX4+CEvd6SYgcwP/2tpvvZCiRIy3kncZ9xp4KAe x/zj1FVryYVZZJ4iLYG9ZZJRorqgsx7sL04AHmRdT5+HFGvbLv8QCkFeZVbflGEq 2jsgo16qTIVfWrYiyuavsy0CRpZ2uupHQvJSA+dy0B9Rw7h2BieAzERzZBgicOvY ZpTk4ji3AvcffBA0/0X7c0Ca1y3Q9ZQw8+GjpAv9KfraTRPt+jrVtxXgLut4IZ1I ommczdNjOHSEtlUjdb3ntLgk5Ahxl/ncEPWmSPToRA06zBdVt1eN77kMKpxUhl3U CqqWemO49VIBOD8YVfkwuv22459vVNK5K9B6Gshlw/KNG3rcnNL3bvoapdX9e2fm rtn6/Xa/XDrovOJ2JCVOd4Yt5dmNVEn3MW+FKdNpRWPB8VX8EweMJOTLiyU0RYXO jkCjpqdNgmt3XikBucuCwajDakAZy/hjL1WidvsHSUJoFlCJ1d+vWq0Cdsu1hvh/ eBDk9SnfqTtGhWqBI3RyxFrgIVOwAxGnqLpYxl8SM1XQRmPlJgmFmzlR1+1U4gNK sKJea7UesifoqOaUOBvjLSFRj2Y/lukN8tdvw4IgzDoAbjtsOeBWwXT3DxdSnEYd Q7NDmLC0GrG1K34X/rJn065c56ukCZ3myCbrm9t4iLqfNkpJQhP1iyGOff8jknkm R4PrMn4/qnuolaDtddib =MbMc -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Wed Apr 8 21:20:45 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 08 Apr 2015 23:20:45 +0200 Subject: [getdns-users] getdns 0.1.7 released Message-ID: <55259BAD.2020001@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We have a new release, version 0.1.7 of our getdns API implementation. This release contains bug fixes. A notable fix is that getdns_address() now schedules AAAA query before the A query. They were and are queried for simultaneously, but before, the request for the A was put on the wire before the request for the AAAA. Now this order is flipped. Besides bug fixes, this release contains the results of a rework shortening the path from wire format to the response dictionary, dramatically decreasing the number of memory allocations and deallocations with each request. The release also has some improvement functions that are not part of the official API (yet), such as: - - getter functions for all the context properties (the API has only setter functions for these properties) - - output to JSON printer functions getdns_print_json_dict() and getdns_print_json_list() - - snprintf style printer functions getdns_pretty_snprint_dict(), getdns_pretty_snprint_list(), getdns_snprint_json_dict() and getdns_snprint_json_list() - - a function to register a context update callback function including a user defined argument: getdns_context_set_update_callback() - - a better method to get the associated text with an getdns error or response code: getdns_get_errorstr_by_id() These new non-API functions are all documented in doxygen style comments in the getdns_extra.h header file. Besides these improvement functions, the release also includes a draft implementation of the section 6 and 7 version of draft-ietf-dnsop-cookies-01.txt ( http://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/ ). This implementation is compatible with (uses the same opcode as) bind's 9.10's implementation. You need to specify the - --enable-draft-edns-cookies option to compile with this feature. Using it involves setting a "edns_cookies" extension. link : https://getdnsapi.net/dist/getdns-0.1.7.tar.gz md5 : edaee48f967c8b05b9d3b8eeab99a039 sha1 : 3e323b9b1217a2b2e20948b50b008e739b7cd01e pgp sig: https://getdnsapi.net/dist/getdns-0.1.7.tar.gz.asc ChangeLog ========= * 2015-04-08: Version 0.1.7 * Individual getter functions for context settings * Fix: --with-current-date function to make build deterministically reproducible (i.e. the GETDNS_COMPILATION_COMMENT define from getdns.h contains a date value). Thanks Ond?ej Sur? * Fix: Include m4 dir in distribution tarball * Fix: Link build requirements in tests too. Thanks Ond?ej Sur? * Fix: Remove executable flags on source files. Thanks Paul Wouters * Fix: Return "just_address_answers" only when queried for addresses * Eliminate ldns intermediate wireformat parsing * The CSYNC RR type * Fix: canonical_name in response dict returns the canonical name found after following all CNAMEs * Implementation of the section 6 and 7 version of draft-ietf-dnsop-cookies-01.txt for stub resolution. Enable with the --enable-draft-edns-cookies option to configure. Use it by setting the edns_cookies extension to GETDNS_EXTENSION_TRUE. * Pretty printing of lists with: char *getdns_pretty_print_list(getdns_list *list) * Output to json format with: char * getdns_print_json_dict(const getdns_dict *dict, int pretty); char * getdns_print_json_list(const getdns_list *list, int pretty); * snprintf style versions of the dict, list and json print functions. * Better random number generation with OpenBSD's arc4random * Let getdns_address schedule the AAAA query first. This results in AAAA being the first in the just_address_answers sections of the response dict. * New context update callback function to also return a user given argument along with the context and which item was changed. Thanks Scott Hollenbeck. * Demotivate use of getdns_strerror and expose getdns_get_errorstr_by_id. Thanks Scott Hollenbeck. * A getter for context update callback, to allow for chaining update callbacks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVJZutAAoJEOX4+CEvd6SYZvwP/RbACid5/Ui5cn88Uli0u36p MQdQxbpvo2xkb157oNl0Fp/IndNEF0u2p0gOmuTPsjT9K7/+9aQ8sWC/oLaO/Wa+ PylIp426dlSKvPVp1/wTBe1MBpByvCoBZ0kqftGFEyaIhbOmy7Pya+j0kVfuwPNo NVv7X4p0CUjLaKfVwts7qnsb/dl5KKPv4Y1wszbre7jDClate4C/N1MN/vWR2SPY ISFcOZXXzY3a9dWsNnkL3bBbIXVxsqqZu2Z1ONA2sOZM5e6F+LY00OAzsvn0PgKD 6s0oJqglKxoxcjrwgQKsIo4ZysAGhawH9FmPAgfNbbjptrEfk5PAEh/WFgPjFLdL H1SsxYlpOJsDOp0hkx75dGlRmKZPZkUP3CaNdG020wNH35rkG0ioixOr3/D4dMdk Fgw+SPZZOAKk838ylZfcD0HJnk0zZ00/WjmGVrnHJpephb5fsXbwlK8pWCQwnU9e xSDbwgViBWOsxwV6Z8qtVio5AP8hM8QAuUo8d8hwHcxvkKocl6vVANshO0p/0Zp0 7r0uFx9EUoCUSbWxf2/pmAly4nyWPzi6VP/qaLDUUKGP6itIxiOP4GLr0wS4Vq2m cVKPL6iYJDhUbW4pcsX0ZMuGL6AMpWSydXePSe4vUMETzKClGV/Mjk5CO/6oqnoY AIj6ucJFiVgoUo+h2XTZ =bKuj -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Sun Apr 19 21:16:10 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Sun, 19 Apr 2015 23:16:10 +0200 Subject: [getdns-users] The special TNW2015 getdns 0.1.8 release Message-ID: <55341B1A.4070406@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We have a special The Next Web 2015 Hack Battle feature release of our getdns API implementation This release adds a single feature: DNS over TLS on port 1021. The feature is offered through two values for use with the getdns_context_set_dns_transport() function: GETDNS_TRANSPORT_TLS_ONLY_KEEP_CONNECTIONS_OPEN and GETDNS_TRANSPORT_TLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN. Coming Wednesday and Thursday, the 22th and 23rd of April, the getdns API will be one of the API's available to use in a Hack Battle at The Next Web Conference in Amsterdam. With this feature release we wish to facilitate and inspire the participants of the Hack Batle with this privacy enhanced way to use the DNS. Note however that this implementation of DNS over TLS is very much a happy path implementation; The new transports only work in stub mode. It is not yet possible to change the port for TLS communication and the TLS handshake currently blocks other outstanding callbacks. A release that will resolve these issues will follow shortly. All other transports remain fully asynchronous with no blocking. Also note that the transport options in the API are under review and are likely to be modified to provide greater flexibility in the near future. Because of the relative smallness and isolation of the new feature, we deemed it safe to do an immediate release. link : https://getdnsapi.net/dist/getdns-0.1.8.tar.gz md5 : 801e180a2013a1ee3bc7f13b3bb2d11f sha1 : 9da08fac561353f06589fe9d13ce5df6a58c2799 pgp sig: https://getdnsapi.net/dist/getdns-0.1.8.tar.gz.asc ChangeLog ========= * 2015-04-19: Version 0.1.8 * The GETDNS_TRANSPORT_TLS_ONLY_KEEP_CONNECTIONS_OPEN and GETDNS_TRANSPORT_TLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN DNS over TLS transport options. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVNBsaAAoJEOX4+CEvd6SYfKYP/2xOgERijXQq+VKzy/sH2yq4 uuEhKvi+kiBGFQl1/UDX49+H6KaLIfxnATytclQmAt3Wlixa7o0ZsGjBYUA40p2i hU6HLwIn2WOEjvVAYksqDc443wAGK6owBkWGJtpwRDDmCDjy/x2tTwMemYddFJ39 AQFTYMFaRjVydT7DYBNlqOgXKHNw/2N4hqF98G6MIGQke75XdipUVzFPCJFR6Z8T 3O/J+7KAI+98S21tDX4CiRbpDtcSVqKfzh6Ww/phTV7ocjVY523mImpaF+TCVeKe UYRZhBGHW8edvfE1GABQsfIlWFc7OitFp+S/DtZgxa+/SaE68dmABoiLksaM6hFS dVkHUgN/vqw4Ol2wp9BofycbLpOfD6XONQ/hA99cJNJf42g4dChLH1Hv7+cb81ar YW/SEKh+haj3hs9QUKjZrknnNU2e9PgnW2Sb+fMWTBI5ipijy89r50Nn/FJZVHcX fys6qgjsN5WpDenpNvrIb83Nnt5RmiKzmCf1iFRHyNj2eykc0X2TxNU48z2mvhhS 9zx1ZFYJDSNftZDUTFt8TJ5Hu1ZEZhGPnRiODofYkvGDVLMIbAj2I34aWUqYhF9I aue4BE1wH9kvD6U42SUsZ2KWpqSJU4FkwdQlWqX4f5reuT4/utj43EodRpB+0EJE ca0R4ToSV4bJn7ZvZA0w =fY6H -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Tue Apr 21 15:10:51 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 21 Apr 2015 17:10:51 +0200 Subject: [getdns-users] PHP Language Bindings and Async Event Management In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49FA5A05@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49FA2D8F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55315949.50005@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F49FA4520@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55352EAC.7050906@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F49FA5A05@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <5536687B.9060707@nlnetlabs.nl> Hi Scott, With our getdns implementation, the extensions are wrappers that provide a uniform interface for different event bases. We provide extensions for libevent, libev and libuv. We also have a built in event base (mini_event) based on select, that will we the default extension when you did not set one explicitly with getdns_extension_set_libevent_base, getdns_extension_set_libev_loop and getdns_extension_set_libuv_loop. All those extension provide their uniform interface through a list of function pointers with the same signature (the virtual method table (hence vmt)) in another struct which might have extension specific data (like the event base itself where the extension provides the uniform interface for). So they are actually objects for the getdns_eventloop class... One of the functions in the VMT is the cleanup function which will destroy the extension, but in case of the libevent, libev and libuv extension, not the event bases with which the extension was created and set. Only with mini_event there was no event base on which the extension was based, so that will destroy the event base with the extension. I think this answers everything you wanted to know about this, but there is something else interesting too. Our implementation provides means to create an event base extension yourself. In fact, the node bindings use this to hook into the node native libuv event loop (so it does not use the libuv extension!). I do not know how async operation is handled with php normally, but to just give an example for its potential (which might event not be realistic)... If we could provide python bindings for those methods to create your own extension, it might be possible to hook into native python event systems, like twisted. Food for thought ;) Cheers, -- Willem Op 21-04-15 om 13:30 schreef Hollenbeck, Scott: >> -----Original Message----- >> From: getdns-api [mailto:getdns-api-bounces at vpnc.org] On Behalf Of >> Goyal, Neel >> Sent: Monday, April 20, 2015 1:58 PM >> To: Melinda Shore; getdns-api at vpnc.org >> Subject: Re: [getdns-api] PHP Language Bindings and Async Event >> Management >> >> Freeing the context should not clean up the event base. If the event >> base >> is shared between other async libs and they are adding to that event >> base, >> a context destroy should not prevent those libs from still functioning. >> The context_destroy makes sure the context is detached from the >> event_base, but any structures specific to libevent are not cleaned up. >> Much like the user has to create the lib event base explicitly and then >> attach it to getdns, the user has to free it. > > Neel, in a note I sent to this list last week (BTW, it looks like recent notes aren't being archived) I described a challenge I found in trying to use the PHP libevent extension with getdns. I can create an event base, but I don't see an easy way to attach that to a context. Come on down if you have a chance and I'll walk you through what I found. > > So, I took a look at how I could use the functions provided by the getdns libevent extension. Looking at the code in context.c, I found that getdns_context_create() calls getdns_context_create_with_memory_functions(), which calls getdns_context_create_with_extended_memory_functions(). That function calls getdns_mini_event_init() (in file libmini_event.c), which creates an event base and sets an event loop. That base is cleaned up when calling getdns_context_destroy(), which calls context->extension->vmt->cleanup(context->extension). > > Scott > > _______________________________________________ > getdns-api mailing list > getdns-api at vpnc.org > From ngoyal at gmail.com Tue Apr 21 17:46:58 2015 From: ngoyal at gmail.com (Neel Goyal) Date: Tue, 21 Apr 2015 17:46:58 +0000 Subject: [getdns-users] PHP Language Bindings and Async Event Management In-Reply-To: <5536687B.9060707@nlnetlabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F49FA2D8F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55315949.50005@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F49FA4520@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55352EAC.7050906@nomountain.net> <831693C2CDA2E849A7D7A712B24E257F49FA5A05@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5536687B.9060707@nlnetlabs.nl> Message-ID: As a followup, the iOS bindings also created an event base that worked native w/ grand central dispatch. Ideally Android could work the same way without an additional worker thread. On Tue, Apr 21, 2015 at 11:11 AM Willem Toorop wrote: > Hi Scott, > > With our getdns implementation, the extensions are wrappers that provide > a uniform interface for different event bases. We provide extensions > for libevent, libev and libuv. We also have a built in event base > (mini_event) based on select, that will we the default extension when > you did not set one explicitly with getdns_extension_set_libevent_base, > getdns_extension_set_libev_loop and getdns_extension_set_libuv_loop. > > All those extension provide their uniform interface through a list of > function pointers with the same signature (the virtual method table > (hence vmt)) in another struct which might have extension specific data > (like the event base itself where the extension provides the uniform > interface for). So they are actually objects for the getdns_eventloop > class... > > One of the functions in the VMT is the cleanup function which will > destroy the extension, but in case of the libevent, libev and libuv > extension, not the event bases with which the extension was created and > set. Only with mini_event there was no event base on which the > extension was based, so that will destroy the event base with the > extension. > > I think this answers everything you wanted to know about this, but there > is something else interesting too. > > Our implementation provides means to create an event base extension > yourself. In fact, the node bindings use this to hook into the node > native libuv event loop (so it does not use the libuv extension!). > I do not know how async operation is handled with php normally, but to > just give an example for its potential (which might event not be > realistic)... If we could provide python bindings for those methods to > create your own extension, it might be possible to hook into native > python event systems, like twisted. > > Food for thought ;) > > Cheers, > -- Willem > > > > > > Op 21-04-15 om 13:30 schreef Hollenbeck, Scott: > >> -----Original Message----- > >> From: getdns-api [mailto:getdns-api-bounces at vpnc.org] On Behalf Of > >> Goyal, Neel > >> Sent: Monday, April 20, 2015 1:58 PM > >> To: Melinda Shore; getdns-api at vpnc.org > >> Subject: Re: [getdns-api] PHP Language Bindings and Async Event > >> Management > >> > >> Freeing the context should not clean up the event base. If the event > >> base > >> is shared between other async libs and they are adding to that event > >> base, > >> a context destroy should not prevent those libs from still functioning. > >> The context_destroy makes sure the context is detached from the > >> event_base, but any structures specific to libevent are not cleaned up. > >> Much like the user has to create the lib event base explicitly and then > >> attach it to getdns, the user has to free it. > > > > Neel, in a note I sent to this list last week (BTW, it looks like recent > notes aren't being archived) I described a challenge I found in trying to > use the PHP libevent extension with getdns. I can create an event base, but > I don't see an easy way to attach that to a context. Come on down if you > have a chance and I'll walk you through what I found. > > > > So, I took a look at how I could use the functions provided by the > getdns libevent extension. Looking at the code in context.c, I found that > getdns_context_create() calls > getdns_context_create_with_memory_functions(), which calls > getdns_context_create_with_extended_memory_functions(). That function calls > getdns_mini_event_init() (in file libmini_event.c), which creates an event > base and sets an event loop. That base is cleaned up when calling > getdns_context_destroy(), which calls > context->extension->vmt->cleanup(context->extension). > > > > Scott > > > > _______________________________________________ > > getdns-api mailing list > > getdns-api at vpnc.org > > > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shollenbeck at verisign.com Mon Apr 27 13:22:24 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Mon, 27 Apr 2015 13:22:24 +0000 Subject: [getdns-users] Transaction Identifier Strangeness Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FBD137@BRN1WNEXMBX01.vcorp.ad.vrsn.com> I'm seeing some strange transaction identifier behavior when calling getdns_address() and getdns_context_run(). Am I doing something wrong or is this expected behavior? First, please note that PHP doesn't do unsigned 64-bit integers. I'm using printf to display values. Hopefully the display format I'm using isn't the problem. I'm passing a NULL to getdns_address(). The API documentation says that "This pointer can be NULL, in which case it is ignored and no value is assigned" and "If the function fails, transaction_id is set to 0". First question: I don't see anything in the getdns_general_ns() function in general.c that actually sets the value of the transaction identifier to zero on error. Is the documentation correct? So, I call getdns_address() and the function returns without error. I then call getdns_context_run() to get things going. I have this print statement in the general.c, function priv_getdns_call_user_callback(), just before it calls my callback function: printf("TransID in getdns: %016llX\n", trans_id); It produces this: "TransID in getdns: E082EBCE57E01192" This is the value I see in my callback function. Second question: is this to be expected if I originally passed NULL to getdns_address()? Thanks, Scott From dkg at fifthhorseman.net Thu Apr 30 01:37:55 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 Apr 2015 21:37:55 -0400 Subject: [getdns-users] [PATCH] Fix libversion numbering Message-ID: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> Version 0.1.7 built libgetdns.so.0 instead of libgetdns.so.1. This broke anything depending on the package keeping the same SONAME from 0.1.6 to 0.1.7. The problem stems from a broken libversion in upstream's configure.ac. This is worked around in 0.1.8 by another change to GETDNS_LIBVERSION, but the change isn't correct either, since interfaces have been added again (in partcular, the GETDNS_TRANSPORT_TLS_* constants have been added, which affects the API at least, for tools trying to compile against the newer version). Note that the commentary in configure.ac about how to update libversion is correct up to a point, but then breaks things badly. This patch removes that as well. Here is the canonical reference for how to update libversion: https://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info --- configure.ac | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 6e98e01..6e321ee 100755 --- a/configure.ac +++ b/configure.ac @@ -52,18 +52,14 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on $CURRENT_DATE for th # if any interfaces have been added since the last public release then increment age # if any interfaces have been removed or changed since the last public release then # set age to 0 -# if api unchanged: no changes -# if api broken: current++ ; revision = 0; age = 0 -# if programs compiled against existing library work and link with new -# version of library with new binary api: revision++; age++ # # getdns-0.1.4 had libversion 0:0:0 # getdns-0.1.5 had libversion 1:0:0 # getdns-0.1.6 had libversion 1:1:0 -# getdns-0.1.7 had libversion 1:2:1 -# getdns-0.1.8 will have libversion 1:3:0 +# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:2:1) +# getdns-0.1.8 had libversion 1:3:0 (but should have had 3:3:2) # -GETDNS_LIBVERSION=1:3:0 +GETDNS_LIBVERSION=3:3:2 AC_SUBST(GETDNS_COMPILATION_COMMENT) AC_SUBST(GETDNS_LIBVERSION) -- 2.1.4 From willem at nlnetlabs.nl Thu Apr 30 10:00:33 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 30 Apr 2015 12:00:33 +0200 Subject: [getdns-users] [PATCH] Fix libversion numbering In-Reply-To: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> References: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <5541FD41.8010702@nlnetlabs.nl> Op 30-04-15 om 03:37 schreef Daniel Kahn Gillmor: > Version 0.1.7 built libgetdns.so.0 instead of libgetdns.so.1. This > broke anything depending on the package keeping the same SONAME from > 0.1.6 to 0.1.7. I know! I wrongly assumed that was referring to too then. I also, until now, had the wrong impression that was reflected in the version number of the .so, which made me a bit reluctant to update . I now see that it is - that makes up the .so version. Thanks for the patch! Committed on the develop branch... -- Willem > > The problem stems from a broken libversion in upstream's configure.ac. > > This is worked around in 0.1.8 by another change to GETDNS_LIBVERSION, > but the change isn't correct either, since interfaces have been added > again (in partcular, the GETDNS_TRANSPORT_TLS_* constants have been > added, which affects the API at least, for tools trying to compile > against the newer version). > > Note that the commentary in configure.ac about how to update > libversion is correct up to a point, but then breaks things badly. > This patch removes that as well. > > Here is the canonical reference for how to update libversion: > > https://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info > --- > configure.ac | 10 +++------- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 6e98e01..6e321ee 100755 > --- a/configure.ac > +++ b/configure.ac > @@ -52,18 +52,14 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on $CURRENT_DATE for th > # if any interfaces have been added since the last public release then increment age > # if any interfaces have been removed or changed since the last public release then > # set age to 0 > -# if api unchanged: no changes > -# if api broken: current++ ; revision = 0; age = 0 > -# if programs compiled against existing library work and link with new > -# version of library with new binary api: revision++; age++ > # > # getdns-0.1.4 had libversion 0:0:0 > # getdns-0.1.5 had libversion 1:0:0 > # getdns-0.1.6 had libversion 1:1:0 > -# getdns-0.1.7 had libversion 1:2:1 > -# getdns-0.1.8 will have libversion 1:3:0 > +# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:2:1) > +# getdns-0.1.8 had libversion 1:3:0 (but should have had 3:3:2) > # > -GETDNS_LIBVERSION=1:3:0 > +GETDNS_LIBVERSION=3:3:2 > > AC_SUBST(GETDNS_COMPILATION_COMMENT) > AC_SUBST(GETDNS_LIBVERSION) > From shollenbeck at verisign.com Thu Apr 30 11:56:10 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Thu, 30 Apr 2015 11:56:10 +0000 Subject: [getdns-users] getdns_context_run() vs. getdns_context_process_async() Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FC02D6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> What's the functional difference between the getdns_context_run() and getdns_context_process_async() functions? Scott From willem at nlnetlabs.nl Thu Apr 30 12:31:16 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 30 Apr 2015 14:31:16 +0200 Subject: [getdns-users] getdns_context_run() vs. getdns_context_process_async() In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49FC02D6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49FC02D6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <55422094.4040005@nlnetlabs.nl> Hi Scott, getdns_context_run() blocks and runs the event loop until there is nothing more to process. getdns_context_process_async() does not block, but has a quick look to see if queries have been received, and if so does the callbacks. Then it looks if events have a timed out, and if so does those callbacks too. Note that getdns_context_process_async() does not work with stub requests with libevent. Although I can see some potential use cases for getdns_context_process_async(), I would rather get rid of it. Cheers, -- Willem Op 30-04-15 om 13:56 schreef Hollenbeck, Scott: > What's the functional difference between the getdns_context_run() and getdns_context_process_async() functions? > > Scott > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From shollenbeck at verisign.com Thu Apr 30 19:21:54 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Thu, 30 Apr 2015 19:21:54 +0000 Subject: [getdns-users] getdns_context_run() vs. getdns_context_process_async() In-Reply-To: <55422094.4040005@nlnetlabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F49FC02D6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55422094.4040005@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FC0C33@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Thursday, April 30, 2015 8:31 AM > To: users at getdnsapi.net > Subject: Re: [getdns-users] getdns_context_run() vs. > getdns_context_process_async() > > Hi Scott, > > getdns_context_run() blocks and runs the event loop until there is > nothing more to process. > > getdns_context_process_async() does not block, but has a quick look to > see if queries have been received, and if so does the callbacks. Then > it looks if events have a timed out, and if so does those callbacks > too. > > Note that getdns_context_process_async() does not work with stub > requests with libevent. Although I can see some potential use cases > for > getdns_context_process_async(), I would rather get rid of it. Thanks, Willem. Should I expect to see a different callback_type value in my callback function if I call one versus the other? I'm asking because while running through my PHP test cases I found that calling getdns_context_run() gave me a callback_type of 700 (GETDNS_CALLBACK_COMPLETE). Calling getdns_context_process_async() gave me a callback_type of 701 (GETDNS_CALLBACK_CANCEL). Is this expected behavior? Thanks, Scott From willem at nlnetlabs.nl Thu Apr 30 21:12:51 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 30 Apr 2015 23:12:51 +0200 Subject: [getdns-users] getdns_context_run() vs. getdns_context_process_async() In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49FC0C33@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49FC02D6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55422094.4040005@nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F49FC0C33@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <55429AD3.2070004@nlnetlabs.nl> Hi Scott, I don't know for sure without seeing the code, but might it be that you destroy the context right after the call to getdns_context_process_async() ? getdns_context_process_async() just has a quick look if it can do some callbacks immediately. If it cannot, it will not block and exit immediately. When there are requests still in flight they will be cancelled on a subsequent call to getdns_context_destroy(). If you want to process all outstanding queries, you should use getdns_context_run(). Also getdns_context_process_async() does not work with stub requests with libevent. The function is a leftover from earlier asynchronous mechanics and I would actually rather get rid of it. Use getdns_context_run() instead. Cheers, -- Willem Op 30-04-15 om 21:21 schreef Hollenbeck, Scott: >> -----Original Message----- >> From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem >> Toorop >> Sent: Thursday, April 30, 2015 8:31 AM >> To: users at getdnsapi.net >> Subject: Re: [getdns-users] getdns_context_run() vs. >> getdns_context_process_async() >> >> Hi Scott, >> >> getdns_context_run() blocks and runs the event loop until there is >> nothing more to process. >> >> getdns_context_process_async() does not block, but has a quick look to >> see if queries have been received, and if so does the callbacks. Then >> it looks if events have a timed out, and if so does those callbacks >> too. >> >> Note that getdns_context_process_async() does not work with stub >> requests with libevent. Although I can see some potential use cases >> for >> getdns_context_process_async(), I would rather get rid of it. > > Thanks, Willem. Should I expect to see a different callback_type value in my callback function if I call one versus the other? I'm asking because while running through my PHP test cases I found that calling getdns_context_run() gave me a callback_type of 700 (GETDNS_CALLBACK_COMPLETE). Calling getdns_context_process_async() gave me a callback_type of 701 (GETDNS_CALLBACK_CANCEL). Is this expected behavior? > > Thanks, > Scott > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users >