ESFramework介绍之(14)-- AS与FS通信方案

简介: 前面我们已经多次提到,每个AS都有一组FS为之服务(回顾),AS将接收到的功能请求通过Tcp连接池 或Remoting转发给某个FS处理。下面我们将深入讨论AS和FS之间的通信机制。    首先要解决第一个问题,AS如何知道每个为之服务的FS的地址?    最常见的一种解决方案是,AS处的配置文件中有一个FS地址列表,AS每次启动时,就读取这个列表,然后与列表中的每个FS建立Tcp连接池。

    前面我们已经多次提到,每个AS都有一组FS为之服务(回顾),AS将接收到的功能请求通过Tcp连接池 或Remoting转发给某个FS处理。下面我们将深入讨论AS和FS之间的通信机制。

    首先要解决第一个问题,AS如何知道每个为之服务的FS的地址?
    最常见的一种解决方案是,AS处的配置文件中有一个FS地址列表,AS每次启动时,就读取这个列表,然后与列表中的每个FS建立Tcp连接池。这种方案很容易实现,但是有很多缺点。最主要的是当动态的添加/移除FS时,都需要修改AS配置文件中的FS地址列表,而且当FS的IP发生变化时,也需要修改这个列表。所以这个列表的维护是相当麻烦的。
    ESFramework全力支持的是另一种非常灵活的方案,在这种方案中,AS的配置文件中不用保存任何FS的信息,为AS服务的FS的地址都是在运行时由FS自己通知给AS的。这样,在动态的添加/移除FS时,AS及其配置文件不用作任何变动。我们知道,AS和FS之间的所有功能通信是通过TCP连接池进行的,在这种情况下,AS是主动联系FS。而AS和FS之间的非功能通信通过Remoting或WebService的方式来完成,即当FS启动时,将自己的地址信息通过AS发布的远程服务接口告诉给AS,然后AS再根据这个地址去与FS建立TCP连接池。在非功能通信中,是FS主动联系AS,所以FS不需要发布远程服务接口,FS只需要知道AS发布的远程服务的地址即可(通常这个服务地址记录在FS的配置文件中)。 

   需要解决的第二个问题是,当网络出现故障后恢复或服务器(AS或FS)重启后,AS与FS之间的连接池如何恢复?主要可分为下面三种情况讨论。
(1)第一种情况:当FS正常工作一段时间后重启:
      每次FS启动/重启时都向向AS发送“我启动了”的消息,这样AS就去主动与FS建立Tcp连接池或恢复已存在的连接池。

(2)第二种情况是AS重启:
      这中情况下有两种解决办法:一是在FS上加个按钮,当AS重启后,工作人员点击按钮,给AS发送“本FS启动了”的信息。二是FS通过Remoting定时给AS发送Check消息,当发生Remoting异常时,FS就知道AS掉线了。AS掉线后,FS就定时给AS发送“我启动了”的消息,直到AS重启完毕。ESFramework对第二种方式进行了全力的支持。

(3)第三种情况是网络断开后恢复:
      这种情况可以由Tcp连接池自动重连机制来解决。

       AS与FS之间的通信的两个主要问题都已经解决了,最后我还想额外补充一点,那就是关于“定时Check消息”的。在ESF平台上,有很多地方需要使用“定时Check消息”的机制,这种机制主要用于使对方确认消息发送者还在线上。比如,手机通过移动与我们的AS建立了Tcp连接,当手机掉线时,移动与AS之间的Tcp连接并没有断开,所以AS并不知道手机客户掉线了。所以,AS要求,手机每隔一定时间就要向AS发送“Check消息”以表明自己在线,如果在指定的时间间隔内,AS没有收到该手机的“Check消息”,则AS认为该手机已经不在线,马上断掉其对应的Tcp连接。上面的FS也定时向AS发送“Check消息”来表明自己一直在线。

       而在AS与IRAS之间,也采用了同样的机制。因为IRAS需要管理所有在线AS的地址,所以AS也是每次启动时向IRAS发送“本AS启动了”的信息,并定时向IRAS发送“Check消息”来表明自己一直在线。关于IRAS的作用的更细讨论,请关注下篇文章!

下一篇文章:ESFramework介绍之(15)-- IRAS

上一篇文章:ESFramework介绍之(13)-- 功能插件处理器工厂

转到  :ESFramework 可复用的通信框架(序) 

目录
相关文章
|
6月前
|
设计模式 算法 测试技术
C++ 创建兼容多个IPC机制的上层接口
C++ 创建兼容多个IPC机制的上层接口
124 1
|
6月前
|
编解码 计算机视觉 Python
IPC机制在jetson中实现硬解码视频流数据通信的逻辑解析
IPC机制在jetson中实现硬解码视频流数据通信的逻辑解析
184 0
|
流计算
最简单的 gRPC 教程—2 通信模式
gRPC 包含四种基础的通信模式: • 一元模式(Unary RPC) • 服务器端流 RPC(Server Sreaming RPC) • 客户端流 RPC(Client Streaming RPC) • 双向流 RPC(Bidirectional Streaming RPC)
306 0
|
网络协议 Unix API
iOS进程间的实时通讯方案: local socket(解决扩展和容器应用的实时通讯问题)
iOS进程间的实时通讯方案: local socket(解决扩展和容器应用的实时通讯问题)
391 0
iOS进程间的实时通讯方案: local socket(解决扩展和容器应用的实时通讯问题)
|
JavaScript 网络协议 Java
|
缓存 网络协议 C#
[连载]《C#通讯(串口和网络)框架的设计与实现》- 5.串口和网络统一IO设计
目       录 第五章           串口和网络统一IO设计... 2 5.1           统一IO接口... 2 5.1.1    串口IO.. 4 5.1.2    网络IO.
1579 0
|
缓存 网络协议 Windows
基于 IOCP 的通用异步 Windows Socket TCP 高性能服务端组件的设计与实现
设计概述   服务端通信组件的设计是一项非常严谨的工作,其中性能、伸缩性和稳定性是必须考虑的硬性质量指标,若要把组件设计为通用组件提供给多种已知或未知的上层应用使用,则设计的难度更会大大增加,通用性、可用性和灵活性必须考虑在内。
1419 0
|
网络协议 Windows
通用异步 Windows Socket TCP 客户端组件的设计与实现
编写 Windows Socket TCP 客户端其实并不困难,Windows 提供了6种 I/O 通信模型供大家选择。但本座看过很多客户端程序都把 Socket 通信和业务逻辑混在一起,剪不断理还乱。
1085 0
|
Unix API 网络协议
《UNIX网络编程 卷1:套接字联网API(第3版)》——8.6 UDP回射客户程序:dg_cli函数
我们的客户尚未请求内核给它的套接字指派一个临时端口。(对于TCP客户而言,我们说过connect调用正是这种指派发生之处。)对于一个UDP套接字,如果其进程首次调用sendto时它没有绑定一个本地端口,那么内核就在此时为它选择一个临时端口。跟TCP一样,客户可以显式地调用bind,不过很少这样做。
1764 0
|
JavaScript 网络协议 Unix
《UNIX网络编程 卷1:套接字联网API(第3版)》——8.12 dg_cli函数(修订版)
所做的修改是调用connect,并以read和write调用代替sendto和recvfrom调用。该函数不查看传递给connect的套接字地址结构的内容,因此它仍然是协议无关的。图8-7中的客户程序main函数保持不变。
1600 0