Is there a "formal" design pattern to DataSnap?

English version:

Is there a "formal" design pattern to DataSnap?

We learn REST DataSnap framework from technical documents in Embarcadero site.

Usually let us feel about:

1. Very slow!
2. 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，一直被詬病的有兩點：

1. 太慢
2. 不穩

Linux 後端開發初體驗，使用Delphi 10.2 Tokyo

掩飾不住內心的喜悅，今天一裝完 Delphi 10.2 Tokyo，馬上就來試試看 Linux 最可能的應用：Web Application 開發！

在 PAServer 安裝好後，在 Target Platforms 上增加了 【64-bit Linux】編譯選項，環境部署也只不過是數秒的時間。

體驗完 Hello World in Linux Console Mode，接著就是實作一個 Web Broker吧！

但單純只出現一個【Hello WebBroker】實在不能表達我現在的喜悅。

那麼，就搭配 JQuery Mobile 來個前端整合試試看！

成果如下圖：

在 Linux 上實現 Debug WebBroker。成功！

掩飾不住內心的喜悅，在 Linux 上終於有了解決方案，Delphier 總算是一吐局限在 Windows 平台的悶氣了！