I don't believe that this should be incorporated into the core server. The core of Apache is an HTTP server, which means that it should only know how to listen on TCP sockets. The support is there however, for other socket types to be added to the server. For the UDP case, your protocol module should implement it's own listen directive, to allow people to add UDP sockets for your protocol module. Then, the protocol module can set the accept_function pointer in the listen_rec, which in this case should be set to unixd_udp_connect. Now, when the server returns from apr_poll, it will automatically call the correct function for the current socket type.
For the actual network I/O, your protocol module will need to have it's own filter to replace the core_output and core_input filters. This makes sense, because the standard filters are very much tuned towards what we expect in the HTTP world. If you replace those functions, you can tune them to give the best possible performance for your protocols. The two places that still need to be fixed for this to work are adding sockets to the listen_rec list and the lingering_close logic. Both of these can be fixed by adding a hook to the server. Adding listeners to the listen_rec list _may_ be possible in the open_logs phase, which is where the core server does it, but I haven't tried to implement that yet. If it can be doine in the open_logs phase, then you won't need another hook for it. The lingering close logic should just be replaced by a simple hook that the core server calls. The core can add lingering_close to that hook, and everything should continue to work. Please let me know if any of this doesn't make sense. I like the idea of allowing the core to be used for UDP-based protocols, but I want to be sure that it is done the best way possible. Ryan On Wed, 14 Aug 2002, Tony Toyofuku wrote: > Hi, > > Many months ago I submitted a patch for UDP support within Apache 2.0. This > a resubmission of that patch, > which allows for UDP packets to work with Unix versions of Apache 2.0. > Here's what I wrote then: > > This patch adds UDP support to unix versions of Apache 2.0. > > This patch is set to add UDP support to the prefork MPM; however it should > be > trivial to add UDP support to other MPMs (changing the MPM_ACCEPT_FUNC > definition in mpm.h, and adding the UDP_LISTEN_COMMANDS line in the MPM > source > code). > > Here's how it works: > > 1. At configuration time, there's a new directive "UDPListen". This is just > like the normal "Listen" directive, but it sets up a UDP "listener". It > sits > in the httpd.conf file, and looks like this (where "8021" is the port > number): > > UDPListen 8021 > > 2. Since there's no notion of accept() on a UDP socket, there's a new > abstraction layer between the accept system call, named unixd_pop_socket. > If > the incoming request is UDP, the socket gets routed to a UDP version of the > "unixd_accept" function. If the request is TCP, it gets send to the > existing > "unixd_accept" function. > > 3. The network I/O is now done using recvfrom() & sendmsg, since UDP must > know > the port/address of the client. Additionally, rather than using sendfile() > for > the UDP requests, emulate_sendfile is used instead. This is required since > sendfile() won't work with connection-less sockets. > > That's pretty much it. > > Although the UDP transport layer will work for HTTP, for me the value of UDP > > is to use Apache 2.0 with its new multiple protocol support. In this way, > I can write an Apache protocol module to communicate with the legacy UDP > systems that I've got to support. > > <<udp.patch>> <<httpd.conf>> <<readme.txt>> <<udpclient.tar.gz>> > > I've included a modified version of one of the APR UDP test apps, and its > Makefile to exercise the server. > > Tony > > -- _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
