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:from:to:date:subject:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=QnSZg5HFTW6lm10WBACic2img/d3W
	Uf25YHrZF58HWKaTwYMbWHue5Xnl3iAfZym6LQ0reBe2BXj+pO+qHRDvefT9FkDv
	YMU9TQZHYW+vGt4WRwygV0Cdv6jFWA6G5GAN50OS5G4rBG3wWNtlYpwdTiJ6sFfQ
	VXP95sNuq6dJOQ=
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:from:to:date:subject:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; s=default; bh=F+DcclxU5lTtT2IlNgs0hxla+/w=; b=A7P
	BppM9MfHPMhTS8voYQILpZe0XwAwyIpubpSWf74QX+4o/mzUNcmIRgD2VpGwtVcr
	saLfWIsgKc8FFsDyQagQG7nAQqgsdVHtKNmIBKOD8sxGGDQ6eEgXS02XlKoe2lgf
	zEB8igTZ3ZldtDj2PowcNCz+Gcw0poQ6j6hxqClU=
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
X-Spam-SWARE-Status:	No, score=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1
From:	Oleg Moskalenko <oleg DOT moskalenko AT citrix DOT com>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date:	Fri, 12 Apr 2013 08:44:41 -0700
Subject:	RE: UDP/DTLS sockets communication pattern is broken in Cygwin
Message-ID:	<031222CBCF33214AB2EB4ABA279428A30140C1ACA37B@SJCPMAILBOX01.citrite.net>
References:	<031222CBCF33214AB2EB4ABA279428A30140C1ACA374 AT SJCPMAILBOX01 DOT citrite DOT net> <20130411212115 DOT GA1376 AT ednor DOT casa DOT cgf DOT cx> <031222CBCF33214AB2EB4ABA279428A30140C1ACA378 AT SJCPMAILBOX01 DOT citrite DOT net> <20130412114354 DOT GC11358 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20130412114354.GC11358@calimero.vinschen.de>
MIME-Version:	1.0
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id r3CFiwAB001085

> 
> However, I think I found a workaround on the application level.
> Apparently all packets sent to a specific address are sent to the first socket
> which has been bound to the address.  If that socket has been closed, the next in
> line gets the packets (unless it has been connected and the sender is not the
> connected address).  So what I did was this:
> 
> Before starting step 14, I created a third socket, which then replaced the server
> socket:

Thank you, Corinna, for the reply and for the idea.

Unfortunately, the workaround will work well only in the case of a single client. 
In the multiple clients scenario, it will create a sort of race condition: 

1) some packets already scheduled by OS to the "original" packet will be lost;
2) some packets delivered in between the sockets destruction/creation will be wrongly rejected.

But this is better than nothing. I'll think whether we can live with it.

Regards,
Oleg

- Raw text -