From: Alan T. DeKok Date: Mon, 15 Feb 2021 21:00:53 +0000 (-0500) Subject: move detail to the new location X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b6d7b31ca202095da634ef0979b723ca5888c192;p=thirdparty%2Ffreeradius-server.git move detail to the new location for now, proto_detail_process is in src/listen/detail, as a reminder that it will go away as soon as possible. --- diff --git a/src/modules/proto_detail/README.md b/src/listen/detail/README.md similarity index 100% rename from src/modules/proto_detail/README.md rename to src/listen/detail/README.md diff --git a/src/modules/proto_detail/all.mk b/src/listen/detail/all.mk similarity index 100% rename from src/modules/proto_detail/all.mk rename to src/listen/detail/all.mk diff --git a/src/modules/proto_detail/proto_detail.c b/src/listen/detail/proto_detail.c similarity index 100% rename from src/modules/proto_detail/proto_detail.c rename to src/listen/detail/proto_detail.c diff --git a/src/modules/proto_detail/proto_detail.h b/src/listen/detail/proto_detail.h similarity index 100% rename from src/modules/proto_detail/proto_detail.h rename to src/listen/detail/proto_detail.h diff --git a/src/modules/proto_detail/proto_detail.mk b/src/listen/detail/proto_detail.mk similarity index 100% rename from src/modules/proto_detail/proto_detail.mk rename to src/listen/detail/proto_detail.mk diff --git a/src/modules/proto_detail/proto_detail_file.c b/src/listen/detail/proto_detail_file.c similarity index 100% rename from src/modules/proto_detail/proto_detail_file.c rename to src/listen/detail/proto_detail_file.c diff --git a/src/modules/proto_detail/proto_detail_file.mk b/src/listen/detail/proto_detail_file.mk similarity index 100% rename from src/modules/proto_detail/proto_detail_file.mk rename to src/listen/detail/proto_detail_file.mk diff --git a/src/modules/proto_detail/proto_detail_process.c b/src/listen/detail/proto_detail_process.c similarity index 100% rename from src/modules/proto_detail/proto_detail_process.c rename to src/listen/detail/proto_detail_process.c diff --git a/src/modules/proto_detail/proto_detail_process.mk b/src/listen/detail/proto_detail_process.mk similarity index 100% rename from src/modules/proto_detail/proto_detail_process.mk rename to src/listen/detail/proto_detail_process.mk diff --git a/src/modules/proto_detail/proto_detail_work.c b/src/listen/detail/proto_detail_work.c similarity index 100% rename from src/modules/proto_detail/proto_detail_work.c rename to src/listen/detail/proto_detail_work.c diff --git a/src/modules/proto_detail/proto_detail_work.mk b/src/listen/detail/proto_detail_work.mk similarity index 100% rename from src/modules/proto_detail/proto_detail_work.mk rename to src/listen/detail/proto_detail_work.mk diff --git a/src/modules/proto_detail/todo.md b/src/modules/proto_detail/todo.md deleted file mode 100644 index 87c2c37003d..00000000000 --- a/src/modules/proto_detail/todo.md +++ /dev/null @@ -1,108 +0,0 @@ -# Detail file reader - -## What works - -proto_detail and proto_detail_file can work together to read a -pre-existing `detail.work` file, process it to completion, and close -the file. - -The detail listener can be configured to read Accounting-Request, -CoA-Request, or Disconnect-Request packets. - -The detail file listener can programmattically set priorities for the -packets. - -Event-Timestamp and Acct-Delay-Time are set for accounting packets. - -Use `MPRINT` to debug the file reading. - -Basic sanity checks of the file format is done. - -Once a `read()` returns data AND at least one packet, the FD is paused -until all of the `write()` functions return. This allows the detail -file reader to be "self clocked". i.e. if the server isn't busy, the -file is read at 100% speed. If the server is busy, the file is read -only when it becomes un-busy enough to respond to the packets. - -The packets are processed through `recv {}` and `send {}` sections. -Note no second name! That could be change? - -The `send Do-Not-Respond { }` section should work. - -The default packet size is 64K. If detail file entries are larger -than this, you will have to set `max_packet_size` to something larger. -Otherwise, larger packets are skipped. - -## What doesn't work - -The `send Protocol-Error { }` section is there, but doesn't work. - -The "self clocking" has some limitations. Right now, it reads -`max_packet_size` data from the file, and adds *all* packets in the -file. So it's somewhat bursty. It would be nice to read one packet, -process it, and then read another only when the first one is done. - -The issue with that is the event loop is FD based. There's no way -right now to determine that the FD may not be ready, but there's still -more data in the `fr_network_socket_t` structure. Fixing that -requires the network code to track sockets which have partial data, -but are paused. - -The code hasn't been tested with very large detail files. - -"too large" packets haven't been tested well. - -The "Done" packets haven't been tested well. - -The read_pause / read_continue hasn't been tested with large detail -files. - -The polling for detail files hasn't been written. No `glob()`, rename -"detail_foo` to `detail.work`, no locking of the detail file. - -The VNODE work hasn't been started. That's the code which will open a -EVFILT_VNODE with NOTE_EXTEND on the directory. Then, once it gets a -signal, either open `detail.work`, or call `glob()` to find the oldest -detail file, rename it to `detail.work`, and process that. With -locking, etc. - -We still have to figure out how to open a locked file from -`proto_detail_file`, probably via having the parent open the file, -lock it, and (somehow) create the child, and pass the opened FD to the -child. - -When the child is done, it should notify the parent VNODE handler that -the file is done, so that the parent can troll through the directory -again. Or maybe we can just delete the file, and rely on the parent -to get a NOTE_EXTEND signal, and then realize that there's no -"detail.work" file, and process that? ... that's probably the simplest -TBH. That way the parent and child can have no real relationship - -The VNODE handler needs to minimize trolling through the directory, so -that it doesn't do so on every file creation. i.e. it should troll -through once, do the detail.work thing, remember there's a -detail.work... and then when it gets NOTE_EXTEND, only check that -there's a detail.work. If it can't stat the detail.work file, it -needs to troll through the directory again. Otherwise, the -detail.work reader is still busy, and the VNODE routine can ignore the -signal. - -There's no documentation in `raddb/sites-available`. - -We should have examples of calling other virtual servers: - - recv { - call default.Accounting-Request { - ... - } - } - -Tho that configuration should be discouraged, as it can result in the -packets being written to the detail file again. In v4 rlm_detail, -there is no logic to suppress that kind of configuration. - -## Ideas - -allow for multiple detail.work files, (detail.work1, detail.work2, -etc). The VNODE handler can then spawn multiple children, allowing -for very fast reading of detail files!