You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by David Williams <dw...@cisco.com> on 1999/11/08 20:24:02 UTC
UDP support?
Is there any work going on in apache 2.0 or 1.3.x to support UDP as a
transport layer. Or support anything other than TCP?
thanks,
-david
Re: UDP support?
Posted by "Kevin A. Burton" <bu...@relativity.yi.org>.
???
This isn't defined in the RFC so I would probably say no.
Why don't you just write your own UDP server?
David Williams wrote:
>
> Is there any work going on in apache 2.0 or 1.3.x to support UDP as a
> transport layer. Or support anything other than TCP?
>
> thanks,
> -david
Re: UDP support?
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> On Wed, 10 Nov 1999, Dean Gaudet wrote:
>
> > i'm not sure what more i can say except that udp sockets aren't connected.
> >
> > try it.
>
> I DID it two years ago. It was my senior project when I graduated from
> college. I KNOW it can be done, because I have done it.
You can probably get away with it if the request fits in a single UDP
packet. The response can take as many as it wants, coz there's only one
client. Forget keepalive.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: UDP support?
Posted by David Williams <dw...@cisco.com>.
Both views are correct. One may open a connected udp socket which
allows a process to communicate with exactly one peer. (The
application may chose the udp port number, or allow the kernel to
chose an ephermal one.)
There are also situations where a server needs to open a well-known
port and listen for requests from multiple clients. In this scenerio
the server may want to have a single process open the socket once.
So that retransmitted requests or multiple PDUs of a single
transaction all get handled by the same process, instead of randomly
be received by different processes.
My comment about the apache process model was related to using
unconnected udp sockets.
thanks,
-david
On Wed, 10 Nov 1999, Ryan Bloom wrote:
> On Wed, 10 Nov 1999, Dean Gaudet wrote:
>
> > i'm not sure what more i can say except that udp sockets aren't connected.
> >
> > try it.
>
> I DID it two years ago. It was my senior project when I graduated from
> college. I KNOW it can be done, because I have done it.
>
> > open up the same udp port in more than one process, and start sending
> > packets. notice how it's random which process get which packets. (unless
> > you broadcast the packets, in which case all the sockets get all the
> > packets).
>
> I think we modified two functions in Apache and two functions in Lynx to
> make it work. If you would like to see it, I am sure I can get the diffs
> from one of the guys I worked with. I lost my copies when I lost my last
> hard drive. :-)
>
> Ryan
>
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
>
Re: UDP support?
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
On Wed, 10 Nov 1999, Dean Gaudet wrote:
> i'm not sure what more i can say except that udp sockets aren't connected.
>
> try it.
I DID it two years ago. It was my senior project when I graduated from
college. I KNOW it can be done, because I have done it.
> open up the same udp port in more than one process, and start sending
> packets. notice how it's random which process get which packets. (unless
> you broadcast the packets, in which case all the sockets get all the
> packets).
I think we modified two functions in Apache and two functions in Lynx to
make it work. If you would like to see it, I am sure I can get the diffs
from one of the guys I worked with. I lost my copies when I lost my last
hard drive. :-)
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: UDP support?
Posted by Dean Gaudet <dg...@arctic.org>.
i'm not sure what more i can say except that udp sockets aren't connected.
try it.
open up the same udp port in more than one process, and start sending
packets. notice how it's random which process get which packets. (unless
you broadcast the packets, in which case all the sockets get all the
packets).
Dean
On Wed, 10 Nov 1999, Ryan Bloom wrote:
>
> You're right, it's been a few years, we didn't accept then dup, we
> select'ed and dup'ed. This should make sense now. I knew something was
> wrong when I wrote it, but I couldn't figure out what it was. I still do
> not see why the process model has implications for which type of socket
> are used.
>
> Ryan
>
> On Tue, 9 Nov 1999, Dean Gaudet wrote:
>
> >
> >
> > On Tue, 9 Nov 1999, Ryan Bloom wrote:
> >
> > > I do not understand why the process model has any implications for tcp or
> > > udp sockets.
> >
> > udp sockets aren't connected... so all the packets are delivered to one
> > socket, there's nothing to accept() and dup().
> >
> > Dean
> >
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
Re: UDP support?
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
You're right, it's been a few years, we didn't accept then dup, we
select'ed and dup'ed. This should make sense now. I knew something was
wrong when I wrote it, but I couldn't figure out what it was. I still do
not see why the process model has implications for which type of socket
are used.
Ryan
On Tue, 9 Nov 1999, Dean Gaudet wrote:
>
>
> On Tue, 9 Nov 1999, Ryan Bloom wrote:
>
> > I do not understand why the process model has any implications for tcp or
> > udp sockets.
>
> udp sockets aren't connected... so all the packets are delivered to one
> socket, there's nothing to accept() and dup().
>
> Dean
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: UDP support?
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 9 Nov 1999, Ryan Bloom wrote:
> I do not understand why the process model has any implications for tcp or
> udp sockets.
udp sockets aren't connected... so all the packets are delivered to one
socket, there's nothing to accept() and dup().
Dean
Re: UDP support?
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
The easiest way to replace tcp with udp in Apache 2.0 will be to just
replace the APR sockets layer with UDP sockets. This should be trivial,
and could be done in a matter of hours. Please take a look at the APR
code in the apache-2.0 repository.
I do not understand why the process model has any implications for tcp or
udp sockets. When I originally made this same modification, we just
accepted the request on the original socket, and dup'ed it immediately.
We then used the dup'ed socket for all of our communication. This is all
possible in APR.
If APR isn't enough, then I would suggest that ANYTHING more that was
needed could be easily accomplished by using a new APR layer in
combination with a UDP-MPM. This would be easy to accomplish.
HTH
Ryan
On Tue, 9 Nov 1999, Ben Laurie wrote:
> David Williams wrote:
> >
> > Ryan, I would be interested in more info. I haven't looked at the
> > APR, and I suppose I need to get a pointer to the new development code
> > base. I understand the need to add reliability to UDP, and I would be
> > doing that for my application. The HTTP/1.1 rfc doesn't require that
> > HTTP be ran over TCP, just that the transport layer be reliable, so I
> > was wondering if someone had successfully implemented an alternative
> > transport layer.
> >
> > I want to leverage the reliability, portability, 3rd party modules,
> > cgi interface, TCP transport, etc. that exists in Apache as a basis to
> > build a new service. But I also want UDP capability.
> >
> > With apache 1.3.9, my concern is that adding UDP support would not be
> > trival because of the process model where a pool of child processes
> > are blocking on a call to accept(), the conn_rec, and lower level I/O
> > routines. All of which presume a process will only communicate with a
> > single client over a single TCP connection. Does 2.0 help any here?
>
> 2.0 is supposed to be more independent of transport and protocol, though
> whether it is independent enough for you depends on what you want!
> Perhaps you should explain more clearly what support you need, or take a
> look and see what you don't get.
>
> I'm interested in pursuing this somewhat.
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: UDP support?
Posted by Ben Laurie <be...@algroup.co.uk>.
David Williams wrote:
>
> Ryan, I would be interested in more info. I haven't looked at the
> APR, and I suppose I need to get a pointer to the new development code
> base. I understand the need to add reliability to UDP, and I would be
> doing that for my application. The HTTP/1.1 rfc doesn't require that
> HTTP be ran over TCP, just that the transport layer be reliable, so I
> was wondering if someone had successfully implemented an alternative
> transport layer.
>
> I want to leverage the reliability, portability, 3rd party modules,
> cgi interface, TCP transport, etc. that exists in Apache as a basis to
> build a new service. But I also want UDP capability.
>
> With apache 1.3.9, my concern is that adding UDP support would not be
> trival because of the process model where a pool of child processes
> are blocking on a call to accept(), the conn_rec, and lower level I/O
> routines. All of which presume a process will only communicate with a
> single client over a single TCP connection. Does 2.0 help any here?
2.0 is supposed to be more independent of transport and protocol, though
whether it is independent enough for you depends on what you want!
Perhaps you should explain more clearly what support you need, or take a
look and see what you don't get.
I'm interested in pursuing this somewhat.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: UDP support?
Posted by David Williams <dw...@cisco.com>.
Ryan, I would be interested in more info. I haven't looked at the
APR, and I suppose I need to get a pointer to the new development code
base. I understand the need to add reliability to UDP, and I would be
doing that for my application. The HTTP/1.1 rfc doesn't require that
HTTP be ran over TCP, just that the transport layer be reliable, so I
was wondering if someone had successfully implemented an alternative
transport layer.
I want to leverage the reliability, portability, 3rd party modules,
cgi interface, TCP transport, etc. that exists in Apache as a basis to
build a new service. But I also want UDP capability.
With apache 1.3.9, my concern is that adding UDP support would not be
trival because of the process model where a pool of child processes
are blocking on a call to accept(), the conn_rec, and lower level I/O
routines. All of which presume a process will only communicate with a
single client over a single TCP connection. Does 2.0 help any here?
thanks,
-david
On Mon, 8 Nov 1999, Ryan Bloom wrote:
>
> I happen to have done some work on getting Apache to use UDP, and I can
> tell you it isn't worth it. I did the work a few years ago, and what we
> found was that you basically have to re-create TCP to get the kind of
> reliability that is required for a web server.
>
> Having said that, APR could be used to abstract out the transport layer.
>
> If you want more info, let me know.
>
> Ryan
On Tue, 9 Nov 1999, Kevin A. Burton wrote:
> ???
>
> This isn't defined in the RFC so I would probably say no.
>
> Why don't you just write your own UDP server?
>
>
> On Mon, 8 Nov 1999, David Williams wrote:
>
> > Is there any work going on in apache 2.0 or 1.3.x to support UDP as a
> > transport layer. Or support anything other than TCP?
> >
> > thanks,
> > -david
> >
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
>
Re: UDP support?
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I happen to have done some work on getting Apache to use UDP, and I can
tell you it isn't worth it. I did the work a few years ago, and what we
found was that you basically have to re-create TCP to get the kind of
reliability that is required for a web server.
Having said that, APR could be used to abstract out the transport layer.
If you want more info, let me know.
Ryan
On Mon, 8 Nov 1999, David Williams wrote:
> Is there any work going on in apache 2.0 or 1.3.x to support UDP as a
> transport layer. Or support anything other than TCP?
>
> thanks,
> -david
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.