Changing transmission parameters

[edmont]

The CoAP specification, section 4.8.1. Changing the Parameters, lets the door open for the modification of some of the transmission parameters. I was looking for the way of changing the number of retransmissions, but it seems to be hard coded in constants.py.

It would be nice to have a way to configure some of this parameters, maybe in the Message class.

[chrysn]

That's a good point.

Right now I think that the way to do that would be to have a collection of transport hints in the message (like the currently existing .remote or .unresolved_remote attributes). They would be similar to options but never serialized into the message but only used to influence how the message is sent. It might be useful to have default hints stored per remote as well.

Right now, changing the values in the constants module is the only workaround option. (If it's urgent and you feel up to it, please consider writing a pull request to that respect).

[chrysn]

That's a good point.

Right now I think that the way to do that would be to have a collection of transport hints in the message (like the currently existing .remote or .unresolved_remote attributes). They would be similar to options, but never serialized into the message but only used to influence how the message is sent. It might be useful to have default hints stored per remote as well. (Looking at the new transports, even MID and type might be suitable to be such hints from an application's PoV, but let's do the noncontroversials first)

Until then, changing the values in the constants module is the only workaround option. (If it's urgent and you feel up to it, please consider writing a pull request to that respect).

[baw-serafin]

Jep this is definitely a missing feature. To change the constants one would need to overwrite constants.py or is it somehow possible to overwrite it while running / before creating the context?

[chrysn]

On Thu, Jul 26, 2018 at 09:58:01AM +0000, baw-serafin wrote:

Jep this is definitely a missing feature. To change the constants one would need to overwrite constants.py or is it somehow possible to overwrite it while running / before creating the context?

The planned way forward is that the constants will be used only in the transports, and later accessed not as module-level constants but in a transport specific way. (Eg. the maximum block size of a coap[s]+tcp connection will be stored next to the socket, while CoAP over UDP could retain a LRU cache of run-time observed block sizes).

[chrysn]

Another parameter that should be considered in this task is EMPTY_ACK_DELAY as suggested by @therealprof in #116 (esp. last few comments). Unlike other parameters considered so far, this can't be transported in a message, but could at best be a property of a resource handler (think "I know this will take a while, just go ahead and send the empty ACK right away"), and would typically be configured per remote or transport ("RTT are in the 2s area, remote will need 4s or more for timeout anyway, so .5s is fine as well").

[therealprof]

@chrysn I tried the suggested workaround and I found one thing (not sure it's a problem or actually allowed, mbedOS does not do this): the MID changes.

DEBUG:coap-server:Incoming message <aiocoap.Message at 0x10bd89d30: Type.CON POST (MID 25164, token 5856) remote <_Connection at 0x10bd5d438 on transport <_SelectorDatagramTransport fd=8 read=polling write=<idle, bufsize=0>>, active>, 1 option(s)>
DEBUG:coap-server:New unique message received
DEBUG:coap-server:Sending empty ACK: Response took too long to prepare
DEBUG:coap-server:Sending message <aiocoap.Message at 0x10bda40b8: Type.ACK EMPTY (MID 25164, empty token) remote <_Connection at 0x10bd5d438 on transport <_SelectorDatagramTransport fd=8 read=polling write=<idle, bufsize=0>>, active>>
DEBUG:coap-server:Sending message <aiocoap.Message at 0x10bda4320: Type.CON 2.04 Changed (MID 38679, token 5856) remote <_Connection at 0x10bd5d438 on transport <_SelectorDatagramTransport fd=8 read=polling write=<idle, bufsize=0>>, active>>
DEBUG:coap-server:Exchange added, message ID: 38679.

[chrysn]

On Tue, Sep 25, 2018 at 03:17:28PM +0000, Daniel Egger wrote:

the MID changes.

That is intentional. The ACK needs to carry the MID of the request. The response uses a MID minted by the server, as it constitutes a new exchange initialized by the server (and the client will then ACK it with the same MID).

This is where the two sub-layers (messaging with MID, request-response with token) of CoAP part: A piggy-backed response covers one request-response pair in a single message exchange, while a separate response (in the CON/CON case) has two message exchanges for the single request-response pair.

See examples in figure 19 and figure 20 of RFC7252.

[therealprof]

Okay, thanks for pointing that out.