> 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. > [some good stuff snipped for brevity] Ok, well I believe that the patches I currently have aren't broken.
How about I change the patches so that after N attempts fail, it does a final attempt allowing different port#s for the 4 cases. (If that fails, I don't think there is anything that can be done, since it means that no port# is available for at least one of the four cases?) Does that sound reasonable? rick ps: I was thinking N should be somewhere in the 10<->100 range. Anyone want to suggest a value for N? _______________________________________________ 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"