Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <46DAB391.303@beamartyr.net>
Date: Sun, 02 Sep 2007 15:58:57 +0300
From: Issac Goldstand <margol@beamartyr.net>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Revisiting UDP support (for trunk)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,
  I've been quietly hacking away at getting UDP support working with 
trunk (prefork/unix only, for starters).  While I had a decent amount of 
success, I eventually got stuck: my original naive  plan had been to 
poll, recvfrom (to get peer address), dup the socket, connect the dup-ed 
socket and close the dup-ed socket after processing a single request (as 
defined by the connection/protocol handlers).  The hope was that since 
we never connected the original socket, it would still do something 
useful.  To make a long story short, I found that it wasn't doing 
anything of the sort.

Before I launch into a new tactic, I wanted to see if someone has a 
better idea than me - the only thing that pops into my mind is moving 
some sort of pointers to the UDP listeners into the scoreboard (or some 
other R/W shared area) and simply letting the children/workers lock used 
sockets (so other children/workers don't poll it), and completely 
replace them after they're used.  There are a lot of disadvantages to 
doing that, I think, but I can't dream up a smarter solution.  Anyone 
have any ideas?

  Issac