lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 30 Mar 2007 21:09:17 +0200 From: "Predrag Hodoba" <predrag.hodoba@...il.com> To: "Stephen Hemminger" <shemminger@...ux-foundation.org> Cc: "David Miller" <davem@...emloft.net>, dagriego@...il.com, netdev@...r.kernel.org Subject: Re: [PATCH] NET: Add TCP connection abort IOCTL On 30/03/07, Stephen Hemminger <shemminger@...ux-foundation.org> wrote: > Predrag Hodoba wrote: > > On 30/03/07, Stephen Hemminger <shemminger@...l.org> wrote: > >> David Miller wrote: > >> > > >> > Something being in the CGL specification is to me exactly a great > >> > reason NOT to add it. That specification is so full of garbage it's > >> > unbelievable. > >> > > >> > Thanks, you've given me one more reason not to even remotely consider > >> > adding this feature. > >> > > >> Agreed, CGL is a vendor driven group that has always wanted to replicate > >> proprietary misfeatures onto Linux. There is a real requirement to > >> provide high availability but there should be no requirement to > >> implement > >> the solution in the same crap way as legacy Unix. > > > > OK, let's put aside CGL and legacy Unices. > > > > Still, I don't see how the case I mentioned can easily be handled. > > (The case being - effective clean up of all affected client TCP > > connections, following failover of the server IP address from active > > to passive node in a highly available cluster). > > Why clean them up? The client connections will timeout and they can > reconnect. Actively killing them early does nothing helpful. Just like > the CGL requirement for forced unmount, the forced operation introduces > a whole bunch of race conditions and shared file descriptor problems. Well, it depends on how fast you have to react on failure. For data-center grade high-availability it is, as you said, enough to wait for clients to timeout. For telco (or similar, more demanding) grade of high-availability, timeout just takes too long. You typically have to discover failure using some kind of heartbeat mechanism and clean up immediately ... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists