| To: | Lennert Buytenhek <buytenh@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH,RFC] explicit connection confirmation |
| From: | bert hubert <ahu@xxxxxxx> |
| Date: | Thu, 7 Nov 2002 17:24:24 +0100 |
| Cc: | netdev@xxxxxxxxxxx |
| In-reply-to: | <20021107143002.GA23858@xxxxxxx> |
| Mail-followup-to: | bert hubert <ahu@xxxxxxx>, Lennert Buytenhek <buytenh@xxxxxxx>, netdev@xxxxxxxxxxx |
| References: | <20021107093207.GA30666@xxxxxxx> <20021107112733.GA24283@xxxxxxxxxxxxxxx> <20021107120956.GA10832@xxxxxxx> <20021107134918.GA28329@xxxxxxxxxxxxxxx> <20021107143002.GA23858@xxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.28i |
On Thu, Nov 07, 2002 at 09:30:02AM -0500, Lennert Buytenhek wrote: > > I like having this ability - I dislike offering it to an unsuspecting > > userspace. > > Userspace needs to turn on the option first, so your 'unsuspecting' > does not apply. Ah ok, I thought 'TCP_CONFIRM_CONNECT' was a TCP connection state like SYN_RECV. > Again, if the app decides to turn on TCP_CONFIRM_CONNECT, then it's > up to the app to deal with it properly. There are very good reasons > for not turning on TCP_CONFIRM_CONNECT by default, which is why it > is not on by default, and why grafting a setsockopt onto every daemon > there is out there is definitely not a good idea. Exactly. Ok, cool. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH,RFC] explicit connection confirmation, Lennert Buytenhek |
|---|---|
| Next by Date: | [PATCH] proc.txt document fix of error_burst and error_cost, Oskar Andreasson |
| Previous by Thread: | Re: [PATCH,RFC] explicit connection confirmation, Lennert Buytenhek |
| Next by Thread: | test, Jacky Hsiao |
| Indexes: | [Date] [Thread] [Top] [All Lists] |