CoAPthon3 is a porting to python3 of my CoAPthon library. CoAPthon3 is a python3 library to the CoAP protocol compliant with the RFC. Branch is available for the Twisted framework.
MIT License
59
stars
50
forks
source link
Added purging transactions as client, don't add transaction when no_response is True #10
Clients never purged the transactions in their message layer as the server does.
We're using devices with the same IP throughout our application, so renewing the client did not natively make sense to us.
As a result, we encountered a memory leak of the piled up transactions.
In this PR, we expose the purge function of the message layer to the CoAP client object, should we take it one step further to the HelperClient?
Additionally, the no_response flag now also flows to the CoAP client object's send_message method, where if no response is expected, no transaction is made.
We have a lot of these calls, so this made a lot of sense for us.
What's your opinion on how the client should be used?
Clients never purged the transactions in their message layer as the server does.
We're using devices with the same IP throughout our application, so renewing the client did not natively make sense to us. As a result, we encountered a memory leak of the piled up transactions. In this PR, we expose the purge function of the message layer to the CoAP client object, should we take it one step further to the HelperClient?
Additionally, the no_response flag now also flows to the CoAP client object's send_message method, where if no response is expected, no transaction is made. We have a lot of these calls, so this made a lot of sense for us.
What's your opinion on how the client should be used?