Is your feature request related to a problem? Please describe.
The filestream client waits for a request to fully complete before terminating the thread. This counts towards the concurrency limit. When streaming a large volume of files, and additionally not using/collecting Strelka events on the client side e.g. "Discard" mode, the client should not wait for events. This should vastly increase throughput for busy systems like network sensors.
Describe the solution you'd like
If the filestream client has no response entries in the config file (response: dict is emtpy), the client should immediately terminate the request after sending the file.
Describe alternatives you've considered
It may be possible to set the Filestream client timeout to a low threshold to quickly release waiting requests. However, that may negatively impact requests with large file sizes.
Is your feature request related to a problem? Please describe.
The filestream client waits for a request to fully complete before terminating the thread. This counts towards the concurrency limit. When streaming a large volume of files, and additionally not using/collecting Strelka events on the client side e.g. "Discard" mode, the client should not wait for events. This should vastly increase throughput for busy systems like network sensors.
Describe the solution you'd like
If the filestream client has no response entries in the config file (response: dict is emtpy), the client should immediately terminate the request after sending the file.
Describe alternatives you've considered
It may be possible to set the Filestream client timeout to a low threshold to quickly release waiting requests. However, that may negatively impact requests with large file sizes.
Additional context
Relevant code sections
https://github.com/target/strelka/blob/0ca89f8906923658daac6af65e96a56820f8a856/src/go/cmd/strelka-filestream/main.go#L80-L107
https://github.com/target/strelka/blob/0ca89f8906923658daac6af65e96a56820f8a856/src/go/pkg/rpc/rpc.go#L195-L208