Agent 通信机制

Mogent 系统的通信机制

陶先平　冯新宇　李新　张冠群　吕建

软件学报2000, 11 (8) : 1060～ 1065

摘要　

移动agent技术是新型软件构件框架的基础技术之一, 而通信机制是其重要的组成部分. 该文结合移动agent 系统Mogent (mobile agent) 平台的研制, 在分析了agent 的移动特性对通信机制的影响后, 提出并实现了一种用于Mogent平台的一套系统的解决方案. 该方案主要包括移动agent命名机制、移动aget 寻址机制以及通信失效解决方法等,具有易于使用、效率高、可靠性好等优点.

关键词　移动agent,Mogent系统,通信机制,通信失效

  • 移动agent[1]
  • Agent协同 -> 若干个移动agent可在网络中相互协作并合作完成某一项任务
    • 3个层次: 功能互通、协作联盟/模式和通信机制
  • agent协同性 -> 通信机制研究
  • 代表性工作
    • 一类是基于知识交换的KQML(knowledge query and manipulation language)[8]
    • 另一类是基于消息传递的aglets[9]系统

author思路: 一个系统的移动agent通信机制应支持agent之间开展不同层次的协作通信,其体系结构应该呈现如图1 所示的分层多模式结构[10]

  • Question: 如何在Internet有效、可靠地支持agent 之间的移动通信,如agent命名唯一性问题、移动agent 的寻址问题及保证消息传递可靠性的移动通信失效问题等

  • Mole[11,12]

    • Mole虽然提供同步通信、异步通信和远程方法调用等多种通信原语,但却缺乏层次支撑,其寻址机制和通信可靠性保证问题的处理也较为简单
    • Aglets虽然提供灵活的基于消息传递的同步和异步通信方式, 保证了agent命名的唯一性, 并通过A glet Proxy 实现了agent透明寻址.但系统在通信失效解决方案等提高通信可靠性方面的工作所见较少,在通信保障的系统性方面存在不足, 较难满足实用需要.

  • authors work

    • Mogent通信机制 + agent随机移动
    • 给出一套包括命名、寻址和可靠性保证的系统性解决方案
      • 首先简要介绍Mogent的基于MP(message passing) 的间接访问模式框架
      • 然后分析agent移动带来的对agent通信的影响
      • 最后结合Mogent的设计和实现,提出一个系统的解决方案.

1 Mogent 系统通信框架

  • MPI同步、异步通信原语
  • 基于Home-Communicator的通信模型

2 Mogent系统中移动通信

  • 移动agent通信面临以下问题:
    • (1) 分布环境中agent标识的唯一性
    • (2) 动态移动agent的定位
    • (3) 排除移动通信失效现象.

2.1 Agent 的命名问题

  • 动态移动agent命名机制

    • (1) 在agent运行的分布环境中必须是唯一的, 也即从理论上应保证在整个Internet范围内的唯一性
    • (2) 为方便agent寻址,该名称应动态地反映agent位置的变化,标识或映射某时刻agent所处位置的物理地址;
    • (3) 应该易于用户理解, 方便用户使用

  • Mobile IP 方案

2.2 Agent 的寻址

  • Communicator集中实现寻址和消息路由
  • 优点:

2.3 通信失效问题的解决

2.3.1 通信失效现象

2.3.4 算法

算法包括通信, 迁移请求和地址注册3 个部分, 以图6 为例.

3 结论及与相关工作比较

底层通信协议中内存映射机制的设计与实现

移动 Agent 系统的主动通信机制

杨博, 刘大有, 杨鲲, 张朝辉
软件学报 Vol.14, No.7

摘要:
解决由 Agent移动产生的可靠性通信问题.在分析已有方法的基础上,提出一种保证移动Agent之间可靠、高效通信的“主动通信”机制,并给出它的可靠性分析和通信效率分析.它能够在通信双方自由移动的情况下,将消息可靠、高效地从发送方提交给接收方,并承诺消息传递的exactly-once 语义,为Agent通信语言等高层通
信方式奠定了可靠的基础.

关键词: 主体;移动主体;消息传递;通信机制;可靠通信

  • 通信失效

1 研究现状与问题

  • 移动受限的通信方式
    • 通信 pk 移动
  • 移动自由的通信方式
    • 广播方式和消息转发方式

2 主动通信机制

主动通信机制的体系结构如图1 所示

3 可靠性分析

性质 1.
如果底层网络可靠通信,则主动通信机制能保证消息的可靠提交

4 效率分析

5 实验

  • 移动 Agent 原型系统JamAgent[10]
  • 3种通信机制

一种移动 Agent 通信算法

王忠群, 陶先平, 冯新宇
软件学报 Vol.14, No.7

摘要:
在 Mogent 系统所实现的通信算法基础上,借助通讯录再次提出一种基于组播和地址注册的通信算法,它更加有效,能适应多种迁移和通信模式,可以较好地解决移动Agent 通信所面临的难题.

关键词: 移动Agent;通信;地址透明性;组播;通讯录

一种基于同步思想的通信算法

outline

  • 第1节描述系统模型和消息发送过程.
  • 第2节详细叙述我们的算法.
  • 第3节给出算法的分析和实验证明.最后给出结论.

1 系统模型

2 新颖的移动 Agent 算法以及通讯录机制描述

2.1 新颖的移动Agent算法

2.1.1 Agent 体通信算法

2.2 通讯录机制描述

3 算法特性分析

一种高效可靠的移动间通信机制

周竞扬十, 陈韬略, 陈道蓄, 吕建

摘要
作为未来分布式系统的一种主流计算模式,移动技术具有广阔的研究前景协作与通信是移动系统必不可少的组成部分然而由于的移动性和自主性,现有研究工作所提出的移动间通信机制在可靠性尤其是有效性上存在着一定的不足,如不能够在底层理想地解决通信失效等问题针对上述问题,设计了一种具有高度自适应性的消息传递机制一一刃该协议在寻址上采取指针寻址和集中式寻址相结合的方式而对于通信失效的解决则采用了以检测法为主,辅以同步的方法,从而能够在彻底解决通信失效的差汗出上,较大地提高整个通信系统的性能此外还对协议的主要参数进行了讨论,从理论上分析比较了的性能,并给出了模拟实验数据,说明了协议的正确性和高效性关键词移动计算移动通信消息传递

本文第节对现有的移动间通信机制进行介绍和分析第节提出了一种有效的基于消息传递的移动通信机制一一, 并对其做了优化模拟实验的结果和系统性能的分析将在第节给出第节是对全文的总结, 并展望了进一步的工作方向

1 相关问题分析

1.1 已有研究

1.2 方案分析
一个完整的移动通信协议至少要包括寻址和消息传送两大主要部分
​

2.1.2 通信过程与算法

消息的异步转发是机制的核心思想

一种改进的移动Agent 通信算法

冯新宇　陶先平　曹春　李新　张冠群　吕建

摘要　
如何实现远程Agent通信的位置透明性,保证消息不会因为目标Agent迁移而丢失,一直是移动Agent通信所面临的难题, 在现有的很多移动Agent系统中都没有得到解决. 作者在Mogent系统中提出的通信算法初步实现了通信的位置透明性和可靠的消息传输.该文在原有算法的基础上提出了一种改进的适于多种迁移和通信模式的移动Agent通信算法,进一步减少了Agent的地址注册开销和迁移受到的限制,并给出了一种避免地址欺骗攻击的解决方案.

关键词　移动A gent, 通信, 地址透明性, 消息路由, 通信失效

  • 第2 节阐述了移动Agent 通信常用的解决方案及其不足, 介绍了相关工作中提出的一些通信算法, 包括Mogen t 系统中采用的通信算法及其不足.
  • 第3 节中我们详细叙述了改进后的算法并分析了算法的特点.
  • 第4 节给出本文的结论及进一步的工作.

2 问题分析及相关工作

  1. 1　问题分析

  2. 2　相关工作

在Mogen t 系统中提出了一种基于同步思
想的通信算法[2 ]

3 改进的移动Agen t 通信算法

3.1　系统模型和算法思想

3.2　算法描述
算法包括迁移请求、通信和地址注册三部分

3.3　算法特性分析

通用的移动 Agent 通信框架设计

冯新宇1,2+, 吕建 1,2, 曹建农3
软件学报 Vol.14, No.5

摘要:
移动 Agent 的通信机制应满足位置透明性、可靠性、高效性、异步性、自适应性等需求.提出一种通用的移动Agent通信框架,以支持在各种应用需求下的移动Agent 通信协议的设计.该框架基于一种灵活的信箱机制,为每个移动Agent分配一个信箱作为消息缓冲,同时允许Agent及其信箱相互分离,独立迁移.在此基础上提出的三维通信框架不仅涵盖了现有的常用通信机制,还支持新的通信协议的设计.通过实验分析了框架的设计参数选择对协议性能的影响,分析结果对框架的应用有一定的指导意义.

关键词: 移动 Agent;通信;协议;信箱;通用框架

  • 第 1节介绍了现有的各类移动通信机制及其不足.
  • 第2 节介绍系统模型、信箱机制及其通用移动Agent通信框架.
  • 第3节通过实验反映框架设计参数的选择对通信性能的影响,从而对不同通信和迁移模式下的框架参数选择给出指导.
  • 第4 节是结论.

1 相关工作分析

2 通用通信框架

2.1 系统模型和基本前提

目前移动 Agent 通信的研究归结起来大致分为4 类,即基于Home的寻址机制、迁移路径上的消息转发机制、层次式通信机制以及广播机制.

2.2 通用框架设计

基于分布对象的异步消息的研究与实现

张小明
2001

  • author's aim: 提出了一种基于分布对象的异步消息模型,研究其消息寻径、可靠通信、性能保障等关键技术问题

  • 异步Onewya调用(CORBA): 指client发出请求后可继续后续工作,不必阻塞等待server返回应答

  • 延迟同步调用

  • 面向消息中间件(MOM)

  • push vs. pull

图2.1给出了CORBA定义一传统分布对象模型

Paste_Image.png

  • 对象请求代理(ORB): 客户和服务器进程之间通讯中介

定义 2.1: 分布对象环境Q是一个四元组(P,ORB,O,M)

此定义方式可参考

如图2.4,基于分布对象的异步消息模型(DOAM模型)是传统分布对象模型扩充,它在保持传统分布对象模型基本框架前提下,增加和补充支持异步消息、传递内容,具体体现在以下几方面:

  • 增加两种异步的远程方法调用模型
    • 异步回调(Callback)模型
    • 异步轮询(polling)模型:
  • 增加时间无关的调用模型
    • 引入路由代理(route)r构件,支持消息存储一转发,保障松耦合应用的时间无关性需求。
  • 引入逻辑对象地址的概念
    • 对象迁移算法
  • 引入对象组地址的概念
    • 消息组播或复制算法

图2.4分布对象异步消息(DOAM)模型

从目前异步处理技术(2016)来看，此文意义不大

异步可靠Web服务关键技术的研究与实现

左克 2003

  • Web服务消息的传输可归为同步和异步两类

    • 同步: http, rmi, smtp
    • 异步: JMS

  • JMS异步传输机制

图2-1 JMS编程模式

  • 异步可靠Web服务的SOAP2JMS中间件系统

云服务的高效传递技术研究

史佩昌
2012

  • 云服务: 托管在远程位置并通过互联网或专用网络访问的任何应用程序或服务

    • 云服务类型
      • 搜狐网、淘宝网为代表的 Web 类
      • 以 PPTV、YouTube 为代表流媒体类

  • CDN 高效传递云服务相关的诸多挑战

  • 内容分发网络（Content Delivery
    Networks, CDN）

    • 可扩展性问题
    • 公平性问题

  • 云服务的蓬勃发展

  • Web类云服务: 主要指可通过Web浏览器进行访问的云服务

    • 静态Web页面的浏览
    • 动态Web页面的浏览
    • Web2.0: Flickr、Facebook、Youtube

  • 流媒体类云服务

  • 其它类型云服务:

    • 网络游戏服务
    • 即时通信服务

  • 互联网的固有缺陷

    • 网间传输存在瓶颈
    • 路由协议低效
    • 网络的不可靠
    • 传输协议低效
    • 可扩展性低
    • 软件、协议难改变

  • Danny Lewin

    • *Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web *
    • A Tight Characterization of NP with 3 Query PCPs

  • 服务器部署研究

    • 内容网络服务节点部署理论综述 .计算
      机学报,2010

  • CDN 发展演化

    • 分布式 CDN
    • 大节点 CDN
    • P2P 辅助 CDN
    • 云计算模式 CDN

一种 CDN 技术分类，如图 2.1 所示

图 2.1 CDN 关键技术分类模型

NIO高性能框架的研究与应用

刘蓬
2013

  • 需求: 高并发、大数据量

  • Reactor模型的 I/O 框架

    • Mina 框架: Multi-purpose Infrastructure for Network Applications
    • XSocket: dead!

  • Proactor 模型

    • NIO
      • 异步 I/O : java.nio.channels

Socket 实现网络通信的流程如图 2.2 所示

图 2.2 Socket 通信机制

  • NIO: 通道、缓冲区和选择器

  • Master Slave模型

  • Pipeline模型

  • Reactor 模型

  • I/O 模型

    • Unix：阻塞 I/O、非阻塞 I/O、I/O 复用、信号驱动 I/O 和异步 I/O
    • POSIX标准: 分为两类：同步 I/O和异步 I/O

  • I/O 操作实际分成两个步骤：I/O 请求和 I/O 读写操作

    • 同步 I/O 和异步 I/O 区别: 在于第二个步骤是否阻塞
      • 如果 I/O 读写阻塞请求进程，则是同步 I/O，因此阻塞 I/O、非阻塞 I/O、I/O 复用、信号驱动 I/O 都是同步 I/O
      • 如果 I/O 读写操作不阻塞请求进程，而是OS完成 I/O 读写，则是异步 I/O
    • 阻塞 I/O 和非阻塞 I/O 区别: 在于第一步，发起 I/O 请求是否会被阻塞
      • 如阻塞直到完成，则是传统阻塞 I/O
      • 如不阻塞，则是非阻塞 I/O

  • 基于 Reactor 模型 NIO 框架: 仅仅是发起 I/O 请求时不阻塞

五个 I/O模型的比较如图 3.3 所示：

图 3.3 五个 I/O 模型的比较

  • Proactor 模型
    • C++网络编程库 ACE

基于Java NIO的通用框架的研究与实现

鲁宾宾
2012

  • Java NIO非阻塞通信
  • Quartz: 一个开源的作业调度框架
    • Quartz Job Scheduling Framework: Building Open Source Enterprise Applications

Reactor 类图(本文图不清楚)

  • Spring框架

    • 控制反转(IoC):依赖注入

  • MINA框架

  • 会话(Session): MINA核心

    • 每次客户端请求服务端时,则创建一新会话,且该会话一直存活到客户端断开连接为止
    • 会话: 用来持久存储连接信息,及服务端在请求处理中可能需要用到信息

  • 会话生命周期:

    • Connected: 创建Session,并初始化
    • Idle: 空闲状态,即无请求事件
    • Closing: 关闭状态,表示会话开始清理工作
    • Closed: 己关闭状态,表示会话己关闭,且不可恢复

Session 状态变迁图

基于NIO的java高性能网络应用的技术研究

曾自强
2009

  • 套接字(socket)
    • select: 事件监听

图2-4 I/0网络应用的硬件和软件架构图

  • 阻塞IO(blocking IO): 请求IO操作中,进程一直等到IO操作完成,才继续执行
    • 进程在输入操作中,需等到数据从内核拷贝到进程缓冲区,然后返回
    • 输出操作中,需等到数据从进程缓存区拷贝到内核,然后才返回
  • 非阻塞IO(nonblocking IO): 进程IO操作中,不需数据读写操作时立即返回;在能进行数据操作时,等到IO操作完成后返回。
    • 输入操作等待数据从内核拷贝到程序缓冲区后返回
    • 输出操作等待数据从程序缓冲区写入内核后返回
  • IO复用(IO multiplexing): Select模式,内核一发现进程指定一或多个IO条件就绪,内核就通知进程
    • 实现方式: select、poll、epoll等
  • 同步IO (synchronous IO):
  • 异步FO(asynchronous IO)

Java定义两种创建线程方法:

  • 继承Thread类
  • 实现Runnable 接口

线程生命周期四种状态, 如图2-7:

  • 新建状态:线程已创建,但尚未执行(start方法尚未被调用)。
  • 可执行状态:线程已可执行,但不一定在执行。CPU时间随时可能被分配给该线程
  • 死亡状态:正常情况下run方法返回使得线程死亡,调用stop方法或destroy方法亦有同样效果,前者产生异常,后者强制终止,不会释放锁。
  • 阻塞状态:线程需等待一事件时,进入该状态

图2-7 线程生命周期状态转换图

  • NlO关键概念: 通道、缓冲区

    • 对应Java类: Channel、Buffer

  • Reactor模型

  • MINA框架

基于NIO的远程调用框架的设计与实现

查骏
2012

  • Socket -> RPC

    • 屏蔽底层通讯协议
    • RMI

  • 远程调用方式

    • Socket: 最底层通讯,效率高,但使用复杂
    • RMI: Java内置,使用简单,但基于同步流,效率中等
    • Hessian: 基于HTTP协议,效率较差
    • Web Service: 基于HTTP协议上封装SOAP协议,格式采用XML,解决跨平台问题,但性能差

  • BIO: 基于流(Stream),属于阻塞调用,

  • NIO

  • Selector (选择器)

网络调用中Socket使用NIO (= Unix IO Select)

  • 各个Channel将事件注册给Selector
  • Select监听所有Socket通道

图 2.4 Selector 模型

  • Netty通讯框架: JBoss NIO

    • 组成: 缓冲(Buffer)、通道(Channel)、事件模型(Event Model)

  • Zookeeper

数据交换平台中消息中间件的研究与实现周乐钦

2013

  • 远程过程调用(RPC)

  • 面向消息中间件MOM

    • 消息传送模型分为: 点对点模型和发布/订阅模型

  • Netty框架: 提供阻塞型/非阻塞型套接字一统一API抽象

图2.1显示 Netty的架构图(Reactor模式)

图2.1 Netty 构架模式图

图1.2 集中式拓扑结构消息中间件

  • 缓冲区
    • 缓冲区接口: ChannelBuffer
    • 缓冲区工厂

图2.2 缓冲区工厂类层次图

  • 通道

    • 状态 + 变迁

  • 服务端
    图2.5服务器通道状态转换图

  • 客户端
    图2.6客户端通道状态转换图

  • WebSocket协议

基于 Apache Mina 的智能家居服务器设计与实现

向运
2013

  • Java NIO 4 个新功能特性

    • 非阻塞式 I/O,用于开发大型服务器应用
    • 支持文件锁和内存映射
    • Perl 风格正则表达式的模式匹配
    • 字符集的编码器和译码器

  • Java NIO 组成

  • 缓冲区: get()和 put()

  • 通道: java.nio.channel

  • 选择器

图 2.2 NIO 的使用流程

  • Mina框架
    • 通讯框架: C++ ACE、Python Twisted

Mina在整个网络通信结构中处于如图 2.3位置

图 2.3 Mina 在网络通信中的位置

Mina总体框架如图 2. 4 所示

图 2.4 Apache Mina 的总体架构

  • IoService
    • 服务端: IoAcceptor
    • 客户端: IoConnector
  • IoProcessor: 负责处理请求的分配
  • IoFilter: 事件请求拦截器 -> 过滤器模型
  • IoHandler: 处理所有协议事件
  • IoSession: 一 IoSession 实例代表一连接

Mina 的工作流程如图 2. 5 所示

图 2. 5 Mina 的工作流程

各接口间的相互关系如图 2.6 所示

图 2.6 Mina 各个接口的相互关系

协议格式,如图 3.4 所示

  • 报文头 Tag 部分表明该协议的类型
  • 数据区 Length 存储整个数据区的长度
  • 数据区的基本数据区存储协议的一些必要信息,如家庭网关的 ID 等
  • 真实数据区为需要转发的数据

图 3.4 通信协议格式

基于Mina框架的系统总体框架如图 3.11所示

图 3.11 基于 Mina 框架的服务器系统总体框架

云工作流引擎的设计与实现

任俊熠

  • 云计算主要解决方案

    • 计算服务
    • 存储服务
    • 数据库服务

  • Biztalk Service ?

    • microsoft

  • Cordys Platform

  • jBPM: 开源

  • Aneka

    • 3 个通用编程模型: Thread Model、Task Model、MapReduce Model

ICE会议会话系统的设计与实现

王刚
2013

  • ICE: Zeroc公司提出一款高性能、面向对象、开源分布式中间件平台

    • code
    • A new approach to object-oriented middleware, 2004

  • ICE5个基本术语:客户端(Client)、服务器(Server)、ICE对象(ICE Object)、客户端代理(Proxy)、服务器端骨架(Servant)

客户端一服务器模型中,如图2-1所示,客户端作为该模型的一端,是主动的实体,主要作用是向服务器发送请求。

图2-1客户端--服务器模型

  • ICE语言: Slice (Special language for ice)语言
    • 对象的定义与实现相分离的机制
//一个简单的hello.ice文件
#ifndefine HELLO_ICE
#define HELLO_ICE

module Demo {
  interface Hello {
    void sayHello;
  };
};
#endif

ICE编译的过程如图2-3所示

图2-3 Slice语言映射并生成可执行文件

  • 编译器
    • slice -> C++, Java, Python etc.

ICE通用服务管理模块以及插件管理模块等,如图2-4所示
图2-4 ICE run time组成部分

  • 对象适配器 -> 活动Servant映射表(ASM) -> map键值对映射

ICE通用服务管理模块提供了常用的ICE服务:Freeze, IceGrid, IceBox, IcePatch2,
Glacier2,IceStorm等

Tables Are
Freeze 内建的数据持久化服务,对象存取数据库
IceGrid 定位,网格计算/负载均衡,随需启动服务器
IceBox 协调多组建的启动停止,减轻系统负担
Glacier2 防火墙解决方案,服务器回调

基于ICE的系统三层结构模型: C-M--S三层结构,如图2-7所示

图2-7 C--M-S三层结构模型

  • ICE中间件 Glacier2服务

  • Question:

    • 服务器如何穿透客户端防火墙并回调客户端
    • 网络连接管理问题,系统认证问题
    • 多客户如何同时进行信息交换

  • 三种实现方案:

    • 直接使用套接字
    • 基于ICE中间件的双向连接调用实现
    • 基于Glacier2服务的网络连接实现

以TCP协议为例,其实现系统服务器与客户端的网络连接的过程如图3-2所示,可描述为:

  • 服务器端: 创建套接字绑定-->监听-->接收连接-->收发数据-->关闭;

  • 客户端: 创建套接字-->连接-->收发数据-->关闭;

  • ChatSession和ChatRoomCallback 两个接口

系统的核心业务逻辑处理,主要包括回调请求客户端、文本消息转发、客户端间文件传输和音频传输、文件上传下载五个部分。前三个需要回调,其编码过程如图5-5所示。

图5-5核心业务实现的过程

  • ICE流接口: 实现Slice 类型数据与字节流序列之间转换
    • ICE 到Java 语言映射: ICE API 提供InputStream 和OutputStream 两个流接口
      • InputStream和OutputStream是字节流接口，定义一系列read( )和write( )方法
        • read( ): 在ICE的InputStream字节流序列中读取Slice 类型数据
        • write( ): 将Slice 类型数据写进ICE 能够处理的OutputStream 字节流中
      • Java IO文件处理: 使用FileInputStream 和FileOutputStream两个字节流。
      • FileInputStream: 将文件转换为字节流，供ICE 中OutputStream 使用
      • FileOutputStream: 将ICE 中InputStream 转换成文件

Ice应用软件框架自动生成研究

王宁
2012

  • CORBA(Common Object Request Broker Architecture): Internet 和企业应用的工业标准

    • Corba issue: 过于庞大复杂而难以实现

  • new solution: Ice

    • 一种轻量级面向对象的分布式中间件
    • ICE（Internet Communications
      Engine）: 基于CORBA 基本体系结构
      • Ice 在 RPC 上建立一层封装，客户端可使用代理(proxy)与服务端(servant)通信

  • ICE vs WCF vs. Java RMI

    • WCF: Windows Communication Foundation

  • 代码自动生成: 即把形式化描述的系统需求转换为特定软硬件平台上基于某一目标语言的系统实现

  • 代码生成器类型与比较

    • 代码生成器:
      • MyGeneration
      • CodeSmith Pro
      • CodeAuto

图 3.1 Ice 基础通信模型

  • Freeze: 基于嵌入式数据库Berkeley DB

  • aim: 针对 Ice 系统设计一全新代码生成器

    • 设计基本思想: 使用 xml 文件描述系统需求，将重复和可预见的代码写入模板中，再通过解析引擎解析整个过程，生成目标系统，总体系统流程如图 4.1 所示：

图 4.1 系统总体流程

  • Reference
    • Chosing Middleware: why performance and scalability do

基于Socket的游戏服务器的设计与实现

郑帅
2014

  • tools: libevent和zeromq

  • 开源框架

    • ICE、ACE、BoostAsio

  • Libevent: C语言 异步事件处理的网络库

    • IOCP模型: Windows
    • 核心数据结构: event_base和event
      • event_base: 整个libevent事件管理者
      • event: 代表具体事件

  • zeromq: 消息处理队列库

    • ZeroMQ vs. RabbitMQ， ActiveMq，Kafka
      • RabbitMQ: 一AMQP实现，传统messaging queue系统实现，基于Erlang

  • muduo: c++木铎

    • author: 陈硕
      • Linux 多线程服务端编程：使用 muduo C++ 网络库

  • epoll:  linux IO复用技术

  • Libevent: 将不同平台IO复用技术封装统一接口

  • ZeroMQ: 消息队列，支持不同的模型，用于将不同应用程序采用消息方式连接起来

基于ICE的互联网的网络监测后台管理系统的研究

王华晓
2014

  • 后台管理模式

    • C/S(Client/Server)客户端/服务器模式
    • B/S(Brower/Server)浏览器/服务器模式
    • C/M/S(Client/MiddleWare/Server)客户端/中间件/服务器模式

  • 中间件: 介于应用系统和系统软件之间一类软件,它使用系统软件提供服务功能，衔接网络上应用系统各组件

    • 数据库中间件
    • 面向消息中间件
      • 三种通信模式：点对点通信，发布者与订阅者通信，消息队列模式
    • 面向对象中间件: ICE,CORBA
    • 事务处理中间件
    • 嵌入式中间件

  • COBRA分为3个层次:对象请求代理、公共对象服务和公共设施

    • 对象请求代理ORB: 最底层,规定分布对象的定义(接口)和语言映射,实现对象间通讯和互操作,是分布对象系统中软总线

  • .NET平台: 取代DCOM,提供比DCOM更强大分布式计算支持,但仍然是Microsoft独家解决方案

  • SOAP: 性能瓶颈

  • IceStorm消息发布模式

  • slice是Ice定义语言,类似COBRA的IDL定义

Ice中间件关键技术的研究与实现

王博

内容整理尚可，无新意

互操作性不同层次，如下表 1-1 所示

表 1-1 互操作的不同层次

  • 中间件
    • OMG CORBA规范
      • 复杂性
    • Microsoft DCOM和.NET
      • 无法跨平台
    • SUN EJB
    • SOAP 和 Web services
      • 低效和安全

图 1-2 中间件的定义

  • Ice vs. CORBA
    • ICE 对象模型
      • ICE对象代理相当于CORBA 中对象引用, 是远程对象句柄
        • 与CORBA 不透明对象引用相反, ICE 对象代理是透明
    • ICE 本身是多线程
      • 服务端使用leader-follower模式实现线程池分派操作
      • 客户端使用一个包含两个线程的线程池。一线程监听从客户端发来调用请求, 而另一线程负责发送调用结果

Ice的体系结构如图 2.1 所示

图 2.1 ICE 体系结构

  • 骨架（skeleton）代码: 由用户定义 Slice文件编译后生成

    • Slice: 描述接口和类型，非具体实现
      • Slice定义关注是对象接口、接口所支持操作，及操作可能引发异常

  • Ice 提供一 RPC协议

    • Ice 协议定义由三个部分组成
      • 数据编码规则：确定各种数据类型串行化方式
      • 协议状态机制：规定客户端和服务器如何交互不同类型的信息
      • 版本控制：确定客户与服务器怎样就特定的协议和编码版本达成一致

  • IcePack: 一服务器配置和激活工具

  • IceStorm: 消息的发布/订阅服务

  • Freeze: Ice 的持久化服务

  • Glacier: Ice 防火墙服务

  • IceBox: Ice 服务的应用程序服务器

  • IcePatch: 一种软件修补服务

如图3-1所示Ice 核心功能模块图，主要指Ice run time 环境的相关模块

图 3-1 Ice 核心功能的模块组成图

  • Ice: 多线程 -> ThreadPool -> 领导者-跟随者模型(leader-follower)

    • procedure
      • 每次允许一线程leader等待在事件源集合上,同时其他线程follower 排队等候成为领导者机会
      • Leader检测到事件后，马上转入follower并提升一个follower为leader，然后直接处
        理事件这时处于processer角色，处理完成后成为follower
    • Leader/Followers: A design pattern for efficient multithreaded event demultiplexing and dispatching

  • question: Leader/Followers vs. master-worker模式

我感觉 master-worker模式，可以考虑actor model或Active object?

  • CORBA 支持同步、异步，以及单向调用模式

  • Ice 支持同步调用、异步调用、单向调用、数据报调用和批调用

    • 同步调用
      • CORBA 提供 最多一次 语义
      • ICE:
    • 异步调用:
      • CORBA: 异步方法调用（AMI）回调模型

  • 插件: Ice为扩展 Ice通信器特性所使用机制

插件的 Ice 接口定义

//图 3-10 Ice::Plugin 插件接口定义 
module Ice 
{ 
  local interface Plugin 
  { 
     void destroy(); 
  }; 
 
  local interface PluginManager 
  { 
     Plugin getPlugin(string name); 
     void addPlugin(string name, Plugin pi); 
     void destroy(); 
  }; 
};

Endpoint采用工厂方法模式 -> 不同传输协议

图 4-1 端点与端点工厂的 UML 图（工厂方法模式）

插件调用过程如图4-2所示，时序图反映为串口设计的CommEndpointFactory 对象和 CommEndpoint对象被调用过程

基于XMPP的跨平台即时通讯软件库的设计与实现

袁宾奇
2013

一般

  • 开源即时通信协议XMPP: Extensible Messaging and Presence Protocol协议
    • 基于XML
    • 基于XMPP协议实现: Google Talk

Web模式下基于XMPP的即时通信系统的设计与实现

王璐
2010

写得还好

特点 SIMPLE XMPP
基础 SIP协议 XML协议
成熟度 较成熟 新兴
功能 实时消息通信 实时消息通信
扩展性 一般 强
厂商支持 微软,IBM Google

XMPP协议栈如图3-1所示,最底层仍然是TCP协议,往上依次是TIS(Transport Layer Security 传输层安全协议),SAS(Simple Authentication and Security Layer 简单认证和安全层协议)

图3-1XMPP协议栈

  • NIO的Mina架构

    • XMPP vs. Mina -> Openfire基于Mina异步I/O通信框架

  • 会话管理模块

基于XMPP协议的网站即时通信系统设计与实现

陈秋平
2015

文章内容不错，可进一步提炼

  • 开源标准即时通信协议

    • SIMPLE 协议簇: IETF 制定，为SIP(Session Initiation Protocol)协议扩展
    • XMPP 协议

  • HTTP 实时刷新技术

  • 请求-响应式 -> Ajax异步提交 -> Comet(服务器推送 + 长连接) -> Websocket

  • Erlang: 函数式编程语言

    • OTP 应用框架监督树形结构如图 2-8所示。监督者在子进程挂掉时可执行一定重启策略，以将影响降至最小
      • Erlang/OTP 并发编程实战

图 2-8 典型监督树结构

  • new issue: Erlang进程间相互独立，不共享任何内存，所以并发不会出现多进程竞争资源问题。但有些情况下又需要多个进程之间共享数据，该如何解决？
  • ETS(Erlang Term Storage)表: Erlang 内部轻量级存储工具
    • 基于内存的KV Table
    • DETS(Disk Erlang Term Storage)

图 3-5 会话建立过程中的状态转移图

  • 服务器和开发库组合: ejabberd+exmpp
    • ejabberd: 基于 XMPP 协议的服务端开源软件 (Github)
    • exmpp: Erlang常用开发库

即时通信系统后端基本组成如图 4-1所示。通信服务器采用 ejabberd，数据库使用 PostgreSQL，XMPP 客户端基于 exmpp 库开发

图 4-1 即时通信系统组成

  • 前后端通信技术: Ajax、Comet和 WebSocket
  • Zotonic 框架
    • Erlang语言，类似 django 框架

基于Web应用的动态集群策略研究与设计

王祎
2014

写得较细

图 2-2 Apache+Tomcat 集群框架模型示意图

  • 两层框架结构: 前端负载均衡+后端会话管理

    • 前端Apache服务器 -> 负载均衡 -> 用户请求信息转发给 Tomcat 节点
    • 后端Tomcat 节点处理用户请求信息和管理用户会话，并实现相应的业务功能
      • Tomcat服务器后端会话管理解决方案
        • 粘连会话（Sticky 会话）
        • 持久性管理
        • 内存会话复制

  • why two layer?

    • 由于服务端会占用一定内存和cpu用来存储和处理session计算，导致tomcat并发连接低
    • 静态资源服务器，如apache或nginx服务器，由于不考虑http无状态问题，则无需处理session，因此静态资源服务器并发连接数高
    • solution:
      • 让那些没有状态保持要求的请求直接在静态服务器里处理
      • 而要进行状态保持的请求则在java web容器里处理，从而提升网站效率

  • question: 无状态http -> 状态保持

  • Tomcat 会话管理

    • Manager类: 管理session工具类，负责创建和销毁session对象
      • StandardManager类: tomcat容器里默认session管理实现类
      • PersistentManagerBase

图 3-10 默认Session对象及相关类 UML 图

图 3-11 默认Session请求过程的时序图

  • Session 对象操作
    • 创建
    • 修改
    • 销毁

基于XMPP协议的移动消息应用的设计与实现

王玉龙
2013

  • 服务器推送技术

    • Apple APNS(Apple Push Notification Services)
    • Google C2DM
    • Windows Phone MPNS

  • the aim of this paper: 应用C2DM架构到Openfire和Android系统,底层使用XMPP协议实现消息的推送

    • 服务器端: Openfire提供插件开发机制
      • 嵌入式数据库
    • 客户端,Android设备

  • APNS服务推送消息过程

    • 首先应用服务器通过APNS接口将消息发送到APNS服务器
    • 然后APNS服务器再将消息推送到iOS设备

  • APNS工作方式包含两个过程

    • 第一个过程是iOS设备向APNS服务器注册过程(如图2-1所示)
    • 第二个过程应用服务器向iOS设备推送消息的过程(如图2-2所示)

图 2-1 iOS 设备注册 deviceToke

  1. 首先iOS设备连接到APNS服务器
  2. APNS服务器向iOS设备返回deviceToken,在一段时间内通过deviceToken可唯一标识这个iOS设备
  3. iOS设备将deviceToken通过本地接口通知客户端应用
  4. 客户端应用再将deviceToken发送到应用服务器(即Provider)

图2-2应用服务器推送消息

  1. 首先应用服务器(Provider)将消息发送到APNS服务器
  2. APNS协议要求在这条消息中必包含deviceToken和要推送消息
  3. APNS服务器再将消息推送到和deviceToken匹配iOS设备
  4. 当推送消息到达iOS设备后,iOS设备再通过本地API通知iOS应用,即完成消息的推送过程

  • Google C2DM -> GCM

  • 移动消息推送协议: SIMPLE、MQTT. XMPP

    • SIMPLE: 基于 SIP (Session Initiation Protocol)的即时通讯协议
    • MQTT (Message Queuing Telemetry Transport): IBM
    • XMPP 协议

表2-1推送协议比较

  • 高并发服务器设计

    • 异步编程模型 -> NIO API -> MINA
    • 线程池
    • 持久连接保持 -> 心跳

  • JAX-RS: 即Java API for RESTful Web Services, 是Java 编程API，支持REST架构风格创建Web服务

    • 注解@POST、@GET、@PUT、@DELETE

  • JAX-WS：JavaTM API for XML-Based Web Services

  • Java 6

    • BlockingQueue<Message> -> 生产者-消费者模式
    • ConcurrentLinkedQueue<Message> -> 队列并发访问
    • Executorservice -> 线程池
posted @ 2016-07-01 10:42  westRiver  阅读(4972)  评论(0)    收藏  举报