I think this is because the keyserver uses (host:port) as an identifier
for a single client process. Perhaps udprelay reuses the same open socket to
the keyserver for the multitude of clients starting at the same time?
When I was writing some perl scripts to redirect the udp traffic thru my
broken slip emulator using tcp sockets, Rocke suggested the following to me:
> However, there is some state information maintained at the server you
> need to be aware of. If you plan for this it shouldn't be much harder.
> If you don't plan for this, it will cause you or I some grief...
>
>
> Remember the fault-tolerance. [If a client doesn't get an answer, it
> resends the same packet.]
>
> Likewise, if the server receives the same packet from a given IP:port,
> it usually resends the same response. [I have found out the hard way
> that with assymetric routes in the Internet, I will often get duplicate
> requests for keyspace over and over and over, sometimes for hours on
> end.]
>
> For your gateway to work correctly, and not adversely impact the server,
> your gateways need to make sure there is a 1:1 correspondence between
> the host:port you present to my server and the real host:port on the
> isolated side of the gateways.
>
> Specifically: Do NOT automatically allocate a new system-assigned UDP
> port at the Internet side of the gateway each time you send a packet
> to the server.
>
> Specifically: DO allocate a new UDP port at the Internet side of the
> gateway each for each different private-side host:port.
Does anyone know what the algorithm udprelay uses? Is it possible it
can confuse the keyserver in any other ways?
Karl
----------------------------------------------------------------------------
Karl J. Runge -- Linux: it's the Real thing -- runge@crl.com
-- http://www.crl.com/~runge
A clean desk is the sign of a sick mind. (510)-516-7127