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
