diff options
| author | Matt Caswell <matt@openssl.org> | 2015-09-23 12:40:09 +0100 |
|---|---|---|
| committer | Matt Caswell <matt@openssl.org> | 2015-09-23 13:53:27 +0100 |
| commit | 468f043ece0e7e262ee6166ae6ec1f7683d82220 (patch) | |
| tree | cf349364556b6bc0513be113da8bcf994a5285a3 /doc | |
| parent | d8249e99b9477ca059d5ed016fa49389bc0eb9e9 (diff) | |
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>
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/ssl/DTLSv1_listen.pod | 8 |
1 files changed, 6 insertions, 2 deletions
diff --git a/doc/ssl/DTLSv1_listen.pod b/doc/ssl/DTLSv1_listen.pod index 7a8f080625..d5f5a525ca 100644 --- a/doc/ssl/DTLSv1_listen.pod +++ b/doc/ssl/DTLSv1_listen.pod @@ -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 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 -filled in with details of the peer that sent the ClientHello. Typically user -code is expected to "connect" the underlying socket to the peer and continue the +filled in with details of the peer that sent the ClientHello. It is the calling +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. Prior to calling DTLSv1_listen() user code must ensure that cookie generation |