| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
using a custom allocator. Currently our allocator just does new/delete
with a memset before deletion, and the mmap and mlock allocators have
been removed.
|
| |
|
|\
| |
| |
| |
| |
| | |
a4741cd07f50a9e1b29b0dd97c6fb8697c038ade)
to branch 'net.randombit.botan.cxx11' (head 116e5ff139c07000be431e07d3472cc8f3919b91)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the peer are automatically responded to. TLS::Channel::heartbeat can
initiate a new heartbeat if the peer allows it. Heartbeat replies are
passed back to the application processing function with an Alert value
of HEARTBEAT_PAYLOAD (a 'fake' value, 256, which is out of range of
the valid TLS alert space), along with the sent payload.
The RFC requires us to have no more than one heartbeat 'in flight' at
a time, ie without getting a response (or a timeout in the case of
DTLS). Currently we do not prevent an application from requesting
more.
|
| | |
|
|/
|
|
| |
and unique_ptr.
|
| |
|
|
|
|
|
|
| |
of just the type code.
Implement Alert::type_string
|
|
the Alert class for namespacing.
|