[OpenSIPS-Devel] RFC: new opensips design

[Bogdan-Andrei Iancu]

Hi Emmanuel,

Just to be clear - is not about embedding a language into the core - the 
idea is to have standalone applications running in other languages (like 
python, perl, JAVA, etc) and just to take routing decission, decision to 
be passed back to opensips core. So opensips and the routing script will 
be in different parallel applications - this will allow to change the 
routing logic without restating opensips, as you will restart only the 
routing application and not opensips itself.

Regards,
bogdan

Emmanuel BUU wrote:
> Well,
>
> Stefan Sayer a écrit :
>> completely async processing with only _one_ thread would make the 
>> simplest design, and context isolation unnecessary (thus 
>> inter-message/inter-transaction/inter-dialog/... processing would 
>> become simple to implement) - and then python would be a possible 
>> candidate.
>>
>> Stefan
>>   
> Yes but how would you:
>
>    * prevent python blocking operation
>    * make the whole thing crash resilient ?
>
> About python, it seems to be lighwheght enough to be embedded in such 
> a router and I like the idea that code can be precompiled in bytecode 
> and loaded in memory for fast execution.
> But : it is VERY important that we keep the same access to each part 
> of the message DIRECTLY as in the the current scripting language. The 
> current language is somtimes cubersome but bears
> a very interesting idea, of what I call message level scripting.  That 
> is key and one should consider message not a s a big string to mo 
> modified but rather as a structured object with properties that can be 
> modified.
>
> ex: msg.from.uri
>
> I feel that embedding a general purpose language at the core may 
> distract the openSIPS user from its core mission, to be a fast SIP 
> service execution environment. If such a language has to be embedded, 
> some enforcement of SIP transaction / state machine / dialog has to be 
> added to safeguard the script writing somehow. The other issue is that 
> for now, OpenSIPS offers a restricted set of primitives (extendable 
> trhough C modules) to process SIP traffic but by using correctly 
> those, you are more or less garanteed to have exellent performances. 
> Usually, when you had a complicated processing to perform, you had to 
> basically call an outside application server. That could be done with 
> SEAS, PERL or even by simply forwarding the SIP message to a Java SIP 
> Servlet. With a full general purpose environment such as python, one 
> could be tempted to bring the app server INSIDE the SIP proxy. Is that 
> what we want ? Is it consistent with the aim of better performances?
>
> The idea is however certainly interesting. Maybe to create a python 
> environment with a kind of restricted sandbox.
>
>
> Emmanuel
>
> http://www.ives.fr/
>> o Bogdan-Andrei Iancu [11/07/08 17:32]:
>>  
>>> And one more thing - of course you process more. Note that not all 
>>> the traffic will require much I/o interaction (rather then reading 
>>> and putting back on the network) - it is 100% CPU using traffic 
>>> (like sequential request - ACK for examples). Such traffic will 
>>> perfectly use the idle time from messages that are stuck in I/O 
>>> (DNS, DB).
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Bogdan-Andrei Iancu wrote:
>>>    
>>>> Hi Stefan,
>>>>
>>>> You do not create additional threads or processes - you just use 
>>>> the time you waist right now in synchronous I/O ops for processing 
>>>> other messages by doing context switching.
>>>>
>>>> So  DOS attack is not possible - at least not on this scenario :)
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> Stefan Sayer wrote:
>>>>  
>>>>      
>>>>> o Bogdan-Andrei Iancu [11/07/08 16:46]:
>>>>>           
>>>>>> So, i the same amount of time, you use all the time for computing 
>>>>>> instead of idle I/O and you can process more traffic.
>>>>>>                 
>>>>> i doubt you can process more traffic - but you can use all your 
>>>>> threads/processes efficiently, and do neither have to create too 
>>>>> many threads, not have all threads blocked, e.g. on some DOS attacks.
>>>>>
>>>>> Stefan
>>>>>
>>>>>             
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>>
>>>>         
>>
>>   
>
>
>