[lkml]   [1998]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Dynamic IP hack (PR#294)
On Sun, Oct 18, 1998 at 09:13:37PM +0200, wrote:
> Hello!
> > IFF_DYNAMIC doesn't try to change the addresses, it simply knows that the
> > connection is lost because the user gurantees that the IP address is gone
> > and cannot be recovered. Because that fact is known for sure it simply
> > calls tcp_reset on the connection to kill it. The 2.0 RST
> > hack used an indirect scheme, it will send out an packet with wrong
> > source and assumes the other end will RST it.
> If address is deleted it has very good chances to be restored
> couple of seconds later after redialing or something.
> And no flag can grant the opposite statement.

That is true for dialup links with static addresses. But 99% of all
dialup links have dynamically allocated addresses, where it is rather
unlikely that you get the same address again. It could happen in theory,
the probability depends on the particular setup. With IFF_DYNAMIC the user
can do the tradeoff: either he wants fast error propagation because it is
too unlikely that the same address reappears, or he thinks his chances in
the gamble are high enough that it is worth to take the disadvantages (hanging
sockets) if he loses. For me I prefer better error recovery, and e.g.
my gnus knows how to reestablish connections to the NNTP server, but it
has no way to know about all kind of weird failures that happen in device
layer. With IFF_DYNAMIC I can chose.

You probably never lived in a dynamic IP world, it makes you really see
some IP aspects differently.

> I want to stress again: tcp resets may be caused only
> by tcp protocol itself or by user request: they cannot be generated
> because of problem of lower layer of ANY KIND.
> All of such kind of problems are transient by definition.

I disagree. A lose of an IP address is definitely not transistent, because
it "destroys" the endpoint forever and it is not possible to recover.

> > So an sk->userbind flag is the way to go I think.
> Excellent. What do you think, if it was sk->autobound flag?
> Set it in inet_autobind(), and reset in bind() or getsockname().
> Seems, it is better or not?

sk->autobound is fine too and even nicer :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:45    [W:0.171 / U:0.012 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site