Am Freitag, 7. Dezember 2007 04:20 schrieb David Miller:
> If IPSEC takes a long time to resolve, and we don't block, the
> connect() can hard fail (we will just keep dropping the outgoing SYN
> packet send attempts, eventually hitting the retry limit) in cases
> where if we did block it would not fail (because we wouldn't send
> the first SYN until IPSEC resolved).
David - I'm aware of this, the discussion is which behaviour is ok. Let's go
back to a real life example. I've already researched that the squid web proxy
has a poll() based main loop doing nonblocking connects, may be with multiple
threads.
Situation: One user wants to access a web page that needs IPSEC. The SA takes
30 seconds to come up.
a) Non-blocking connect is respected: SYN packets during the first 30 seconds
will be dropped as you said. Connection can be completed on the next SYN
retry (timeout in linux: 3 minutes). During this time, the 500 other users
can continue to browse using the proxy.
b) Non-blocking connect is ignored during IPSEC resolving as you advocate it:
Connection for the one user can be completed immediatly after IPSEC comes up.
That's the pro. However, until then, the other 500 proxy user CANNOT ACCESS
THE WEB because squid's threads are stuck in connect()s on sockets they
configured not to block. If the IPSEC SA never resolves due to some network
outage, squid will sleep forever or until an admin configures it that it
doesn't try to connect the adress in question and restarts it.
Don't you realize how broken this behaviour is? Can you give me ONE example of
an application that works better with b) and why this outweights the problems
it creates for everybody else?
Even the DNS example you posted in
<[email protected]> is wrong because the second
server will never queried if the kernel puts the process into coma while the
IPSEC SA to the first server cannot be resolved.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
