[OpenSIPS-Devel] RFC: new opensips design

Emmanuel BUU emmanuel.buu at ives.fr
Fri Nov 7 19:50:14 CET 2008


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
>>>
>>>   
>>>       
>
>   





More information about the Devel mailing list