X-Recipient:	archive-cygwin AT delorie DOT 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:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=kZYU9qNpSPQfeqbL
	6L25/xf0ZiT6AAf+IYsxHROrSoTV2tzP56Vs4kdDSbNjUAy9E+bxeku9x3/kHEer
	TlY2mmfsjv/N1V0ggPieZll+NkC1LkVRmMpaEqMD2jqKrUNTl1GmexQ05dn2LvOS
	Et3WBDFj5NdZlbRDjH+l5AfBEW4=
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:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=/K/SmBuNEJmcfWrnY5RN9p
	ZaQho=; b=MEUDbwZa4MnC4jqs938d8Ag20IZMBisuzH4ji/2QlvjHorVZVA/CET
	HN4w5m4okBM1f+RytBkjzLC5g3yZ0GIuPqU018YImDQEw7Nj7Q27WoUsqVOXOTY2
	axn/3sv/l/mUIn2uN8iXkvWT7g+cT9aB51Clfx4wk6sT5VIUiZX7w=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.7 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,SPAM_BODY,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO:	smtpback.ht-systems.ru
Date:	Tue, 4 Mar 2014 05:36:03 +0400
From:	Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To:	cygwin AT cygwin DOT com
Message-ID:	<397967999.20140304053603@yandex.ru>
To:	Warren Young <warren AT etr-usa DOT com>, cygwin AT cygwin DOT com
Subject:	Re: Testers needed: New passwd/group handling in Cygwin
In-Reply-To:	<53152031.3000208@etr-usa.com>
References:	<20140227094951 DOT GD2246 AT calimero DOT vinschen DOT de> <loom DOT 20140227T134714-188 AT post DOT gmane DOT org> <20140227134632 DOT GG2246 AT calimero DOT vinschen DOT de> <765945729 DOT 20140228031219 AT yandex DOT ru> <20140228120748 DOT GN2246 AT calimero DOT vinschen DOT de> <87y50vc910 DOT fsf AT Rainer DOT invalid> <20140228201047 DOT GC2381 AT calimero DOT vinschen DOT de> <CAKf2h5TjyeMxuw=XkqoGMC8A_f+LpSzcx5nof5ViUBQ-0sYXFg AT mail DOT gmail DOT com> <20140228210804 DOT GE2381 AT calimero DOT vinschen DOT de> <CAKf2h5QbafQq25jndf8RdDGWsp_MMfziBep2Pe1H7rA+OmOCdA AT mail DOT gmail DOT com> <20140303092114 DOT GA26619 AT calimero DOT vinschen DOT de> <1686957830 DOT 20140303195207 AT yandex DOT ru> <53152031 DOT 3000208 AT etr-usa DOT com>
MIME-Version:	1.0
X-IsSubscribed:	yes

Greetings, Warren Young!

>> 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.)

I've tried to rely on some obscure "system timeout"... it didn't worked well.
Socket just doesn't die by itself after hours of waiting.
I had to manually enforce some sane timeout to ensure consistent operation of
the program. Even if it'd be something like "15 minutes", it was still better
than "I don't know, may be next century..."

> Over the past 3 decades of TCP/IP, we've discovered that 
> networks are weird.

I concur.

>> 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.

Perhaps, you didn't understand, but I specifically mentioned connection time,
which is clearly distinct in case of TCP connection.
Once connection is established, control is returned to application, the
connection timeout is a thing of past, and session can only be terminated by
a request of calling application.

> 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.

Amount of packets doesn't matter. Once TCP session is established, it remains,
until closed or dropped on either end of the wire.


--
WBR,
Andrey Repin (anrdaemon AT yandex DOT ru) 04.03.2014, <05:25>

Sorry for my terrible english...


--
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

- Raw text -