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
現在下班后，又一次看到閣下的文章，可以下載到新的文檔~
呵呵，謝謝~