BeetleX

在之前的文章中已经介绍如何使用Beetlex.XRCP组件进行接口/委托远程调用；由于组件BeetleX.XRPC.Clients支持.NETStandard2，因此Xamarin同样可以使用它来实现基于接口/委托的数据交互通讯。 接下来通过Xamarin实现一个简单的移动程序，并通过XRPC的功能基于远程接口调用的方式登陆到服务端，然后再通过委托远程调用的方式来相互获取对方的系统和时间信息。 服务端定义 服务主要定义一个用户接口并实现登陆方法，然后注册一个委托用于返回服务信息和时间给客户端。 class Program { static void Main( string [] args) { var builder = new HostBuilder() .ConfigureServices( ( hostContext, services ) => { //开 services.UseXRPC( s => { s.ServerOptions.LogLevel = BeetleX.EventArgs.LogType.Info; s.ServerOptions.DefaultListen.Port = 9090 ; s.ServerOptions.DefaultListen.SSL = true ; //开启SSL s.ServerOptions.DefaultListen

在之前的文章中已经介绍如何使用Beetlex.XRCP组件进行接口/委托远程调用；由于组件BeetleX.XRPC.Clients支持.NETStandard2，因此Xamarin同样可以使用它来实现基于接口/委托的数据交互通讯。 接下来通过Xamarin实现一个简单的移动程序，并通过XRPC的功能基于远程接口调用的方式登陆到服务端，然后再通过委托远程调用的方式来相互获取对方的系统和时间信息。 服务端定义 服务主要定义一个用户接口并实现登陆方法，然后注册一个委托用于返回服务信息和时间给客户端。 class Program { static void Main(string[] args) { var builder = new HostBuilder() .ConfigureServices((hostContext, services) => { //开 services.UseXRPC( s => { s.ServerOptions.LogLevel = BeetleX.EventArgs.LogType.Info; s.ServerOptions.DefaultListen.Port = 9090; s.ServerOptions.DefaultListen.SSL = true;//开启SSL s.ServerOptions.DefaultListen

最近在测试一个功能代码时发现一个非常奇怪的问题，主要是Task.Run引起一些不符合逻辑的错误，以下针对这一问题排查的总结。 问题代码 可以建个控制台程序来运行以下代码 class Program { static User user = new User(); static void Main(string[] args) { for (int i = 0; i < 50; i++) { Task.Run(user.Init); } System.Threading.Thread.Sleep(-1); } } public class User { private bool mInit = false; private Task OnInit() { Console.WriteLine("User init"); System.Threading.Thread.Sleep(1000); return Task.CompletedTask; } public void Init() { lock (typeof(User)) { if (!mInit) { var task = Task.Run(this.OnInit); if (!task.Wait(5000)) { throw new TimeoutException("user init error!"); } mInit

在编写tcp服务的时候经常需要对服务的基础性能进行一个压力测试，虽然网上这些工具有很多，但具备使用方便和高强度的测试工具则不多。为了方便这方面的高强度压测所以在beetlex的基础扩展这样一个工具。 安装 可以访问https://github.com/beetlex-io/TCPBenchmarks 下载最新版本工作，工具可以运行在linux和windows系统，安装完成后通过浏览器访问相关服务进行操作。 操作 工具提供的操作很简单，只需要简单地添加服务和发送的消息即可对服务进行一个压力测试。具体操作界面如下： 测试方式 工具提供两种测试方式，分别是：请求响应和间隔两种模式。前者是工具收到响应后马上进行下一次数据发送；后者则是每隔指定时间向服务端发送数据。 本地IP选项主要告诉工具由那个IP发起请求，如果测试的连接太多单个IP的端口数满足不了测试的情况下，请根据连接数量来选择多个IP地址。测试工具占用的端口是10000-60000。 高吞吐压测 如果服务端在局域网想测试高吞吐交互则可以选用请求响应模式，这种模式可以具备高强度的压测效果；注意这种测试模式不适合采用大量在连接，只需要适当的连接数量即可。以下用200连接对2K数据进行一个高吞吐测试。 通过测试结果可以看到测的IO读写量和相应的总带宽数。 高连接数压测 有些情况只观察大量在线的情况，不太关注极限吞吐的能力

为了方便压力测试ws服务，Beetlex同样提供相关工具来对ws/wss服务的性能进行测试测试。 安装 可以访问https://github.com/beetlex-io/TCPBenchmarks 下载最新版本工作，工具可以运行在linux和windows系统，安装完成后通过浏览器访问相关服务进行操作。 使用 工具提供的操作很简单，只需要简单地添加服务和发送的消息即可对服务进行一个压力测试。在添加服务的时候可以指定ws对应用的path和相关头信息，如果有需要还可以启用SSL。 消息类型 工具发送的消息有两种类型:utf8和hex,分别对应websocket数据包类型的text和binary。 测试方式 工具提供两种测试方式，分别是：请求响应和间隔两种模式。前者是工具收到响应后马上进行下一次数据发送；后者则是每隔指定时间向服务端发送数据。 本地IP选项主要告诉工具由那个IP发起请求，如果测试的连接太多单个IP的端口数满足不了测试的情况下，请根据连接数量来选择多个IP地址。测试工具占用的端口是10000-60000。 高吞吐压测 如果服务端在局域网想测试高吞吐交互则可以选用请求响应模式，这种模式可以具备高强度的压测效果；注意这种测试模式不适合采用大量在连接，只需要适当的连接数量即可。以下用200连接对2K数据进行一个高吞吐测试。 高连接数压测 有些情况只观察大量在线的情况

BeetleX组件提供了HTTP网关组件，但使用过程中需要自己写宿主程序来启动它。为了更好的直接使用，组件发布了一个基于.net core 3.1的可运行版本程序并集成了管理插件；只需下载程序即可以在linux或windows下部署一个HTTP网关部署。 部署安装 运行环境 安装有.net core 3.1的linux或windows操作系统 下载 https://github.com/IKende/Bumblebee/releases/download/1.4.2.3/netcore31_1.4.2.3.zip 安装运行 解压运行包后，可以通过以下命令运行服务 dotnet BeetleX.HttpGatewayApp.dll 运行后会显示以下日志 程序默认是启用80端口，如果想更改可以修改HttpConfig.json配置文件。 运行成功后可以通过访问以下地址进入管理界面 http://localhost/__system/bumblebee/index.html 使用介绍 登陆 网关管理功能只有涉及到操作的情况才需要登陆，默认登陆用户名/密码:admin/123456 如果需要修改密可以在Options功能里进行修改 如果有必要可以把Token key值也重新生成一下。 服务器添加 网关使用第一步是添加可访问的HTTP服务应用

Websocket应用协议已经普及多年了，它是HTTP1.1的内部升级协议，主要作用是补充HTTP1.1无法灵活地主动推送消息给客户端的缺陷问题。在这里主要介绍一下使用组件如何扩展一个完整的Websocket协议。 协议介绍 Websocket并不复杂，但协议文档内容还是很全面的，以下是协议原文 https://tools.ietf.org/html/rfc6455。其实一个简单的图可以看出Websocket协议结构。 在这里主要介绍组件是如何实现的就不详细介绍内容了。 存储顺序 在协议中有一个地方需要关注存储顺序，那就是消息长度描述。不同语言平台对于基础值类型的存储顺序都不一样分别是：大端和小端。这个协议使用的是大端存储顺序，但.NET则是使用小端存储顺序；所以使用组件解Weboskcet协议前要更改一下流读写的存储顺序。 IServer.Options.LittleEndian = false ; 组件可以通过配置来统一更改网络流针对大小端读写配置，应用中也可以默认用小端读出来后再移位转换也是可以。 分析状态 虽然Websocket已经有协议描述，但在分析过程中还是需要一些状态来处理。在TCP流中无法知道当前buffer里的情况，有可能不到一个消息帧，或存在多个消息帧；更有可能当前流的尾部可能只两个字节内容的playload len 127的情况；为了应对存在不同状态的网络流

对于 BeetleX 来说编写 WebSocket 服务是一件非常简单的事情，当你实现一个 Web Api 应用的同时这些API方法也是 WebSocket 服务方法。接下来主要讲解如何通过JavaScript调用 BeetleX 的 WebSocket 服务方法或定义一个适合自己数据格式的 WebSocket 服务。 引用组件 通过Nuget引用最新版本的 BeetleX.FastHttpApi 或通过下载源码编译组件 实现服务 由于组件支持基于类方法的方式来制定服务，所以定义一个服务非常简单，以下是一个基于 Websocket 的 hello world 服务： [BeetleX.FastHttpApi.Controller] class Program { private static BeetleX.FastHttpApi.HttpApiServer mApiServer; static void Main( string [] args) { mApiServer = new BeetleX.FastHttpApi.HttpApiServer(); mApiServer.Debug(); mApiServer.Register( typeof (Program).Assembly); mApiServer.Open(); Console.Write(mApiServer

Websocket应用协议已经普及多年了，它是HTTP1.1的内部升级协议，主要作用是补充HTTP1.1无法灵活地主动推送消息给客户端的缺陷问题。在这里主要介绍一下使用组件如何扩展一个完整的Websocket协议。 协议介绍 Websocket并不复杂，但协议文档内容还是很全面的，以下是协议原文 https://tools.ietf.org/html/rfc6455。其实一个简单的图可以看出Websocket协议结构。 在这里主要介绍组件是如何实现的就不详细介绍内容了。 存储顺序 在协议中有一个地方需要关注存储顺序，那就是消息长度描述。不同语言平台对于基础值类型的存储顺序都不一样分别是：大端和小端。这个协议使用的是大端存储顺序，但.NET则是使用小端存储顺序；所以使用组件解Weboskcet协议前要更改一下流读写的存储顺序。 IServer.Options.LittleEndian = false; 组件可以通过配置来统一更改网络流针对大小端读写配置，应用中也可以默认用小端读出来后再移位转换也是可以。 分析状态 虽然Websocket已经有协议描述，但在分析过程中还是需要一些状态来处理。在TCP流中无法知道当前buffer里的情况，有可能不到一个消息帧，或存在多个消息帧；更有可能当前流的尾部可能只两个字节内容的playload len 127的情况；为了应对存在不同状态的网络流

在网络通讯应用中直接操作数据流是比较繁琐的事情，毕竟在业务层面处理的都是对象化消息；为了让网络数据操作变得更友好直观，一般都会引用序列化组件来处理网络流和对象之前的转换工作；在这里介绍组件如何使能Protobuf进行数据交互通讯。 协议定义 组件使用对象处理就不同之前HelloWorld示例一样简单操作流就可以，在这里需要进一步封装一个简单的应用协议。 |-----------------------------------------------------------------| |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 | |----------------------------------------------------------------| |Probobuf数据流长度,占4字节 | |----------------------------------------------------------------| |Protobuf数据流 | |----------------------------------------------------------------| 以上是一个简单的应用协议，消息头4字节描述消息的长度