#114 3 features related to connections
In attach there are 3 files git format-patch. Commits are based on current trunk version.
Description:
0001- Related to buffer_event. Addrinfo struct is held in buffer_event for buffer_event's lifetime in order to be queried. Added bufferevent_get_addrinfo function.
0002- bufferevent has new state BEV_EVENT_RESOLVE: DNS resolve failed. So we can disinguish between address resolution failures and connection errors (BEV_EVENT_ERROR)
* 0003- Possibility to make client connection creating sockets with SO_NOLINGER option. Need to set Connection option to EVCON_OPT_NOLINGER (call new function evhttp_connection_set_options)
Tests are adjusted in order to handle the changes.
We had to implement these features cause we needed them. We currently use them.
0001-Hold-addrinfo-in-buffer_event-in-order-to-be-able-to.patch :
-- what is the use-case here?
-- The documentation needs to explain that this is only for bufferevents which were created with bufferevent_socket_connect_hostname()
-- The new field should go in struct bufferevent_private, not bufferevent.
-- There should probably be a unit test
-- Do we support multiple invocations of the bufferevent_socket_connect_hostname() on the same bufferevent? If so we should probably have a
0002:
-- It doesn't make sense to have BEV_EVENT_RESOLVE indicate a failure. It might make more sense to have BEV_EVENT_RESOLVING to take a role like BEV_EVENT_READING and BEV_EVENT_WRITING, to indicate when an error occurred.
-- The change above would allow the error to be BEV_EVENT_RESOLVING|BEV_ERROR, so that old code which checked for only BEV_EVENT_ERROR would not break. Only under really exceptional circumstances is it okay to take changes that would break existing code.
-- Needs unit tests.
0003:
-- At a minimum, this needs documentation of when you would want to set it.