Peter Memishian writes:
> > You're assuming the packets sent on this UDP socket all have the same
> > destination and that routing does not change between transmissions.
> I'm not assuming that, just pointing out that in general there will
> not be a different source address in each packet, and that for a given
> destination we latch the source address for long periods of time. That
> is, one could read your original statement as a promise that we will
> repeat source address selection for each packet, which is not the case.
> (And yes, I realize this is an implementation detail. Source address
> selection algorithms for an unconnected and unbound UDP socket seems
> entirely like "implementation-defined behavior" to me.)
What I said was this:
If you don't explicitly bind a preferred address to use (most
applications do not), then the kernel will choose an address for you.
With UDP, this happens on a packet-by-packet basis.
I don't see how anything you've said actually refutes that, except
that you're focussing on "packet-by-packet" as a kernel implementation
detail. The fact that we're caching information or that our cache is
currently designed around a single source address per destination is
unimportant: at the time each packet is sent, the validity of the
cache information is checked, and it's discarded if it's wrong.
You, as a user, *may* see the source address change if the destination
changes or if anything about the routing used changes. Or if we just
get a wild hair and decide to nuke the cache IRE out of spite. It's
not predictable or guaranteed in any way, and thus behaves as though
it's unstable on a packet-by-packet basis.
I can't guarantee that something _will_ change (that doesn't make
sense to me ... what if the result of all that effort is exactly the
same answer?), but it's certainly the case that you have to expect
that it may well change. Nothing really stops it.
Strictly from a user's point of view (and not staring at the bowels of
the implementation), there is *no* real difference between saying that
we redo source address selection on every packet (on the one hand) and
saying that we cache the results but throw away those results and get
new ones when conditions change. Users can't really tell the
difference between those two in any reliable way. The cache isn't a
The original question here was about what sort of source selection
behavior to expect, and what happens when the "wrong" routes are
present when a TCP connection is attempted. As far as the user is
concerned, the answers are (1) you must discard a TCP socket if it
fails to connect and you're going to try again and (2) when you try
again, you get another roll of the dice as far as forwarding and
source selection is concerned. If something new is available, you may
well end up using it.
The fact that we cache and that our caching has limitations doesn't
really enter into that discussion.
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
zones-discuss mailing list