Clarify DTLSv1_listen documentation
Clarify that user code is required to allocate sufficient space for the addressing scheme in use in the call to DTLSv1_listen. Reviewed-by: Andy Polyakov <appro@openssl.org>
This commit is contained in:
parent
d8249e99b9
commit
468f043ece
@ -44,8 +44,12 @@ When a ClientHello is received that contains a cookie that has been verified,
|
|||||||
then DTLSv1_listen() will return with the B<ssl> parameter updated into a state
|
then DTLSv1_listen() will return with the B<ssl> parameter updated into a state
|
||||||
where the handshake can be continued by a call to (for example) SSL_accept().
|
where the handshake can be continued by a call to (for example) SSL_accept().
|
||||||
Additionally the B<struct sockaddr> location pointed to by B<peer> will be
|
Additionally the B<struct sockaddr> location pointed to by B<peer> will be
|
||||||
filled in with details of the peer that sent the ClientHello. Typically user
|
filled in with details of the peer that sent the ClientHello. It is the calling
|
||||||
code is expected to "connect" the underlying socket to the peer and continue the
|
code's responsibility to ensure that the B<peer> location is sufficiently large
|
||||||
|
to accommodate the addressing scheme in use. For example this might be done by
|
||||||
|
allocating space for a struct sockaddr_storage and casting the pointer to it to
|
||||||
|
a struct sockaddr * for the call to DTLSv1_listen(). Typically user code is
|
||||||
|
expected to "connect" the underlying socket to the peer and continue the
|
||||||
handshake in a connected state.
|
handshake in a connected state.
|
||||||
|
|
||||||
Prior to calling DTLSv1_listen() user code must ensure that cookie generation
|
Prior to calling DTLSv1_listen() user code must ensure that cookie generation
|
||||||
|
Loading…
x
Reference in New Issue
Block a user