rr_reply - multiple clients @ same machine
-
Re: rr_reply and http interfaces
Was the issue above solved?
I have a Controller server that contains 2 services (
Commander
andMonitor
)Commander
is responsible for sending the commands to DuetMonitor
is responsible for monitoring the status of the Duet and collect telemetry
Visual representation of the arch:
The problem is that (sometimes)
Commander
gets inGET /rr_reply
diagnostics data that was requested by theMonitor
.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 theseqs.reply
increases by 96 or 97. -
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 inGET /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 ?
-
@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.
-
@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?
-
@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.
-
@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 -