[Serdev] SER's core design features(process model/parser/lumps/script) - was: So who/what is SER for, anyway?

[Dragos Vingarzan]

> Maybe not the right time to say this, but honestly, that sounds like a
> bad design decision. Monolithic applications with all sorts interfaces
> increases complexity, cost of maintenance, increases exponentially the
> number of potential bugs etc etc.  Maybe there are things I don't see
> here, but with the appropriate interfaces, I cannot really see why you
> would want Diameter built into ser binary?!
right, like nobody else uses SER with RADIUS ;-). Well, simply because
SIP doesn't do AAA and I don't see the point in interleaving another
communication protocol between SIP and Diameter.
>>     
> But if you create Diameter separately, you can even run Diameter on a
> separate physical server, do load balancing across SER servers (if
> they replicate), you can create a queue, you can handle DoS attacks on
> Diamete you can maintain Diameter with a separate team of developers
> who know nothing of SER, etc etc ...
yes, but Diameter, as RADIUS, does AAA. So why, when getting a REGISTER,
should I send a RPC call to a separate Diameter client, which
interrogates a Diameter server, which responds back and then I pick up
somewhere else (where???) in SER and send a 200 OK...

Same thing for the other direction of requests, from the AAA server
towards the AAA client (SER)....

It's the same question as: Why would you integrate a db interface into
SER...

The only difference is that Diameter is more complicated than Radius and
it is bidirectional. So old approaches for doing Diameter as RADIUS was
done are flawed, IMO. This is a new thing and anything new that is
breaking old  assumptions that were taken on the initial design will
continue to give us headaches.

-Dragos