Date: Tue, 14 Jan 2020 08:35:14 +0000
From: "Schwarz, Konrad" <konrad.schw...@siemens.com>
Message-ID:
<a45b1767f1002449a37508c2cc6003d7172c9...@defthw99em4msx.ww902.siemens.net>
| Captain Obvious here:
| A minimal quality of implementation attribute for DHCP daemons is for
| these addresses to remain fixed for as long as possible.
Yes, address stability is useful, as connections break when it is
lost (given connections are identified by a tuple that includes the
address).
| Cf. https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdleases,
| which is designed to persist address assignments across restarts,
| e.g., because the hosting server needs to reboot.
It is a design goal. Some dhcp servers have no stable storage at
all, and cannot meet that goal.
| Or are you suggesting applications must be (re-)coded
| such that they are resistant to dynamic changes of IP addresses?
There is no way around that. Sometime addresses simply need to
change. In the v4 world, the typical practice was to reconfigure
the system, and then reboot, which forced all the applications to
restart, with new addresses. Not exactlty an ideal environment.
More recently, addresses can (even if they do not often) change
while the system is running, so yes, applications need to be able
to cope with that.
It is only because in practice the addresses do not change very
frequently - especially as most hosts live inside NAT enclaves,
where use of private addr space means there is very little incentive
to change, that there has been elatively little movement in this area.
But consider a mobile device (not mobile-IP here, just a typical
modern phone) that is using 4G comms as you move around, when you
with who knows what addr from your phone company, when you arrive
at my house, and connect to my WiFi, and are now using something
on network 10.*.*.* ... the addresses the apps on the phone are
seeing will have changed (unless the phone OS does a private internal
NAT, and makes some internal address space into whatever it is given
externally - which is just a method of coping with changing addresses,
not of avoiding it from happening).
eg: I know I need to, and so have a script to do it, restart
my sendmail daemon whenever my laptop connects to a different
access point, eg: when I move from my house to a hotspot provided
by my phone ... because sendmail doesn't deal with this well at all.
| The point I was trying to make with the text you did not quote is that
| if the OP had been more judicious in closing sockets/file descriptors,
| he would not have run into the problem in the first place.
The issue (as I understand it, I do not like the threading methedology,
and do not use it) is that in threaded processes, with everything happening
in parallel, and no one thread having any real idea what any other
thread might be doing, there is no way to achieve the result you are
expecting.
That is, at the exact same instant one thread is doing fork() another
is doing open() or socket(). If it happens that the open() finishes one
zeta-second before the fork() starts then the fd from that open will
be inherited by the child of the fork, but because the thread doing the
open has not hat time to save the fd anywhere yet, there is no way for
the child process (which only contains the thread which forked, not the
others, including not the one that did the open()) to ever discover what
that fd was, or what it connects to.
| This seriously undermines the case for an all new F_CLOFORK flag
If it weren't for threading, I would not support it at all. In any
non-threaded context it is a stupid idea. But I can see the need for
it with our current threading methedology. The real problem is that
threads are a horrid misfeature. Unfortunately, lots of people seem
to like the evil things.
kre
