From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28276 invoked by alias); 4 Mar 2014 00:37:11 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 28264 invoked by uid 89); 4 Mar 2014 00:37:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.4 required=5.0 tests=AWL,BAYES_20,RP_MATCHES_RCVD,SPAM_BODY autolearn=no version=3.3.2 X-HELO: etr-usa.com Received: from etr-usa.com (HELO etr-usa.com) (130.94.180.135) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Mar 2014 00:37:09 +0000 Received: (qmail 1333 invoked by uid 13447); 4 Mar 2014 00:37:05 -0000 Received: from unknown (HELO [172.20.0.42]) ([68.35.121.157]) (envelope-sender ) by 130.94.180.135 (qmail-ldap-1.03) with SMTP for ; 4 Mar 2014 00:37:05 -0000 Message-ID: <53152031.3000208@etr-usa.com> Date: Tue, 04 Mar 2014 08:07:00 -0000 From: Warren Young User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Testers needed: New passwd/group handling in Cygwin References: <20140227094951.GD2246@calimero.vinschen.de> <20140227134632.GG2246@calimero.vinschen.de> <765945729.20140228031219@yandex.ru> <20140228120748.GN2246@calimero.vinschen.de> <87y50vc910.fsf@Rainer.invalid> <20140228201047.GC2381@calimero.vinschen.de> <20140228210804.GE2381@calimero.vinschen.de> <20140303092114.GA26619@calimero.vinschen.de> <1686957830.20140303195207@yandex.ru> In-Reply-To: <1686957830.20140303195207@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00062.txt.bz2 On 3/3/2014 08:52, Andrey Repin wrote: > > I'd say it again, "sane defaults are better, than alot of options". Agreed in principle. However, observe that all network stacks have a bunch of built-in timeout options. They're rarely exposed to the user level, but their defaults are typically quite high. (e.g. 60 seconds for connection timeout.) Over the past 3 decades of TCP/IP, we've discovered that networks are weird. > for comparison, default DNS _roundtrip_ timeout is 2 seconds, The typical DNS transaction is just 2 UDP packets, one each direction: query and response. I tested a simple, unencrypted LDAP login-and-drop-conn transaction here against a real production AD server, and it required 8 packets, 5 of which were TCP/IP connection establishment and shutdown. Add in the encryption, authentication, and authorization overheads of a "real" LDAP query, and it could go up to dozens of packets. That said, it only took about 1 ms to my simple test. The AD server was on the other side of a router, on a fast WAN. Someone testing this new cygwin1.dll in a domain environment[*] should do a packet capture of what Windows sends when the DLL does its new thing. The captured data isn't terribly interesting here. What we want to know is how many packets it takes, and what the timestamps are on the captured frames. Most especially, the delta between the first and last packets, but if there are any significant time gaps, that could be interesting, too. [*] Not me. The only reason we have any AD around here at all is for testing software that authenticates users against third party AD servers. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple