+/* Even with SSLv2, we have 16 bytes (128 bits) of session ID space. SSLv3/TLSv1
+ * has 32 bytes (256 bits). As such, filling the ID with random gunk repeatedly
+ * until we have no conflict is going to complete in one iteration pretty much
+ * "most" of the time (btw: understatement). So, if it takes us 10 iterations
+ * and we still can't avoid a conflict - well that's a reasonable point to call
+ * it quits. Either the RAND code is broken or someone is trying to open roughly
+ * very close to 2^128 (or 2^256) SSL sessions to our server. How you might
+ * store that many sessions is perhaps a more interesting question ... */
+
+#define MAX_SESS_ID_ATTEMPTS 10
+static int def_generate_session_id(const SSL *ssl, unsigned char *id,
+ unsigned int *id_len)
+{
+ unsigned int retry = 0;
+ do
+ RAND_pseudo_bytes(id, *id_len);
+ while(SSL_CTX_has_matching_session_id(ssl->ctx, id, *id_len) &&
+ (++retry < MAX_SESS_ID_ATTEMPTS));
+ if(retry < MAX_SESS_ID_ATTEMPTS)
+ return 1;
+ /* else - woops a session_id match */
+ /* XXX We should also check the external cache --
+ * but the probability of a collision is negligible, and
+ * we could not prevent the concurrent creation of sessions
+ * with identical IDs since we currently don't have means
+ * to atomically check whether a session ID already exists
+ * and make a reservation for it if it does not
+ * (this problem applies to the internal cache as well).
+ */
+ return 0;
+}
+