| Age | Commit message (Collapse) | Author |
|---|
|
|
|
If upper limit is reached invalidate the current cache entries, e.i the session
lifetime is the max time a session will be keept, but it may be invalidated
earlier if the max limit for the table is reached. This will keep the ssl
manager process well behaved, not exhusting memeory. Invalidating the entries
will incrementally empty the cache to make room for fresh sessions entries.
|
|
ssl_session_cache:select_session/2 returned [sesionid(), #session{}]
instead of #session{} as the API demands.
This was wrongly compensated for in the code in one place making it
look like everything was good. But the client check for unique session
would always fail, potentially making the client session table grow
a lot and causing long setup times.
|
|
|
|
Even though in the most common case an erlang node will not be both client
and server, it may happen (for instance when running the erlang ditribution
over TLS).
Also try to mitigate the affect of dumb clients that could cause a
very lagre session cache on the client side that can cause long delays
in the client. The server will have other means to handle a large
session table and will not do any select operations on it anyhow.
|
|
So we can use partial bound keys for matching
|
|
|
|
|
|
|
|
We want the certificate table to be handled the same way as the
session table and not have a global name, so that we may easier
create a separate ssl-manager to handle erlang distribution over ssl.
|
|
|
|
In ssl-4.1.5 temporary clean-up processes would crash resulting in
that the session table would not be cleaned up (e.i. using more and
more memory) and error reports would be printed, but connections would
not be affected.
|
|
Started to improve code documentation by using -spec directive, and
some small refactorings to avoid ugly code.
|
|
|
|
|
