It's been a while since I gave a status update on version 4. The good news is that it's making progress. The bad news is that it's about 4 weeks later than I had hoped. I've been putting design documents (and whiteboard diagrams) into the wiki: http://wiki.freeradius.org/version4/ I have a number of test programs for the new code, which let me test each part in isolation. So far, I have the underlying asynchronous message passing interface working, and as of yesterday, the back-end worker threads: $ time ./build/make/jlibtool --mode=execute ./build/bin/local/worker_test -m 1000000 -o 100 -c 2000 -w 4 ... Worker 3 kq = 5 num_channels = 1 num_requests = 250000 calculated (predicted) total CPU time = 152250000 calculated (counted) per request time = 457 start = 0 end = 0 when = 0 yielded = 0 resumed = 0 predicted = 609 running = 114384642 waiting = 0 In this test, there are 4 worker threads, and a "master" thread which invents packets and sends them to the worker. Each worker "processes" the packets (just a plain ACK). The framework is getting about 2M packets/s for the full round trip, with 4 worker thread. That number will go down with real packets, of course. It takes additional time to read packets from the network, and then process them through "unlang" statements. But the key part is that this code is completely asynchronous, thread-safe, and can be scaled horizontally with more network reader threads and more worker threads. In contrast, the current code (single mutex, linked list, lots of contention) maxes out at about 70K packets/s. And finally, the worlds worst RADIUS server. :) A test program that just ACKs packets: $ ./build/make/jlibtool --mode=execute ./build/bin/local/radius_test -c 100 -w 1 -xx Executing: /bin/sh -c ./build/bin/local/radius_test -c 100 -w 1 -xx Master started. Master created 1 workers. Worker 0 started. Worker 0 looping. Master creating channel to worker 1. Master created all channels. Master waiting on events. Master kevent returned 1 Master got packet size 62 Master sending packet size 62 to worker 0 Master waiting on events. DECODE <<< request 159 - 0x7fef1ae00060 data 0x10fa51060 size 62 PROCESS --- request 159 action 0 ENCODE >>> request 159 - data 0x7fef1ae00060 0x7fef1b832e60 room 1024 Master kevent returned 1 Master servicing control-plane Master got channel event 2 Master got data ready signal Master got reply 159 size 20 Master waiting on events. So I'm not confident that the new framework will handle RADIUS packets, too. The next step is to finish off the protocol abstraction layer, and then to finally replace the current networking code with the new code. And hopefully in January, we'll have a new protocol to announce. One which people have been asking about or 15+ years. Alan DeKok.