



In v4, all "server" sections MUST start with a "namespace"
parameter.  This tells the server which protocol is being used.

RADIUS, or DHCPv4, or any other protocol supported by the server.



This virtual server will read detail files from the
following directory.



The "listen" section MUST have a second name here, which
says "load the detail file processor, and not the typical
RADIUS UDP / TCP socket IO.


Overrides the default transport prefix set by
namespace and loads the detail reader code.



Types of packets we are reading.



There is no need to specify a transport.
The default is `file`, which is the only
one supported.



Unlike v3, there is no "load_factor" configuration.

Instead, the detail file listener is "self
clocking".  The listener reads one entry, and as
soon as it gets a response to that entry, the
listener reads a second entry.

Packets from the detail listener are low priority,
so they are processed only when there is nothing
else to do.  i.e. if the server receives many
Access-Request or Accounting-Request packets from
the network, they will be processed *before* any
packets from the detail file.

This behavior ensures that the detail file is read
as fast as possible.  At the same time, it ensures
that the detail file does not affect higher
priority packets from the network.



Set the priority for packets from the detail
listener.  For safety, it should be set low.  This
means that "real" packets from a NAS will be
processed before packets from the detail listener.

i.e. the packets from the detail listener won't be
processed until ALL OTHER packets in the system
have been received, processed, and responded to.

The default is for the server to process packets in
the following priority:

Status-Server
Access-Request
Disconnect-Request
CoA-Request
Accounting-Request
packets from the "detail" listener.

This priority setting ensures that the server will
be responsive and stable.

Allowed values: 1 to 65536.

Setting it to "1" means "very low priority".

Setting it to "65536" means "higher priority than
Access-Request packet"



Check for the existence of detail files.

You MUST also configure a "work" subsection below.


The wildcard to use for finding detail files



If there are no detail files in the directory,
the listener will periodically wake up to check
for new entries.

If this is set to `0`. then the server will
rely on file system notifications to
discover when a detail file has been added.
Setting it to `0` only works on Linux.  On
other operating systems, it MUST be set to
a non-zero value.

Allowed values: 0 to 3600


Configuration related to processing the
"detail.work" file.

This MUST also be specified, along with the "file"
subsection above.


The name of the current working file.  If
omitted, it is the directory from the
`file` subsection, `filename` argument
given above, with "/detail.work" appended
to it.

As of v4, you can have multiple detail file
readers in the same directory.  The only
caveat is that the wildcards CANNOT overlap.

The best way to enforce that is to give the
the files different prefixes.



Track progress through the detail file.  When the detail
file is large, and the server is restarted, it will
read from the START of the file.

Setting `track = yes` means it will skip packets which
have already been processed.  The default is `no`.



The maximum size (in bytes) of one entry in
the detail file.  If this setting is too
low, then the "too large" entries in the
detail file will be ignored.



Whether or not the detail.work file reader
retransmits packets which have failed.

If this configuration item is set to `no`, then
the reader will ignore any failures, and will
go to the next entry as soon as the current
entry is finished, even if it failed to process
that entry.

default = yes



Limits for the files, retransmissions, etc.


Number of simultaneous packets it
will read from the file and feed
into the server core.

Useful values: 1..256


Initial retransmit time: 1..60

If there is no response within this time,
the module will retransmit the packet.



Maximum Retransmit Time: 5..30

The maximum time between retransmissions.



The following are maximums that *all* apply.
i.e. if any one of the limits is hit, the
retransmission stops.



Maximum Retransmit Count: 0..20

How many times the module will send the packet
before giving up.

A special value of "0" means "retransmit forever".



Maximum Retransmit Duration: 0..600

The total length of time the module will try to
retransmit the packet

A special value of "0" means "retransmit forever".



The detail file reader runs the normal RADIUS / DHCP / etc. processing sections.


If there's an Acct-Delay-Time, increase its value based on the
difference between when the packet was written, and the current time.

Note that we do NOT rely on any Event-Timestamp in the original packet,
it could be wrong.




We handled the packet successfully.  Run the "send ok" section.



If the "recv" section returns "ok" or "updated", it
will run the "send ok" section to send the reply.

All other return codes (e.g. "fail") will cause it to run
the "send fail" section.



If the listener is configured with 'track = yes', then the entry in
the detail file is marked up as being "done".  Subsequent re-reads
of the same detail file (e.g. on server restart) will skip the
"done" entries.



All failed packets sent by the detail listener should be processed
through the 'send Do-Not-Respond' section.

If the listener is configured with 'track = yes', then the packet
will be retransmitted by the detail file reader, until the packet
returns "success".  See the "limit" subsection above for retransmission
configuration.


== Default Configuration

```
#	This virtual server gives an example of reading the detail
#	file for the v4 configuration.
server detail {
	namespace = radius
	directory = ${radacctdir}/detail
	listen detail {
		proto = detail
		type = Accounting-Request
#		priority = 1
		file {
			filename = "${...directory}/detail-*"
			poll_interval = 5
		}
		work {
			filename = "${...directory}/detail.work"
			track = yes
			max_entry_size = 65536
			retransmit = yes
			limit {
				max_outstanding = 1
				initial_rtx_time = 1
				max_rtx_time = 30
				max_rtx_count = 6
				max_rtx_duration = 40
			}
		}
	}
recv Accounting-Request {
	if (&Acct-Delay-Time) {
		&Acct-Delay-Time += %l - &Packet-Original-Timestamp
	}
	if (!&Event-Timestamp) {
		&Event-Timestamp := &Packet-Original-Timestamp
	}
	ok
}
send Accounting-Response {
	ok
}
send Do-Not-Respond {
	ok
}
} # virtual server "detail"
```
