You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Holsman <ia...@apache.org> on 2002/08/15 01:03:57 UTC
Re: [PATCH] UDP support
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
>>
>>
>
>
Re: [PATCH] UDP support
Posted by Jeff Trawick <tr...@attglobal.net>.
Ian Holsman <ia...@apache.org> writes:
> 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,
Are there any problems you know of in that area?
I don't normally exercise apr/test/testsockets, but it plays with
basic UDP interaction and it works for me on Solaris.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: [PATCH] UDP support
Posted by rb...@apache.org.
On Wed, 14 Aug 2002, Ian Holsman wrote:
> 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?
Definately not in favor of the bucket changes. A UDP bucket should have
it's own bucket type IMHO. As for the APR-proper changes, I need to look
at them in more detail before I can give an educated opinion.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------