Ryan Bloom wrote: > 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. >
I think we should get the patches that affect APR in the codebase as currently I don't think we can create a udp socket properly, and then we can discuss how http should listen on a UDP port. ryan.. are you happy with the changes to APR that this patch provides? > 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 >> >> > >
