聂永的博客

记录工作/学习的点点滴滴。

我的评论

re: MQTT协议笔记之发布流程 nieyong 2017-01-05 15:20  
@Haven

兄弟,针对QoS2,为了便于说明,我们先假设一个方向,Server -> Client:

----PUBLISH--->
<----PUBREC----
----PUBREL---->
<----PUBCOMP---

1. Server发送PUBLISH消息到Client,Client接收之后需要确认收到嘛,就返回PUBREC吧;但此时Client仅仅是把数据发送出去了而已,至于Server端收不收到那就不得而知
2. Server接收ClientPUBREC消息之后,需要回一个PUBREL消息告诉Client自己收到啦,同样道理也仅仅只是发送出去,Client是不是能收到的这个响应,心里面也没谱呀
3. Client收到来自Server的PUBREL之后,就非常明白自己针对PUBLISH消息做出的PUBREC响应消息在Server端是已经收到啦,但是需要告诉Server,自己收到它的再三确认啦
4. Server端此时等待Client上报PUBCOMP消息,一旦接收到之后,表示针对某个消息双方都再三确认了,这事就没有问题啦

其核心所设定网络是不靠谱的,任何一次发送数据到对端,都有可能因收不到(比如发送之后,某一端断网啦,或中间路由设备因为容量满了抛弃啦)。

好比双发约定一件事:

Server - 我给你说说这件事....
Client - 我同意了你这样做。
Server - 你确定你同意了?
Client - 是的,我同意了。
Server - OK,那这事就这么定了,我知道该怎么做啦。
@王大
当前官方没有打1.6.1包,检出最新代码:https://github.com/processone/tsung 手动编译就是1.6.1了。
@tinsang
针对单台Redis而言,单线程模型。一旦pipeline阻塞了,其它请求会被阻塞住。可考虑单线程操作管道,一个一个批处理。
@tinsang
把较为耗时任务委派到其它线程处理,当前业务线程继续忙别的。
re: MQTT 3.1协议非严肃反思录 nieyong 2015-05-18 16:41  
@kdm
是的,比如根据协议,只需要注册一次,服务器端可持久化topic和clientId的对应关系,后面不需要再次注册等。或者再简单一些,就直接根据clientId作为topic就行。

怎么说呢,越是海量用户/终端的系统,协议交互层面需要越简单,架构层面也是如此。
re: MQTT 3.1协议非严肃反思录 nieyong 2015-05-15 10:04  
@kdm
clientId等同于topic就行
re: MQTT 3.1协议非严肃反思录 nieyong 2015-05-08 09:49  
@kdm
其实,灵活一点是不需要建立10W个topic的,根据clientId就可以
re: MQTT协议笔记之连接和心跳 nieyong 2015-04-23 18:01  
@h2appy
十分感谢,已做修改。希望您以后给我多提改进意见 :))
re: 微信协议简单调研笔记 nieyong 2015-04-17 10:05  
@Leo 理论上是可以的,不同线程/不同组件处理不同事宜,只要不混杂在一起就行。
re: HTTP/2笔记之开篇 nieyong 2015-03-18 14:02  
@simon
线头阻塞,这里指的是多个请求排队等待前面请求完成,后续的请求只有前面的请求完成了,才有机会得到处理。串行化方式,一个一个处理,一旦有阻塞,后续的任务只能被动等待。
HTTP/1.1 pipelining会导致线头阻塞的问题。
re: MQTT协议笔记之连接和心跳 nieyong 2015-03-09 09:43  
@zer0
clientID可以用于授权,若授权不通过(比如检测是否他人没有按照已定义规则生成的的恶意ClientId),可以直接拒绝之。比如在企业/公司内部,用于PUBLISH的MQTT服务器端,可以选择对ClientId进行指定,若非指定值,则属于恶意的ClientId。
re: Fastsocket学习笔记之小结篇 nieyong 2015-02-09 09:40  
@xanpeng
在Linux内核版本 2.6.18 以前,所有监听进程都会被唤醒,但是只有一个进程 accept 成功,其余失败。这就是所谓的惊群效应 。在2.6.18 以后,已得到修复,仅有一个进程被唤醒并accept成功。
@allankliu
第一个问题:一个服务器可以绑定多个端口,每一个端口各司其职即可,但需要应用程序支持才行。但可能会造成功能耦合在了一起。
第二个问题:node.js我不熟,不好回答。

re: MQTT-SN协议乱翻之小结篇 nieyong 2015-01-28 09:41  
@mq
请参考 Mosquitto,RMSB等
@黎洪鑫
没有遇见过类似问题,爱莫能助。
因为pipeline是一个阻塞请求-响应过程,这一点很重要;另外网络机房拥塞会导致非常大的延迟,具体情况就是请求发出去,等待很长时间响应。若是机房网络延迟问题,可以考虑把pipeline异步提交,不要阻塞当前线程。
以上都是建议,仅供参考!
re: shell读文件的方法 nieyong 2015-01-13 17:19  
十分受用,收下了~
re: MQTT 3.1协议非严肃反思录 nieyong 2014-12-18 22:06  
@tangsir
措辞有问题,可不是什么大神,呵呵。
只是总结而已。
re: MQTT 3.1协议非严肃反思录 nieyong 2014-12-17 10:25  
@tangsir
目前除了MQTT,暂时找不到比它更好的业界标准了。建议选择MQTT 3.1.1协议:
支持客户端在发送完毕CONNECT之后,无须等待服务器响应直接发送其余命令
支持服务器和客户端两端暂时会话保存,上次连接之后,再次CONNECT,会话标志位true,可无须发送SUBSCRIBLE命令
具体请参考:
MQTT 3.1.1,值得升级的6个新特性
re: 初探IMEI【译】 nieyong 2014-12-12 10:39  
赞,希望可以看到更多翻译文章,加油!
@全智贤代言
原本应该是8192,65536/8=8192。
其实,传入8102,也未尝不可。
@CharlesSong
记忆力不好,我都忘记具体怎么操作了,亲。
貌似先输入Yes,然后回车。试试看。
@molasses_macaw
收到简历之后,若合适会直接转发给HR,安排具体面试时间。
工作日时间整个审阅过程不会超过3个小时,亲!
欢迎大家自荐和推荐。
推荐的同学若最终上岗,会有一份额外的伯乐奖的 :))
占一个广告位~
北京优酷最近在招移动服务器端JAVA攻城师,有需要的同学(也可以推荐一下),可以发邮件到 yongboyATgmail.com

每日接触海量用户请求,机会、舞台都很不错,欢迎各位不妨考虑一下:))
re: 深入Jetty源码之Server和Container nieyong 2014-05-25 08:11  
亲,北京优酷最近在招移动后端JAVA攻城师,有需要或者可以推荐的,可以发送邮件到 yongboyATgmail.com
re: MQTT协议笔记之消息流 nieyong 2014-03-06 16:23  
@依然清风
要非常清楚总体协议,代码不过是在实现协议。
Client A与Client B,在逻辑上不存在转发。
1. Client A在Broker上订阅/注册Topic M
2. Broker接收包含Topic M的消息,检索所有订阅Topic M的客户端
3. Broker逐一会发送给所有订阅Topic M订阅者/客户端,包括Client A
@goxplanet
更新到最新版吧。
Usage: docker save IMAGE
Save an image to a tar archive (streamed to stdout)
@小孟
问题太模糊,很难清晰定位。服务器端,需要修改两处:
1. 编辑/etc/security/limits.conf文件,添加如下内容
* soft nofile 1048576
* hard nofile 1048576

2. 在/etc/sysctl.conf中添加如下配置:

fs.file-max = 1048576
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_mem = 786432 2097152 3145728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

在测试端,也需要执行两处:
1. 编辑/etc/security/limits.conf文件,添加如下内容

* soft nofile 1048576
* hard nofile 1048576
2. 在/etc/sysctl.conf中添加如下配置:

fs.file-max = 1048576
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_mem = 786432 2097152 3145728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

测试端最重要配置也就是
fs.file-max = 1048576
net.ipv4.ip_local_port_range = 1024 65535

具体问题,请具体定位。
@piboye
正常,发送和接收都得需要,要不就发送或接收不了啦。
@iriyadays
十分高效,谢谢~
re: 高并发web框架基本设计思路 nieyong 2012-06-11 17:13  
为什么要“会单独的使用jsp + servlet实现一个简单的信息发布系统.”,可以讲一下原因吗 ?个人很感兴趣。
@josh
您是什么平台 ?若是android,默认的浏览器不支持websocket协议。
@steven

这个问题,已经在邮件组里面解决了,哈。
具体,请参考
邮件讨论组为
http://groups.google.com/group/socketio-netty
或者
https://groups.google.com/group/socketio-netty
re: 如何熟悉一个开源项目? nieyong 2012-05-24 11:03  
受益良多!
若早点阅读到就更好了哈~
@ge_star
采用Netty,或者http://socket.io,或者http://code.google.com/p/socketio-netty/
或者,直接增加对RCFRFC 6455的支持等。
@文文木
偶不是什么牛,只是大家一起学习,分享心得而已 :))
感觉很罗嗦的。
CAS默认是UTF-8编码,可以不添加Filter,原CAS页面也可以保持不变。
唯一需要变化的是
WEB-INF\view\jsp\protocol\2.0\casServiceValidationSuccess.jsp需要和跳转过去的那个页面的编码一致。
添加:pageEncoding="UTF-8" 或 pageEncoding="GBK" 根据实际情况而定。
@RonQi
暂无在正式环境下使用Servlet3的推送。
不过在现实环境下,有人已经使用golang做服务器,采用长轮询做推送,在实际环境中长轮询使用较多一些。
有关轮询还是推送,可以参考
《Push Or Pull?》
http://rdc.taobao.com/team/jm/archives/918

里面对推送和轮询分别存在的问题,分析的很透彻。
re: XFire开发指南电子书[未登录] nieyong 2007-05-09 17:18  
从昨天晚上开始就看XFire,开始下载《Xfire实战[Web服务开发之旅]》.pdf
现在下班后,又一次看到阁下的文章,可以下载到新的文档~
呵呵,谢谢~

公告

所有文章皆为原创,若转载请标明出处,谢谢~

新浪微博,欢迎关注:

导航

<2018年11月>
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678

统计

常用链接

留言簿(55)

随笔分类(125)

随笔档案(147)

个人收藏

最新随笔

搜索

最新评论

阅读排行榜

评论排行榜