I would like to commit your UDP listener patch to apache 2.1's source tree.
(providing other people don't have any major objections)
I'm at a loss as to what the big picture is with the programming model enabled by this path. I could go read the whole "DNS+HTTP redirection system" but I'd rather not :)
How does process_func field ever get set? What type of MPM thread would be used to process the UDP -- the type of thread that polls on sockets or the type of thread that processes work. It doesn't fit well within the rest of Apache to assume that the "accept"-ing thread should process the message.
Why does ap_old_listeners need to be externalized?
About this code below: It seems like process_func is a flag that means ????? (I dunno; why wouldn't we be using the existing record here). Is that inherently connected to having a process_func, or are those separate issues?
/* Some listeners are not real so they will not have a bind_addr. */
if (sa) {
apr_sockaddr_port_get(&oldport, sa);
! if (!strcmp(sa->hostname, addr) && port == oldport && !(*walk)->process_func) {
/* re-use existing record */
new = *walk;
*walk = new->next;
Regarding the code below: Setting a key in a pool is not an appropriate way to get Apache to do some special processing on a socket. Surely the problem is that Apache doesn't have quite the right hook currently and an existing hook needs to be modified in Apache 2.1-dev or some new hook is needed?
{
apr_status_t rv;
! conn_rec *c;
! ap_listen_rec * lr = NULL;
!
! rv = apr_pool_userdata_get((void**)&lr,AP_LISTEN_REC_KEY,ptrans);
! if (rv == APR_SUCCESS && lr && lr->process_func) {
! apr_pool_userdata_set(NULL,AP_LISTEN_REC_KEY,NULL,ptrans);
! lr->process_func(csd,lr,server,ptrans);
! return NULL;
! }