Request Expiration Timestamp

[tsengia]

Just want to double check my thinking here:

The Request Expiration Timestamp (RET) is an absolute timestamp, correct?

That means that if I want my request to timeout in 5 seconds, I need to send an RET that is equal to the current timestamp plus five seconds? Or can I just send an RET with a value equal to 5 seconds?

Thank you!

[reinaortega]

It can be either an absolute timestamp or a relative timestamp. So you can send just RET equal to 5 seconds (I think it should be in ms)

[tsengia]

To use this, I would add the X-M2M-RET: 5000 header to my HTTP request, correct? which would give me a 5 second timeout?

[tsengia]

and ACME should close the connection when the timeout is reached?

[ankraft]

Yes, it should. It could be, however, under certain circumstances, for example if the request is currently processed by the CSE, that particular process is not hard interrupted. In general, the timeout test is done before the processing starts.

The connection is not closed immediately, but you will get a response that the timeout has been reached. It is not the same as a timeout on the transport layer.

[tsengia]

Thank you, this timeout helped resolve a bug occurring on the Thingy:91.

It turns out that the socket libraries authored by Nordic are missing the implementation of the shutdown() method, which is responsible for terminating the socket connection when the Thingy:91's request timeout it's reached.

By setting this RET field, it is now ACME that responds to and terminates the connection, which allows our Thingy:91 to behave properly.

[ankraft]

This is great! I am sure that this took a lot of efforts to debug, and I am very glad about the outcome!

Please put this in your report.

[reinaortega]

I think that for relative timestamp you have to use just a number. The ISO8901 string is for the xs:duration data type.

[ankraft]

Ah, you are right. I edited my comment.