理论上,这也可以看成是互不相连的服务器上执行各自的脚本.由于CPL脚本的构架设计成答应脚本在多重信号服务器上执行,在寻找用户期间,概念上,我们可以把脚本--脚本之间的冲突转变为服务器--服务器之间的冲突,就象下部分中讲的那样,应该尽量减少我们需要面对的冲突种类.
接下来,要解决的问题,就要将脚本正确的进行排序.为了处理这样一种情况,当一个脚本向一个地址传递时,该地址同时有另外一个脚本,顺序是明显的;另外的一些情况就较为敏感了.当起始者和目的地同时有两个脚本,起始者的脚本应该在目的地的脚本执行前执行;这就意味着起始者可以做地址传输,呼叫过滤,等等,在目的地地址和顺序被确定之前.
更为复杂的情况是要确定治理员级的脚本.许多治理员级的脚本,比如,某些限制资源和目的地地址的治理员级脚本,需要在起始者之后执行,在目的地之前执行.这主要是为了防止用户脚本越过治理员级脚本;但是,另外的情况中,比如全球的地址转移功能,就需要或早或晚的执行.答应服务器级脚本运行的服务器就得要治理员来配置,尤其是当脚本执行过程中,非凡的治理员级脚本可能会失败.
9.3服务器--服务器之间的冲突
第三种情况的特征交互性,服务器--服务器之间的冲突,是三种之间最复杂的.这种冲突中,规则的例子如下,就是起始呼叫和继传的冲突:用户(或者是治理员)可能不想让呼叫传到某个非凡的地址,但是当地的脚本可能并没有这项功能,它并不知道呼叫将传往何处,合法的地址将被代理传输给较远的服务器,同样可以传输到一个被禁止的地址.这种类型的问题,即使在治理员级的网络中也不能够解决,就算是较低级别的网络,就象现存的电话网中也不能够解决.CPL还没有声明对它的解决方法,当然这个问题也并非只对CPL脚本产生效应,它对所有研发服务都有害.
服务器--服务器之间的冲突的另外一个类型,被下面的信号协议很好的解决了.因为它们可以升级,不管这个信号服务器是不是被呼叫处理语言或者其他方式控制.举一个例子,就是向前的循环,假设某个地方,用户X想把呼叫继续向前传给用户Y,而Y又会把它传回给X.SIP有一个机制,可以检测这种续传循环.因此,呼叫处理语言服务器根本不需要定义非凡的机制来防止这种情况的发生;但是,还是会引发不同形式的呼叫处理行为,在那里循环被发现,然后就发回一个错误信息给脚本的所有者,通过一些标准的错误回报机制.
9.4信号模糊
补充说明,[8]讨论得出了电话网络中的第四类型的特征冲突,信号模糊.这通常会发生在这样一种时候,当若干个特征过载一个相同操作,在一个从终端出发的有限信号路径,在一个网络中:快速转变(switch--hook)同时意味着两样东西.一个是"增加一个第三方",另外一个是"转向呼叫等待".由于Internet电话协议的信号的外在特性,就象上面讨论的那样,这种情况应该不会发生.
10同现有语言的关系
这篇文档将CPL描述成语言,并不是有意要暗示,一门新的语言就必须要用工具操作.服务器可以操作所有上述功能,就象是现存语言的图书馆或者是扩展;Java以及其他各种脚本语言(TCL,PERL,PYTHON,GUILE).都是明显的可能.
但是,创建一种新语言有很多动机.所有现存语言都是一样的,自然的,完整的;但是有两个天然的缺点.第一个缺点,任何功能的执行,都要花很长的一段时间,使用相当大的记忆库,并且从不能间断.对于呼叫处理,这种资源使用方法是不必要的,就象12.1的描述的那样,实际上是不可信的.相关的模型,电子邮件过滤语言服务[4],有意与图灵机区别.
相似的安全与保护级别(尽管不是自动的,也不能分析),同样可以完成,但是要通过一个"沙盒子"(sandbox),就象java中的Javaapplets.在那里,对一切的要求都很严格,比如存储容量,中心处理器的周期,堆栈空间,等等,只要程序用的到的,都做了规定.这个方法的难点就在于,它从根本上的不透明和不够方便:除非这些级别都严格按照标准,现在有个并不好的消息,就是程序占用的空间成摩尔数量级的增长,因此,用户永远都不能确定到底哪个程序可以在指定的服务器上执行,而不耗光系统资源,并且一个在某台服务器上可以执行的程序,可能到了另一台就不会象想象中的那么好用.不能完整表示的语言,换句话说,就是答应脚本作者与服务器之间有协定:在脚本符合语言规范的同时,服务器一定要保证能够运行脚本.
推荐阅读
- 计算机语言有哪些 计算机语言一共有几种
- 维仕担保代偿后怎么处理
- 吃不完的杨梅怎么处理
- 铺复合地板之前地面要怎么处理
- petl10的处理器多少
- win7系统中出现bonjour服务被禁用具体处理方法
- 牛场粪便处理有招
- 泡完酒的灵芝怎么处理
- 房子漏水找谁投诉处理
- 衣服染色怎么处理