X-Recipient: archive-cygwin@delorie.com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=qSfvn2ErV0G6bKPIKRTwQTYeTDSSuiacz8iweMxfYCe
	LXYIrtDMBF/kHVEVcLbh3/gWamHWBZ71MgoeMee7kEgKRCAZdK+6elQsbQjXOBYq
	aG90VDNj9m4qLj/SjTpLIcqBd0TkUCNtUIWIjdeDMuYv8+ahN9q6rEGKsGU83e+4
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=vN+ivvx97njxXiGx1i4sT/9yq24=; b=llpkQd6LqtPcIKWyc
	c7PLTOtVN5Jyn4MWV6U0ezREFUXNS93CyISA/g8rcsIAolQxse3atw6M6w6ayy8q
	PD/141FM79uPqx+cavfClTxyM4hNhce7dUQZxSEPgL9tv/Yax/yAA7S8vnscyT3o
	6P5JFP2m/hzKwcZmHeK0kcFIfc=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
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
Message-ID: <53152031.3000208@etr-usa.com>
Date: Mon, 03 Mar 2014 17:37:05 -0700
From: Warren Young <warren@etr-usa.com>
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> <loom.20140227T134714-188@post.gmane.org> <20140227134632.GG2246@calimero.vinschen.de> <765945729.20140228031219@yandex.ru> <20140228120748.GN2246@calimero.vinschen.de> <87y50vc910.fsf@Rainer.invalid> <20140228201047.GC2381@calimero.vinschen.de> <CAKf2h5TjyeMxuw=XkqoGMC8A_f+LpSzcx5nof5ViUBQ-0sYXFg@mail.gmail.com> <20140228210804.GE2381@calimero.vinschen.de> <CAKf2h5QbafQq25jndf8RdDGWsp_MMfziBep2Pe1H7rA+OmOCdA@mail.gmail.com> <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

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

