Create DoS binary to test load handling in eID-Service

[frankmorgner]

Does not require a real (or emulated) card. Simply fire enough PAOS requests pretending to have a card...

[eriknellessen]

Should be solved in #66

[frankmorgner]

Not yet soved:

• the 2 second delay after each execution (I think this has once been added to not pollute the commandline too much in case of an error)
• connections should be done in parallel, not sequentially

[psytester]

I agree.
For me, the hard coded 2 seconds delay is just used, that eID service does not get too much stress load. BTW: A command line option for flexible value would be great.
For a real DoS the client needs to setup parallel connections and as much as possible. But maybe a configurable maximum number of sockets would be usefull for some "moderate" DoS tests.

[wolfmueller]

Questions:

• I think that the simplest way is to start one process for each PAOS-connection and setting the delay via a command line option. Is that sufficient for your purpose?
• Or is needed one eIDCC-Test-Binary which opens multiple PAOS-connections? This solution has may be higher requirements with respect to tread safeness of our eIDCC-librariy and all libraries which are used by eIDCC.
• Do you need e.g. multiple PAOS-connections through one SSL/TLS channel?

[psytester]

At the end I would need a way to open several parallel PAOS connections.
One use case will be: The client keeps the connection simply open, until the server maybe will close it due to inactivity.
Another use case is: The client closes the connection right after its establishment.
Each PAOS connection gets its own TLS channel to be able to simulate a real scenario as I want to consume as much as possible TCP sockets.
Optional: The number of parallel sockets sould be configurable, but at least 50 parallel sockets per client host are required.

With such simulation I was able in past to stress already some proccesses.

[eriknellessen]

"At the end I would need a way to open several parallel PAOS connections."
What does "parallel" mean exactly? Does PAOS work like TCP connections, which are open until they are closed?
"One use case will be: The client keeps the connection simply open, until the server maybe will close it due to inactivity."
What does "keeping the connection open" mean? Do we have to send something to keep the connection open? Does the client have to save information about the connection? Can the client not just forget about the connection?
"Another use case is: The client closes the connection right after its establishment."
By "closing" you mean "tell the server, that this connection is closed"?
"Each PAOS connection gets its own TLS channel to be able to simulate a real scenario as I want to consume as much as possible TCP sockets."
Ok. We will have to find out, in which steps the eIDClientCore opens a new TLS channel.

[psytester]

Yes, it is based on a simple TCP connection, because "PAOS" is just a Special usage of HTTP layer to get the client side into the server mode and the real server will act as the Client.
The eIDClientcore will open the TCP socket to establish the overlaying PAOS connection.

Keep open the TCP socket means, that the eIDClientcore client will noch send the TCP FIN or RST. We simply wait until the Server will maybe close the socket. No keep alaive is required here.

"Another use case is: The client closes the connection right after its establishment."
By "closing" you mean "tell the server, that this connection is closed"?
--> Yes, here the eIDClientcore will close the socket with a TCP FIN. On application Level it will be something like StopHttpConnection() from library eIDClientConnection

[eriknellessen]

If I understand the problem correctly:

• The approach taken in Added option to abort after PAOS connection establishment. #66 is in general correct.
• You would like to have a new socket for every PAOS connection. I could not find a way to tell libcurl to open a new socket for every new connection. I could not find a way to get a guarantee from libcurl about opening or not opening new sockets for a connection to a host, to which we already have a connection. That means, that we can only be sure to get a new socket, if we create a new process.
• You would like to open connections in parallel.
  • We could do so by using threads. But then again, we do not have a guarantee from libcurl about opening new sockets. Besides, the eIDClientCore can not guarantee to be thread-safe without further work.
  • We could also create parallel processes. This would solve both problems, but is not as efficient as using threads. Would using processes be efficient enough for your needs?
• You would like to have a command line parameter for the time to wait between two runs. This should not be a problem.

One way to solve these problems would be to create a script, which starts multiple instances of the eIDClientCore. This could be a bash script or python etc. Would that be an acceptable solution for you?

[psytester]

Hello Erik,

yes that's it. Approach from #66 is correct.
And if libcurl does not support it, don't make it too complicate and simply start several processes. Threads would be nice but the work and its effort is too bad. So again, single processes are enough. I can put a shell script around which starts me several processes.

[eriknellessen]

We implemented starting a configurable number of parallel processes in #80.