hstb1230/http-to-cq

Communicate with CoolQ through HTTP.

http-to-cq's Issues

设置完http地址后点关闭后保存不上

在docker下运行的，找半天不知道什么原因，前来求教

注册不上

{"data":{"Type":,"Group":,"Msg":"FromHttp:"}}Error:由于目标计算机积极拒绝，无法连接。 (10061)

关于消息处理的一点想法

前段时间@ℳℓdhdjℳℓSYS 跟我反馈了一个问题：
当有用户恶意刷消息，导致消息频率变高时，消息的处理时间会越来越长(一条消息光提交的时间就可以高达几秒)。
原本我以为是php后端处理高并发量的影响，但是经过一系列测试，我发现并不是PHP的锅。
第一，收到消息后，插件先将消息内容写到文件后再进行处理。而消息频率的升高，使得该文件处于不断被读写的过程，因而操作时间变长了。
第二，处理消息的过程中，插件会生成一条日志记录，不管是使用酷Q还是插件自带日志，都是需要等到记录被写入文件后(并显示在日志窗口上)才算处理完毕，而这个过程同前面一样影响操作时间。

因此，对新版本做出如下改进：

1. 抛弃原有的写到文件后再处理做法，直接将文本指针传递给线程处理。
2. 生成日志记录时，将同样使用线程完成相应操作，并且加入读写锁避免多个相同操作发生时出错，(以上仅针对插件自带日志)

另外，经过多天的思考，对@ℳℓdhdjℳℓSYS 提出的“限制提交频率”作出一个回应：
因为插件现在使用线程处理消息，那么，在此基础上作一个变动：额外使用一个线程池，这个线程池用来分配消息处理入口，但是并不是所有消息都通过线程池进入处理入口。具体是这样的：限制线程池的线程数量，(即设置线程池掌管的入口数量)。另外设定一个阈值，用来区分正常频率和不正常频率，当 单个消息来源(群/QQ) 处于正常频率时，插件就正常处理(也就是允许不经过线程池就直接进入处理入口)；而当消息频率处于不正常频率范围后(即超过阈值)，插件就将这个消息来源的所有新消息都加入到线程池里，让这些新消息去争夺线程池中有限的处理入口，抢不到的就排队等待，这样既能缓解后端服务器的处理压力，又能保证业务的正常运行。

更换json库

现在使用的json库为JS对象，据一些用户反馈消息量很大时（指同时接收几百个群消息）会消耗大量CPU资源（单核CPU）

提交规则里的正则如何写

.* 还是 /.*/ 都显示此正则表达式不可用

上报参数中增加当前机器人的QQ账号

是否可以在上报的参数中增加当前机器人的QQ账号以支持账号多开