English version:
 |
| Is there a "formal" design pattern to DataSnap? |
Usually let us feel about:
- Very slow!
- Unstable!
But, I tried 50000 clients concurrent calling EchoString process into myself DataSnap Service.
......Don't worry.
All process is normal end. It's fine!
My REST DataSnap is strong!
So...Why always have "unstable" infomation appear in many website.
.
.
.
.
.
.
.
.
.
.
.
.
.
Oh! Because "HTTP persistent connection"!
About "HTTP persistent connection", In wiki is:
HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.
 |
| Multiple connections V.S. Persistent connection |
Although "HTTP persistent connection" have advantages about "Reduced latency in subsequent requests (no handshaking)".
But, The advantages is "disadvantages": Connection count is little in REST DataSnap Service!
Because each client is hold in service, this is hard pressure!
If client lose connection from service when network unstable, and then affect memory usage continuously grows, final crash.
More than "HTTP persistent connection" same "More Energy consumption" in mobile device!
The App connection closed when into sleep mode from mobile device.
When re-open, we will get: wrong window.
 |
| A error info is like it. |
About problem,
we can used "Heartbeat packet mode" is fine solution.
Heartbeat packet mode:
Send a message from each sec to service, it like heartbeat behavior, so named it.
But it's energy consumption more!
..........
conclusion:
DataSnap framework features is flexibility!
Have a "formal design" in DataSnap framework?
Any can solve problem are all great formal design!
When you think "DataSnap is bad", please think differently, what is Correct Design?
Maybe you will discover the new continent!
中文版本：實作 REST DataSnap，你用對方法了嗎？
 |
| 看似好棒棒的 DataSnap 框架，這裡頭的眉眉角角還真是不少。 |
官方所給的 REST DataSnap DMEO，一直被詬病的有兩點：
- 太慢
- 不穩
這一陣子認真研究下去，以測試並發 50000 Client 的 EchoString 攻擊後。
發現它還真的能消化完畢，不論是 ISAPI 模式或是 Stand-Alone 模式，也都能消化。
這就好奇了，到底連線不穩的問題出在哪個環節？
笨蛋，問題出在【持久連線】！
關於持久連線，維基百科是這麼說的：
HTTP持久連線（HTTP persistent connection，也稱作HTTP keep-alive或HTTP connection reuse）是使用同一個TCP連線來傳送和接收多個HTTP請求/應答，而不是為每一個新的請求/應答開啟新的連線的方法。
 |
| 多點連接(multiple connections)和持久連接(persistent connection)的差異 |
持久連線看似有【可以減少再連線所造成的連線成本】的優點，但這項優點也是造成 DataSnap 能服務的 Client 數減少的主因。
因為每個 Client 都 Hold 在服務器上，自然對服務器造成很大的壓力。
如果因為網路不穩引發 Client 失去連結，進而造成服務器的死連結，最終因 Session Timeout 來不及引發就先造成服務器崩潰的事情時有所聞。
更悲劇的是，在行動平台上的長連接等同宣告【耗電】。
因為行動裝置在螢幕關閉時會讓 App 導入休眠模式，網路狀態自然斷開，App再開啟時我們就會看到可愛的：
錯誤視窗。
好吧，那就來個心跳包，讓 App 不要進入休眠就好啦！
**心跳包在百度百科上的定義是：
心跳包就是在客户端和服务器间定时通知对方自己状态的一个自己定义的命令字，按照一定的时间间隔发送，类似于心跳，所以叫做心跳包。
 |
| 這招很危險，會上新聞的！ |
這麼悲慘，我都不知道該怎麼說才好了。
結論：
DataSnap 的特色就是極為彈性，說到底也沒有所謂【正規】的設計法，能滿足需求才是正道，不懂？就看看官方的 DataSnap Demo 吧。
所以，當心中浮上了【 DataSnap 是個爛東西】的時候，請換個角度想想：是否用對了方法設計？或許會有新的發現也說不定！
設計沒有好壞，你，用對方法了嗎？
See also:
- Android推送（長連接）探索
- Android推送技术研究
- 無責任技評 : DataSnap
- Delphi XE程式設計系列 2-開發DataSnap/REST伺服器
- 百度百科：心跳包
- 維基百科：HTTP持久連線
- DataSnap Rest Server windows Service
- DataSnap REST Application开发 [技巧/经验/心得] 征集
- 使用http.sys，让delphi 的多层服务飞起来
謝謝你的解說！！突然明白了什麼。來改看看..
回覆刪除請問不要持久連線的關鍵設定是在Client嗎？能從Server設定嗎？
回覆刪除