xdeon / ecoap Goto Github PK

The present implementation deals with requests and responses asynchronously with complex overhead on tracking a variety of things. It would improve both readability and maintainability by refactoring ecoap_client with a simpler structure.

What is the consequence of NAT? Consider client behind NAT and server behind NAT, both with ongoing observe. And consider what will happen with current implementation that endpoint with alive client process will not terminate.

Currently we use simple listener supervisor + acceptor/connection state machine to handle DTLS. This structure does not differ process busy accepting and process already connected. Also it is hard to track e.g. number of connections, as accepting is a blocking operation.

Furthermore, reconnecting logic is absent because we are unclear about how the client would react in such a scenario (consider what to do when the device went into sleep mode).

ecoap should definitely be refactored thoroughly as it inherits too many weird code from modifications around the original code base.

It might be a good idea to build proper-based tests either using ecoap itself as a model or using the RFC as a model. That should,

1. ensure the refactored system work as before
2. figure out some hidden bugs that violate the RFC

However how to achieve reasonable properties is not easy. The whole task might take longer time than expected.

When message lifetime is set to value less than retransmit interval, it is possible that we never get a reply if using synchronous APIs with infinity timeout + the remote endpoint is unresponsive. This is because message exchange is cleaned up too early and the transmit timeout message leads to nowhere. However in this case we still have stale token info left in the endpoint process ...

How to handle server failover? Do we need persistent store for observe relationships? This also affects load balancing strategy since they both involve switching between different server endpoints.

Make ecoap_handler general handler for both server and client, let embedded client directly apply its logic within the handler process, let standalone client go with current way.

Related to #2

Currently block-wise transfer is handled by ecoap_handler automatically, which means it stores segments of the payload in the process state until it is complete or expired, and will only invoke user-defined handler function when the transfer finished.

This method is easy for users, but requires potential large memory to operate. Does it make sense to have it optional? That is to say, user can choose whether to deal with the blocks themselves or not.