pylessard / python-udsoncan

Python implementation of UDS (ISO-14229) standard.
MIT License
575 stars 199 forks source link

How to moke starting the next request without waiting for the previous request to return? #165

Closed amsyrena closed 1 year ago

amsyrena commented 1 year ago

code: client.py send_request payload = self.conn.wait_frame(timeout=timeout_value, exception=True)

The next request can only be initiated after checking the previous round of request replies.

pylessard commented 1 year ago

The client does not support pipelining of request, sorry. UDS is a request/response protocol, I think it is reasonable to work this way.

Do you have a relevant use case that would require that?

amsyrena commented 1 year ago

Yes, There are such scenarios and needs. Sometimes there is no need to wait for a reply before starting the next request. No sequence is required. Maybe I waited for a reply after sending multiple requests in a row. Or I want to create a simulated test scenario, the requests sent continuously will be replied one by one, to test not lose the request.

pylessard commented 1 year ago

pipelining assumes that the ECU is able to receive pipelined request, which I think might not always be the case. Also, the are no request number that can allow the client to match a response with a request. all you have is the service number which is not enough because you could pipeline 2 request for the same service. If one response fails in the pipeling, how do you know which one?

The Client object is stateful and will wait for an answer before going forward. You can craft the request yourself and pipeline them into the connection object. I don't plan on adding support in the Client for such feature.

Regards

amsyrena commented 1 year ago

Thank you very much for your reply. And I agree with you. I think it should be better to do the processing at the connection layer. For example, similar to message queue processing, thread or coroutine processing. Or to create some pipeline...

pylessard commented 1 year ago

Can we close this issue?