On Saturday 10 September 2005 10:34, Nikos Mavrogiannopoulos wrote: > The problem is that in the 2nd forked session the server tries to resume > the previous connection. You can check this by looking the session ID. The > one the server selects the second time is the same as the client requested > (resume). This is totally strange since there is no communication > between the objects (lie in a different process), so the second process > shoudn't even know the session ID of the first server process. > It seems to work ok if you move the gnutls_session_t session declaration to > after the forked process has been created (after if (pid==0)). I'm still > looking at it but it really looks odd.
The problem seems to be libgcrypt's random generator. As far as I understand when you fork() the random generator is on the same state for every children. That's why the server produces the same session ID in the second process. I am not really sure about it, and I don't know how to overcome this, that's why I crosspost to gcrypt-devel as well. -- Nikos Mavrogiannopoulos _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
