随着IC卡从简单的同步卡发展到异步卡,从简单的EPROM卡发展到内带微处理器的智能卡(又称CPU卡),对IC卡的各种要求越来越高。而卡本身所需要的各种管理工作也越来越复杂,因此就迫切地需要有一种工具来解决这一矛盾,而内部带有微处理器的智能卡的出现,使得这种工具的实现变成了现实。人们利用它内部的微处理器芯片,开发了应用于智能卡内部的各种各样的操作系统。COS的出现不仅大大地改善了智能卡的交互界面,使智能卡的管理变得容易;而且,更为重要的是使智能卡本身向着个人计算机化的方向迈出了一大步,为智能卡的发展开拓了极为广阔的前景。

  COS概述

  COS的全称是Chip Operating System(片内操作系统),它一般是紧紧围绕着它所服务的智能卡的特点而开发的。由于不可避免地受到了智能卡内微处理器芯片的性能及内存容量的影响,因此,COS在很大程度上不同于我们通常所能见到的微机上的操作系统(例如DOS、UNIX等)。

  首先,COS是一个专用系统而不是通用系统。即:一种COS一般都只能应用于特定的某种(或者是某些)智能卡,不同卡内的COS一般是不相同的。因为COS一般都是根据某种智能卡的特点及其应用范围而特定设计开发的,尽管它们在所实际完成的功能上可能大部分都遵循着同一个国际标准。其次,与那些常见的微机上的操作系统相比较而言,COS在本质上更加接近于临控程序、而不是一个通常所谓的真正意义上的操作系统,这一点至少在目前看来仍是如此。因为在当前阶段,COS所需要解决的主要还是对外部的命令如何进行处理、响应的问题,这其中一般并不涉及到共享、并发的管理及处理,而且就智能卡在目前的应用情况而盲,并发和共享的工作也确实是不需要曲。COS在设计时一般都是紧密结合智能卡内存储器分区的情况,按照国际标准(ISO/IEC7816系列标准)中所规定的一些功能进行设计、开发。但是由于目前智能卡的发展速度很快,而国际标准的制定周期相对比较长一些,因而造成了当前的智能卡国际标准还不太完善的情况,据此,许多厂家又各自都对自己开发的COS作了一引起扩充。

  就目前而言,还没有任何一家公司的COS产品能形成一种工业标准。因此本文将主要结合现有的(指l994年以前)国际标准,重点讲述COS的基本原理以及基本功能,在其中适当地列举它们在某些产品中的实现方式作为例子。

  COS的主要功能是控制智能卡同外界的信息交换,管理智能卡内的存储器并在卡内部完成各种命令的处理。其中,与外界进行信息交换是COS最基本的要求。在交换过程中,COS所遵循的信息交换协议目前包括两类:异步字符传输的T=0协议以及异步分组传输的T=l协议。这两种信息交换协议的具体内容和实现机制在IS0/IEC78l6-3和IS0/IEC7816-3A3标准中作了规定;而COS所应完成的管理和控制的基中功能则是在 ISO/IEC78l6-4标准中作出规定的。在该国际标准中,还对智能卡的数据结构以及COS的基本命令集作出了较为详细的说明。至于IS0/IEC78l6-l和2,则是对智能卡的物理参数、外形尺寸作了规定,它们与COS的关系不是很密切。

  COS的体系

  依赖于上一节中所描述的智能卡的硬件环境,可以设计出各种各样的COS。但是,所有的COS都必须能够解决至少三个问题,即:文件操作、鉴别与核实、安全机制。事实上,鉴别与核实和安全机制都属于智能卡的安全体系的范畴之中,所以,智能卡的COS中最重要的两方面就是文件与安全。但再具体地分析一下,则我们实际上可以把从读写设备(即接口设备IFD)发出命令到卡给出响应的一个完整过程划分为四个阶段,也可以说是四个功能模块:传送管理器(TM)、安全管理器(SM)、应用管理器(AM)和文件管理器(FM)。其中,传送管理器用于检查信息是否被正确地传送。这一部分主要和智能卡所采用的通信协议有关;安全管理器主要是对所传送的信息进行安全性的检查或处理,防止非法的窃听或侵入;应用管理器则用于判断所接收的命令执行的可能性;文件管理器通过核实命令的操作权限,最终完成对命令的处理。对于一个具体的COS命令而言,这四个阶段并不一定都是必须具备的,有些阶段可以省略,或者是并人另一阶段中;但一般来说,具备这四个阶段的COS是比较常见的。以下我们将按照这四个阶段对COS进行较为详细的论述。

  在这里需要提起注意的是,智能卡中的“文件”概念与我们通常所说的“文件”是有区别的。尽管智能卡中的文件内存储的也是数据单元或记录,但它们都是与智能卡的具体应用直接相关的。一般而言,一个具体的应用必然要对应于智能卡中的一个文件,因此,智能卡中的文件不存在通常所谓的文件共享的情况。而且,这种文件不仅在逻辑广必须是完整的,在物理组织上也都是连续的。此外,智能卡中的文件尽管也可以拥有文件名,但对文件的标识依靠的是与卡中文件—一对应的文件标识符,而不是文件名。因为智能卡中的文件名是允许重复的,它在本质上只是文件的一种助记符,并不能完全代表整个文件。

  传送管理(Transmission Manager)

  传送管理主要是依据智能卡所使用的信息传输协议,对由读写设备发出的命令进行接收。同时,把对命令的响应按照传输协汉的格式发送出去。由此可见,这一部分主要和智能卡具体使用的通信协议有关,而且,所采用的通信协议越复杂,这一部分实现起来也就越困难、越复杂。

  我们在前面提到过目前智能技术卡采用的住处传输协议一般是T=0协议和T=1协议,如果说这两类协议的COS在实现功能上有什么不同的话,主要就是在传送管理器的实现上有不同。不过,无论是采用T=0协议还T=1协议,智能卡在信息交换时使用的都是异步通信模式;而且由于智能卡的数据端口只有一个,此信息交换也只能采用半双工的方式,即在任一时刻,数据端口上最多只能有一方(智能卡或者读写设备)在发送数据。T=0、T=1协议的不同之处在于它们数据传输的单位和格式不一样,T=0协议以单字节的字符为基本单位,T=1协议则以有一定长度的数据块为传输的基本单位。

  如果传送管理器认为对命令的接收是正确的,那么,它一般是只将接收到的命令的信息部分传到下一功能模块,即安全管理器,而滤掉诸如起始位、停止位之类的附加信息。相应地,当传送管理器在向读写设备发送应答的时候,则应该对每个传送单位加上信息交换协议中所规定的各种必要的附属信息。

  安全体系(Security Structure)

  智能卡的安全体系是智能卡COS中一个极为重要的部分,它涉及到卡的鉴别与核实方式的选择,包括COS在对卡中文件进行访问时的权限控制机制,还关系到卡中信息的保密机制。可以认为,智能卡之所以能够迅速地发展并且流行起来.其中一个重要的原因就在于它能够通过COS的安全体系给用户提供一个较高的安全ttributes)和安全机制(SecurityMachinams) 。其中,安全状态是指智能卡在当前所处的一种状态,这种状态是在智能卡进行完复位应答或者是在它处理完某命令之后得到的。事实上,我们完全可以认为智能卡在整个工作过程中始终都是处在这样或是那样的一种状态之中,安全状态通常可以利用智能卡在当前已经满足条件的集合来表示。安全属性实际上是定义了执行某个命令所需要的…些条件,只有智能卡满足了这些条件,该命令才是可以执行的。因此,如果将智能卡当前所处的安全状态与某个操作的安全属性相比较,那么根据比较的结果就可以很容易地判断出一个命令在当前状态下是否是允许执行的,从而达到了安全控制的目的和安全状态与安全属性相联系的是安全机制。安全机制可以认为是安全状态实现转移所采用的转移方法和手段,通常包括:通行字鉴别,密码鉴别,数据鉴别及数据加密。一种安全状态经过上述的这些手段就可以转移到另一种状态,把这种状态与某个安全属性相比较,如果一致的话,就表明能够执行该属性对应的命令,这就是COS安全体系的基本工作原理。

  从上面对cos安全体系的工作原理的叙述中,我们可以看到,相对于安全属性和安全状态而言,安全机制的实现是安全体系中极为重要的一个方面。没有安全机制,cos就无法进行任何操作。而从上面对安全机制的介绍中,我们可以看到,coS的安全机制所实现的就是如下三个功能:鉴别与核实,数据加密与解密,文件访问的安全控制。因此,我们将在下面对它们分别进行介绍。其中,关于文件访问的安全控制,由于它与文件管理器的联系十分紧密,因此我们把它放到文件系统中加以讨论。

  鉴别与核实:鉴别与核实其实是两个不同的概念,但是由于它们二者在所实现的功能上十分地相似,所以我们同时对它们进行讨论,这样也有利于在比较中掌握这两个概念。

  通常所谓的鉴别(Authentication)指的是对智能卡(或者是读写设备)的合法性的验证,即是如何判定一张智能卡(或读写设备)不是伪造的卡(或读写设备)的问题;而核实(verlfy)是指对智能卡的持有者的合法性的验证,也就是如何判定一个持卡人是经过了合法的授权的问题。由此可见,二者实质都是对合法性的一种验证,就其所完成的功能而言是十分类似的。但是,在具体的实现方式上,由于二者所要验证的对象的不同,所采用的手段也就不尽相同了。具体而言,在实现原理上,核实是通过由用户向智能卡出示仅有他本人才知道的通行字,并由智能卡对该通行字的正确性进行判断来达到验证的目的的。在通行字的传送过程中,有时为了保证不被人窃听还可以对要传送的信息进行加密/解密运算,这一过程通常也称为通行字鉴别。

  鉴别则是通过智能卡和读写设备双方同时对任意一个相同的随机数进行某种相同的加密运算(目前常用DES算法),然后判断双方运算结果的一致性来达到验证的目的。根据所鉴别的对象的不同,COS又把鉴别分为内部鉴别(Internal Authentlcation)和外部鉴别(EXternal Authentication)两类。这里所说的"内部"、"外部"均以智能卡作为参照点,因此,内部鉴别就是读写设备对智能卡的合法性进行的验证;外部签别就是智能卡对读写设备的合法性进行的验证。

  智能卡通过鉴别与核实的方法可以有效地防止伪卡的使用,防止非法用户的入侵,但还无法防止在信息交换过程中可能发生的窃听。因此,在卡与读写设备的通信过程中对重要的数据进行加密就作为反窃听的有效手段提了出来。我们下面仅对加密中的一个重要部件密码在COS中的管理及存储原理加以说明。

  密码管理:目前智能卡中常用的数据加密算法是DES算法。采用DES算法的原因是因为该算法已被证明是一个十分成功的加密算法,而且算法的运算复杂度相对而言也较小,比较适用于智能卡这样运算能力不是很强的情况。 DES算法的密码(或称密钥)长度是64位的。COS把数据加密时要用到的密码组织在一起,以文件的形式储存起来,称为密码文件。最简单的密码文件就是长度为8个字节的记录的集合,其中的每个记录对应着一个DES密码;较为复杂的密码文件的记录中则可能还包含着该记录所对应的密码的各种属性和为了保证每个记录的完整性而附加的校验和信息。其中的记录头部分存储的就是密码的属性信息,例如是可以应用于所有应用文件的密码还是只对应某-应用文件可用的密码;是可以修改的还是只能读取的密码等等。但是,不论是什么样的密码文件,作为一个文件本身,COS都是通过对文件访问的安全控制机制来保证密码文件的安全性的。

  当需要进行数据加密运算时,COS就从密码文件中选取密码加入运算。从密码文件中读出密码时,与读取应用数据一样,只要直接给出密码所在的地址就可以了。当然,最简单的产生密码的方法是直接从密码文件中随机读出一个密码作为加密用密码。但是这样的机制可能会多次选中同一密码,从而给窃听者提供破译的机会,安全性不太高。因此,比较好的办法是在随机抽取出一个密码后再对密码本身作一些处理,尽量减少其重复出现的机会。

  例如PCOS产品中,采用的办法就是对从密码文件中选出的密码首先进行一次DES加密运算,然后将运算结果作为数据加密的密码使用。其计算公式如下:Key=DES(CTC,K(a))式中,K是从密码文件中随机选取的一个密码;CTC是一个记录智能卡的交易次数的计数器,该计数器每完成一次交易就增一;key就是最后要提供给数据加密运算使用的密码。使用这种方法可以提高智能卡的安全性,但却降低了执行的效率。因此,具体采用什么样的方法来产生密码应当根据智能卡的应用范围及安全性要求的高低而具体决定。

  应用管理器(AppIication Manager)

  应用管理器的主要任务在于对智能卡接收的命令的可执行性进行判断。关于如何判断一条命令的可执行性,我们已经在安全体系一节中作了说明,所以我们可以认为,应用管理器的实现主要是智能卡应用软件的安全机制的实现问题。而因为智能卡的各个应用都以文件的形式存在,所以应用管理器的本质就是我们将要在下一节加以讨论的文件访问的安全控制问题。正是基于这一点,我们也可以把应用管理器看作是文件管理器的一个部分。

  文件管理器(File Manager)

  与安全一样,文件也是COS中的一个极为重要的概念。所谓文件,是指关于数据单元或卡中记录的有组织的集合。COS通过给每种应用建立一个对应文件的方法来实现它对各个应用的存储及管理。因此,COS的应用文件中存储的都是与应用程序有关的各种数据或记录。此外,对某些智能卡的COS,可能还包含有对应用文件进行控制的应用控制文件。在CoS中,所有的文件都有一个唯一的文件标识符(Filel Identifier),因此通过文件标识符就可以直接查找所需的文件。此外,每个文件还可以有一个文件名作为助记符,它与文件标识符的不同之处在于它是可以重复的。CoS中的各文件在智能卡的个人化过程中由发行商(Is suer)根据卡的应用而创建,对卡的用户而言通常是不能对文件进行创建或删除的。但是用户可以根据情况对文件内容进行修改,可以对文件中的记录或数据单元进行增加、删除等操作。

  (1) 文件系统:COS的文件按照其所处的逻辑层次可以分为三类; 主文件(Master File),专用文件(Dedicated File) 以及基本文件(Elementary File)。其中,主文件对任何COS都是必不可少的,它是包含有文件控制信息及可分配存储区的唯一文件,其作用相当于是CoS文件系统的根文件,处于COS文件系统的最高层;基本文件也是必不可少的一个部分,它是实际用来存储应用的数据单元或记录的文件,处于文件系统的最底层,而专用文件是可选的,它存储的主要是文件的控制信息、文件的位置、大小等数据信息。我们可以用下图的树状结构来形象地描述一个COS的文件系统的基本结构。

  当然,对于具体的某个COS产品,很可能由于应用的不同,对文件的实际分类表示会有所不同。但只要仔细地进行分析,都可以归结为上面的三个逻辑层次。例如前面提到过的PCOS产品。它对文件的分类不是按照逻辑层次划分的,而是根据文件的用途进行的。它的文件分为三类: COS文件(COS File)、密码文件(Key File)和钱包文件(Purses File)。其中所谓的COS文件保存有基本的应用数据;密码文件存储的是进行数据加密时要用到的密码;钱包文件的作用有些类似 于我们日常生活中的钱包。由此可见,它的这三类文件本质上又都介于基本文件(EF)类。在PCOS中,专用文件的概念不是很明显,但是事实上,如果大家留心的话,那么从以前的论述中,应该不难发现该产品存储器分区中FAT区内的文件的作用就类似于专用文件;而整张PCOS卡本身的性质实际就是一个主文件。COS文件有四种逻辑结构:透明结构,线性定长结构,线性变长结构,定长循环结构。它们的定义及特点可以参阅ISO/IEC78l 6-4协议中的有关部分,这里不再详述。不过无论采取的是什么样的逻辑结构,COS中的文件在 智能卡的存储器中都是物理上连续存放的。卡中数据的存取方式、记录的编号方法、数据单元的大小等作为文件系统的特征,在智能卡的复位应答过程中由卡给出。

  一般而言,在智能卡中最为重要的数据存取方式还是随机存取方式,也就是卡的用户在得到授权后,可以直接地任意访问文件中的某个数据单元或记录。至于COS具体对文件可以进行什么样的操作.我们将在cos的命令系统中进行讨论。

  (2) 文件访问安全:对文件访问的安全性控制是cos系统中的一个十分重要的部分,由于目前的国际标准(1S0/IEC78l 6-4)在这方面基本没有作出什么实质性的规定,因此,现有的文件访问的安全控制机制的具体实现方式多种多样。我们在这里准备介绍其中比较有代表性的两种实现方式:鉴别寄存器方式以及状态机方式。其中,采用鉴别寄存器方式的有PCOS、ME2000等产品:采用状态机方式的产品有STARCOS。采用鉴别寄存器方式时,通常是在内存RAM中设置一个8位(或者是16位)长的区域作为鉴别用寄存器。这里的鉴别是指对安全控制密码的鉴别。鉴别用寄存器所反映的是智能卡在当前所处的安全状态。采用这种方式时,智能卡的每个文件的文件头(或者是文件描述器)中通常都存储有该文件能够被访问的条件,一般是包括读、写两个条件,分别用cr、cu表示这就构成了该文件的安全属性。而用户通过向智能卡输入安全密码.就可以改变卡的安全状态,这一过程我们通常称为出示,这就是鉴别寄存器为主的安全机制。把上面的两方面结合起来,就能够对卡中文件的读写权限加以控制了。具体的操作机制我们以PCOS为例加以描述。

  首先,PCOS中的鉴别寄存器是8位字长的,这8位字长的各位分别与PCOS存储器中保密字区内的7个安全密码的序号一一对应。寄存器中每一位的初始值都被置为"o"。如果用户向智能卡出示了某一个安全密码,并且被判断为正确的话,系统就在鉴别寄存器的相应位上写入"l"。例如,如果处于保密字区中的第2个安全密码被用户正确出示的话,PCoS就在寄存器的第2位上写"l"。同时,文件描述器中的读、写条件Cr、Cu保存的都是在o和7之间的一个数,它的值对应于该文件进行读(或写)操作时所需要出示的密码在保密字区小的序号。在对某个文件进行读(或写)操作之前,系统首先判断在鉴别寄存器内对应的第Cr(或Cu)位是否己被置为"l" (如果Cr等于O,就表示该文件可以被用户随意读取;对于Cu也是一样),只有当该位为"l"时,才表示读(或写)权限已经得到满足.才能对该文件进行读(或写)操作。这也就是说,如果用户想要对一个件进行操作的话,就必须要首先出示对应于该文件的安全属性为正确的安全密码。系统据此就达到了对文件的访问进行安全控制的目的。与鉴别寄存器方式完全不一样,状态机方式更加明显地表示出安全状态、安全属性以及安全机制的概念以及它们之间的关系(关于状态机的知识不属于本文章的范畴,有兴趣的读者请自行查阅有关资料)。以STARCoS为例,它采用的是一种确定状态机的机制,该机制通过系统内的应用控制文件(Application Control File,ACF)而得以实现。ACF是一个线性变长结构的文件,其rh记录0l包括了该ACP所控制的应用可以允许的所有命令的指令码 (INS);其余的记录分别与记录ol中的指令码一一对应,其中存储的都是对应命令的变体(Varient)记录。所谓变体记录指的是这样的一些记录:记录中存储的是控制信息、初始状态、可能的下一状态以及某些附加的指令信息的组合,利用ACF中的这些变体记录就可以形成状态转移图。在变体记录中,控制信息部分是必不可少的。不同的变体记录主要在两个方面有区别:一是命令所允许的状态不同,二是以CLA字节开始的指令信息部分不相同。这主要是由命令要操作的应用的对象不同而决定的。

  利用ACF,COS系统就可以实现对文件访问的安全控制了。当系统接收到一个应用进行操作的一条命令后,首先检验其指令码是否在相应的ACF文件的记录01中。如果不在其中,系统就认为该命令是错误的。在找到了对应的指令码后,系统把命令的其余部分与该命令对应的备变体记录中的指令信息按照该变体记录的控制信息的要求进行比较,如果比较结果一致,那么再查验变体记录中的初始状态信息。若所有这些检测都顺利通过,那么系统就进入对应变体记录中指明的下一状态;否则,继续查找下一个变体记录直到发现相应变体或是查完该命令对应的所有变体记录为止。如果没有找到相应的变体记录,说明该命令是非法的;否则就进入下一步对命令的处理,即由COS调用实际的处理过程执行对命令的处理。并且仅当处理过程正常结束的时候,系统才进入一个新的状态,并开始等待对下一条命令的接收。

  摘自《金卡工程》2003年第2期

转自:http://www.williamlong.info/archives/1857.html

智能卡操作系统COS概述的更多相关文章

  1. 嵌入式实时操作系统μCOS原理与实践任务控制与时间的解析

    /*************************************************************************************************** ...

  2. 卡内操作系统COS

    https://wenku.baidu.com/view/dbaa94916bec0975f465e2e8.html 智能卡与cos技术简析: http://www.360doc.com/conten ...

  3. 嵌入式实时操作系统μCOS原理与实践+事件部分代码

    //事件等待表的初始化函数:pevent表示事件控制块的指针#if (OS_EVENT_EN)void  OS_EventWaitListInit (OS_EVENT *pevent){    INT ...

  4.  Link 

    GNU/Linux, Bash, C, PHP, Perl, JavaScript, Vim, Git http://blog.sanctum.geek.nz/about   中文數學詞典 http: ...

  5. PBOC

    http://blog.sina.com.cn/s/blog_64cc82620100rcgu.html 最近在做一个基于PBOC电子现金卡的终端应用, 项目还没有完成, 但电子现金部分的处理模块已完 ...

  6. 智能卡安全机制比较系列(六) TimeCOS

    TimeCOS是握奇公司推出的智能卡操作系统,也可以说是国内早期自己开发的为数不多的几款COS之一.当然随着后来国内公司对于CPU卡开发的投入,其他公司的COS产品也纷纷推出. 其实从握奇的TimeC ...

  7. 智能卡安全机制比较系列(一)CardOS

    自从智能卡开始进入人们的日常生活之后,大家对于智能卡的安全性普遍看好,但是不同公司的智能卡在安全机制的实现方面也存在很多的差异.对于智能卡应用开发和智能卡COS设计人员来说,如果能够更多地了解不同公司 ...

  8. 智能卡安全机制比较系列(五) StarCOS

    StarCOS是捷德公司的推出的智能卡COS,和前面说过的几种COS不同的是,国内的用户对于StartCOS可以说非常熟悉,而且因为握奇.明华.天喻等公司的安全机制都基本上是脱胎于StarCOS,所以 ...

  9. 智能卡安全机制比较系列(三) MPCOS

    MPCOS是金普斯早期推出的一款多应用支付芯片卡操作系统,支持ISO7816以及PCOS的数据格式和命令.MPCOS具有两级目录文件结构,即MF下可以有一级DF,每个DF下最多可创建63个EF. MP ...

随机推荐

  1. 想要打动HR的心,UX设计师求职信究竟应该怎么写?

    在努力准备申请一份UX设计师职位时,你最烦心和担忧的事哪一个环节?是写一份UX设计师简历?回答面试官的问题?还是在一遍遍的煎熬中等待一个面试电话?是的,这些都是不轻松的事儿,但还有一个同样糟心的事,那 ...

  2. dwr 框架 ,实现 ajax 的java 框架

    1. 引入 dwr.jar 包 2. 配置web.xml 文件 ,拦截请求 <servlet> <servlet-name>dwr-invoker</servlet-na ...

  3. cnn 反向bp这个地方怎么推导??

  4. Monte carlo

    转载 http://blog.sciencenet.cn/blog-324394-292355.html 蒙特卡罗(Monte Carlo)方法,也称为计算机随机模拟方法,是一种基于"随机数 ...

  5. cucumber安装可能发生的错误

    1.--ignore-certification-errors 解决:可能是你的chromedriver版本与ruby版本不匹配,换一个版本 2.找不到文件,certification verify ...

  6. 【转载】不得不知道的Python字符串编码相关的知识

    原文地址:http://www.cnblogs.com/Xjng/p/5093905.html 开发经常会遇到各种字符串编码的问题,例如报错SyntaxError: Non-ASCII charact ...

  7. Google Maps 基础

    创建一个简单的 Google 地图 现在让我们创建一个简单的 Google 地图. 以下是显示了英国伦敦的 Google 地图: <!DOCTYPE html> <html> ...

  8. OpenGL中的帧缓存

    OpenGL中的帧缓存 在OpenGL窗口中, 左下角的像素为(0, 0). 一般而言, 像素(x, y)占据的矩形区域左下角为(x, y), 右上角为(x+1, y+1). 1. 缓存及其用途 [1 ...

  9. DagScheduler 和 TaskScheduler

    DagScheduler 和 TaskScheduler 的任务交接 spark 调度器分为两个部分, 一个是 DagScheduler, 一个是 TaskScheduler, DagSchedule ...

  10. leanCloud 笔记

    目的:javascript实时通讯.感觉:nodejs的socket.io加了一个图形界面和接口,它保证了所有环境下的实时通信. 最新版leancloud支持的服务:实时消息推送,实时点对点消息服务. ...