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
-------------------------------------------------------------------------------