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.
| [reply] |
Ah, Ok. I can clean that up ;)
In my existing server (not posted):
- it is single-threaded
- the SSL peer cert authentication works
- the server loses some requests because only accept() is non-blocking.
In the code I posted in the OP:
- it is single-threaded
- it is almost entirely non-blocking
- the server DOES NOT lose requests if peer auth is turned OFF
- if peer auth is ON, the server gives Net::SSLeay errors and destroys the listening socket
-David.
| [reply] |
Your first server only has the problem that it is missing new accepts while being busy but it still has to complete authentication before you serve the request, which is more likely to be the source of the blocking than local servicing of requests alone. The code posted in the OP attempts to force everything into a synchronous handling. But of course the authentication is not part of your synchronous handling and your attempted solution is certainly breaking it - but I think this probably isn't just a code-fixing issue but more likely a question of writing code that is asynchronous (so cannot be single-threaded) where it needs to be i.e. that respects the asynchronous nature of the requests and authentications occurring at a lower layer than you have control over when using the modules you have selected.
I'd be inclined instead to conform as closely as possible to the examples shown in Chapter 16 of Programming Perl, which covers everything discussed so far, except that your processing is synchronous and Chapter 16 (when the relevant sections are considered together - they are of course split up for more general purposes than just yours) appears to me to advocate an asynchronous multi-threaded approach.
And re Thread::Queue, you said you already did that in the first solution. And yet you say now that solution was ALSO single-threaded? I think you are missing the point of that module.
| [reply] |