Stefan A. wrote:
I have to provision the DEST1 using live session information, and DEST1 only needs the information during the current IP, but if I set up: 1. manual Proxy from sites-enabled/default file: all ACK Packages are delayed to the NAS, if DEST1 is not there, and the NAS possibly retries... not good!?
That's why the other virtual servers exist.
2. if I use'copy-acct-to-home-server', I have to keep track of the packet, to not send too old information to the DEST1. In strange cases, where DEST1 is down for hours, I will keep sending packets of old sessions, until I went through all left files...
Uh... the server keeps track of the packet. And the whole point of accounting is to store data. i.e. to send *all* traffic, even after the home server has been down for hours. If you don't like this, you can change the proxying rules to *ignore* accounting packets that are older than X hours. See Acct-Delay-Time.
3. I could possibly mix it: I might send START and STOP packets to DEST1. In case DEST1 is not available, I put all STOP Packets into the 'copy-acct-to-home-server' files. After DEST1 is back up, all previous ended sessions will be cleared and new sessions will overwrite the possibly old status in the DEST1 databases ..., but this might not work, as 'redundant' does not take updates on a attribute list.
That sounds complicated.
also... 'copy-acct-to-home-server' seems to delay the forwarded packet at about 0.2 to 0.5 seconds... I checked to use a ramdisk for this, but it did not speed up the process... I sometimes see 0.05 but often 0.4
I don't understand why that's a problem. Do you really need millisecond resolution on accounting packets?
Again, nobody cares about start packets after the session has been terminated, but fast delivery is critical...
Why? No one else needs millisecond response time for accounting packets. Alan DeKok.