The A_PROCESSING_TIME in constants.py is not effective when using a TCP connection？ about python-doipclient HOT 2 OPEN

The order was intentional - I can't think of a good reason for a user to want to deal with timeouts on first connect, and I would imagine that many ECU's have trouble with the initial connection as there's more packets back/forth and setup. The OS will still have a timeout in the overall TCP layer as well as any timeouts with IP resolution, etc. I would accept a patch to allow the client constructor to accept an optional connect_timeout if you have a use case for it though.

from python-doipclient.

Thanks, the patch is useful for us if allowed. We need to deal with so many ECUs with uncertain state (connected or not). The only possible way is to send a doip package to the specific logical address and observe the response. The default timeout will be too long to accept if the timeouts on first connect is not optional in doipclient : )

from python-doipclient.