[OpenSIPS-Devel] RFC: new opensips design

[Stefan Sayer]

o Emmanuel BUU [11/07/08 19:50]:
> 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
that is up to the python script writer. of course there needs to be
support for async db/rpc/io, and it needs to be documented (i.e.
receipes, and DOs/DONTs). its obviously easier to break, but this is the
responsibility of the user.

>    * make the whole thing crash resilient ?
replicate the context, either as a whole or in groups of
transactions/dialogs (those who might interact).

> 
> 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
getters and setters for objects' properties in python can be implemented
in c with pretty fine grained control. whether below is a parser on full
string, accessor to parsed structure, lump, or whatever, does not
necessarily matter on python acstraction level.

> 
> 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 
did you have to? you could also place this in the ser process, if you
are comfortable with c, and with linking with the core.

> 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?
its maybe not a good analogy, but for voip applications which involve
media, our experience is that it is _way_ simpler to integrate
application and media server into the same server (/software/process).
separating application from media server, e.g. by using java SIP servlet
+ media server, creates so much more complexity even for very simple
services. additionally, HA designs are much more complicated, up to that
extend that my guess would be to get more availability without.

for me the question is not whether it is bringing app server into proxy,
but whether *ser makes a good basis for an app server. and this depends 
mostly on
  - api/language/programmability
  - processing paradigm
  - performance of transaction or dialog handling (depending on what is
used)

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

-- 
Stefan Sayer
VoIP Services

stefan.sayer at iptego.com
www.iptego.com

IPTEGO GmbH
Am Borsigturm 40
13507 Berlin
Germany

Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann