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，那这事就这么定了，我知道该怎么做啦。
re: tsung笔记之ip地址和端口限制突破篇 nieyong 2016-08-19 16:37
@王大
当前官方没有打1.6.1包，检出最新代码： 手动编译就是1.6.1了。
nieyong 2015-06-01 13:58
@wander
可以参考：
这两篇文章 :)
nieyong 2015-05-29 09:52
@tinsang
针对单台redis而言，单线程模型。一旦pipeline阻塞了，其它请求会被阻塞住。可考虑单线程操作管道，一个一个批处理。
nieyong 2015-05-28 17:04
@tinsang
把较为耗时任务委派到其它线程处理，当前业务线程继续忙别的。
nieyong 2015-05-18 16:41
@kdm
是的，比如根据协议，只需要注册一次，服务器端可持久化topic和clientid的对应关系，后面不需要再次注册等。或者再简单一些，就直接根据clientid作为topic就行。
怎么说呢，越是海量用户/终端的系统，协议交互层面需要越简单，架构层面也是如此。
nieyong 2015-05-15 10:04
@kdm
clientid等同于topic就行
nieyong 2015-05-08 09:49
@kdm
其实，灵活一点是不需要建立10w个topic的，根据clientid就可以
nieyong 2015-04-23 18:01
@h2appy
十分感谢，已做修改。希望您以后给我多提改进意见 :))
nieyong 2015-04-17 10:05
@leo 理论上是可以的，不同线程/不同组件处理不同事宜，只要不混杂在一起就行。
nieyong 2015-03-18 14:02
@simon
线头阻塞，这里指的是多个请求排队等待前面请求完成，后续的请求只有前面的请求完成了，才有机会得到处理。串行化方式，一个一个处理，一旦有阻塞，后续的任务只能被动等待。
http/1.1 pipelining会导致线头阻塞的问题。
nieyong 2015-03-09 09:43
@zer0
clientid可以用于授权，若授权不通过（比如检测是否他人没有按照已定义规则生成的的恶意clientid），可以直接拒绝之。比如在企业/公司内部，用于publish的mqtt服务器端，可以选择对clientid进行指定，若非指定值，则属于恶意的clientid。
nieyong 2015-02-09 09:40
@xanpeng
在linux内核版本 2.6.18 以前，所有监听进程都会被唤醒，但是只有一个进程 accept 成功，其余失败。这就是所谓的惊群效应 。在2.6.18 以后，已得到修复，仅有一个进程被唤醒并accept成功。
nieyong 2015-02-05 14:51
@allankliu
第一个问题：一个服务器可以绑定多个端口，每一个端口各司其职即可，但需要应用程序支持才行。但可能会造成功能耦合在了一起。
第二个问题：node.js我不熟，不好回答。
nieyong 2015-01-28 09:41
@mq
请参考 mosquitto，rmsb等
nieyong 2015-01-26 09:39
@黎洪鑫
没有遇见过类似问题，爱莫能助。
因为pipeline是一个阻塞请求-响应过程，这一点很重要；另外网络机房拥塞会导致非常大的延迟，具体情况就是请求发出去，等待很长时间响应。若是机房网络延迟问题，可以考虑把pipeline异步提交，不要阻塞当前线程。
以上都是建议，仅供参考！
nieyong 2015-01-13 17:19
十分受用，收下了~
nieyong 2014-12-18 22:06
@tangsir
措辞有问题，可不是什么大神，呵呵。
只是总结而已。
nieyong 2014-12-17 10:25
@tangsir
目前除了mqtt，暂时找不到比它更好的业界标准了。建议选择mqtt 3.1.1协议：
支持客户端在发送完毕connect之后，无须等待服务器响应直接发送其余命令
支持服务器和客户端两端暂时会话保存，上次连接之后，再次connect，会话标志位true，可无须发送subscrible命令
具体请参考：
nieyong 2014-12-12 10:39
赞，希望可以看到更多翻译文章，加油！
nieyong 2014-08-25 11:34
@全智贤代言
原本应该是8192，65536/8=8192。
其实，传入8102，也未尝不可。
nieyong 2014-07-12 09:34
@charlessong
记忆力不好，我都忘记具体怎么操作了，亲。
貌似先输入yes，然后回车。试试看。
nieyong 2014-07-12 09:14
@molasses_macaw
收到简历之后，若合适会直接转发给hr，安排具体面试时间。
工作日时间整个审阅过程不会超过3个小时，亲！
欢迎大家自荐和推荐。
推荐的同学若最终上岗，会有一份额外的伯乐奖的 ：））
nieyong 2014-05-25 08:18
占一个广告位~
北京优酷最近在招移动服务器端java攻城师，有需要的同学（也可以推荐一下），可以发邮件到 yongboyatgmail.com
每日接触海量用户请求，机会、舞台都很不错，欢迎各位不妨考虑一下：））
nieyong 2014-05-25 08:11
亲，北京优酷最近在招移动后端java攻城师，有需要或者可以推荐的，可以发送邮件到 yongboyatgmail.com
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
nieyong 2013-12-31 15:42
@goxplanet
更新到最新版吧。
usage: docker save image
save an image to a tar archive (streamed to stdout)
nieyong 2013-05-19 16:23
@小孟
问题太模糊，很难清晰定位。服务器端，需要修改两处：
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
具体问题，请具体定位。
nieyong 2013-04-28 10:05
@piboye
正常，发送和接收都得需要，要不就发送或接收不了啦。
nieyong 2013-04-28 10:05
@iriyadays
十分高效，谢谢~
nieyong 2012-06-11 17:13
为什么要“会单独的使用jsp servlet实现一个简单的信息发布系统.”，可以讲一下原因吗 ？个人很感兴趣。
nieyong 2012-06-11 09:09
@josh
您是什么平台 ？若是android，默认的浏览器不支持websocket协议。
nieyong 2012-06-06 11:24
@steven
这个问题，已经在邮件组里面解决了，哈。
具体，请参考
邮件讨论组为
或者
nieyong 2012-05-24 11:03
受益良多！
若早点阅读到就更好了哈~
nieyong 2012-05-11 09:43
@ge_star
采用netty，或者，或者
或者，直接增加对rcfrfc 6455的支持等。
nieyong 2012-04-27 08:57
@文文木
偶不是什么牛，只是大家一起学习，分享心得而已 ：））
nieyong 2011-07-21 14:27
感觉很罗嗦的。
cas默认是utf-8编码，可以不添加filter，原cas页面也可以保持不变。
唯一需要变化的是
web-inf\view\jsp\protocol\2.0\casservicevalidationsuccess.jsp需要和跳转过去的那个页面的编码一致。
添加：pageencoding="utf-8" 或 pageencoding="gbk" 根据实际情况而定。
nieyong 2011-05-04 14:02
@ronqi
暂无在正式环境下使用servlet3的推送。
不过在现实环境下，有人已经使用golang做服务器，采用长轮询做推送，在实际环境中长轮询使用较多一些。
有关轮询还是推送，可以参考
《push or pull?》
里面对推送和轮询分别存在的问题，分析的很透彻。
nieyong 2009-03-26 09:07
收到，准备下载中
nieyong 2007-05-09 17:18
从昨天晚上开始就看xfire，开始下载《xfire实战[web服务开发之旅]》.pdf
现在下班后，又一次看到阁下的文章，可以下载到新的文档~
呵呵，谢谢~