rr_reply - multiple clients @ same machine

[AndMaz]

Re: rr_reply and http interfaces

Was the issue above solved?

I have a Controller server that contains 2 services (Commander and Monitor)

• Commander is responsible for sending the commands to Duet
• Monitor is responsible for monitoring the status of the Duet and collect telemetry

Visual representation of the arch:

The problem is that (sometimes) Commander gets in GET /rr_reply diagnostics data that was requested by the Monitor.

Is there a way to avoid this?

Also, can somebody provide a detailed description/documentation about how seqs are increasing?
For example, M122 returns 79 lines (78 text + 1 \n at the end) but sometimes the seqs.reply increases by 96 or 97.

[AndMaz]

One possible solution to this is to include a request number inside of GET /rr_gcode response.

For example, { "buff": <bufferSpace>, "req": <number> }. Then the client could use the req. number to fetch the reply (e.g., GET /rr_reply?req=<number> )

Adding this logic would not cause a breaking change. If req is not provided in GET /rr_reply then it would reply using the already existing logic.

With this solution there's no need to add a new HTTP header that holds the session number.

What do you think @chrishamm ?

[chrishamm]

@AndMaz No, this limitation is still present in standalone mode. SBC mode already caches G-code replies per session key. To work-around it in standalone mode, you'd have to add a second IP address to your network adapter and send HTTP reqeusts from your monitoring app from there.

PS: When this limitation is removed from RRF, I think we will add a new (optional) session key to the HTTP request headers like in SBC mode.

[AndMaz]

@chrishamm said in rr_reply - multiple clients @ same machine:

To work-around it in standalone mode, you'd have to add a second IP address to your network adapter and send HTTP reqeusts from your monitoring app from there.

Yeah, it could work but it doesn't seem to be a very elegant solution. What do you think about GET /rr_reply?req=<number> approach?

PS: When this limitation is removed from RRF, I think we will add a new (optional) session key to the HTTP request headers like in SBC mode.

Do you have an estimation of when this is going to be available?

[chrishamm]

@AndMaz That won't work because we need to free memory as quickly as possible, there isn't a huge amount of available RAM in standalone mode. RRF saves G-code replies per HTTP session and those sessions are keyed by IPv4 address. That concept would have to be changed first to allow for use-cases like yours.

[AndMaz]

@chrishamm thank you for quick response.

That won't work because we need to free memory as quickly as possible, there isn't a huge amount of available RAM in standalone mode. RRF saves G-code replies per HTTP session and those sessions are keyed by IPv4 address. That concept would have to be changed first to allow for use-cases like yours.

The logic would be similar to the one that's currently in place. In other words, the reply contents would be deleted after the client has fetched them or if the client has not requested the reply within reasonable time (1 second). But I agree with you that this would imply re-working the current logic @ the firmware.

For now I will try to go with a mutex that will block concurrent reqs to the device. Hopefully, it this will avoid diagnostics data to "leak" into Commander service