Henning Westerholt wrote: > On Friday 20 April 2007 17:49, Sebastien Tricaud wrote: > >> [..] >> * What I would like to do: >> - Make sure each component is usable individually: I would like to use >> a high performance SIP parser. The OpenSER one fills the room. I am sure >> this is one way to have this library having more users, which mean >> used in ways OpenSER could not imagine, leading to discovering >> new bugs and have OpenSER avoid SIP parsing troubles [1]. >> > > Hello Sebastien, > > i clearly understand the usecase for a isolated openser parser, but why do > think that this would solve eventual security problems for OpenSER? > I am not saying that there is something bad about current SIP parsing. Just that the more we have users of OpenSER components, the best it is as a whole. And more users mean code looked by more people, which could avoid a possible security issue. Sure, I am talking about security because I work in the field, one can say more people can optimize the thing.
> >> - Maybe replace useless(!) things like memory management, which is >> what most C-written projects do. I think the base library could be Apache >> libAPR [2]. Maybe this is not the best choice, and if you have a >> better idea please let me know. >> > > The reason for the custom memory management is that the system memory manager > don't fulfil the performance requirements of OpenSER in the past. Perhaps > this is now different. The SER people did sometime ago memory performance > tests [1], you'll find also on the mailling list some discussion about this. > I totally agree with this. I think this is also the same reason why you wrote an other SIP parser. It goes with the high performance logic... and that's why I am interested in it now. > I think that the libAPR is also highly optimized, the requirements for an web > server and for an SIP server should be somewhat the same. If we would change > the memory management, i would go with libAPR. > > It would be interesting to know how different is the libAPR memory interface > from the current used is. I don't think that there is much acceptance for an > rewrite of the whole code base just for an different memory manager. > > Actually maybe libAPR will not fulfill OpenSER expectations. This is mostly a matter of having this possibility latter. I guess that's part of an other discussion, once the current OpenSER is libified. _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
