Victor, thanks for trying to help out. But still this cannot be true. In Postfix I cannot setup a different socket for each smtpd process, if I had 100 smtpd processes, I cannot tell Postfix that each of these 100 processes should connect with a different client socket.
So we have one socket here, with 1 client side and 1 server side and we're going to keep the connection alive. Lets say Postfix wants to give me this: request=smtpd_access_policy protocol_state=RCPT protocol_name=SMTP ... If two smtpd processes would talk over the same connection at the same time, we may receive something like this: request=smtpd_access_policy protocol_sta request=smtpd_access_policyte=RCPT protocol protocol _name=SMTP So of course this is not happening, simply because the Postfix smtpd processes are not talking through the pipe at the same time. Now let's say you meant this: they don't talk at the same time, but they can handle things at the same time so Postfix is NOT waiting for an answer before sending a new request, in that case, I could receive this: smtpd process 1 sais this: ========================== request=smtpd_access_policy protocol_state=RCPT protocol_name=SMTP ... smtpd process 2 sais this: ========================== request=smtpd_access_policy protocol_state=RCPT protocol_name=SMTP ... Read: 2 requests, the first one is not waiting for an answer and some other smtpd process is also sending a request. Now I have put a sleep( 20 ) in my answer and I know for a fact that there is no second request like above, but let's just say there is a second request like above, my server will then send 2 reply's: action=dunno\n\n action=reject ...\n\n So how does Postfix now know to what request what answer belongs to, should he reject the first request or the second? The documentation doesn't say anything about having to give the reply's in the same order as they got in. Anyway, talking over 1 socket, there is no way for the client to know where the answer belongs to, unless you have multiple client sockets. I can see it with my own eyes, I've put a sleep( 20 ) in my program (in another thread, so the main thread is meanwhile waiting for another Postfix connection) and I can assure you: there will be no other request from Postfix before the previous one is answered with a action= reply. So what exactly do you mean? Perhaps I misunderstood you, perhaps there IS a way to give Postfix multiple client connections, so one for each smtpd process. How can I do that? -----Original Message----- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones Sent: vrijdag 26 februari 2016 18:51 To: postfix-users@postfix.org Subject: Re: Postfix & check_policyd_service no concurrent connections? On 2/26/2016 11:13 AM, Saskia van Schagen wrote: > Not quite true, one can set smtpd_policy_service_request_limit to 1 > and have a new connection for each request. Yes, you can force a new connection for each request, which will reduce performance considerably. This should only be used if the policy service is incapable of processing multiple requests over the same connection. > But even if you don't and you keep using the same connection, Postfix > is still not giving the next request before receiving the answer of > the previous request. One smtpd process --> one policy service connection. The connection stays open as long as the smtpd process runs. A busy server may have thousands of active smtpd processes, each with its own connection to the policy service. > This is not strange, if you talk over the same pipe, Postfix could > never know to what request the answer belongs to, cause we're talking > over 1 pipeline / socket. So with this design, it's not strange that > Postfix wants an answer before sending the next request. One socket with thousands of long-running connections to it. This is a common high performance design. -- Noel Jones
