Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Oct 2002 19:35:42 +0100
From:      Ian Dowse <iedowse@maths.tcd.ie>
To:        freebsd-net@freebsd.org
Subject:   IP_SENDSRCADDR implementation
Message-ID:   <200210141935.aa83883@salmon.maths.tcd.ie>

next in thread | raw e-mail | index | archive | help

It was discussed here some time ago that we should have an
IP_SENDSRCADDR ancillary data type to match the IP_RECVDSTADDR
socket option. This permits a server process binding to a wildcard
UDP socket to select the IP address from which outgoing packets are
sent on a per-datagram basis. When combined with IP_RECVDSTADDR,
such server processes can guarantee to reply to a request using the
same source IP address as the destination IP address of the request,
without having to open one socket per server IP address. Thomas
Moestl did an initial implementation of this feature, and the patch
presented here is based on his work and some discussions that
followed.

One approach would be to add to mess in udp_output() where we
temporarily block input and connect the wildcard-bound socket to
the destination address while sending, and do something similar
with binding the source address.

The approach taken here was to instead separate each of in_pcbbind()
and in_pcbconnect() into a *_setup() version of the function that
only performs the port allocation (but does not change the PCB),
and an outer wrapper with the original name that calls the *_setup()
version and then commits the changes to the PCB. Now udp_output()
can use the *_setup() versions to perform the port and address
allocation, so it does not need the temporary connect() hack any
more.

The IP_SENDSRCADDR change consists of adding a control-message
reading loop to udp_output(), and doing an in_pcbbind_setup()
to determine what source address to use for the datagram.

The patch is at:

	http://www.maths.tcd.ie/~iedowse/FreeBSD/sendsrcaddr.diff

Unfortunately it is relatively extensive. I've been running it for
about 4 months now, but that does not rule out the possibility of
bugs and unintended side-effects. Any comments, reviews or suggestions
welcome. Is this something that is useful enough to commit now, or
should it be deferred until after 5.0?

Ian

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200210141935.aa83883>