Detail reader concurrency

[Nathan Ward]

Hi,

We are using the detail file reader to relay accounting from our “frontend” servers to a number of backend servers which have different roles.

We write every packet to a detail file per backend, then read them in, and send them on.

One of the servers takes around 80ms to respond to a request, regardless of the request rate - if I send 1/s it responds in 80ms. If I send 100/s, it responds in 80ms. I guess you could just imagine that there is 80ms network latency, which is a problem I imagine is somewhat common.

It looks like the detail reader’s behaviour is to do one packet at a time. I can understand why this would be - it’s certainly a lot simpler! Is there a way to configure it to relay multiple requests at once? The protocol supports this of course with multiple IDs (and some BNGs even do multiple source ports), but, not sure if the detail reader (or, wherever this would need to live) does.


One option open to us of course is to attempt to relay the packet first, and only write to the detail file if relaying fails, which would (I think!) mean multiple requests can be in flight at once. Because we’re sending the requests off to multiple backend servers, this means we’ll be waiting for each of them in turn before responding to the original clients, which is something we want to avoid.
I have considered a detached subrequest, and relaying to the slow backend server immediately and not using the detail writer unless the backend is broken - but, I don’t want to respond to the client unless the data is either on the backend server, OR, is written to disk on the frontend.
I have also considered writing to many detail files based on some sort of hash, and having many readers.. but that is not very elegant.

--
Nathan Ward