Matt Caswell <m...@openssl.org> wrote:
>> Matt Caswell <m...@openssl.org> wrote: >> a) when the existing FD is
>> connect(2) any future traffic to the bound >> port will get rejected
>> with no port. So the application really has to >> open a new socket
>> first. The application can do this two ways: it can >> open a new
>> socket on which to receive new connections, or it can open >> a new
>> socket on which to communicate with the new client. The second >>
>> method is better for reason (b) below. Either way, it socket to >>
>> communicate with the client needs to be bind(2) to the address that >>
>> the client used to communicate with the server, and DTLSv1_listen() >>
>> didn't collect or return that information.
>>
>> > The second way is what is intended.
>>
>> Unfortunately, there remains a race condition because we have to call
>> bind() before connect() on the new socket. Under load, if a packet is
>> received between the bind() and the connect(), it might go onto the
>> wrong socket queue. So some packets that could have been processed
>> will get dropped and have to be retransmitted by the client.
> This seems like a non-issue to me. At this point in the handshake the
> client will have sent its ClientHello and won't progress until it gets
> the server's flight back (ServerHello etc), i.e. in the vast majority
> of cases it won't be sending anything.
*That* client will be waiting, but other clients may be sending new ClientHello
messages (with or without cookies).
>> The address of the remote client is returned ("getpeername()") by
>> DTLSv1_listen(). That's all that recvfrom() gives you.
>>
>> recvfrom() was a reasonable API for SunOS 3.x machines with a single
>> 10Mb/s interface with a single IPv4 address. I loved all that at the
>> time... But it doesn't work that well when we might have a dozen
>> different kind of IPv6 addresses on each virtual interface.
>>
>> The address that I'm talking about needing is the one the remote
>> client used to reach us. That's the destination IP of the incoming
>> packet ("getsockname()" in TCP speak).
> Ahhh....its the *server's* address you are after. This requirement
> seems more reasonable. I think the API is designed to expect you to
> only bind to a single IP. I'd be interested in Richard Levitte's
> opinion on this.
okay.
binding to a single IP is not scalable in many applications.
> It seems like a fairly simple solution could solve this. Currently we
> have BIO_dgram_get_peer() which returns the peer's address for the last
> message read from a BIO. You could imagine a new call being introduced
> to get our own address. You could then call that immediately after a
> successful DTLSv1_listen() call. Obviously we'd have to change the
> dgram BIO to use recvmsg for this to work.
That's here:
https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
and:
https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
