in reply to Re^2: SSL-socket on Windows
in thread SSL-socket on Windows

Since I haven't actually done this myself, I can't say for sure that this is going to work, but you can pass a normal socket, so I would suppose that is ok for an SSL socket. This is indeed a strange design. But you plan sounds like its worth a shot.

Replies are listed 'Best First'.
Re^4: SSL-socket on Windows
by morgon (Priest) on Mar 18, 2012 at 16:54 UTC
    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.

[reply]
      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]
        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]

In Section Seekers of Perl Wisdom