Checking network input processing by Python for a multi-threaded server

[Markus Elfring]

>> An instance for the class “threaded_TCP_server” and a call of “subprocess.run(…)”.
>>
> 	And how many connections does the subprocess make?

A new TCP connection is performed with the information from the passed parameters
for each call of the function “sendall”. The test command will send JSON data
over these six connections then.


> A full connect(), send(), close() for each output?

Yes, for this test variant.


> OTOH, if you are making multiple connect() calls, then OS scheduling
> could result in multiple server threads running.

This functionality is desired.


…
> Of course, you still have to use your head!
…
> For instance, it makes no sense to use a forking server
…

I would expect that the main test process will not be forked here.


>> I hope that the execution of the statement “server.shutdown()” triggers
>> a separation in the reported inter-process communication.
>
> 	.shutdown() stops the server from processing new connections...

I hope so, too.
(Additional server objects can be created in subsequent loop iterations.)

How does this interpretation fit to the wording “Tell the serve_forever() loop
to stop and wait until it does.” from the documentation of
the class “socketserver.BaseServer”?


> It does nothing for the nature of TCP streams

This aspect should be fine.


> 	I'd be tempted to convert the master and subprocess from TCP to UDP,
> just to see if there is a difference.

I do not want to change the data transmission technique for this use case.


I suggest to take another look at a related discussion topic like
“Data exchange over network interfaces by SmPL scripts” if you would prefer
to review a concrete source code example instead of recognising
data processing consequences from a known test algorithm.
https://systeme.lip6.fr/pipermail/cocci/2019-April/005792.html
https://lore.kernel.org/cocci/6ec5b70f-39c3-79e5-608f-446a870f02f3@web.de/


Will it help to add a bug report in an issue tracker?

Regards,
Markus