分发管理系统范文（精选11篇）
分发管理系统 第1篇
关键词：数据分发服务,非关系型数据库,发布/订阅,船舶信息系统
0 引言
船舶信息系统是利用计算机、通信、网络、自动控制等技术, 将相对独立的各个分系统纳入到统一的信息网络中, 实现信息集成, 集监测、控制、管理于一体的网络化、信息化综合系统[1 - 3]。由于船舶平台的各分系统采用不同的监控技术、通信标准和来自不同的制造商的监控设备, 给平台综合管理系统的信息集成设计带来了巨大的困难。而且随着实时性的需求越来越高, 在信息集成的同时, 必须保证各个子系统之间数据实时交互。目前, 船舶信息系统采用的客户机/服务器模型 ( 如CORBA[4]) 和消息队列模型 ( 如JMS[5]) 等模型虽然可以实现系统内部之间的互连、互通和互操作, 但针对船舶信息系统中越来越高的实时性应用需求, 仍存在通信的实时性、快捷性和灵活性问题。为了满足分布式实时应用的通信需求, 对象管理组OMG公布了全球第一个用于发布/订阅[6，7]数据分发服务DDS[8 - 10]的新规范。DDS为各种不同类型的分布式应用提供了数据通信模型, 能促使数据实时、高效地分发。
同时日益复杂的船舶信息系统, 伴随着通信分系统的扩充、通信节点的增加, 通信数据量日益加剧, 历史数据量成爆炸性趋势增加, 这些数据资源对存储系统的存储空间、存储可靠性、数据访问性能等方面的要求越来越高。目前, 船舶信息系统主要采用关系型数据库 ( 如SQL Server、DB2、Oracle等) , 随着数据爆炸性的增长, 这些传统的基于关系型的数据库的存储系统己经远远不能满足船舶网络综合信息系统对数据存储和管理的需求, 因此, 非关系型的数据库No SQL[11 - 13]现在成了一个极其热门的新领域, 发展非常迅速。
针对船舶系统集成中通信的实时、高效性问题和海量历史存储问题, 本文在对DDS进行深入分析和研究的基础上, 设计了以数据为中心的船舶信息系统数据分发服务模型, 并结合No SQL数据存储, 提出一种海量历史数据的存储、管理方法。最后搭建了平台仿真系统实现了基于DDS的船舶信息数据分发系统及其存储方案, 满足了信息集成系统的通信实时、高效性需求和海量历史数据的有效存储、高效查询。
1 基于Open DDS的船舶信息系统数据分发
1. 1 船舶信息系统数据分发服务
通过深入分析OMG发布的数据分发服务 ( DDS) 规范, 以开源Open DDS[14]产品为基础, 对其进行优化和封装后, 设计了一种以数据为中心的适合船舶信息系统的分布式实时通信的数据分发服务模型, 满足船舶信息系统的数据分发需求, 将采用不同监控技术、通信标准和来自不同制造商的监控设备的船舶分系统 ( 如航行、电站、损管、推进) 集成起来, 并实现了数据的高效、实时分发。
Open DDS中以数据为中心的发布/ 订阅模型构建了一个共享的全局数据空间的概念, 负责完成数据的发布、订阅, 以及相关服务质量的控制保证等。任何对该空间中的数据感兴趣的应用程序都可以通过接口接入: 向这个数据空间提供信息的应用程序通过声明意图可成为“发布者”, 从数据空间中获取数据的应用程序通过声明订阅意图和感兴趣主题成为“订阅者”。每当发布者将新数据发送到全局数据空间, 全局数据空间就会将感兴趣的订阅者与之进行关联, 把信息传送给所有感兴趣的订阅者。
船舶信息系统数据分发模型如图1 所示。船舶信息系统中节点的角色主要分为3 部分: ( 1) 发布各个分系统数据的数据源节点; ( 2) 订阅各个分系统数据的订阅节点; ( 3) 管理数据交互的监测节点。一个节点也可以起到3 个角色的作用, 即可以在发布、订阅数据的同时监测交互过程。根据角色需求, 数据分发服务中间件主要提供3 种接口: 发布接口、订阅接口和监测接口。
负责发布数据的船舶应用程序即数据发布者, 为不同分系统的数据构建主题, 然后通过发布接口建立实体对象将数据推入数据分发服务中间件中; 负责订阅数据的船舶应用程序即数据订阅者, 通过订阅接口建立实体对象, 到数据分发服务中间件中订阅感兴趣的主题; 负责监测交互过程的节点, 直接到数据分发服务中间件中订阅内置的主题, 当有主题、数据发布者、数据订阅者等通信实体进入数据分发服务中间件时, 监测节点就可以监听到消息、获得交互信息。
1. 2 船舶分系统数据发布和订阅流程
在上述构建的船舶信息系统中, 各个分系统的数据发布和订阅的流程如图2 所示。数据分发服务中间件的数据模型由“主题 ( Topic) ”和“类型 ( Data Type) ”标识。“主题”是惟一标志某种数据的标志符。“类型”则提供了中间件如何操纵这些数据所需的结构信息, 同时也允许中间件提供一定的类型保护措施。发布数据的应用需要注册声明为“发布者”, 注册时需要声明其发布的数据类型、主题号, 以及提供的服务质量 ( Qo S) , 然后针对每个数据类型创建相应的数据写入者, 将数据推送到中间件中。类似的, 获取数据的应用则注册声明成为一个“订阅者”, 注册时需要描述其需要的数据类型、主题号、以及要求的服务质量, 然后针对每个数据类型创建相应的数据读取者来获取数据。中间件根据双方的数据类型、主题号以及服务质量来进行关联, 若匹配则建立数据链路, 这样每次发布者将新的数据对象推送到中间件, 中间件将把数据正确地分发给所有的订阅者。
具体步骤如下所示: ( 1) 发布者在数据分发服务中间件上注册数据类型; ( 2) 返回; ( 3) 发布者通知数据分发服务中间件生成主题, 数据分发服务中间件根据数据类型定义主题并设置服务质量; ( 4) 返回; ( 5) 发布者根据数据类型创建相应的数据写入者 ( Data Writer) , 每个数据写入者只专注于应用程序的一种数据类型; ( 6) 返回; ( 7) 订阅者向中间件发出请求, 直接声明感兴趣的主题或在中间件中查找; ( 8) 返回; ( 9) 订阅者根据数据类型创建相应的数据读取者 ( DataReader) , 每个数据读取者只专注于应用程序的一种数据类型; ( 10) 返回; ( 11) 订阅者订阅主题, 中间件保存订阅信息; ( 12) 返回; ( 13) 中间件根据发布和订阅同一主题的双方的Qo S进行关联: 如果发布者提供的Qo S满足订阅者要求的Qo S, 匹配成功, 进入下一步; 否则不进行数据传递过程; ( 14) 关联的发布者和订阅者之间直接进行数据发布和传递。
1. 3 数据分发服务的通信过程监测
在数据分发服务的通信过程中, 发布者和订阅者是以通信实体的形式参与, 并且每个实体都有相应的Qo S绑定。这些通信实体包括: 主题 ( Topic) 、参与者 ( Participant) 、发布者 ( Publisher) 、订阅者 ( Subscriber) 、数据写入者 ( Data Writer) 和数据读取者 ( Data Writer) 。为了实时监控通信过程中实体的状态及其变化, 基于开源Open DDS在全局数据空间中封装了监控接口, 对通信实体及其交互关系、状态进行实时监测。对于每种通信实体, 数据分发服务中间都有相应的内置主题, 具体如下:
Built In Topic_Topic: 主题的内置主题, 发布或订阅的数据的标志符。
Built In Topic_Participant: 参与者的内置主题, 发布者和订阅者都是以参与者实体进行通信。
Built In Topic_Publisher: 发布者的内置主题, 发布者是一个负责分发数据的对象, 它可以发布不同类型的数据。
Built In Topic_Data Writer: 数据写入者的内置主题, 数据写入者是发布者的一个类型化的接入者。
Built In Topic_Subscriber: 订阅者的内置主题, 订阅者是负责接收已发布的数据并使接收方的应用程序能够获得此数据, 它可以接收并分派不同类型的数据。
Built In Topic_DataReader: 数据读取者的内置主题, 数据读取者是订阅者的一个类型化的读取者。
负责监测的应用直接订阅这些内置主题, 订阅流程同普通主题的订阅流程。每当有参与者、主题、发布者、订阅者、数据写入者或数据读取者进入船舶分发服务中间件时, 订阅这些内置主题的订阅者会收到相应通信实体的实体信息数据及相应的服务质量, 如果是发布者/订阅者, 则可以收到与其关联的订阅者/发布者信息。
2 海量历史数据的存储设计
为了将订阅到的数据进行数据持久化以保留历史数据以待查询、分析, 针对订阅的历史数据随着时间推移以爆炸性的趋势增长, 设计关系型数据库 ( RDB) 和非关系型数据库 ( No SQL) 相结合的混合分布式存储架构Hybrid DB: 当日的数据存储在传统的关系型数据库中, 以便快速查询; 历史数据存储在非关系型数据库中, 便于海量数据的持久保存、高效查询, 以及系统和数据的易扩展。存储系统的设计如图3 所示。
应用程序查询数据时, 具体查询步骤如下所示:
( 1) 用户的查询首先被传到查询引擎模块, 查询引擎对查询语句进行时间解析: 如是当日日期, 进入关系型数据库查询;如是历史信息, 进入非关系型数据库查询。
( 2) 查询引擎解析完后, 调用存储服务与数据库进行查询交互, 获取数据, 返回给用户。
Hybrid DB包含传统的数据库服务: 日志服务、事物服务和缓存服务, 并且包含数据拷贝模块。数据拷贝模块负责历史数据的拷贝加载工作, 即定期将关系型数据库中的数据加载到非关系型数据库中。为了提高海量数据的加载效率和性能, 数据拷贝模块采用分布式MapReduce算法。MapReduce算法的计算框架和逻辑如图4 所示。MapReduce算法是一个框架模型, 主要是通过简单的接口来实现自动的并行化和大规模的分布式计算, 通过使用MapReduce模型接口实现在大量普通的PC机上高性能计算。计算过程由称为Map和Reduce两部分用户程序组成, 然后利用框架在计算机集群上面根据需求运行多个程序实例来处理各个子任务, 然后再对结果进行归并。当调用MapReduce函数, 具体计算过程如下所示。
( 1) 用户程序首先调用MapReduce库将输入的RDB存储分成M个数据片度, 然后用户程序在机群中创建大量的程序副本。
( 2) 这些程序副本中有一个特殊的程序: 主程序。副本中其它的程序都是工作进程 ( 运行在工作机上) , 由主程序分配任务。有M个Map任务和R个Reduce任务将被分配, 主程序将一个Map任务或Reduce任务分配给一个工作进程。
( 3) 被分配了Map任务的工作进程将读取RDB存储片度的数据, 从输入的数据片段中解析出key/value对, 然后把key/value对传递给定义的Map函数, 由Map函数生成并输出中间key / value对, 并存储在本地磁盘中的中间文件中。
( 4) 中间文件在本地磁盘的存储位置被传递回主程序, 主程序负责把这些存储位置传送给Reduce工作进程。
( 5) 当Reduce进程收到这些存储位置信息后, 使用RPC从Map进程所在的磁盘上读取这些数据。当Reduce进程读取了所有的中间数据后, 通过对key进行排序后使得具有相同key值的数据聚合在一起。
( 6) Reduce进程遍历排序后的中间数据, 对于每一个唯一的中间key值, Reduce进程将这个key值和它相关的中间value值的集合传递给Reduce函数。Reduce函数的输出被追加到所属分区的No SQL存储片区中。
3 系统仿真实现验证
为了验证DDS技术和分布式存储技术在船舶信息系统上的应用可行性, 本文以船舶信息系统中的电力分系统、损管分系统、船桥分系统和舰长终端系统为例, 搭建了一套基于DDS和分布式存储的船舶信息仿真系统。系统仿真实现如图5 所示。
“数据源模拟-发布”是船舶信息系统的数据发布方。驾驶数据通过仿真控制台上的驾驶模拟器硬件设备模拟产生, 电力分系统、损管分系统和船桥分系统中的数据通过程序模拟产生。应用程序采集、解析模拟的数据, 为不同数据构建相应主题, 将数据发送到数据分发服务中间件中。
“数据显示-订阅”是船舶信息系统的数据订阅者。他们依角色登录, 订购各自感兴趣的数据。航行观测终端只订阅航行数据; 雷达观测终端只订阅雷达数据; 综合船桥终端订阅船桥分系统发布的所有设备数据, 包括GPS、测深仪、电罗经、计程仪和风速风向仪设备的数据; 损管观测终端订阅损管分系统发布的所有设备数据, 包括吃水、综合消防、火警探测设备的数据。其中舰长终端可以灵活地订阅各个分系统的数据, 对全部数据进行监测和统计。
“数据分发管理中心”监控发布方和订阅方的参与实体及其状态变化。包括主题、发布者、订阅者实体及其服务质量信息, 以及发布者和订阅者的匹配关系。
“数据存储管理”负责实时数据和历史数据的存储和管理, 当日的数据存储到关系型数据库中, 历史数据存储到非关系型数据库中。这里的关系型数据库采用SQL Server, 非关系型数据库采用Mongo DB, 是由5 台虚拟机组成的机群进行存储和管理的。每日的23: 00 将当日的数据从SQL Server导入到Mongo DB中。
利用上述的数据分发服务平台和混合存储数据库方案, 实现了船舶信息系统的集成, 各个系统之间能够灵活的通过发布/订阅进行数据分发, 消除了系统之间的紧密耦合性; 实现了海量历史数据的持久存储、高效查询, 以及数据存储系统的易扩展。
4 结语
教学用书分发方案 第2篇
按照网上教学实际需要，更好的帮助学生们的学习，我校计划分发下学期教学用书，具体安排如下：
1.3月30日下午，由图书管理员老师按照年级分发教学用书，按初二年级、初一年级顺序，各班主任领取本班教学用书，核对好人数。
2.3月31日，初二班主任通知本班学生家长来学校领取；4月1日，初一班主任通知本班学生家长来学校领取。
3.具体要求：
（1）学生家长先在学校大门口排成一人排，保持一米间隔依次入校。
（2）先亮健康码，测体温，体温合格的，再过消毒通道到各自班级教室领书。
（3）家长必须戴口罩，不准聚集、喧闹，听从工作人员的指挥，领完后迅速离校。
（4）各班严格按照时间节点，不能按时到校的家长请与班主任联系。
日期 | 年级 | 班级 | 到校时间 | ||
3.31上午 | 初二 | 1班 | 上午8：00入校 | 9：00结束 | |
2班 | 上午9：00入校 | 10：00结束 | |||
3班 | 上午10：00入校 | 11：00结束 | |||
4班 | 上午11：00 | 12：00结束 | |||
3.31下午 | 5班 | 下午2：00 | 3：00结束 | ||
6班 | 下午3：00 | 4：00结束 | |||
7班 | 下午4：00 | 5：00结束 | |||
8班 | 下午5：00 | 6：00结束 |
日期 | 年级 | 班级 | 到校时间 | ||
4.1上午 | 初一 | 1班 | 上午8：00入校 | 9：00结束 | |
2班 | 上午9：00入校 | 10：00结束 | |||
3班 | 上午10：00入校 | 11：00结束 | |||
4班 | 上午11：00 | 12：00结束 | |||
4.1下午 | 5班 | 下午2：00 | 3：00结束 | ||
6班 | 下午3：00 | 4：00结束 | |||
7班 | 下午4：00 | 5：00结束 | |||
8班 | 下午5：00 | 6：00结束 |
***第二中学
分发管理系统 第3篇
关键词：无证书；认证；密钥分发；服务系统
中图分类号：TP311.52文献标识码：A文章编号：1007-9599 (2011) 06-0000-02
The Key Distribution Service System Based on the No Certificate Signature Verification Kong Xueyuan,Wang Tao,Peng Haiping,Li Tong (Computer School of Wuhan University,Wuhan430072,China)
Abstract:In order to solve problems in the traditional public key cryptography system and authentication password system,some scholars have put forward no certificate signature verification algorithm.In recent years,through the continuous improvement,the algorithm has been shown to be safe and effective in theory.However,in practical application,there is still no substantial development in no signature verification certificate.In the traditional public key cryptography system,the process of user registration and certification issue is very cumbersome.In this case,we put forward a plan of designing a authentication key distribution service system based on no certificate.The service system is easy to use and safe.
Keywords:No certificate;Certification;Key distribution;Service system
一、引言
传统公钥密码体系，需要权威的认证中心（Certficate Aauthority，CA）签发用户的公钥证书，而在实际应用中，证书的注册、存储、发布、验证等过程复杂且代价高。同时，CA不可信时，公钥被替换而不能发现，公钥的真实性和完整性受到危害。为此，Shamir等人提出了基于身份的密码体系。用户使用能唯一代表他身份的一个公开信息（如身份证号）作为公钥，用户公钥不需要认证，但是在该系统中，密钥完全由可信的密钥产生中心（Key Generation Centre，KGC）托管，存在着密钥托管问题，要求KGC积极且诚实。为了解决基于传统公钥体系的证书认证、公钥证书的管理耗费问题和身份密码体系的密钥托管问题，AL-Riyasni首次提出了无证书公钥密码体系。在该体系中，用户私钥由KGC和用户共同产生。KGC不能获取用户的私钥。无证书密码体系提出以来，很多学者对其进行了深入的研究探讨，逐渐完善，安全性越来越高。
目前，在实际生活中广泛应用的仍是基于传统公钥密码体系建立的公开密钥基础设施PKI。对大部分并不需要经常进行安全通信的用户来说，注册证书麻烦且低效。而且，由于传统公钥密码体系的局限性，PKI存在着公钥认证的问题。无证书认证的密钥分发服务系统有效的解决了PKI存在的安全性问题。同时，无证书认证的密钥分发服务系统使用简单、高效，无须颁发证书，对于安全通信的普及有着重要意义。
二、无证书签名认证机制
KGC为密钥生成中心，是一个半可信的第三方实体，其主要任务是利用其掌握的系统主密钥辅助用户生成签名公私钥，并且发布其对应的系统公共参数，使得用户能够利用用户ID和系统公共参数进行有效地签名认证。用户根据KGC发布的参数和自己保存的秘密值生成签名公私钥。无证书签名认证机制的基本模型如下：
初始化：KGC输入一个安全参数I，执行算法输出系统主密钥msk、对应的系统主公钥mpk、公开的系统公共参数params。Msk由KGC秘密保存。交互过程：
（1）用户A产生随机秘密值a，RA=f（a）即RA是由a推导出来的，但是不能由RA推出a，将RA，IDA发送给KGC。
（2）KGC验证用户A的合法性，如果验证不通过，KGC放弃此次交互，若验证通过，KGC经过计算得出用户A的部分公私钥，并将其发送给用户A。
（3）用户A接收到部分公私钥后，首先进行验证，验证通过后，计算生成签名公私钥，否则放弃此次交互。
（4）用户B的签名公私钥生成过程与用户A相同。
（5）A利用自己的秘密值生成密钥分配公开参数mA，然后A用自己的公私钥对mA进行签名得到sigA。并将mA和sigA传输给用户B。
（6）用户B首先利用sigA对mA进行验证，然后计算相关等式是否成立。若成立，验证通过，否则放弃此次交互。用户B发信息M给A时，利用A的密钥分配公开参数mA加密消息M得到密文M1，然后B利用自己的签名公私钥对M1签名得到sigM1，将M1，sigM1发送给A。
（7）用户A利用与（6）相同方案认证用户B身份。若认证通，用自己的秘密值a，解密出M1。否则放弃此次交互。
三、系统总体设计
（一）系统体系结构
基于无证书签名认证服务系统采用层次性体系结构进行设计。总体分为：客服端层、服务器层、数据库层。
客服端层通过浏览器显示用户注册、登陆、操作请求的一系列界面。在该服务系统中，密钥的生成中心KGC，由用户组内的核心用户（有公信力的领导者）充当。因此，在基于无证书签名认证服务系统中，根据用户的身份返回用户不同的客服端：KGC与普通客服端。KGC具有动态充当服务器的功能，接受组内普通用户的连接请求，保存系统参数，辅助普通客服端生成签名公私钥。
服务器层负责接收客服端层的各种请求，依据用户的请求进行分析、查询数据库并返回用户相应信息，同时，为系统中的普通用户与组内KGC之间建立连接提供必要的信息如KGC当前登录的IP地址、开放的端口port等。
数据库层则存储注册系统用户的个人信息和消息记录。用户的个人信息包括：组号、ID号、组内身份（KGC、普通用户）等。消息记录包括：收信人ID号、发信人ID、待接收消息等。
（二）系统的功能模块
系统主要分为两大功能模块：一是密钥的分发，二是密钥的共享。
1.密钥的分发。用户要使用基于无证书认证的密钥分发服务系统时，首先要进行注册。注册内容包含：组号、ID号、组内身份（KGC、普通用户）等个人信息。
密钥分发模块可实现的功能主要是组内的的普通用户与组内KGC建立直接（KGC在线）或间接（KGC离线）的连接后，按照上文提出的无证书签名认证协议进行交互生成签名公私钥。同时，将生成的签名公私钥保存在本地。
2.密钥的共享。密钥分发模块生成的签名公私钥并不是用来直接进行数据加密传输使用的，这是因为相比对称密钥机制而言非对称密钥机制效率很低。一般用这一对公私钥进行对称密钥的传输，传输成功后，发信人用双方共享的对称密钥加密数据发送给收信人，收信人用双方的共享密钥解密数据，这样就实现了数据加密传输。
密钥共享的功能是组内用户之间利用密钥分发模块获取的签名公私钥，实现相互间的签名认证，并且将需要共享的密钥安全的发送给指定的用户。具体流程参照第2部分的（5）-（7）。
四、系统应用及动态维护
某一个用户群体要实现秘密通信，完成密钥的分发，应先拟定一个公共的组名。群体成员注册时，填写拟定的组名标识，用户ID及相关的个人信息然后选择用户身份即可完成注册，建立起了一个可信域。用户注册时也可不提供组名，这样的用户将被划分为无分组用户，以后登录系统时可再加入已经建立起来的分组中。
KGC具有添加和删除组成员的功能，添加用户时输入用户ID，向服务器发出添加请求，KGC组号为H、用户标识为ID，若该用户已有其他分组，把（H，ID，身份）insert到数据库。若该用户无分组，改该用户组号项为H，更新数据库。删除成员时，选中删除的成员ID，向服务器提出请求删除用户请求。若该用户有其他分组，删除组号为H的数据行，若用户无其他分组则将组号改为空，表示此用户目前无分组。当然，普通用户也可以申请加入某个小组、或者退出群组具体实现方法与上文类似，在此不赘述。
五、总结
从安全性方面来讲，基于无证书认证的服务系统，密钥由用户选中的秘密值S和KGC产生的部分公私钥共同生成。第三方实体没有完全掌握用户的公私钥，对第三方实体的要求降低，KGC不需要完全可信。文献[1]具体阐明了该方案对于外部攻击者、一般的内部攻击者、与KGC的合谋攻击、恶意KGC自身都具有很强的抵抗力。
同时，该服务系统具有很强的实用性。对普通用户来说申请颁发证书十分的麻烦，然而目前基本上没有密钥分发的服务系统可以为普通用户之间实现隐秘通信提供支撑。因此，该服务系统的实现很有必要性。而且，通常用户的合法性由第三方来验证如服务器，这种情况下大大增加了用户身份信息验证通过的繁琐性。在该服务系统中，组内内部成员直接担当KGC，身份认证简单而高效，也增强了安全性，因为服务器不保存系统相关参数。
当然，该系统仍然存在着很多不足之处，在以后的发展中需要不断的完善。
参考文献：
[1]程芳权.可信数据库环境下无证书认证的可信密钥共享[J].计算机科学与探索,2010,9:0791-0801
[2]张建中.高效无证书签名方案的分析与改进[J].计算机工程,2010,11:0128-013
[3]洪东招.有效的无证书签名方案[J].计算机应用,2010,7:1809-1811
分发管理系统 第4篇
该文基于现有的Bit Torrent系统,提出了一种采用网络编码的内容分发系统。其主要思想是在结点发送数据前对数据进行某种线性组合(线性网络编码),接收方收到一定数量的数据包后即可译码恢复出原始数据。利用网络编码的优势,可以大大提供Bit Torrent系统的稳定性和下载效率。
1 Bit Torrent原理分析
Bit Torrent下载,俗称BT下载,是现在非常流行的一种P2P下载技术。BT系统由tracker和peer组成,拥有完整文件的peer称为seed,也就是“种子”。Bit Torrent完成一次下载过程如图1所示。
Bit Torrent之所以具有良好的大文件下载性能主要由两大机制来保证:负责分块选择的分块(piece)选择机制和结点调度机制即阻塞(Choke)与非阻塞(Un Choke)算法。BT的piece选择策略是本地最少优先(local-rarest first),即选择所有邻居结点都拥有最少的piece进行下载,这样能够保证piece在系统中尽量均匀的分布,避免出现所有大量缺失某些piece的情况。结点调度算法使每个peer的下载性能达到最优,并在一定程度上防止“只下载不上传”(free-riding)现象的出现。
BT的piece选择算法是基于局部结点集合做出的选择,因而可能并不是最优选择,导致同一文件的piece并不能完全均匀的分布在BT网络中,当种子结点或拥有稀缺piece的某些结点突然退出都会造成BT下载进行不下去,这就是常说的“最后一块下载不完”(last-piece)问题。下面提出的将网络编码应用于BT下载的思想可以有效地解决这个问题,同时采用网络编码的新系统还拥有Bit Torrent所没有的其他众多优点。
2 基于网络编码的Bit Torrent系统
2.1 网络编码及其优势
网络编码是近几年提出的一个新的研究领域,作为信息论和网络技术的融合,它最先由Ahlswede提出[2]。传统的网络中,路由器或网络中间结点(如P2P网络中的各主机)对收到的数据包只简单转发到下一个结点。而利用网络编码,网络结点可以将收到的多个数据包通过一定的编码方法(如线性网络编码)重新组合成新的数据包再发送到下一结点,接收端收到一定数量的包后通过解码(译码)获得数据。
对于网络编码在P2P网络上的应用,已有众多研究成果表明网络编码可以提高网络吞吐量,增强网络的鲁棒性等。最为著名的是微软提出的内容分发系统Avalanche[3],该系统采用了随机网络编码(Random Network Coding,简称RNC)技术,可以大大提高文件的下载速度。
将网络编码应用于现有的Bit Torrent系统,其工作原理如图2所示。在该模型中,各结点采用网络编码,当seed(种子结点)或者中间结点要发送数据时,将其本地多个文件块进行线性网络编码,产生新的单个编码文件块然后发送出去。开始时,结点Peer A从种子结点seed获得两个编码文件块E1、E2,编码向量为c=(c1,c2,…,cn)和c′=(c1′,c2′,…,cn′)。E1=c1B1+c2B2+⋯+cnBn,E2=c1′B1+c2′B2+⋯+cn′Bn,其中ci,ci′i∈{1,2,…,n}为主机随机分配的编码系数(基于有限域),并将编码文件块E1、E2和编码向量c、c′发送给结点Peer A。然后Peer A产生随机编码向量c1″和c2″,把得到的编码文件进行再次编码c1″E1+c2″E2后发送给结点Peer B。接收端结点Peer B只要获得n个编码数据包,就可以解线性方程组还原数据。分析该模型,网络编码应用于Bit Torrent中的优势主要在于:
1)降低了文件分块调度算法的复杂性。网络编码后的数据块之间是相互独立的,不存在哪个数据块更为优先的问题,因而不需要复杂的分块选择算法;
2)提高了系统的健壮性和可靠性。编码后的每个数据块都包含了整个原始文件的信息,把原始文件更为均匀地分布在Bit Torrent网络中,因而每个结点能更有效地完成下载;
3)有效解决了last-piece问题。编码后的数据块没有重要性上的区分,只要接收端收到n个线性无关的数据包,就能成功译码获得原始数据,因而不存在等待last-piece的问题。
2.2 基于网络编码的Bit Torrent系统架构
本系统采用的是随机线性网络编码技术(Random Network Coding,RNC),网络编码的编译码算法具有较高的时间复杂度,这里采用稀疏网络编码(Sparse Coding)[4],编码时本地生成的编码向量矩阵是稀疏的,能有效提高编码器的编码速度。另外,出于实用性的考虑,在这个系统中引入了generation[5]和编码区间的概念,一定数量的文件块组合成一个generation,对每个generation进行编译码,最后组合成原始文件,避免对大文件编译码时耗时过长;引入编码区间可以有效降低收到线性相关包的概率,有助于成功译码。整个系统的结构如图3所示,主要有4个模块组成:
1)编码:其他结点向本地请求数据时,该模块根据相应的编码区间对当前现有的数据进行编码,然后全部发给请求结点;
2)相关性检测:该模块判断新收到的数据包是否与现有的数据块线性相关,如果线性无关,则接收,否则将该数据包丢弃;
3)译码:对一个完整的generation进行译码,获得该generation的原始数据;
4)传输控制:负责对数据的收发以及各种消息报文的处理。
3 系统性能分析
本系统采用基于稀疏矩阵的随机线性网络编码,实现了编码、译码器,并将编、译码部分作为独立模块与现有的Bit Torrent客户端进行集成,整个系统均采用C/C++实现。系统在12个结点组成的真实网络环境中运行,结点配置为CPU>=1.5GHz,内存>=512MB,Linux操作系统。下面对实验结果进行分析。
3.1 编码译码速度分析
用一个54MB的视频文件在单机(CPU:Intel 3.0GHz,内存:1GB)上测试了分块从64KB到2MB的编译码速度,一个generation大小为100个分块。
编码的时间复杂度为O(n log n),译码采用高斯消元法,时间复杂度为O(n3),实际的编译码速度如表1所示,随着数据块的增大,编译码速度都有所提高。因为同样大小的原文件,分块越大,意味着分组个数n越小,编译码的速率都有所提高,这与实验结果相符合。
3.2 系统下载性能分析
新的系统在12个结点的真实网络环境中运行,一个结点做种,其余进行下载,仍以54MB的文件为例。经上节分析,网络编码在提高Bit Torrent系统的鲁棒性、降低调度算法的复杂性、有效解决last-piece问题方面都有一定的优势。在实验中,将种子结点在下载中途退出,观察其余各个结点的下载情况,实验结果证实各个结点均能成功的下载文件。
不同分块大小下结点的平均下载时间如表2所示。与编译码速度的分布趋势类似,系统的下载性能随文件分块的增大而提高。当分块大小为2MB时,系统的下载速度最快。
4 结束语
通过对当前流行的P2P内容分发系统Bit Torrent进行分析,利用网络编码技术,实现了一种新的P2P下载系统,该系统具有更好的稳定性和可靠性,提高了结点下载的成功率;同时分析了网络编码应用于实际系统时存在的问题,降低网络编码的编译码算法复杂度,将是后续研究工作的重点。
参考文献
[1]Cohen B.Incentive build robustness in BitTorrent[C]//P2P Economics Workshop,Berkeley,CA,2003.
[2]Ahlswede R,Cai N,Li S.-Y.R,et al.Network information flow[C].IEEE Trans.Inform.Theory,IT-46,2000:1204-1216.
[3]Gkantsidis C,Rodriguez P.Network Coding for Large Scale Content Distribution[C].INFOCOM 2005,Miami,FL,2005:13-17.
[4]Ma G,Xu Y,Lin M,et al.A content distribution system based on sparse linear network coding[C]//Proc.3rd Workshop on Network Coding,Theory,and Applications(NETCOD 2007),Jan,2007.
2012校报分发策划书 第5篇
活
动 策 划 书
主办单位: 漳州师范学院经济学系团委
承办单位: 经济学系11统计学2班青年志愿者服队协办单位: 经济学系青年志愿者中心
一·活动主题:
校报进宿舍，真情邮递员
二·活动背景:
校报作为一份贴近大学生生活，反映我们真实情况的文字媒体，让每个同学能及时了解学校情况，作为一名志愿者，我们应该致力于服务师生，服务社会，让校报进宿舍，让志愿者的真诚温暖每个人。
三．活动目的：
1.志愿者活动有利于提高学生自身实践能力，也有利于展现当代大学生的爱心，带动校园精神文明的建设；
2.该活动有利于宣传并展现志愿服务的组织精神，有利于公益精神在学生中的树立和推广，有利于提高志愿者中心在全院的地位
3.围绕服务精神，志愿者通过分发报纸提高交涉能力，礼貌待人。
4.提高校报的宣力度传和班级集体活动意识。
四·活动时间: 2012下学年1到18周 周五晚 19:30至21:30
五·活动地点:漳州师范学院瑞京及白宫及研究生宿舍楼
六·活动对象:经济系11统计2班全体同学(每次15个人)
七·活动开展阶段
(一)前期准备阶段：
1.书写活动策划，上交审批；
2，班级宣传，负责人负责点名，并将参与者分组。
3．在芙蓉餐厅准时集合。
(二)活动开展阶段:
1.让同学7:30分准时在芙蓉餐厅集合2.到达工作地点后，领取报纸，负责人分组。以小组为单位，分别派发瑞京，白宫，研究生宿舍。
4.工作过程中如果有什么难题及时与负责人商量
5.负责人现场拍照以作留念,并存档；
6.工作后进行总结
八．活动经费:无
九．活动规则：
1.在工作岗位上要求每个人忠于职守，不擅自离位，若有特殊情况告知负责人林之楠；
2.以真诚的态度面对工作中的每个人；
3.保护好公共产品，不喧哗，不吵闹，不偷懒。
4.注意文明用语，礼貌待人，不影响宿舍人员的正常休息。
十·活动可行性分析:
周五晚上同学一般都有时间，而且统2班志愿者队伍作为本次活动者，秉着“奉献、友爱、互助、进步”的志愿精神，借此机会锻炼提升自我志愿服务精神。并在进宿舍之前得到了楼管以及老师的许可。
十一·预期效果:
1.可以使得班级同学得到实践经验，增进同学间的交流。
2, 将分配到的报纸分发到各个宿舍，并始终保持良好态度，维持志愿者
形象。
十二·注意事项:
1.活动期间发生冲突负责人要灵活处理，寻求全面的解决方法；
2.活动期间注意安全；
3.提前安排好人员；
策划人： 漳州师范学院经济系11统计二班
张一鸣：移动内容分发第一战赢家 第6篇
缺乏共享经济、交易闭环等热门概念，乍看之下，今日头条不是那么酷的玩家。但真正走近张一鸣，将他与今日头条的故事还原到移动互联网的历史大转折背景下，才能发现其野蛮生长背后的凶悍。
2012年，以技术切入内容分发的今日头条进入移动互联网的时间点并不好，彼时PC门户裹挟品牌和内容优势已经基本完成由PC到手机的用户平移。从侧翼杀入，逐渐进入中心，进而重整体系——今日头条后来的发展再次展现了边缘创新的魅力。
迅猛抓住用户由PC向移动迁移的历史机遇，以程序智能为基础，以个性化内容呈现为利器，在巨头环伺的大众新闻/信息领域，今日头条获取亿万用户，拓展了App内内容的边界，并最终构建起自己的商业模式。
2014年的版权风波，其实是一场成人礼。“杀不死我的，必使我更强大”，进入2015年，今日头条驶入快车道。日活跃用户突破3500万，日均用户使用时间达到50分钟，公司扩展到1200人，广告收入飙升——张一鸣和今日头条已经成为移动互联网内容第一战的真正赢家。
今日头条发展三年，曾经刻意把谁当成要击败的目标吗，比如门户？
我们没有刻意攻击过门户。最初我们想的路线就和门户不一样，门户是做传统意义上的新闻，我们是用技术路线整合推送信息。
新闻和信息最大的差别是前者范围窄，后者可以涵盖各种形式——组图、视频、文字、问答，涵盖各种领域——政治、社会、娱乐、三农等等。
但今日头条可能是很多产品的假想敌。
我们的UI长得像门户，但是介于几个产品形态之间，技术上像搜索，跟社交也有很多共同点，在评论上像微博又不是微博，在导航、聚合、推荐上很多浏览器也像我们。
用户是水，各家产品就是连通器。只要我的短板少，水就会往我这里流。今日头条用户体验好，类似的产品就追不上了。
最大的对手是谁？微信？
打不过微信。其他对手此起彼伏的，UC头条、360头条、网易的千人千面、腾讯的天天快报，应接不暇。
这是因为今日头条对信息的再组织获得了成功，激发各个公司用各种手段去组织信息，而且想把它当成一个变现生意来做？
业界现在对这件事的热情很高可能跟我们有关，有很多产品直接自称XX领域的今日头条，生活领域的、电商领域的、视频领域的……
信息更有效的组织能产生价值，就像一本字典，如果没有索引，这本字典只能一页页翻，起不到查找作用。互联网上的信息组织方式相比纸质字典可以不断演化，不论是搜索、维基百科还是推特，其实都是演化。而且，你有各种方法去组织信息，比如国外有把“家谱”再组织的，有把“人”再组织的Facebook，国内有把“餐馆”再组织的大众点评，这些本身都是数字化的过程。
今日头条比过去“编辑式组织”和“搜索式组织”的方式优化的地方究竟在哪里？
我列出过7种组织方式，都是比较基础的解决方法——基于地理位置，基于关注关系（人）、订阅关系（主题），基于二者的混杂，人和对象、人和媒体的交集，还有搜索，大部分都是用一种强特征或社交方法去组织，但每一种都有不足，它们都不能覆盖所有用户。
今日头条的信息构建方式能够容纳其他的组织方式，无论是地理位置还是热度，都可以被包容进来。
从门户到搜索，信息组织的价值更大了，今日头条有可能做到多大？它能代表多久的未来？
任何事物都是过渡性的事物，多久的未来取决于今日头条产品的演化。如果演化跟不上时代进步的速度，我们就会成为过渡性的事物。
那么，你是否想过两三年后的手机阅读是什么样？
其实我认为手机阅读不是最理想的，它让颈椎酸疼，但现在我们没看到突破点。手机和笔记本都是反人体工程学的东西，但是VR、AR、Glass离现实还都比较远。相比之下，手机上的软件演化会更快。
每一种传播介质稳定一段时间后，都会催生适应它的内容形态，现在适应手机的内容形态出现了吗？
正在出现，比如短视频。文章的体裁也有一些变化，虽然变化没有那么大，互动性的内容会增多。
“我要让自媒体人养得起自己”
如果给今日头条的用户画像，是什么样子？
用户相对偏成熟一点点。他们跟智能手机整体的用户特征非常接近，无论城市、年龄、学历都很接近。20岁以下的用户要落一大半，他们对世界相对没那么关心，但只要年轻用户的绝对值在增大就可以了。
会根据这些用户的特点和爱好取向去选择头条号（今日头条旗下的自媒体平台）的创作者吗？
不会。只要是不错的内容都会进入头条号，然后我们就应该用技术帮这些内容找到读者，找不到读者是因为我们没有做好。优质内容就应该分发，比如现有用户不看三农信息，但自从今日头条有了三农的内容，我们就开始有关心三农的用户了。如果没有我们就去发展，因为我认为今日头条就应该是个平台。
所以你仍然相信好内容自己放在上面读者就会来？
首先我们覆盖的用户量已经很大了（累计下载3.5亿次），任何主题内容都会有读者，无非是多和少，但是读者少的内容，我们应该帮它发展读者。
什么样的机制能让现在头条号的4万多名自媒体人对平台有很好的黏性，又很有动力地创作内容？
满足他们获取用户或者收入的目标。
在获得收入方面，头条号会用微信的方法吗？
我们其实更激进。我们会给不能通过广告变现的自媒体人收入，也会给投放广告效果不好的自媒体人补贴，让他坚持创作，这样对生态有利。
nlc202309022329
这是在做公益吗？
那你说谷歌为什么做不收费的安卓呢？就是为了让人更好地上网，有人上网他就受益：上网就要搜信息，搜信息就有搜信息的商业模式。我们没有像谷歌那样，但更好的创作肯定对我们有益，而且我们的市场盘子越大，这件事越值得做。
自媒体人必须跟头条号签独家协议吗？
不需要。你如果要求排他，他可能就拿不到微信的收益，活得就不够好，不能更好地创作。
这么宽松的条件反而能驱生更好的内容？
这样其实并不宽松。自媒体人写得不好就拿不到内容，而且现在整个市场偏小，作者收入是偏高的。“好”的标准是用户点击、喜欢、收藏、分享，我们也一直在修正评估。
但用户在手机上的活度其实非常弱，比如一篇文章的点击有15万，但订阅号只增加了20个粉丝。
我们之前也没有太强烈地给订阅号涨粉丝，现在在鼓励粉丝订阅。
订阅用户其实是有门槛的，你相信他们活跃度会提高吗？
重度粉丝会，他们在我们这里活跃度是很高的。我们的用户使用时间是50多分钟。但其实订阅并不是最好的方式。用户订越来越多的号，但打开率可能越来越低，一年前是10%，现在是越来越少的。如果你对局部不控制，整体就会过载。
既然如此，还要引导用户订阅？
我们想引导。我们鼓励他表达自己的兴趣，并且表达得更明显，更突出。现在用户没有什么机会去表达，无非是收藏、分享和订阅。
除了分享对自媒体的价值大一些，收藏和订阅后，很可能用户就不再看这篇内容了。这些看上去有用的表达行为，实际上……
真正有用的比例会低一点，但是没关系，对系统来说这些行为是有意义的。至少系统方获取了点击，看和收藏也代表用户对这条信息是满意的。
我们没有计划让用户在这套系统里做更多事，当然阅读和讨论除外。用户在同一个主题下的评论可以有更多的结构，他可以回复，可以发私信，也可以提问回答。
除了这些，今日头条的自媒体机制与微信还会有哪些不同？
微信首先是通信，其次是社交，然后才是媒体，所以整体上就会与我们有很多不同。今日头条不是基于订阅的机制，所有文章都可以评论，一般情况下我们也不可以删评论，但是可以关评论。
今日头条不强调自媒体的地盘是他自己的，我们认为都是公共平台。用户10条评论里有5条是反对的，我们不认为应该控制那5条反对意见。我们更强调公开性，微信更强调私密性。
市场会不会出现恶性争抢优质内容的情况？
因为中国互联网行业不够市场化，如果不按市场流动，你想买版权，但他不卖给你，或者高价卖你，用户就很不方便，你就不能专心做产品创新。
就像音乐市场，阿里把台湾唱片公司的版权占了，腾讯拿了大陆和欧美的，现在如果你是一个做音乐软件的新创业者，你的推荐最准也没用，因为你没有歌可以推荐。但是内容行业的版权战争应该不至于在2016年就变得这么严重。
95%的收入还是广告
广告仍然是今日头条最主要的变现方式吗？打算开发其他变现方式吗？似乎也尝试过今日特卖这个电商？
做过一些小的尝试，比如游戏，但还是以广告为主。今日特卖现在也在逐步增长，但我们的重点还是广告，广告收入占比达到95%以上。
如何平衡广告推广效果和用户体验？
我们会测试用户反馈，对广告质量会进行控制。我认为今日头条对广告的控制是业界最严的。我们的广告商从来没有P2P类的，没有二类电商——价高质低的那种，也没有医疗——不是医疗不好，只是我们态度谨慎。
因为现在变现的方法已经有很多，业界会不自觉地看轻“广告变现”，认为对用户是简单粗暴的伤害，你怎么看？
业界一直在看轻广告，但我觉得这是以讹传讹。阿里也是靠广告收入，大家都在指望腾讯的社交广告，BAT既然都在以广告为主，为什么业界要看轻广告？还有一说社区大家都很兴奋，喜欢社区，鄙视工具，但其实这些都看不到依据。
“2015年我给今日头条打40分”
听说今日头条也做了些投资，但不是投做内容的公司？
我们应该不会直接投内容，因为我们是做平台的，这会不太公平。我们更看重产品技术方面的公司。
投内容不是顺理成章吗，为什么还会有这种顾虑？
苹果就很少投App，按照你的道理App Store前100名App苹果干脆都投了，不要给安卓机会了。当然这也是一种思路，但我认为这不是上上策。
可是文化类消费趋势已经很明显，这几年正在崛起，今日头条有这个地盘，为什么不自己做些孵化IP之类的事情？
如果我们可以做火箭级的事情，我不会想圈一小块地深耕。其实做企业和做投资无非三种方式：开拓、巩固、变现。巩固是因为国内竞争带来的不安全感，但我觉得今日头条应该是求发展创新的，而非求安全巩固，最其次的策略才是深耕细作变现。
道理很简单，你跑得足够快就不需要挡别人的路，因为挡路使你自己也跑慢了。当你的产品还有很大改进空间时，就不用考虑去阻挡对手。最危险的时候是你的产品没有改进空间，必须要去挡对手的时候。2015年我给今日头条打40分，还有很多改进的空间，比如内容的丰富、准确、多元，用户更好的交流、讨论氛围，都没有达到令人满意的水平。
对今日头条这样的App来说，给用户做社区交流的意义在哪儿？
反正意义不在于提高估值，就是在于满足用户需求。用户看完一篇内容有些感想要抒发，希望被肯定，评论可以解决一部分这样的需求，但是无法随着时间沉淀下来。
根据你的判断，内容上还有什么样的创新可能？
我判断互动会增加，视频会增加。现在好内容还是不够的。感觉现在只要是资质不错或阅历不错的人，认真做一个自媒体品牌都能做得不错，但就只是“不错”。
让你感觉不够带劲？
应该有更多更好的人做内容。比如科技行业有些问题我觉得应该有不错的记者研究到了，但为什么一直没有人关注到？好像现在只要内容“还不错”，再配合手机上的形式做些优化就OK了。
是不是内容春天一来，大家心情浮躁了呢？
还是青黄不接的问题。优质媒体人转行了，可是没有更多的年轻人进入行业，行业又有一定的周期。
所以头条号是来拯救媒体人的？
我们希望贡献一些力量，谈拯救实在是压力山大。
分发管理系统 第7篇
首先在数据库中建立一个专用数据表来记录应用软件的最新版本信息, 当软件重新编译之后, 利用软件分发定义上传程序把最新的软件版本号写入该数据表, 并把最新的程序上传至文件服务器, 然后客户端下载代理程序对本地软件的版本和服务器软件版本进行比较, 如果不同则自动从文件服务器下载新程序, 并更新本地软件, 从而实现软件的自动升级。
1、更新文件存放方式
(1) 文件共享
需要一个文件共享服务器, 利用管理程序将需要更新的文件存放在文件共享服务器上, 并修改数据库版本号, 前台读取该更新标志, 判断有更新后将共享服务器映射为本地网络驱动器, 然后复制文件到本地硬盘, 实现程序的自动更新, 该方式受前台操作系统、网络、防火墙等因素影响, 有时候会出现映射网络驱动器失败的情况。
(2) FTP
基本原理同上, 只是将文件共享服务器替换为FTP服务器, 管理程序将更新文件上载至FTP服务器, 客户端从采用FTP传输方式下载文件, 与文件共享方式相比, FTP传输兼容性更好, 不受操作系统、网络环境等因素限制, 只要保证前台能够连上FTP服务器, 就可以实现文件的自动下载更新。
2、实现程序的自我更新
现在我们已经实现客户端下载程序自动更新其他软件的功能, 但有时候我们需要修改下载程序本身, 但下载程序运行的过程中不能覆盖自己, 如何才能实现下载程序的自我更新呢?我们需要另外设计一个自我更新程序, 专门用来实现下载程序的自我更新, 当然这个自我更新程序也可以通过下载程序来更新, 这样问题就解决了。
3、下载过程中的异常控制
软件更新过程中会遇到各种各样的异常情况, 比如网络连接突然中断、系统掉电, 导致下载程序只更新了应用软件的一部分文件, 就可能导致客户端软件崩溃, 为避免这些问题, 首先把需要更新的文件下载到本地临时目录, 等全部下载完毕再更新本地应用, 然后启动应用程序, 即使这次下载不成功, 下次运行下载程序时会继续上次未完成的下载, 这样即使下载过程出错也不会导致本地应用无法启动, 对客户端应用没有任何影响。
二、软件设计与实现
本系统采用Powerbuilder7.0 (以下简称PB) 做为开发工具, 数据库采用SQLServer 2000服务器, 利用数据库存储文件方式, 实现服务端系统定义、文件上传、客户端维护, 客户端自动更新并执行应用软件, 并实现下载程序的自我更新功能。
1、数据库设计
数据库的主要表结构及主要字段有:
(1) 应用系统表, 用来存放各应用系统定义;
(2) 客户端信息表, 用来存放客户端信息及软件版本信息;
(3) 文件信息表, 用来存放各应用系统的文件信息, 其中content字段为image类型, 该类型为可变长度二进制数据, 可存储大小介于0与231-1 (2, 147, 483, 647) 字节之间的二进制数据。
2、软件分发定义上传程序设计
软件分发定义上传程序的主要功能模块有:客户端应用软件定义、程序文件定义及上传、客户端管理, 程序界面如图2所示。
(1) 客户端应用软件定义:定义客户端需要的各个应用软件;
(2) 程序文件定义及上传:从上传主机选择各系统的程序文件, 并将文件上传至数据库服务器;往数据库写文件时, 首先在文件信息表中插入一条记录, content字段为null值, 然后将本地文件循环读取至BLOB变量中, 最后用UPDATEBLOB语句将二进制变量写入文件信息表content字段中;上传的同时更新客户端信息表中对应的版本信息。
(3) 客户端管理:查看客户端应用软件的更新情况, 同时可以添加、删除每个应用对应的客户端, 每个客户端用IP地址来区分。
3、客户端下载代理程序设计
(1) 从数据库中下载文件的实现:定义一个BLOB变量, 用selectblob命令从文件信息表content字段中读取二进制数据到该变量, 然后用PB的写文件函数filewrite将变量内容写入本地的临时目录, 即可实现文件下载, 同样PB每次只能写入32765字节, 因此需要预先确定写文件的循环次数。
(2) 更新软件部分的实现:当全部文件下载完成后, 首先判断应用软件是否正在运行, 这是可以通过调用WINDOWS API函数判断应用进程是否存在, 如果存在进程, 则提示用户安全退出应用程序, 然后更新软件, 这样就不会因为软件正在运行导致无法覆盖的情况发生, 确保软件升级成功。
分发管理系统 第8篇
近年来, 随着信息技术的飞速发展, 全球正处于信息技术深度应用和新一轮技术革命孕育阶段, 技术创新渐趋活跃, 各国的技术竞争将更加激烈, 对技术标准、平台以及产业链主导权的争夺将成为竞争的焦点。
我国高度重视国家信息化工作, 党中央、国务院要求充分发挥科学技术在拉内需、保增长、调结构、上水平、惠民生中的重要支撑作用, 并将三网融合作为重要任务纳入国家发展战略。建设下一代广播电视网 (NGB) , 积极推进广电三网融合战略, 是国家新闻出版广电总局贯彻落实中央精神, 通过科技创新推进产业升级和发展方式转变、促进全面协调持续发展的重要举措。开发适合我国国情的、天地一体、有线无线相结合的中国下一代广播电视网技术体系, 突破NGB跨网络业务互联互通平台和智能内容分发核心技术, 建成示范网络, 对于加快构建现代传播体系、发展我国信息服务业、促进广电产业升级、提升行业核心竞争力, 具有十分重要的意义。
江苏有线作为全国广电行业技术创新发展先头兵之一, 基于江苏有线云媒体电视技术体系架构, 创新研发了有线无线卫星融合一体化的NGB业务互联互通平台及内容分发系统, 实现了跨网络业务互动、内容自动适配和智能流转, 形成一系列标准草案, 建成了试验平台和示范网络。本文着重探讨了江苏有线在NGB业务互联互通平台与内容分发系统总体架构研究方面的工作。
2 NGB业务互联互通平台及内容分发系统建设
2.1 技术架构
江苏有线基于平台化、水平化的理念, 整合江苏有线各类能力系统, 开放业务开发接口, 研发了NGB业务平台和内容分发系统, 提供业务公共运营支撑, 构建开放、智能、融合、安全的媒体云平台。通过媒体云平台聚合全社会的优秀内容提供商和业务运营商, 可以为用户提供:融合电视媒体、互联网媒体和平面媒体为一体的全媒体服务, 融合视频业务、互联网数据业务、多媒体通讯业务、开放的视频增值业务等全业务服务, 以及多屏统一的业务体验。
基于有线无线卫星融合一体化总体技术架构和“有线无线相结合、天地一体”的NGB技术路线, 江苏有线研发了多总线智能驱动的NGB业务互联互通平台及内容分发系统总体技术架构, 实现了跨网络、跨系统、多终端的统一业务运营和卫星、互联网、个人、业务基地等多来源内容的自动适配与智能分发。
图1为NGB业务互联互通平台及内容分发系统总体架构。
2.2 逻辑架构
江苏有线基于开放总线技术, 研发了多总线智能驱动的开放业务平台, 实现了跨网络统一业务运营和智能内容分发。根据业务特性和管理需求, 创新设计了业务驱动总线、直播流总线和点播流总线等多总线驱动架构, 实现了整个系统内部的内容与资源的高效流转和各业务之间的协同关联。
无线卫星信号、SDH信号、互联网内容和内容提供方的直播/点播内容经过融合一体化信源交换矩阵, 直播视频进入直播流总线, 点播视频内容进入点播流总线, 然后在系统中生成标准化的数据类型, 供上层业务调用。业务驱动总线打通能力资源系统与业务层, 实现各类型业务的快速部署与访问。
NGB业务互联互通平台和内容分发系统逻辑架构图如图2所示。
2.3 NGB内容分发系统
NGB内容分发系统采用分层模式, 对系统软件功能进行抽象分层, 使系统具有更高适应性和扩展性。系统主要包括内容采集模块、内容审核模块、内容管理模块、内容分发模块、视频文件关联模块、统计分析模块、工作流引擎和展现门户等核心功能模块, 并且自身具备或者可以调度使用其他内容管理系统的能力, 例如转码能力、自动技审能力、IP推流服务器内容注入能力等。
NGB内容分发系统提供从内容采集、入库、审核、加工, 到分发的完整内容管理流程, 并可提供全局的内容统计、内容查询、生命周期管理等集中的内容管理工具。系统向上承接多种内容提供商, 向下可以汇接多种业务平台。如图3所示, NGB内容分发系统架构大致分为展现层、服务层、数据链路层和工作流引擎四层, 对外接各个能力系统。
(1) 系统展现层
第一层为系统展现层, 主要为CP、运营商和合作商提供管理和展现门户, 为CP、运营商和合作商提供管理和操作界面。
(2) 系统服务层
第二层为服务层, 通过工作流引擎管理接口对下层的数据链路层进行管理和操作, 主要分为内容采集、内容审核、内容管理、统计分析、生命周期、内容分发和关联几个模块。内容采集模块主要负责采集运营商各业务系统或者CP和SP的内容元数据和实体文件;内容审核模块主要负责对采集模块采集上来的内容进行审核, 分为自动技审和人工技审两部分;内容管理模块主要负责对各内容文件的元数据和实体文件的管理和调度;内容分发模块主要负责导入平台的内容 (包括元数据和实体文件) , 在各级CMS、CDN、门户系统、业务协同系统和各类流推送系统之间的内容分发策略和分发管理;生命周期模块主要负责内容的生命周期管理;统计分析模块主要负责统计各项内容业务使用情况;关联模块主要负责关联同一节目的不同格式和码率的视频, 并根据内容ID和子ID来进行相同内容不同码率的视频文件关联。
(3) 数据链路层
第三层为数据链路层, 主要有存储管理、链路管理和数据管理三个模块, 并由数据库和文件库两个库进行支撑。
(4) 工作流引擎
通过工作流引擎, NGB内容分发系统还支持通过统一的接口封装和适配, 调度第三方内容管理系统或者第三方能力系统, 包括且不限于CDN能力、编转码能力、DRM能力、流推送能力、智能分析能力等。
2.4 内容协同关联
同一内容在不同格式、码率的码流之间存在对应关系, 通过规则匹配, 可满足多终端之间互操作的需求, 实现同一内容和业务在不同终端上的使用。
内容关联通过自动和手动两种方式建立完成。自动方式是指通过工作流引擎调度内容关联任务, 经过后台管理系统自动分析内容的元数据, 根据元数据信息对内容文件进行管理, 比如:根据影片导演、主演、年代、题材、热度、排行、推荐程度等, 自动建立关联机制, 在页面中显示这部影片的时候就会将相关影片显示出来。通过手动的人工建立关联的方式, 即录入、编辑影片信息的时候直接指定其关联的影片。同时, 也可以实现自动和手动相结合的方式, 即在手动指定影片关联的时候, 不是特别指定哪部影片, 而是指定这部影片相关联的分类, 这样在显示关联影片的时候就会以手动指定的条件作为优选条件进行关联显示。
内容关联模块主要实现四个层面的内容关联功能。
(1) 将批量导入的媒体文件与批量录入的元数据信息建立关联
批量操作可以减少数据录入、维护的工作量, 可以方便地检索查询到需要关联的媒体文件和元数据信息, 并进行关联操作。在关联的同时, 将系统分配给唯一的内容ID配置在媒体文件属性中, 同时将此内容ID插入元数据中。
(2) 将相关媒体关联
相关媒体可以是同一系列电影等, 关联的对象可以是剧情、导演、演员、编剧等, 信息受众将更加方便地获取与当前媒体相关联的媒体信息群, 从而最大范围地增加了信息受众点击下载媒体的可能性。
(3) 将相关的媒体文件关联
相关的媒体文件包括正片、预告片、片花、电影原声带等。关联的对象可以是预告片、片花、电影音乐等整个媒体影片制作过程中的方方面面, 实现真正意义上地为信息受众提供更加充实的、多维化的媒体内容。
(4) 将相同内容不同屏幕媒体文件关联
不同码率不同大小但是相同内容的媒体文件, 发布在不同的屏幕上, 需要建立关联关系, 方便用户在不同屏幕上切换或续看相同的内容。
2.5 内容安全管控
节目内容要经过一个完整的审批流程, 并在确认审核通过之后, 才可以进行发布。审核通过的内容才可进行内容分发。
NGB内容分发系统的整体流程如图4所示, 元数据流程与实体文件流程分离, 经过工作流引擎驱动, 将来源于各个不同CP的内容经过技审、编目等环节, 发布到各个能力系统和应用系统中去, 最后向各个业务系统提供服务。
元数据从采集、初审、复审、技审再到打点、编辑、编目、终审、发布等环节, 均可以做到流程自定义, 所有的环节均可以人工进行删减或者添加, 为跨屏内容的多流程做到自动适配, 包括调用外部编转码能力、IP推流能力、CDN能力等, 都可以根据使用需求的不同来进行不同的组合。
内容审核包括三级审核, 分别由入库技审、内容审核和发布审核组成。
(1) 入库技审
指内容实体文件上传至本系统后, 系统自动对其实体文件进行技审。其审核对象是内容的实体文件, 审核内容包括文件类型、时长、文件长度、MD5、清晰度、码率、内容连续性、内容完整性等。该部分工作由自动技审能力单元完成, 无需人工参与。
(2) 内容审核
内容审核是指操作人员在系统中对已经送审的内容进行审核, 其审核对象包括内容的元数据和实体文件, 审核内容至少应包括元数据的正确性、版权有效性、实体文件正确性等。
(3) 发布审核
发布审核是指业务门户运营支撑系统的运营人员向内容管理平台提交了内容申请以后, 内容管理平台根据申请进行内容制作和加工, 完成以后提交审核, 审核通过的内容才能真正发布给提交申请的业务门户运营支撑系统, 该环节可作为可选环节。
通过本模块, 内容审核人员可以方便地对通过、未通过、待通过审查的节目编排进行浏览、状态标注, 对不能通过审查的节目编排填写原因, 对审核的内容添加文字批注, 然后反馈给相应编排的负责人。审核人员可以对用户进行分角色定义, 灵活地对不同的角色授予权限。审核人员可以灵活地对审批流程进行定义, 还可以对审批流程进行追踪。
3 结语
回顾江苏有线NGB业务互联互通平台与内容分发系统研发历程和云媒体电视技术演进路线, 从总体发展趋势上来看, 主要有几个方面的技术推进:第一, 积极应用云计算、大数据、物联网等高新技术, 大力倡导技术创新、转变传播模式、转变运营模式、深挖价值链, 有效推动传统广电媒体与新媒体的融合与发展;第二, 深入推进智慧江苏、智慧广电建设规程, 打造智慧城市、智慧社区、智慧家庭三位一体的江苏有线智慧城市创新服务云平台;第三, 加快产业链上游4K、交互等新型视听内容的产业布局, 打造跨网、跨屏的云媒体内容集成服务平台。
技术和市场的发展是相辅相成、互相推进的, 云媒体电视作为江苏有线技术和业务融合创新的承载平台, 将随着技术的演进和市场的需求不断持续创新, 与时俱进, 成为广电有线行业创新发展的标杆产物。
摘要：有线电视的发展经历了从模拟到数字、从单向到双向, 以及目前"互联网+"时代传统媒体与新兴媒体的融合这三次重大变革。面对这些机遇和挑战, 江苏有线根据总局NGB技术体系标准, 着力研发了江苏有线NGB业务互联互通平台与内容分发系统, 实现了跨网络业务互动、内容自动适配和智能流转等功能, 本文主要探讨了NGB业务互联互通平台与内容分发系统总体架构研究。
关键词：NGB,云媒体电视,内容分发,互联互通
参考文献
[1]刘晓雪, 章文辉.浅谈下一代广播电视网 (NGB) [J].电视技术, 2009 (33) :150-152.
[2]张星昱, 杨凤娟.建设符合我国国情的NGB[J].中国有线电视, 2012 (2) :23-27.
[3]王厚芹, 丁颐.我国三网融合发展战略[J].电视技术, 2011, 35 (10) :63-67.
[4]谷虹, 黄升民.三网融合背景下的“全战略”反思与平台化趋势[J].现代传播, 2010 (9) :6-10.
[5]王伟, 李鑫.江苏有线云媒体电视平台研发与实践[J].有线电视技术, 2012 (19) :136-142.
[6]薛留忠, 王伟, 占亿民.江苏有线云媒体电视平台研发建设与推广应用[J].广播与电视技术, 2013 (40) :123-130.
分发管理系统 第9篇
关键词：导航数据,网络化,分发,共享变量,虚拟仪器技术
1. 引言
导航系统工作状态监测、各种定位手段精度分析等是我院某专业实习的主要任务, 导航信息的实时获取是保障上述任务的必要条件。舰载导航装备功能多样, 型号繁杂, 如果基于现有条件进行学员计算机 (下称客户端) 与装备之间一对一的数字通讯, 则对客户端接口种类及数量的要求过高, 造成无法在规定时限内达到既定实习效果。
针对上述问题, 以LabVIEW为开发平台, 以NI myDAQ采集卡及串口为数据硬件接口, 设计了导航数据网络化集散系统。
2. 总体方案
系统由1台服务器和多台客户端组成。在服务器上建立罗经、DGPS、GPS、GLONASS、北斗和Loran C等装备数据的采集、存储与发送功能模块, 实现导航数据高效、灵活的集散, 具有较强的兼容性和可扩展性。
罗经航向信号采集通过NI myDAQ的数字I/O与计数器功能配合专用轴角-数字转换电路完成, 其它装备数据均通过PCI多串口卡经串口接收, 其中GLONASS等导航仪的RS-422/485形式信号电平需转换为RS-232后再接收[1], 继而利用NI-PSP共享变量将最新数据实时发送至客户端, 供进一步分析、处理与显示。
3. 服务器软件设计与实现
3.1 DGPS等导航仪数据采集
由于DGPS等大部分导航仪兼容NMEA 0183协议, 即其数据输出接口能够直接或经电平转换后用计算机RS-232C串口接收[2], 因此串行总线是服务器在数据接收过程中的主要通讯方式。DGPS数据读取过程如图1所示。
GPS、GLONASS及Loran C导航仪的数据采集方式与DGPS类同。
3.2 罗经数据采集
实习舰艇所装配的某型罗经型号较老, 不能输出数字信号, 故从分罗经接线盒引出自整角机3相电压信号及2相激磁信号, 并转换为2路数字信号:一路是罗经航向变化的计数信号, 1个脉冲表示航向变化了1°/6;另一路是自整角机正/反转信号, 高电平表示航向增大, 低电平表示航向减小。通过NI myDAQ的数字输入与计数器功能完成航向数据接收, 配合初始航向装定即可实现航向信号的数字化, 再参照NMEA 0183协议将航向值构建成标准语句。
3.3 数据流盘
为便于后续的数据分析处理工作, 服务器软件除了进行数据实时收发外, 还以可调速率将原始数据流盘, 每种数据每小时形成1个ASCII文件。
此外, 为了提高导航数据流盘所附时间标识的准确性, 服务器软件每次启动前会调用校时模块, 利用GPS时间对服务器进行时间同步。
3.4 数据的网络传输
本系统中导航数据的网络传输主要通过NI共享变量实现。共享变量是一块内存空间, 用户可将一个数据集合中最新的值发布至多台计算机。发布共享变量时, LabVIEW将部署包含共享变量的项目库至共享变量引擎 (SVE) , SVE通过NI-PSP技术协议管理和更新共享变量。
客户端共享变量节点通过网络路径识别NI-PSP数据项。网络路径由数据项所在的计算机名、数据项所在的进程和数据项名称组成。图1中节点的PSP URL为“DH�183语句共享库W_DGPRMC”, 通过配置客户端对应节点的网络路径即可实现网络数据的实时读取。
4. 客户端软件设计与实现
客户端软件设计中力求通用化, 能通过以太网接收服务器各共享变量节点发送的导航数据语句, 并根据NMEA协议将其中的信息进行解码与显示。为了对各定位手段的精度进行分析, 客户端以DGPS纬度、经度、航向和航速数据为约定真值, 对GPS、Loran C、GLONASS、北斗等其他导航仪的系统误差、均方差、综合误差等进行分析、对比和记录。
4.1 NMEA 0183语句解析
导航仪可发送多种类型的语句, 而客户端可能只需要某些语句中的某几个字段, 因此需要对接收到的数据进行解析。因为非标准的导航数据在服务器端已按照NMEA协议进行标准化处理, 均包含起始标志“$”、校验和与终止符“
4.2 导航数据可视化
在客户端软件界面中可实时观察各种导航手段的信号质量、数据可用性等。例如, 根据各导航仪的经纬度信息分别绘制舰艇航迹, 根据$GPGSV语句信息显示可见卫星及其分布状态, 根据北斗自检信息 ($ZJXX) 查看6个出站波束的功率电平等, 从而实现对各导航系统工作状态的监测。客户端程序界面如图2所示。
5. 结语
基于虚拟仪器及NI共享变量技术的导航数据网络化分发系统, 用服务器至多客户端的网络化数据传输代替传统一对一的串行通信, 避免了甲板上的凌乱布线, 充分利用了实习舰艇现有以太网络及计算机集成网卡, 对接口种类及数量无其它要求。实际使用表明, 系统不仅弥补了装备数量的不足, 降低了实习成本, 还通过数据格式的标准化降低了客户端程序的编写难度, 使学员可专注于实习任务, 从而改善了实习效果, 有力保障了实习的顺利进行。
参考文献
[1]马海瑞, 韩云东, 袁群哲, 等.基于LabVIEW的GPS信息采集与解析[J].国外电子测量技术, 2011, 30 (9) :64-66.
[2]陈锡辉, 张银鸿.LabVIEW8.20程序设计从入门到精通[M].北京:清华大学出版社, 2007.
分发管理系统 第10篇
1 系统需求分析
许多企业的应用系统是分别在不同时期由不同的开发商进行开发和实施,业务数据由各应用系统自采自用,数据源多,存放分散,各业务系统之间多采用点对点的人工数据交换方式实现信息共享;由于开发商的技术封锁,造成数据集成壁垒,普遍存在的数据多头重复采集问题,缺乏对数据的集中管理和有效集成,无法保证数据之间逻辑正确性校验,无法保证数据的一致性和唯一性。
随着业务协同要求的提高,对分散的数据系统改造优化提出了新的挑战。需要通过技术手段使相关信息在各系统之间有效同步、消除信息孤岛、减轻人工操作工作强度和减少错误,各系统之间必须进行必要的数据交换。通过梳理企业目前业务模型和已建及在建的信息化系统,建立信息资源标准体系,在此基础上梳理出主数据,并通过建立主数据管理系统实现对主数据的管理,最后通过建立数据交换服务系统,实现主数据管理系统与企业各业务系统之间的数据集成。
2 系统设计与实现
本平台的框架包括建立信息资源标准体系、主数据管理系统、数据交换服务系统三大部分,总体架构如图1所示,主数据管理系统和数据交换服务系统是基于信息资源标准体系建立的,本平台的建设成果,是后续的数据中心建设以及应用系统建设的基础。
平台的体系结构及功能组件如图2所示。在用户通过入口进入系统后,接触到的是系统的功能组件,这些组件是整个系统的核心功能点,包括:主数据建模、规则配置、主数据维护、主数据展现、信息分类编码维护、主数据发布、主数据同步和代办事项等。功能组件下面联结的是主数据的资源库,根据存储的数据类型不同,分为发布库、流程库、配置库和维护库。
除了功能组件外,应用支撑组件和主数据资源库也是紧密联结的,这些应用支撑组件在数据交换、工作流管理、用户/组织/角色管理及系统任务调度方面起到强有力的支撑作用。同时系统应用支撑组件通过企业服务总线(ESB)发布各种服务,外部系统调用这些对外服务与主数据管理系统进行数据交换。
3 结论
目前国内外许多企业、单位都进行了企业数据集成方面的研究,主要用于解决多个元数据之间的分布性和异构性的问题,形成了很多成熟的技术框架和构建方法,例如联邦式、基于中间件模型、数据仓库等。许多行业、企业都根据自身数据特点,结合信息化建设情况进行了企业数据集成,使得数据可以在各应用系统之间交换、共享、融合,以消除企业“信息孤岛”。本平台研发了一种基于主数据分发管理的企业数据集成资源服务平台,其主要技术特点为:①基于一致性数据标准约束,实现包含分布式与集中式两类数据源,集中式分发的双源定向主数据分发管理;②对企业数据集成交换的状态进行仪表式的服务可用性监测,实现数据交换健康分析和报警;③采用插件式技术,实现主数据生成、编码及校验的规则管理。
参考文献
[1]张鹏.工信部解读《大数据纲要》:推动信息技术与传统产业深度耦合、交叉创新[J].通信世界,2015(25):5.
[2]李雪锋,楚磊,顾笑鹏.基于诺兰模型规划企业信息化发展路径[J].企业管理,2015(7):107-110.
[3]马戎,周翀.制造企业基础资源数据管理系统设计与实现[J].中国管理信息化,2016(7).
分发管理系统 第11篇
随着3G业务的普及, 当前手机用户越来越具有移动互联网使用者的特征, 电信运营商在业务的运营模式上也面临着从语音业务经营向数据业务经营发展的变革, 为了适应移动互联网的发展、提升用户感知, 电信运营商建设自己的APP分发系统势在必行。通过该系统可以为3G用户提供APP应用的下载、安装及使用辅导, 降低用户使用3G业务技术门槛、培养用户的使用兴趣, 并按需要提供关联其日常学习生活娱乐的方方面面优秀APP软件让用户真正玩转3G, 畅享3G。该电信运营商“APP分发体系”可有效解决了3G应用软件普及、3G业务发展中面临的问题, 在业务的发展中, 起到3G应用的发现者、传播者、辅导师的作用, 进而极大推动移动互联网的发展。
二、系统总体架构
系统总体架构如图1所示。
运营商建设自己的APP应用分发系统, 前端通过PC客户端或用户自助终端的方式进行展现, 运营人员通过该界面为客户提供APP应用下载、安装服务, 并对用户进行使用指导;系统的后端与APP应用的开发者进行合作, 通过系统的模块将其开发的应用展现给用户。通过本体系形成了整个APP产业链的贯通。
三、系统实现方案
APP应用分发系统总体功能包括三方面:接口服务、后台管理和手机PC套件功能。详细功能及子功能模块如图2所示。
3.1接口服务
接口服务主要包括短信接口、数据业务办理接口、和定时服务、管理接口、套件接口模块。各模块功能设计如下:
(1) 短信接口包括短信发送和发送状态反馈两类:一类是数据业务办理时, 在验证流程中需要的短信验证码;另一类是软件分发时, 发送至用户手机的软件下载链接短信;
(2) 数据业务办理接口实现按需进行业务订购的功能;
(3) 定时服务接口利用服务器闲时 (如每日凌晨) , 定时执行以下功能, 包括:在线查询数据的静态化、缓存化服务;各种详细数据、统计报表的导出/导入服务等;
(4) 管理接口为后台管理提供接口, 包括登录验证、各数据库的操作、文件管理、数据统计等支持功能;
(5) 套件接口为手机软件PC套件提供接口, 包括登录验证、手机软件源文件下载、套件自动更新、机型识别等支持功能。
3.2后台管理
后台管理功能主要包括软件及应用管理、i Phone信息管理、数据业务管理、终端管理、用户管理、统计数据和基础管理等模块。主要模块功能描述如下:
(1) 软件及应用管理包括软件的宣传信息配置、软件类别和参数管理和软件源文件管理三项功能;
(2) IPhone信息管理功能提供i Phone限时免费信息、应用排名信息等信息的更新。
(3) 数据数据业务的信息管理和参数管理两项功能数据业务信息管理包括对数据业务基础信息条目 (包括业务名称、业务类别、业务资费、适用客群、套餐资费、业务描述、适用网络、生效时间、业务操作等) 的查询、增加、删除、修改、审核、发布等功能。据业务参数管理包括对数据业务参数条目 (包括业务类别参数、资费类型参数、客群参数、网络参数、生效时间参数等) 的查询、增加、删除、修改等功能;
(4) 手机品牌参数配置、手机型号参数配置和终端机型库管理;
(5) 用户机构管理包括机构设置、账户设置和角色管理功能三项功能;
(6) 统计数据包括在线查询和数据报表功能, 其中在线查询功能提供按软件、按业务、按机型、按用户、按周期等多维度的在线查询, 提供查询结果导出为Excel数据文件;数据报表功能可以提供多周期、多层级、多维度的定时报表, 提供报表导出功能;
(7) 基础管理包括登录验证、账户信息修改、手机PC套件版本管理, 对支持客户端软件自动更新的支持, 对手机PC套件提供后台支撑功能。
3.3手机P C套件
手机PC套件主要包括登录验证、客户手机号验证、自动更新、数据业务展示、数据业务办理、手机软件展示、手机软件分发、手机接口等。
电信运营商营业人员使用客户端通过该套件以数据线、短信、蓝牙等方式为用户进行服务, 在应用的展示页面为用户进行应用的推介及APP的安装, 安装完成后对用户进行使用的指引, 达到APP分发之目的。
四、总结
APP应用分发系统具有开放性、先进性、高效性、易用性、可维护性和可扩展性等特点, 不仅能提供手机机型自动识别、自动匹配、批量安装等特色功能, 还能提供渠道管理、统计报表等管理能力, 具有技术独创性。
该系统使电信运营商的营业网点能够迅速转化APP分发渠道以及3G应用普及的培训场所, 有效降低用户使用3G网络的技术瓶颈, 让用户充分体验畅快凌厉的3G网络, 对整个移动互联网产业的发展也起到了积极的促进作用。
参考文献
[1]Craig Hockenberry (克雷格·霍肯伯里) 著, 高京, 历勤勇, 施迪宏译, 《iPhone App开发实战手册》, 电子工业出版社, 2012年
【分发管理系统】相关文章：
分发管理07-18
基于B/S架构的医疗就诊分发系统设计09-11
信息分发08-07
分发算法08-24
腾讯游戏分发平台介绍04-13
一种基于自动分发策略的SSLVPN方案09-12
管理系统计划管理论文04-26
管理系统计划管理论文提纲08-12
管理创新仪表管理系统06-25
来料信息管理管理系统论文04-18