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>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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