On 03/13/2011 08:23, Daniel Braniss wrote:
On 03/12/2011 02:21, Daniel Braniss wrote:
The problem with trying to get the same port for all tcp/udp/inet/inet6
though might succeed most of the time, will fail sometimes, then what?
Can you please describe the scenario when it's completely impossible to
find a port that's open on all 4 families?
i did not say impossible, concidering that Rick asked how many times he
should try, unless N is forever, it could fail.
And what I'm asking is that you describe the circumstances which might
lead to that failure.
I saw Doug's commnent, and also the:), it's not as simple as tracking port
80 or 25, needs some efford, but it's deterministic/programable, and worst case
you can still use the -p option (which again will fail sometimes:-).
Given that Rick has already written the patch, I don't think it's at all
unreasonable to put it in as the first choice, perhaps with a fallback
to picking any available port if there isn't one available for all 4
families.
as Rick mentioned, the patch is not trivial, and to quote him:
"My only concern with the "same port# patch" is that it is more complex
and, therefore, somewhat riskier w.r.t. my having gotten it wrong."
Yeah, I saw that, did you see my response? I'm very much in favor of
keeping things simple, but only as simple as they can be made.
Meanwhile, I don't think I'm the only person who has ever had trouble
trying to track down network traffic from "random" ports that would
prefer that doing so not be made harder by having the same service on
the same host using 4 different ports.
To track rpc based traffic, which means random-port to start with, you have to
check with rpcinfo anyways. So yes, it's harder than tracking 1 port, but
IMHO, less complex than the patch requiered :-),
Clearly you've not spent any significant amount of time trying to figure
out what traffic is coming from what port. A small increase in code
complexity is worth it if it saves real people real time, especially in
critical situations.
and BTW, mountd is already
heavely patched, rpc.statd less, and rpc.lockd is, so far, the only one
that is not complaining - guess Rick is a good programer!
and I concider myself lucky that we don't use NIS/yellow-pages.
Some of us are not so lucky. :)
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
