httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] UDP Listeners (was Re: DNS+HTTP redirection system inside an Apache module)
Date Tue, 15 Jul 2003 19:32:42 GMT
At 08:30 AM 7/15/2003, Michal Szymaniak wrote:

>What we have now, is a working UDP listener with two custom functions,
>'accept' and 'process'. Since accept's are serialized, we don't want to do
>any long-lasting stuff there. So, inside 'accept', we only retrieve all
>immediately-available datagrams, create a fake TCP socket to be
>returned (to fool some MPMs, such as worker, which tries to close the
>socket in some special cases), and register the listener inside the
>transaction pool, together with a list of the just-received datagrams (see
>dns_comm.c::dns_comm_accept_udp()).

First off, this should be considered a bug... that code SHOULD be handled
by the core, not the MPM.  We need an alternative for those special cases 
inside the worker MPM instead of directly manipulating the socket.  Hooks
would be fine here.  But let's not inject crufty workarounds when the real
answer is to just fix the bug.

Other 'protocol modules', eg pop3, also do interesting things with sockets.
The MPM should really avoid interacting with them directly.

>All this shows that running UDP in Apache can make sense, and I tried
>to get some attention about it one year ago.. But somehow everybody
>thought that UDP inside Apache can be used only for HTTP-over-UDP,
>which is indeed controversial.. I hope that full UDP-support will not
>be neglected in the next Apache release :-)

Let me offer one thought here.  I'm -0 on including this patch in Apache for
one very simple reason.  We are a standards-based server.  Yes, UDP is
a clear standard, as is HTTP.  But in order to incorporate your patch, I would
want to see nothing less than a draft RFC explaining the what and why of
what you are accomplishing, with community review.

Apache is a community project that tries to fill the need of the entire
community.  Without such review, this feature might be a great add-in
module (yes, we will help you find or add the right hooks), but it shouldn't
become part of the core distribution without RFC community discussion.
(IMHO).  Feel free to announce the draft RFC review discussion to this
list, it belongs on the IANA HTTP listserv, not here.

Bill



Mime
View raw message