Re: [PATCH] UDP support
Ian Holsman <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] UDP support
Tony Toyofuku <[EMAIL PROTECTED]> writes: > Hi, > > Many months ago I submitted a patch for UDP support within Apache 2.0. This > a resubmission of that patch, Regarding the APR changes: Why would we need apr_udp_connect() that dups the socket? I don't see the relationship between normal udp client behavior and duping the socket. It looks like IPv6 support is broken by the patch. apr_sockaddr_t has the length of the native socket address in it. Use that when you set msg.msg_namelen. It looks like apr_sendto() is broken by the patch. Previously the caller could specify the target socket address. With your patch the caller's parameter is ignored. Discussion of the APR changes should move to [EMAIL PROTECTED] I hope this helps, Jeff p.s. if you must use attachments, please use a mime type of text/plain -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] UDP support
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 [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
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. >> >> <> <> <> <> >> >>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
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. > ><> <> <> <> > > 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 ---
