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包，检出最新代码：
https://github.com/processone/tsung 手动编译就是1.6.1了。
re: 100万并发连接服务器笔记之准备篇 nieyong 2015-06-01 13:58
re: 为什么批量请求要尽可能的合并操作 nieyong 2015-05-29 09:52
@tinsang
针对单台Redis而言，单线程模型。一旦pipeline阻塞了，其它请求会被阻塞住。可考虑单线程操作管道，一个一个批处理。
re: 为什么批量请求要尽可能的合并操作 nieyong 2015-05-28 17:04
@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等
re: 为什么批量请求要尽可能的合并操作 nieyong 2015-01-26 09:39
@黎洪鑫
没有遇见过类似问题，爱莫能助。
因为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，然后回车。试试看。
re: 求JAVA后端服务器开发程序猿若干枚~ nieyong 2014-07-12 09:14
@molasses_macaw
收到简历之后，若合适会直接转发给HR，安排具体面试时间。
工作日时间整个审阅过程不会超过3个小时，亲！
欢迎大家自荐和推荐。
推荐的同学若最终上岗，会有一份额外的伯乐奖的 ：））
占一个广告位~
北京优酷最近在招移动服务器端JAVA攻城师，有需要的同学（也可以推荐一下），可以发邮件到 yongboyATgmail.com
每日接触海量用户请求，机会、舞台都很不错，欢迎各位不妨考虑一下：））
亲，北京优酷最近在招移动后端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
re: Docker学习笔记之三，有关状态的记录 nieyong 2013-12-31 15:42
@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
正常，发送和接收都得需要，要不就发送或接收不了啦。
re: 高并发web框架基本设计思路 nieyong 2012-06-11 17:13
为什么要“会单独的使用jsp + servlet实现一个简单的信息发布系统.”，可以讲一下原因吗 ？个人很感兴趣。
@josh
您是什么平台 ？若是android，默认的浏览器不支持websocket协议。
re: 如何熟悉一个开源项目？ nieyong 2012-05-24 11:03
受益良多！
若早点阅读到就更好了哈~
@文文木
偶不是什么牛，只是大家一起学习，分享心得而已 ：））
感觉很罗嗦的。
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
现在下班后，又一次看到阁下的文章，可以下载到新的文档~
呵呵，谢谢~