轉自：Indy -- 專業的Blocking


我不知道！(被毆)

但在 Indy in Depth 中提供了這樣的解釋 (原文自己去找！)：

Blocking = 專業！

1. 簡單的程式設計：Blocking socket是非常簡單的設計方式。所有使用者都能把邏輯程式寫在同一個空間且連續的範圍裡面。

2. 跨平台(好像一定都會看到這個特色)：由於Unix使用Blocking socket，能輕易地寫出便於移轉的程式碼。Indy發揮這個論述，去實現單一來源的跨平台能力。其它跨平台的Socket元件則是透過內部使用Blocking來模仿non-Blocking的行為。

3. 在執行緒裡工作：由於Blocking Socket先天就屬於連續的封裝類型，所以非常適合與執行緒搭配。

4. 不依賴Messages：Non-Blocking Socket依存於視窗訊息傳遞系統。於執行緒下使用時，必須建立獨立的訊息佇列。不使用執行緒時，則在進行多點連線時非常容易造成效能瓶頸。

不管你信不信，反正我是信了！

 
我也是用 INDY 來做專案,從不懂--> 到懂一點 --> 案子完成 , 自己摸索了約半年(終於入門了)

昨日 聽 蕭大俠的課,有點頓悟, 原來還有這麼多不懂

不過就您所說的, INDY 就是可以用啦,因為我也沒用其它原件,所以無從比較好壞

我是用 DELPHI 2007, 專案 : 醫院全院區,條碼標籤機網路化(約 22 台,不架設PRINTER SERVER)

謝謝您

------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.

An alternative solution of internet components, ICS(http://www.overbyte.be/frame_index.html), use non-blocking(by message mechanism) way to meet up all the internet service. There's a bit discussion on how they choose between indy and ics : http://stackoverflow.com/questions/2663494/indy-or-ics-or

For me, ICS is good to use and have the ability of maintenance, you will get the connect result with a event. this simply separate the code what you want to do and the result will be done. And you almost need not to care about how to process between multiple threads and mutexs in lots of situations, and free to use.

The lack of ICS, for me, is short of documentation, just like what other most freeware does. And you will need to find some of definition even immediately in source code.

------
不論是否我發的文，在能力範圍皆很樂意為大家回答問題。
為了補我的能力不足之處，以及讓答案可以被重複的使用，希望大家能儘量以公開的方式問問題。
在引述到我的文時自然會儘量替各位想辦法，謝謝大家！

編輯記錄

(我忘了換自己的帳號，用了這個測式的 = =|||   我是蕭沖啦!)

哈，我承認沒把最主要的比較說出來。若硬是要說none-blocking與blocking的差別…

就是thread了啊。當然就是它。

1/ 若你懂thread，那一切就還好。因為thread裡有 thread-safe的問題要去注意喔!
2/ 就算你懂thread，那有一點小小的缺點 : 一個作業系統大致上最多2000個thread吧? (以windows來說，與你的thread的實作有關)，加上thread之間切換有一點點小時間。

而nonbloking的話
1/ 表面上看似乎比較容易寫: 就處理event就好。但也因此比較不直觀。因為write 與 read是分開的。並不像thread是"循序"的實作。
2/ 沒有thread就可以不用管thread safe 的問題
3/ 缺點: 要自己去注意noneblocking經常不總是馬上就送出訊息或是收到。要注意這個問題。

總的來說:
若你實作的程式"循序性"不多(即先寫a，然後收到b，才可以再寫c，然後收到d等…)，那none-blocking比較容易實作。
若你的程式循序很多，那就blocking吧，除非你的連線(server)要能大量的連入。

對小一點的程式來說，這二種方式都差不多。以我講座的工具來說，用none-blocking來實作則相較很容易、很方便。因為沒有處理循序的問題。當然，indy本身已做掉一堆的知名protocol，理當類似http等這類的，都用indy會方便很多。

以上是我的看法啦! 參考一下!

===================引 用 GrandRURU 文 章===================


我不知道！(被毆)

編輯記錄

蕭大一語就道破重點了  XD

Indy的實作可以說是難到爆炸啊！

Indy開發到後期就真的是與Thread在PK

還好有上到蕭大所開的Thread課程，大幅降低開發上的難度 (讓我詐騙了不少開發時間 XD)

另外 Coffee版大 所說的ICS元件，好像很好玩的樣子，改天再來摸摸 ^ ^

Andy大也太強了，Indy學半年就能把案子完成，正常人都要花兩三年吧 XD
(Indy真的很難學)

===================引 用 forcast 文 章===================
哈，我承認沒把最主要的比較說出來。若硬是要說none-blocking與blocking的差別…

就是thread了啊。當然就是它。

1/ 若你懂thread，那一切就還好。因為thread裡有 thread-safe的問題要去注意喔!
2/ 就算你懂thread，那有一點小小的缺點 : 一個作業系統大致上最多2000個thread吧? (以windows來說，與你的thread的實作有關)，加上thread之間切換有一點點小時間。

而nonbloking的話
1/ 表面上看似乎比較容易寫: 就處理event就好。但也因此比較不直觀。因為write 與 read是分開的。並不像thread是"循序"的實作。
2/ 沒有thread就可以不用管thread safe 的問題
3/ 缺點: 要自己去注意noneblocking經常不總是馬上就送出訊息或是收到。要注意這個問題。

總的來說:
若你實作的程式"循序性"不多(即先寫a，然後收到b，才可以再寫c，然後收到d等…)，那none-blocking比較容易實作。
若你的程式循序很多，那就blocking吧，除非你的連線(server)要能大量的連入。

對小一點的程式來說，這二種方式都差不多。以我講座的工具來說，用none-blocking來實作則相較很容易、很方便。因為沒有處理循序的問題。當然，indy本身已做掉一堆的知名protocol，理當類似http等這類的，都用indy會方便很多。

以上是我的看法啦! 參考一下!

編輯記錄

GrandRURU 兄:

您太高估我的能力了,那種案子,是 "硬" 想辦法解決,不是熟透 INDY 才開始

拿來 "用' 與 懂細節,再教別人,有天壤之別 , 蕭大俠的課,真的有很多啟發,

本站高手如雲,小弟是半路出師,應該多向各位討教.

謝謝您

===================引 用 GrandRURU 文 章===================
Andy大也太強了，Indy學半年就能把案子完成，正常人都要花兩三年吧 XD
(Indy真的很難學)

------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.

其實 block & non-block 的差異就在於你接到連線，會不會"專注"於這個連線而不去處理別的事情。

如果要以傳統的程式來說的話 block 就像我們當年 dos 的程式. 只有單工。
而 non block 的話, 就有"多工"的味道在.

你一定很奇怪, 明明是多工. 怎麼我會說是"單工"？等一下再說明.
多工是怎樣？就是不停的"切換"連線. 只有在連線所傳進來的資料達到某個條件時, 才處理.(比方說一個完整封包, 或是某個長度...ETC)
那這樣就可以做到一個程式可以接很多的連線.
在 unix 下. 這個部份利用了 poll or select 來做到.

而我剛才說的 block 成了單工. 那怎麼辦？
簡單.
我們的系統都已經有了 thread, process 了. 就把它分出去. 成為另一個 thread 或是用 fork 這種方式成另一個 process
那樣, 就算卡在等待資料傳進來, 也沒差. 因為卡住的是你分出去的 thread/ process 你接客(listen)的主要功能還是依然在動作中.

而這兩個 block/ nonblock 沒有所謂的好或壞. 主要是看你想要怎麼做你的系統.
你要用 thread 的話. 用 nonblock 當然會造成怪怪的後果.
你要用 block 而去選用 poll/select 的話, 那就會造成在第一個連線傳送時就卡住了.

不過, 說實在的, 我比較喜歡用 non-block, 因為它有些好處.
比方說, 當我要各個 client 之間要"講話"時, 它們都在同一個"空間", 不會是在不同的 thread, 很容易就溝通了.
再說到一個 windows 下真的可以同時開出 2000 thread 嗎？
我真的存疑. 我上次只開了 12 個 thread 用在 RS232 的通訊時(也許它比較慢, 所以比較卡)它就慢到出事了.
反而改架構成為 polling 時, 一切順利. 而這個現像, 也有其他人有相同的反應。

總歸一句, 它們沒什麼好壞, 只是用在不同的場合而已。

PS.這是我之前測試的結果, 有些並沒有再重測一次, 所以說卡住的地方是第一個連線還是第X個, 請自行再測試, 如果有誤, 別K我.

繼續潛水了. ^^

 
暗黑破壞神 大哥,果然.....厲害,別在潛水了,您也是版主,該出來教教大家
網站沒您,感覺太單調了....

謝謝您

------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.

Windows limit threads 的確存在，只是，小弟還沒碰上需要 create 這麼多 thread 來完成事情．．．
http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx


提外話，關於 Thread 通訊部份，根據自己團隊的開發經驗，要讓一台 Server 與2000/3000/4000 台 Client 對打，不是開越多個 Thread 就能順利應付，經過實驗， 32 個 thread 是有最佳的效率。 (但是 Server 未採用 Delphi Indy)

暗黑大，既然都浮上來了，就待久一點嘛
茶都還沒泡好哩 (笑)

>> 我們的系統都已經有了 thread, process 了. 就把它分出去. 成為另一個 thread 或是用 fork 這種方式成另一個 process

編輯記錄