基于分布式Http长连接框架--代码模型

好的代码应该是方便客户端使用,代码能够自描述,规范化,大众标准化.

而且我相信代码也是有生命的,需要不断的维护它,你以什么样的态度对待它,它就会以同样的态度回敬你,所以在写代码前,先摆好自己的态度(一个心态良好的创造者),只有这样你的生命才会精彩,代码的生命也会精彩.

前面说了简单的框架模型,简单的设计模型,如果具体到客户端使用的话还需要代码模型来描述下,当作集成的sdk说明即可.

生产者如何发送消息:

1:配置服务端地址及名称;

2:注册本身为客户端,并约定一个全局唯一的名称

3:开启代理

4:使用消息总线发送消息.

代码如下:

ISignalRClient.Config("http://localhost:4681/", "GuitarCometService")
.RegisterClient("App2")
.StartProxy();

IMessageBus.Handle(new MessageEnvelope("App1", "Topic1", messageBody)); // 发送Topic1的消息

消费者如何消费消息:

1:配置服务端地址及名称(和上述一样的);

2:注册本身为客户端,并约定一个全局唯一名称(和上述一样的);

3:订阅消息,可以订阅为同步处理消息,也可以异步.

4:开启代理

代码如下:

ISignalRClient.Config("http://localhost:4681/", "GuitarCometService")
.RegisterClient("App1")
.AsyncSubscriber<ICustomer, Customer01>(_currentContainer, "Topic1")
.SyncSubscriber<ICustomer, Customer02>(_currentContainer, "Topic2")
.StartProxy();

以上就是发送消息和消费消息的代码,很清晰也很简单.

基于分布式Http长连接框架--代码模型

时间: 2024-10-03 23:02:29

基于分布式Http长连接框架--代码模型的相关文章

基于分布式Http长连接框架--架构模型

我画了个简单的架构图来帮助说明: 其实为发布订阅架构模式. 生产者和消费者我们统一可理解为客户端,消息中间件可认为是服务端. 生产者和消费者做为客户端要跟服务端交互,则先通过代理订阅服务端,订阅成功后即可跟服务端互通互联,此刻的连接通道为长连接. 长连接的优势在于会将消息主动通知到客户端,避免客户端去做大量的轮询工作而造成资源浪费,而且对于移动应用来说,可较大程度上节省GPRS流量. 当连接建立好后,生产者可随时发送消息,如果在发消息过程当中,服务端由于各种原因不能连接,则消息的发送会回放重试,

RPC、基于netty的长连接和websocket

1 RPC RPC也采用C/S的编程模式,以模块调用的简单性忽略通讯的具体细节,以便程序员不用关心C/S之间的通讯协议,集中精力对付实现过程.这就决定了 RPC生成的通讯包不可能对每种应用都有最恰当的处理办法,与Socket方法相比,传输相同的有效数据,RPC占用更多的网络带宽. RPC实在socket的基础上实现的,但是它比socket需要更多的网络和资源系统. 2 基于netty的长连接 异步.高性能 Boss线程(一个服务器端口对于一个)---接收到客户端连接---生成Channel---

Java Socket长连接示例代码

SocketListenerPusher.java代码如下: Java代码   import java.io.IOException; import java.net.InetSocketAddress; import java.net.ServerSocket; import java.net.Socket; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import ja

基于Ajax的长连接

JS代码: 1 <script> 2 function longPolling() { 3 $.ajax({ 4 url: "testlp", 5 data: { "time": 2, "timeout": 3 },//time:假设传输数据时间,timenout:最大延迟 6 dataType:'JSON', 7 success: function (data) { 8 //输出data 9 longPolling(); 10 }

Redis实践操作之—— 直播视频定时控制【TCP长连接框架(WorkerMan)+键空间通知的机制 ( Keyspace Notifications)+短信接口(API)】

一.思路梳理 同步直播视频到Redis 用户观看直播模板,点击直播按钮,检查是否有权限. 直播定时免费观看(免费观看10分钟),用户点击播放按钮开始,异步检查获取直播活动设置的免费观看时间(后台维护人员设置,Redis的hash存储信息),是否是直播. 是直播视频:判断该客户是否已经观看过了免费的20分钟时间, 没有看过,则获取该直播视频的免费时间根据活动ID,同时设置该直播视频的过期时间(只针对该用户自己哦),返回个模板,说:这个人可以观看的. 直播视频已经看过了,则不可以继续观看哦!嘻嘻..

Web 通信 之 长连接、长轮询(long polling)(转载)

基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性. 一.什么是长连接.长轮询? 用通俗易懂的话来说,就是客户端不停的向服务器发送请求以获取最新的数据信息.这里的“不停”其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已. 二.长连接.长轮询的应用场景 长连接.长轮询一般应用与WebIM.ChatRoom和一些需要及时交互的网站应用中.其真实案例有:WebQQ

Web 通信 之 长连接、长轮询(long polling)

基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性. 一.什么是长连接.长轮询? 用通俗易懂的话来说,就是客户端不停的向服务器发送请求以获取最新的数据信息.这里的“不停”其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已. 二.长连接.长轮询的应用场景 长连接.长轮询一般应用与WebIM.ChatRoom和一些需要及时交互的网站应用中.其真实案例有:WebQQ

Web 通信 之 长连接、长轮询(转)

Web 通信 之 长连接.长轮询(long polling) 基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性. 一.什么是长连接.长轮询? 用通俗易懂的话来说,就是客户端不停的向服务器发送请求以获取最新的数据信息.这里的"不停"其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已. 二.长连接.长轮询的应用场景 长连接.长轮询一般应用与W

web长连接,长轮询(long polling)

Web 通信 之 长连接.长轮询(long polling) 基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性. 一.什么是长连接.长轮询? 用通俗易懂的话来说,就是客户端不停的向服务器发送请求以获取最新的数据信息.这里的“不停”其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已. 二.长连接.长轮询的应用场景 长连接.长轮询一般应用与WebIM.ChatR