On Fri, Jun 08, 2001 at 09:37:15AM -0500, Mike Silbersack wrote:
>
> On Fri, 8 Jun 2001, Terry Lambert wrote:
>
> > OK, I read the code. Not to poop the party, but off the top
> > of my head, I have several major objections:
> >
> > 1) You stole the space reserved for the cache status
> > flags; calling it 'tao_flags' would have been more
> > honest.
>
> rmx_filler still has extra space in it, there's no problem fitting in
> tao_flags when and if it becomes used.
>
> > 2) This doesn't work right for cloned routes.
>
> On the contrary, it only works for cloned routes.
>
> > 3) This blows up if you delete and re-add the default
> > route, and the route in question is a clone of the
> > default.
>
> Yes, this will cause the cloned route to get blown away, and the ISN
> reset. This is only a minor issue, and can be ignored unless a host sees
> frequent route changes. Even if the cloned route is blown away
> frequently, this will simply cause the algorithm to revert to totally
> random ISNs, which isn't the end of the world.
>
This still could be handled. When the parent (or even this particular)
route is deleted, it is only deleted from the routing table and is marked
as "down". TCP's PCB still holds on it. On the next socket write,
ip_output() sees that the route is no longer "up", and reallocates the
new route. tcp_output() could check that the cached route is still up
before passing it to ip_output(), and reallocate the route preserving
the old value of ISN (thus avoiding the re-randomization of the latter).
Alternatively, ip_output() could probably do this.
Just an untested idea.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
