in reply to Re^3: Multiplexing HTTPS server, peer cert authentication problem.
in thread Multiplexing HTTPS server, peer cert authentication problem.

In my real server, I *am* actually using Thread::Queue::Any to farm out work to my worker threads from my multiplexing server.

The code I posted is my (boilded down for SoPW) attempt at making my *mostly* non-blocking server *fully* non-blocking. (I see from Thelonius's suggestion that I may not have finished the job). The real server replaces the "file" code from the OP with a mechanism to send work to a Dispatcher thread which classifies the request, finds an appropriate handler class then farms the "work" out to a pool of worker threads.

I can't actually import Threads.pm into the multiplexing server's package as some "magic" internal to Threads.pm causes crashes in IO::Socket::SSL (actually XS from Net::SSLeay).

As for the excellently old-skool open "|blah" method of IPC, i would use it in a second (over say Thread::Queue::Any) if there was currently any problem with the IPC -- I do not believe this to be the case.

-David.
  • Comment on Re^4: Multiplexing HTTPS server, peer cert authentication problem.

Replies are listed 'Best First'.
Re^5: Multiplexing HTTPS server, peer cert authentication problem.
by Moron (Curate) on Mar 06, 2007 at 12:25 UTC
    I am suggesting repairing the SSL data by sending it across from a parent process. The open "|blah" suggestion is a last resort option to prevent the need for Threads, not because there are any problems with IPC.

    -M

    Free your mind

[reply]
      I still don't understand ;) I'm not very smart.

      In the OP, there is no use of threads. It's a single-threaded multiplexing server... works/fails the same on Windows with threads or Linux without.

      I guess I'm not effectively describing my problem; that the peer certificate authentication is screwing up.

      I don't know if the solution is to somehow go back to a more reliable 'blocking' server, or to somehow fix the multiplexing server from the OP.

      -David.
[reply]
        I am also confused as to what is implemented where, what works and where and what doesn't work and where in regard to your two solutions. Until now I had been assuming that both solutions were always losing requests, just that your multithreaded solution lost other requests after doing authentication on one or more and still not listening for a while and that the new single-threaded solution got less far because it lost the authentication request right there.

        -M

        Free your mind

[reply]

In Section Seekers of Perl Wisdom