On 18 Aug 2016, at 11:14, Zhang Huangbin wrote:
On Aug 18, 2016, at 10:02 PM, Wietse Venema <wie...@porcupine.org>
wrote:
What are you using to "run" the policy service? Try using "telnet
127.0.0.1 9998" or "nc 127.0.0.1 9998" to test it.
Thanks Wietse. :)
What do you mean "run" the policy service? It's a python program.
Which must be running in order for it to be listening for connections.
Likely mechanisms would be via a SysV init script in /etc/init.d/ or via
a systemd service definition.
In particular, what happens when you make 100 simultaneous
connections?
Any idea how i can simulate 100 concurrent connections on Linux
command line?
If your policy server is listening on 127.0.0.1:1234, you could try
this:
for x in {1..100} ; do nc 127.0.0.1 1234 & done
That attempts to make 100 TCP connections to 127.0.0.1:1234 with 100
different 'nc' processes, all running in the background.
If your policy server is accepting the connections, running the "jobs"
command after all of those background processes have launched should
show them all in "Stopped(SIGTTIN)" state, meaning that they are
connected and waiting for input. Other possibilities are that some may
exit quickly with a "Done(1)" status (indicating a rejected connection,
most likely because the policy server has exited or closed its listener)
or take a long time to do so (exactly how long is dependent on your OS,
config, and version of 'nc'), indicating that the policy server isn't
actually accepting connections, but is running and has a listener. If
you end up with a lot of those jobs in the "Running" or
"Stopped(SIGTTIN)" states indefinitely, you can clean them up with
"killall nc".
If all 100 processes connect in a reasonable time, the next step would
be to do the same test, but with input piped into all of the nc commands
simulating what Postfix sends to a policy server.
