Re^4: SSL-socket on Windows

Unfortunately I've hit a wall now.

I cannot directly share the IO::Socket::SSL - I get an error if I try.

So I guess the only way forward now is not to share the SSL-object but the unterlying filehandle and try to reconstruct the SSL-object in the other tread using that.

Does anyone have an idea if this is feasible or are there any other approaches to sharing IO::Socket::SSL instances among threads?

As I said there will only be one thread using this instance at any given time, so thread-safeness (or the lack of it) should not affect me.

Comment on Re^4: SSL-socket on Windows

Replies are listed 'Best First'.
Re^5: SSL-socket on Windows by Marshall (Canon) on Mar 18, 2012 at 18:01 UTC
I have no idea why it was implemented like that (one thread making the TCP-connection and another upgrading it to SSL), This just sounds very bizarre to me! You may have to fix this which sounds like an fundamental problem? I've never had to "upgrade" a connection to SSL after successful connection to a particular IP/port combination - in my experience, I have to start that way or the server won't talk to me at all! Is there a way to "dumb the code" down so that the other Monks can work on it? The SSL connection should happen fast (like 1+ second, not 30 minutes). Your credentials work or they don't work. I guess this also has to do whatever you are connecting to!	[reply]
Re^6: SSL-socket on Windows by morgon (Priest) on Mar 18, 2012 at 18:30 UTC
I now believe that the reason it was done like that is the problem of sharing IO::Socket::SLL-instances. The code is old, has not been maintained for years and the original developer has been gone for a long time... Under normal circumstances it works (then you see SSL-connections being established fast) but when there is high load on the system both WMI-calls and the SSL-upgrade take a lot more time than usual. I assume (not being an expert here) that the establishment of a SSL-connection is CPU-intensive as it entails a key-exchange and when you have another process that hogs the CPU this seems to take longer and unfortunately breaks all the implicit timing-assumptions of something that at the end of day is nothing more then one big hack...	[reply]
Re^7: SSL-socket on Windows by Marshall (Canon) on Mar 18, 2012 at 19:24 UTC
I think your analysis is correct. You are dealing with code that works "most of time", but "not all of time". The SSL calculations take time, but "that is not that much time". Certainly not 30 minutes! We are actually talking milliseconds (even on a very slow computer - like mine!) for all of the calculations. The basic design appears to be flawed.	[reply]