delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2013/04/12/12:40:48

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=L39xZ/q6ZxNJ8r0qOuJqpXcUB5O0z
2RXBPXNwQD408AEf091teC/LahBJvvT8hrGUsbbFjqyrC7Q1xQYvKMqVwNPI0+B4
iRq39N00tUVq8twBz+f7oATco8YHqKl2u0mnxclHfRV96XlXTja1XtmAnN9RAmQ0
IfWLcYNRK7FckM=
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=HrRYdxfAYOInfsDtuvWaBdQesyo=; b=SPn
YX57RPL3LwHLADM5X1U9sQtsbEqquKD0O4cPE/vE1VoAKQt+OUfZPvuhdYKlfLSM
Kr46PtqzjDue4ts/YgF0TaRry8z7DO6XuDLwhw3TCeuk41fQgPBnhzSrlW0EYgiB
eJlkPUEeBwCr+2tNXotWGcsE0r/W/kGDzIcjHG/s=
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.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,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 09:40:28 -0700
Subject: RE: UDP/DTLS sockets communication pattern is broken in Cygwin
Message-ID: <031222CBCF33214AB2EB4ABA279428A30140C1ACA37C@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> <031222CBCF33214AB2EB4ABA279428A30140C1ACA37B AT SJCPMAILBOX01 DOT citrite DOT net> <20130412155606 DOT GF11358 AT calimero DOT vinschen DOT de>
In-Reply-To: <20130412155606.GF11358@calimero.vinschen.de>
MIME-Version: 1.0
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id r3CGeiY3012164


> 
> Too bad.  I don't know the DTLS protocol, but isn't it possible to do the server
> part with a single UDP socket?  If you keep track of the already connected
> clients, you know if the just incoming packet is a connected or connecting client,
> and then you can use different threads to handle the packet further.
> 
> 
> Corinna
> 

Corinna, I suppose that it would be possible with a different API. The API
that OpenSSL provides makes it rather difficult. A DTLS session is "served" by a BIO 
object that has a dedicated socket underneath it. I am not aware whether a workaround 
is possible. May be application can replace that BIO with something "artificial" but 
I am not sure that that's possible.

The same problem happens even with "plain" UDP when many clients (thousands)
are talking to the same single UDP port (for example, a TURN server). The workaround would be
to create an extra application layer on top of sockets layer to differentiate packet "streams"
by their remote address. With POSIX behavior, such a layer is not necessary.

Oleg



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019