皮皮网

1.屏幕取词
2.windows下paho.mqtt安装教程（C/C++）
3.org.eclipse.paho.client.mqttv3和emqx的源码关系是什么?
4.EMQX-简介、安装部署、源码基础功能、源码python代码测试
5.JMeter 扩展开发：自定义 Java Sampler

屏幕取词

       â€œé¼ æ ‡å±å¹•å–词”技术是在电子字典中得到广泛地应用的，如四通利方和金山词霸等软件，这个技术看似简单，其实在WINDOWS系统中实现却是非常复杂的，总的来说有两种实现方式：

        第一种：采用截获对部分GDI的API调用来实现,源码如TextOut,TextOutA等。

        第二种：对每个设备上下文(DC)做一分Copy,并跟踪所有修改上下文(DC)的操作。

        第二种方法更强大,但兼容性不好，而第一种方法使用的截获WindowsAPI的调用，这项技术的强大可能远远超出了您的想象，毫不夸张的说，利用WindowsAPI拦截技术，你可以改造整个操作系统，事实上很多外挂式Windows中文平台就是这么实现的！而这项技术也正是这篇文章的主题。

        截WindowsAPI的调用，具体的说来也可以分为两种方法：

        第一种方法通过直接改写WinAPI 在内存中的映像，嵌入汇编代码，使之被调用时跳转到指定的地址运行来截获；第二种方法则改写IAT（Import Address Table 输入地址表），重定向WinAPI函数的调用来实现对WinAPI的截获。

        第一种方法的实现较为繁琐，而且在Win、下面更有难度，这是因为虽然微软说WIN的API只是为了兼容性才保留下来，程序员应该尽可能地调用位的API,实际上根本就不是这样！WIN 9X内部的大部分位API经过变换调用了同名的位API，也就是说我们需要在拦截的函数中嵌入位汇编代码！

        我们将要介绍的是第二种拦截方法，这种方法在Win、和NT下面运行都比较稳定，兼容性较好。由于需要用到关于Windows虚拟内存的管理、打破进程边界墙、向应用程序的进程空间中注入代码、PE（Portable Executable）文件格式和IAT（输入地址表）等较底层的知识，所以我们先对涉及到的这些知识大概地做一个介绍，最后会给出拦截部分的关键代码。

        先说Windows虚拟内存的管理。Windows9X给每一个进程分配了4GB的地址空间，对于NT来说，这个数字是2GB，系统保留了2GB到 4GB之间的地址空间禁止进程访问，而在Win9X中，2GB到4GB这部分虚拟地址空间实际上是由所有的WIN进程所共享的，这部分地址空间加载了共享Win DLL、内存映射文件和VXD、内存管理器和文件系统码，Win9X中这部分对于每一个进程都是可见的，这也是Win9X操作系统不够健壮的原因。

        Win9X中为位操作系统保留了0到4MB的地址空间，而在4MB到2GB之间也就是Win进程私有的地址空间，由于 每个进程的地址空间都是相对独立的，也就是说，如果程序想截获其它进程中的API调用，就必须打破进程边界墙，向其它的进程中注入截获API调用的代码，这项工作我们交给钩子函数（SetWindowsHookEx）来完成，关于如何创建一个包含系统钩子的动态链接库，《电脑高手杂志》已经有过专题介绍了，这里就不赘述了。

        所有系统钩子的函数必须要在动态库里，这样的话，当进程隐式或显式调用一个动态库里的函数时，系统会把这个动态库映射到这个进程的虚拟地址空间里，这使得DLL成为进程的一部分，以这个进程的身份执行，使用这个进程的堆栈，也就是说动态链接库中的代码被钩子函数注入了其它GUI进程的地址空间（非GUI进程，钩子函数就无能为力了），当包含钩子的DLL注入其它进程后，就可以取得映射到这个进程虚拟内存里的各个模块（EXE和DLL）的基地址，如：

       HMODULE hmodule=GetModuleHandle(“Mypro.exe”);

        在MFC程序中,我们可以用AfxGetInstanceHandle()函数来得到模块的基地址。EXE和DLL被映射到虚拟内存空间的什么地方是由它们的基地址决定的。它们的基地址是在链接时由链接器决定的。当你新建一个Win工程时，VC＋＋链接器使用缺省的基地址0x。可以通过链接器的BASE选项改变模块的基地址。EXE通常被映射到虚拟内存的0x处，DLL也随之有不同的基地址，通常被映射到不同进程的相同的虚拟地址空间处。

        系统将EXE和DLL原封不动映射到虚拟内存空间中，它们在内存中的结构与磁盘上的静态文件结构是一样的。即PE (Portable Executable) 文件格式。我们得到了进程模块的基地址以后，就可以根据PE文件的格式穷举这个模块的IMAGE_IMPORT_DESCRIPTOR数组，看看进程空间中是否引入了我们需要截获的函数所在的动态链接库，比如需要截获“TextOutA”，就必须检查“Gdi.dll”是否被引入了。

        说到这里，我们有必要介绍一下PE文件的格式，如右图，这是PE文件格式的大致框图，最前面是文件头，我们不必理会，从PE File Optional Header后面开始，就是文件中各个段的说明，说明后面才是真正的段数据，而实际上我们关心的只有一个段，那就是“.idata”段，这个段中包含了所有的引入函数信息，还有IAT（Import Address Table）的RVA（Relative Virtual Address）地址。

        说到这里，截获WindowsAPI的整个原理就要真相大白了。实际上所有进程对给定的API函数的调用总是通过PE文件的一个地方来转移的，这就是一个该模块(可以是EXE或DLL)的“.idata”段中的IAT输入地址表（Import Address Table）。在那里有所有本模块调用的其它DLL的函数名及地址。对其它DLL的函数调用实际上只是跳转到输入地址表，由输入地址表再跳转到DLL真正的函数入口。

        具体来说，我们将通过IMAGE_IMPORT_DESCRIPTOR数组来访问“.idata”段中引入的DLL的信息，然后通过IMAGE_THUNK_DATA数组来针对一个被引入的DLL访问该DLL中被引入的每个函数的信息，找到我们需要截获的函数的跳转地址，然后改成我们自己的函数的地址……具体的做法在后面的关键代码中会有详细的讲解。

        讲了这么多原理，现在让我们回到“鼠标屏幕取词”的专题上来。除了API函数的截获，要实现“鼠标屏幕取词”，还需要做一些其它的工作，简单的说来，可以把一个完整的取词过程归纳成以下几个步骤：

        1． 安装鼠标钩子，通过钩子函数获得鼠标消息。

        使用到的API函数：SetWindowsHookEx

        2． 得到鼠标的当前位置，向鼠标下的窗口发重画消息，让它调用系统函数重画窗口。

        使用到的API函数：WindowFromPoint，ScreenToClient，InvalidateRect

        3． 截获对系统函数的调用，取得参数，也就是我们要取的词。

        对于大多数的Windows应用程序来说，如果要取词，我们需要截获的是“Gdi.dll”中的“TextOutA”函数。

        我们先仿照TextOutA函数写一个自己的MyTextOutA函数，如：

       BOOL WINAPI MyTextOutA(HDC hdc, int nXStart, int nYStart, LPCSTR lpszString,int cbString)

       {

       // 这里进行输出lpszString的处理

       // 然后调用正版的TextOutA函数

       }

        把这个函数放在安装了钩子的动态连接库中，然后调用我们最后给出的HookImportFunction函数来截获进程对TextOutA函数的调用，跳转到我们的MyTextOutA函数，完成对输出字符串的捕捉。

        HookImportFunction的用法：

       HOOKFUNCDESC hd;

       PROC pOrigFuns;

       hd.szFunc="TextOutA";

       hd.pProc=(PROC)MyTextOutA;

       HookImportFunction (AfxGetInstanceHandle(),"gdi.dll",&hd,pOrigFuns);

        下面给出了HookImportFunction的源代码，相信详尽的注释一定不会让您觉得理解截获到底是怎么实现的很难，Ok,Let’s Go：

       ///////////////////////////////////////////// Begin ///////////////////////////////////////////////////////////////

       #include <crtdbg.h>

       // 这里定义了一个产生指针的宏

       #define MakePtr(cast, ptr, AddValue) (cast)((DWORD)(ptr)+(DWORD)(AddValue))

       // 定义了HOOKFUNCDESC结构,我们用这个结构作为参数传给HookImportFunction函数

       typedef struct tag_HOOKFUNCDESC

       {

       LPCSTR szFunc; // The name of the function to hook.

       PROC pProc; // The procedure to blast in.

       } HOOKFUNCDESC , * LPHOOKFUNCDESC;

       // 这个函数监测当前系统是否是WindowNT

       BOOL IsNT();

       // 这个函数得到hModule -- 即我们需要截获的函数所在的DLL模块的引入描述符(import descriptor)

       PIMAGE_IMPORT_DESCRIPTOR GetNamedImportDescriptor(HMODULE hModule, LPCSTR szImportModule);

       // 我们的主函数

       BOOL HookImportFunction(HMODULE hModule, LPCSTR szImportModule,

       LPHOOKFUNCDESC paHookFunc, PROC* paOrigFuncs)

       {

       /////////////////////// 下面的代码检测参数的有效性 ////////////////////////////

       _ASSERT(szImportModule);

       _ASSERT(!IsBadReadPtr(paHookFunc, sizeof(HOOKFUNCDESC)));

       #ifdef _DEBUG

       if (paOrigFuncs) _ASSERT(!IsBadWritePtr(paOrigFuncs, sizeof(PROC)));

       _ASSERT(paHookFunc.szFunc);

       _ASSERT(*paHookFunc.szFunc != '\0');

       _ASSERT(!IsBadCodePtr(paHookFunc.pProc));

       #endif

       if ((szImportModule == NULL) || (IsBadReadPtr(paHookFunc, sizeof(HOOKFUNCDESC))))

       {

       _ASSERT(FALSE);

       SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);

       return FALSE;

       }

       //////////////////////////////////////////////////////////////////////////////

       // 监测当前模块是否是在2GB虚拟内存空间之上

       // 这部分的地址内存是属于Win进程共享的

       if (!IsNT() && ((DWORD)hModule >= 0x))

       {

       _ASSERT(FALSE);

       SetLastErrorEx(ERROR_INVALID_HANDLE, SLE_ERROR);

       return FALSE;

       }

       // 清零

       if (paOrigFuncs) memset(paOrigFuncs, NULL, sizeof(PROC));

       // 调用GetNamedImportDescriptor()函数,来得到hModule -- 即我们需要

       // 截获的函数所在的DLL模块的引入描述符(import descriptor)

       PIMAGE_IMPORT_DESCRIPTOR pImportDesc = GetNamedImportDescriptor(hModule, szImportModule);

       if (pImportDesc == NULL)

       return FALSE; // 若为空,则模块未被当前进程所引入

       // 从DLL模块中得到原始的THUNK信息,因为pImportDesc->FirstThunk数组中的原始信息已经

       // 在应用程序引入该DLL时覆盖上了所有的引入信息,所以我们需要通过取得pImportDesc->OriginalFirstThunk

       // 指针来访问引入函数名等信息

       PIMAGE_THUNK_DATA pOrigThunk = MakePtr(PIMAGE_THUNK_DATA, hModule,

       pImportDesc->OriginalFirstThunk);

       // 从pImportDesc->FirstThunk得到IMAGE_THUNK_DATA数组的指针,由于这里在DLL被引入时已经填充了

       // 所有的引入信息,所以真正的截获实际上正是在这里进行的

       PIMAGE_THUNK_DATA pRealThunk = MakePtr(PIMAGE_THUNK_DATA, hModule, pImportDesc->FirstThunk);

       // 穷举IMAGE_THUNK_DATA数组,寻找我们需要截获的函数,这是最关键的部分!

       while (pOrigThunk->u1.Function)

       {

       // 只寻找那些按函数名而不是序号引入的函数

       if (IMAGE_ORDINAL_FLAG != (pOrigThunk->u1.Ordinal & IMAGE_ORDINAL_FLAG))

       {

       // 得到引入函数的函数名

       PIMAGE_IMPORT_BY_NAME pByName = MakePtr(PIMAGE_IMPORT_BY_NAME, hModule,

       pOrigThunk->u1.AddressOfData);

       // 如果函数名以NULL开始,跳过,继续下一个函数

       if ('\0' == pByName->Name[0])

       continue;

       // bDoHook用来检查是否截获成功

       BOOL bDoHook = FALSE;

       // 检查是否当前函数是我们需要截获的函数

       if ((paHookFunc.szFunc[0] == pByName->Name[0]) &&

       (strcmpi(paHookFunc.szFunc, (char*)pByName->Name) == 0))

       {

       // 找到了!

       if (paHookFunc.pProc)

       bDoHook = TRUE;

       }

       if (bDoHook)

       {

       // 我们已经找到了所要截获的函数,那么就开始动手吧

       // 首先要做的是改变这一块虚拟内存的内存保护状态,让我们可以自由存取

       MEMORY_BASIC_INFORMATION mbi_thunk;

       VirtualQuery(pRealThunk, &mbi_thunk, sizeof(MEMORY_BASIC_INFORMATION));

       _ASSERT(VirtualProtect(mbi_thunk.BaseAddress, mbi_thunk.RegionSize,

       PAGE_READWRITE, &mbi_thunk.Protect));

       // 保存我们所要截获的函数的正确跳转地址

       if (paOrigFuncs)

       paOrigFuncs = (PROC)pRealThunk->u1.Function;

       // 将IMAGE_THUNK_DATA数组中的函数跳转地址改写为我们自己的函数地址!

       // 以后所有进程对这个系统函数的所有调用都将成为对我们自己编写的函数的调用

       pRealThunk->u1.Function = (PDWORD)paHookFunc.pProc;

       // 操作完毕!将这一块虚拟内存改回原来的保护状态

       DWORD dwOldProtect;

       _ASSERT(VirtualProtect(mbi_thunk.BaseAddress, mbi_thunk.RegionSize,

       mbi_thunk.Protect, &dwOldProtect));

       SetLastError(ERROR_SUCCESS);

       return TRUE;

       }

       }

       // 访问IMAGE_THUNK_DATA数组中的下一个元素

       pOrigThunk++;

       pRealThunk++;

       }

       return TRUE;

       }

       // GetNamedImportDescriptor函数的实现

       PIMAGE_IMPORT_DESCRIPTOR GetNamedImportDescriptor(HMODULE hModule, LPCSTR szImportModule)

       {

       // 检测参数

       _ASSERT(szImportModule);

       _ASSERT(hModule);

       if ((szImportModule == NULL) || (hModule == NULL))

       {

       _ASSERT(FALSE);

       SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);

       return NULL;

       }

       // 得到Dos文件头

       PIMAGE_DOS_HEADER pDOSHeader = (PIMAGE_DOS_HEADER) hModule;

       // 检测是否MZ文件头

       if (IsBadReadPtr(pDOSHeader, sizeof(IMAGE_DOS_HEADER)) ||

       (pDOSHeader->e_magic != IMAGE_DOS_SIGNATURE))

       {

       _ASSERT(FALSE);

       SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);

       return NULL;

       }

       // 取得PE文件头

       PIMAGE_NT_HEADERS pNTHeader = MakePtr(PIMAGE_NT_HEADERS, pDOSHeader, pDOSHeader->e_lfanew);

       // 检测是否PE映像文件

       if (IsBadReadPtr(pNTHeader, sizeof(IMAGE_NT_HEADERS)) ||

       (pNTHeader->Signature != IMAGE_NT_SIGNATURE))

       {

       _ASSERT(FALSE);

       SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);

       return NULL;

       }

       // 检查PE文件的引入段(即 .idata section)

       if (pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress == 0)

       return NULL;

       // 得到引入段(即 .idata section)的指针

       PIMAGE_IMPORT_DESCRIPTOR pImportDesc = MakePtr(PIMAGE_IMPORT_DESCRIPTOR, pDOSHeader,

       pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);

       // 穷举PIMAGE_IMPORT_DESCRIPTOR数组寻找我们需要截获的函数所在的模块

       while (pImportDesc->Name)

       {

       PSTR szCurrMod = MakePtr(PSTR, pDOSHeader, pImportDesc->Name);

       if (stricmp(szCurrMod, szImportModule) == 0)

       break; // 找到!中断循环

       // 下一个元素

       pImportDesc++;

       }

       // 如果没有找到,说明我们寻找的模块没有被当前的进程所引入!

       if (pImportDesc->Name == NULL)

       return NULL;

       // 返回函数所找到的模块描述符(import descriptor)

       return pImportDesc;

       }

       // IsNT()函数的实现

       BOOL IsNT()

       {

       OSVERSIONINFO stOSVI;

       memset(&stOSVI, NULL, sizeof(OSVERSIONINFO));

       stOSVI.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

       BOOL bRet = GetVersionEx(&stOSVI);

       _ASSERT(TRUE == bRet);

       if (FALSE == bRet) return FALSE;

       return (VER_PLATFORM_WIN_NT == stOSVI.dwPlatformId);

       }

       /////////////////////////////////////////////// End //////////////////////////////////////////////////////////////////////

       ä¸çŸ¥é“在之前，有多少朋友尝试过去实现“鼠标屏幕取词”这项充满了挑战的技术，也只有尝试过的朋友才能体会到其间的不易，尤其在探索API函数的截获时，手头的几篇资料没有一篇是涉及到关键代码的，重要的地方都是一笔代过，MSDN更是显得苍白而无力，也不知道除了IMAGE_IMPORT_DESCRIPTOR和IMAGE_THUNK_DATA，微软还隐藏了多少秘密，好在硬着头皮还是把它给攻克了，希望这篇文章对大家能有所帮助。

windows下paho.mqtt安装教程（C/C++）

       （1）Github仓库地址：

       C库：

       C++库：

       （2）Visual Studio （社区版即可）

       （3）CMake

       选择最新版本的Installer即可：

       安装过程比较简单，一路next，源码注意把CMake加到系统路径里即可：

       2、源码滴滴打车脚本源码编译C库

       这里的源码主要步骤均来自于仓库的readme。

       首先clone源码到本地文件夹，源码例如MQTT\paho.mqtt.c ，源码它包含几个文件夹：

       然后打开CMake客户端，源码需要依次完成以下步骤：

       （1）选择源代码路径，源码也就是源码source code：

       这个路径就是上面clone的路径。

       （2）选择输出路径，源码CMake会将生成的源码vs工程保存在这个路径下，这里为了方便，源码可以直接在源码路径下新建一个文件夹，例如build:

       （3）配置configure，点开后如下：

       第一个是选择VS的版本，一般选择比较高的即可，这里是。然后选择输出平台，可根据情况选择x或win。这里没有特殊参数，就可以忽略Optional toolset...，然后选择下面的工具链为跨平台：

       整体的选择如下：

       然后点击Next，选择cmke文件夹下的toolchain：

       这里根据前面选择的输出平台选择win或者，然后点击完成。

       CMake界面如下，显示配置完成：

       然后可以看到一大片红色区域，它是CMake的编译选项，这里主要关注一下PAHO即可，点击展开后，有如下选项：

       这些选项都很好理解，可以看仓库的介绍，这里截取一部分如下：

       这里注意，选择的PAHO_BUILD_SHARED或者 PAHO_BUILD_STATIC最好是和后面编译C++版本的选项要一致。我这里选择SHARED。

       这里要注意一点，权限管理源码vnext记住这个路径，后面编译C++库会用到：

       （4）点击生成（Generate），产生VS工程目录，位置在第（2）步选择的那个路径。

       然后就可以通过VS编译了，完成后，可以看到

       这些是编译C++库需要的一些文件。

       最后一步：安装生成的这些库文件，方便后续编译C++库文件。

       首先在源码路径打开命令行窗口或者powershell，输入如下命令，并执行：

       这一步的意义是把编译出的文件安装到指定的目录，这个目录就是第（3）步末尾提示的那个CMAKE_INSTALL_PREFIX路径，后面编译C++库文件时会用到，当然也可以在CMake中指定别的目录，如果默认的这个目录需要管理员权限才能创建，可以选择一个普通的目录（当然也可以管理员权限运行这条命令）。

       这个目录下的文件如图：

       后面会用到\lib\cmake\eclipse-paho-mqtt-c路径下的几个文件。

       3、编译C++库

       同样先把源码clone下来，然后打开CMake，按照上面编译C库的方式设置那些选项，但不需要设置工具链，直接默认即可。

       点击完成后会报错：

       原因是没找到eclipse-paho-mqtt-c，它就是刚刚要设置的C库安装目录，找到设置这个路径的CMake的选项如下，填上C库的安装目录：

       然后重新配置，就成功了。

       下一步点击生成，会报新的错误：

       原因是CMakeList里行报错：

       这里是要编译静态库版本，这与C库生成的不符合，直接把这个if编译选项去掉即可。

       再次尝试又会报错：

       原因是CMakeList选择的是security版本，这里在git仓库也有描述：

       所以，我们看C库的安装目录下是哪个，就把CMakeList里替换掉：

       将eclipse-paho-mqtt-c::paho-mqtt3as替换为eclipse-paho-mqtt-c::paho-mqtt3a 就大功告成，淘宠商城源码点击生成，就全部完成了，打开生成的VS工程，编译。

       整个过程要注意的是：C库的编译选项和C++库的编译选项最好保持一致。

org.eclipse.paho.client.mqttv3和emqx的关系是什么?

       EMQX，全球领先的MQTT消息服务器，作为开放源代码分布式MQTT代理在全球享有盛誉，其官网提供了详尽的文档与技术支持，帮助开发者深入理解其功能与特性。

       在GitHub上，EMQX的项目地址吸引了众多开发者关注，开源社区的活跃为项目持续贡献与优化提供了强大动力。

       而org.eclipse.paho.client.mqttv3是用Java编写的MQTT客户端SDK，专为开发自定义的MQTT客户端应用程序而设计。它与EMQX协同工作，使得开发者能够轻松构建基于MQTT的实时数据传输解决方案。

       组织上，org.eclipse.paho.client.mqttv3和EMQX之间不存在直接隶属关系，但它们在MQTT生态系统中紧密合作。开发者可以使用paho客户端SDK连接到EMQX服务器，实现消息的发送与接收。通过这种方式，paho SDK成为了EMQX生态系统的一部分，增强了其在物联网、实时通信等场景中的应用能力。

       总的来说，EMQX提供了一个强大的MQTT消息传递平台，而org.eclipse.paho.client.mqttv3则作为一个灵活的客户端工具，与EMQX结合，为开发者提供了实现高效实时通信的完整解决方案。这种协同工作模式使得它们在各自领域内都发挥着重要作用，共同推动了MQTT技术的发展。

EMQX-简介、安装部署、基础功能、python代码测试

       MQTT属于是引流网站 源码物联网的通信协议，在MQTT协议中有两大角色：客户端（发布者/订阅者），服务端（Mqtt broker）；针对客户端和服务端需要有遵循该协议的的具体实现，EMQ/EMQX就是MQTT Broker的一种实现。

       EMQX是基于 Erlang/OTP 平台开发的 MQTT 消息服务器，是开源社区中最流行的 MQTT 消息服务器。EMQ X 是开源百万级分布式 MQTT 消息服务器（MQTT Messaging Broker），用于支持各种接入标准 MQTT协议的设备，实现从设备端到服务器端的消息传递，以及从服务器端到设备端的设备控制消息转发。从而实现物联网设备的数据采集，和对设备的操作和控制。

       到目前为止，比较流行的 MQTT Broker 有几个：使用 C 语言实现的 MQTT Broker，使用 Erlang 语言开发的 MQTT Broker，使用 Node.JS 开发的 MQTT Broker，同样使用 Erlang 开发的 MQTT Broker。从支持 MQTT5.0、稳定性、扩展性、集群能力等方面考虑，EMQX 的表现应该是最好的。

       与别的MQTT服务器相比EMQ X 主要有以下的特点：经过+版本的迭代，EMQ X 目前为开源社区中最流行的 MQTT 消息中间件，在各种客户严格的生产环境上经受了严苛的考验；支持丰富的物联网协议，包括 MQTT、MQTT-SN、CoAP、 LwM2M、LoRaWAN 和 WebSocket等；优化的架构设计，支持超大规模的设备连接。企业版单机能支持百万的 MQTT 连接；集群能支持千万级别的 MQTT 连接；易于安装和使用；灵活的扩展性，支持企业的一些定制场景；中国本地的技术支持服务，通过微信、QQ等线上渠道快速响应客户需求；基于 Apache 2.0 协议许可，完全开源。EMQ X 的代码都放在 Github 中，用户可以查看所有源代码；EMQ X 3.0 支持 MQTT 5.0 协议，通信达源码安装是开源社区中第一个支持 5.0协议规范的消息服务器，并且完全兼容 MQTT V3.1 和 V3.1.1 协议。除了 MQTT 协议之外，EMQ X 还支持别的一些物联网协议；单机支持百万连接，集群支持千万级连接；毫秒级消息转发。EMQ X 中应用了多种技术以实现上述功能；利用 Erlang/OTP 平台的软实时、高并发和容错（电信领域久经考验的语言）；全异步架构；连接、会话、路由、集群的分层设计；消息平面和控制平面的分离等；扩展模块和插件，EMQ X 提供了灵活的扩展机制，可以实现私有协议、认证鉴权、数据持久化、桥接发和管理控制台等的扩展；桥接：EMQ X 可以跟别的消息系统进行对接，比如 EMQ X Enterprise 版本中可以支持将消息转发到 Kafka、RabbitMQ 或者别的 EMQ 节点等；共享订阅：共享订阅支持通过负载均衡的方式在多个订阅者之间来分发 MQTT 消息。比如针对物联网等 数据采集场景，会有比较多的设备在发送数据，通过共享订阅的方式可以在订阅端设置多个订阅者来实现这几个订阅者之间的工作负载均衡。

       典型的物联网平台包括设备硬件、数据采集、数据存储、分析、Web / 移动应用等。EMQX 位于数据采集这一层，分别与硬件和数据存储、分析进行交互，是物联网平台的核心：前端的硬件通过 MQTT 协议与位于数据采集层的 EMQX 交互，通过 EMQX 将数据采集后，通过 EMQX 提供的数据接口，将数据保存到后台的持久化平台中（各种关系型数据库和 NOSQL 数据库），或者流式数据处理框架等，上层应用通过这些数据分析后得到的结果呈现给最终用户。

       EMQX 公司主要提供三个产品，可在官网首页产品导航查看每一种产品；主要体现在支持的连接数量、产品功能和商业服务等方面的区别。

       完整的 MQTT V3.1/V3.1.1 及 V5.0 协议规范支持；QoS0, QoS1, QoS2 消息支持；持久会话与离线消息支持；Retained 消息支持；Last Will 消息支持；TCP/SSL 连接支持；MQTT/WebSocket/SSL 支持；HTTP 消息发布接口支持；$SYS/# 系统主题支持；客户端在线状态查询与订阅支持；客户端 ID 或 IP 地址认证支持；用户名密码认证支持；LDAP 认证；Redis、MySQL、PostgreSQL、MongoDB、HTTP 认证集成；浏览器 Cookie 认证；基于客户端 ID、IP 地址、用户名的访问控制 (ACL)；多服务器节点集群 (Cluster)；支持 manual、mcast、dns、etcd、k8s 等多种集群发现方式；网络分区自动愈合；消息速率限制；连接速率限制；按分区配置节点；多服务器节点桥接 (Bridge)；MQTT Broker 桥接支持；Stomp 协议支持；MQTT-SN 协议支持；CoAP 协议支持；Stomp/SockJS 支持；延时 Publish ($delay/topic)；Flapping 检测；黑名单支持；共享订阅 ($share/:group/topic)；TLS/PSK 支持；规则引擎；空动作 (调试)；消息重新发布；桥接数据到 MQTT Broker；检查 (调试)；发送数据到 Web 服务。

       EMQ X 目前支持的操作系统：Centos6、Centos7、OpenSUSE tumbleweed、Debian 8、Debian 9、Debian 、Ubuntu .、Ubuntu .、Ubuntu .、macOS .、macOS .、macOS .、Windows Server 。产品部署建议 Linux 服务器，不推荐 Windows 服务器。安装的方式有很多种，可供自由选择：Shell脚本安装、包管理器安装、二进制包安装、ZIP压缩包安装、Homebrew安装、Docker运行安装、Helm安装、源码编译安装。

       Dashboard界面查看基本信息。

       身份认证是大多数应用的重要组成部分，MQTT 协议支持用户名密码认证，启用身份认证能有效阻止非法客户端的连接。EMQ X 中的认证指的是当一个客户端连接到 EMQ X 的时候，通过服务器端的配置来控制客户端连接服务器的权限。EMQ X 的认证支持包括两个层面：MQTT 协议本身在 CONNECT 报文中指定用户名和密码，EMQ X 以插件形式支持基于 Username、ClientID、HTTP、JWT、LDAP 及各类数据库如 MongoDB、MySQL、PostgreSQL、Redis 等多种形式的认证；在传输层上，TLS 可以保证使用客户端证书的客户端到服务器的身份验证，并确保服务器向客户端验证服务器证书。也支持基于 PSK 的 TLS/DTLS 认证。

       EMQ X 支持使用内置数据源（文件、内置数据库）、JWT、外部主流数据库和自定义 HTTP API 作为身份认证数据源。连接数据源、进行认证逻辑通过插件实现的，每个插件对应一种认证方式，使用前需要启用相应的插件。客户端连接时插件通过检查其 username/clientid 和 password 是否与指定数据源的信息一致来实现对客户端的身份认证。（v5.0以上默认集成）EMQ X 支持的认证方式：内置数据源、外部数据库、其他。认证结果：认证成功、认证失败、忽略认证（ignore）。

       EMQ X 默认配置中启用了匿名认证，任何客户端都能接入 EMQ X。没有启用认证插件或认证插件没有显式允许/拒绝（ignore）连接请求时，EMQ X 将根据匿名认证启用情况决定是否允许客户端连接。

       可以订阅多个主题。

       安装 paho-mqtt：导入 Paho MQTT 客户端。

       通过TCP连接：设置 broker、port、topic、client_id，连接 MQTT Broker。

       通过SSL/TLS连接：设置 broker、port、topic、client_id，连接 MQTT Broker，使用 CA certificate，设置用户名密码。

       订阅主题：设置 on_message 回调函数，当收到消息时执行。

       取消订阅：通过以下代码取消订阅，此时应指定取消订阅的主题。

       发布消息：通过以下代码发布消息，设置消息内容、主题，调用 publish 方法。

       接收消息：通过以下代码指定客户端对消息事件进行监听，并在收到消息后执行回调函数，将接收到的消息及其主题打印到控制台。

       断开连接：如客户端希望主动断开连接，可以通过如下代码实现。

       完整代码：导入 random、time、paho.mqtt.client as mqtt_client，设置 broker、port、topic、client_id，连接 MQTT Broker，设置 on_connect 回调函数，设置 publish 回调函数，运行客户端。

JMeter 扩展开发：自定义 Java Sampler

       JMeter 是一个广泛使用的开源性能测试工具，其内置支持了一系列常用的协议，比如 HTTP/HTTPS、FTP、JDBC、JMS、SOAP 和 TCP 等，便于测试场景的编写。然而，对于一些特定需求，用户可能需要测试的协议并未被 JMeter 内置支持，或者在已有协议基础上增加定制化内容。这时，通过自定义 Java Sampler 的方式，用户可以轻松扩展对新协议的支持。本文将详细介绍如何利用 Java Sampler 扩展 JMeter 的协议支持功能。

       Java Sampler 是 JMeter 提供的一种机制，允许用户通过自定义 Java 类来扩展对新协议的支持。这些扩展的协议以“Java请求”的形式加入到测试脚本中，而非针对特定的 Java 协议。

       为了说明如何实现这一扩展，本文将以 MQTT 协议中的连接为例。用户可以通过添加 Java 请求并选择不同的 Java Sampler 来实现对 MQTT 协议的支持。

       在开发 JMeter 插件时，通常无需下载 JMeter 的源代码，只需引用相关的 JMeter 库即可。在此示例中，除了引用 ApacheJMeter_core 外，还需引入支持 MQTT 协议的 Java 类库，如 Eclipse Paho Java MQTT client 库。选择其他 MQTT Java 类库取决于被扩展的协议和协议扩展者的偏好。

       以下是开发自定义 Java Sampler 的步骤，以及如何在 JMeter 中添加 MQTT 连接的示例代码。

       准备开发环境时，确保已准备好了开发所需环境，包括 JMeter 库和其他 MQTT Java 类库的引用。在开发过程中，可以参考 JMeter 扩展开发的其他文章以获取更多细节。

       在开发 Java Sampler 时，主要涉及以下几个关键方法：

runTest 方法：这是扩展协议主体逻辑的核心部分，用于实现协议数据的正确发送和接收。 getDefaultParameters 方法：用于定义默认参数，这些参数将出现在 JMeter Java 请求界面中。如果不需要默认参数，可以跳过此步骤。 setupTest 和 teardownTest 方法：分别用于初始化和清理操作。这两个方法并非必须实现，但可以用于执行额外的准备工作和收尾操作。

       实现 runTest 方法时，主要逻辑包括正确发送协议数据和接收反馈，然后根据接收到的数据设置 SampleResult 对象。对于 MQTT 协议的普通 TCP 连接，可参考提供的代码示例。

       在实现 getDefaultParameters 方法时，可从 JavaSamplerContext 参数中读取连接信息，从而实现脚本编写人员在界面输入参数值的功能。

       编译和部署完成后，将自定义的 Java Sampler 添加到 JMeter 测试脚本中，通过类名称下拉列表框选择新扩展的类。如果未成功显示，可检查 jar 包是否正确复制到 JMeter 的 lib/ext 目录，并查看 JMeter 日志以排除异常。

       通过 Java Sampler 扩展 JMeter 的协议支持功能，实现过程相对简单。然而，这种方式在界面友好性上可能与 JMeter 内置的协议有所差异。后续文章将介绍如何利用 JMeter 更强大的扩展方式来改善这一问题，敬请期待。