Valts Mazurs wrote:
I already had a suspicion that I would get reply to my previous email really fast.
That's what happens when you troll on a list.
Alan DeKok wrote:
If you're going to bash the server and direct people to your own product, I suggest you unsubscribe.
This is not the case.
Simple contradiction doesn't establish your point, or make mine not true.
I have been user of FreeRADIUS for very long time, and I (and company I worked for then) decided that it will be much easier and comfortable to make small RADIUS server which would not be designed for general use. It's main purpose is to provide easy and stable backend for writing modules in Python. I tried to do the same with FreeRADIUS some time ago. There were fixes to rlm_python but it still has never worked as expected (at least on all my systems).
Hmm.. You're saying it's easier to write & support a complete RADIUS server than to fix rlm_python. Right.
I am not going to redirect any FreeRADIUS user to my product.
So when you said people should use bsdradius, you were doing what, exactly?
The very most of FreeRADIUS users don't want to develop their own modules in Python. Oh, and I am so unlucky to be the maintainer of another RADIUS project. Seems like this is very serious reason for bashing me.
Ah, yes. I'm being rude for asking you to follow common politeness.
In case of all known radius servers they become slow when there's serious business logic implemented in the backend.
You've successfully optimized the backends by writing a BSD-licensed server? i.e. This response indicates that your web site claims about the need for a fast, small server are B.S.
And what if authorization requests had higher priority than the accounting ones?
You can do this with FreeRADIUS. Read the config files, and the documentation for the "nice" command.
And what if accounting response could be sent even before processing the request? It is a major speedup. It is optimization in design, not in several parts of code.
It optimizes away robust accounting. That's a non-starter for anyone who's basing a business on correct accounting. FreeRADIUS won't be implementing this "feature" It can destroy a business.
In VoIP world 50 requests per second is nothing BIG. Users begin and terminate their sessions very often. The main reason is bad link quality which results in many unsuccessful call attempts.
Is that near the 1000's/s limit I said? Nope. Then why the B.S. claims about the need for a fast & efficient server?
"reduce code size" - Nonsense.
I think that code size matters, a lot. It is much easier to hold in your head all the stuff if it takes less space. The same is with screen.
Try using something called "structured programming". It helps.
Just, please, Alan, don't take it so personally that there are other RADIUS servers in the world.
It's easier to dismiss my points by labelling me as taking it "personally". It's harder to dismiss my points by arguing the facts.
P.S. You should take a look at openradius.org I really like the idea when RADIUS server communicates with modules through pipes.
Really? Wow... it's only been listed as another open source RADIUS server on freeradius.org for what, 3-4 years now? And the author of OpenRADIUS hasn't trolled in this list, either. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog