大家好 milu 1.01b 這個軟體之前有在本討論區被推薦過 , 現在版本已經做更新了 , 應該會比舊版更穩定 , 操作更方便 , 藉著這個地方發表 , 希望大家能喜歡 , 並且也可以幫忙測試. 給我意見. 這是我用 Delphi indy 9 開發的 , 也許大家會對 indy 有興趣 在 indy 上面我花了相當多的時間在測試及調整. 如果大家對 indy 有興趣 , 我也很樂意分享經驗 . 但是因為這個軟體有一些部份屬於 機密 , 所以可能無法公開原始碼 , 跟各位抱歉 . 提供一些我的心得. 即時通訊軟體 , 是一個很有意思的題材 , 簡單兩個端點溝通的程式撰寫 相當簡單 , 但是如果要在上面加功能 , 會發現越來難度越高 , 功能越多, 難度相對增高越多 , 這是一個很特殊的狀況 . 難度曲線會隨著功能的增加而迅速爬升 , 這是大家很容易忽略的東西, 以我的經驗 , 即時通訊軟體真的不好寫 , 這也是我一開始所未料到的. 到底是什麼因素會造成這種現象, 其實就是一個問題--> 穩定度. 功能越多, 維持穩定度越是困難 , 因為有太多不知名的狀況會發生 , 需要一一解決. 這應該也是大部分的 internet 程式所遇到的狀況. 解決穩定度的問題 , 我覺得重點在於 internet socket 的元件還有心法 , 如果元件用的好 , 穩定度就會好. indy , 是大家公認很好的元件 , 但其實我有一點存疑 , 因為我在開發此 軟體時 , 在indy 上遇到很多狀況, 也曾不止一次 要放棄此元件. (ps : 現在正在進行 , 把indy 換掉的工作 , 因為我覺得 indy 還是不能承受負雜且大量的功能) 這邊曾與一些高手交換過意見 , 或者查過許多資料 , 其實大家都會有一些 方法 , 但是採用後 改善的情況還是令我不滿意. 這邊分享一下一些技巧 (也可以說心法) , 不一定正確 ,但是我是以這樣的 觀念再做. 1. 不要在 onConnect , onDisconnect 做太多事情 , 否則這樣會讓 連線品質變的不穩定 2. 盡量不要在 Thread 裡面用 vcl 元件 , 或者 com . 3. 對於不穩定的 Thread 不要客氣 , 直接 Terminate . 不要期望 Disconnect , 或者把 err handle 掉會有幫助. indy 對於 disconnect 的處理很不穩定..所以大部分出狀況 都是在 onDisconnect , 然後就是 onConnect. 4. Thread 的資源能夠用 Synchronize , 就儘量使用 , 不要在 同一時間佔用太多的 Thread 資源. 5. 所有跟 Thread 有關的地方 , 都要做好萬全的 Error Handle 因為如果 handle 不利 , 很容易讓系統穩定度 , 越來越差. 6. 隨時檢查已經 Disconnect 的 Thread . Disconnected 的參數值 不一定正確 , 很可能連線早以中斷. 7. 手動去做 KeepAlive 的事情 , 不要讓一個 Connection 沒事休息 太久 (例如 1 個小時不傳資料 or more ..) 8. 做好三次以上的握手動作 , 雖然是 TCP , 但是有時仍會有 miss (很可能是發生 error 被 handle 掉了) , 例如 : 我要傳檔案囉 , 好 ! 請傳檔案 , 我收到檔案了 , 請繼續.... 9. 盡量採用非同步模式 , 不要有任何一方用迴圈或..等待另一方的狀況 10. 少用緩衝 buffer , 這是很奇怪的概念 , 因為這與 winsock 觀念 完全相反 , winsock 要我們多用緩衝區 , 但是如果你用indy 的 buffer , 你會發現 cpu 會吃很高....(大量資料時) , 因為他會把 資料先 load 到記憶體...(這邊相關的調整很重要, 用 buffer 當然是對的, 但是要能考量效能及整體) 以上分享 , 提供給各位參考 軟體的網址在 : http://www.microbean.com.tw/ 歡迎大家來坐坐

INDY元件优劣仁者见仁智者见智，每个元件都有优缺点，当你转换到其它元件深入使用后同样会发现N多问题，所有程式元件是死的，程序员是活的，现在有很多大型程式＼游戏都在用DELPHI+INDY的组合，也不见有什么不稳定的，关键是元件有问题要自己根据自己的程式进行少量调整，整体等着升级版或补丁包，或想用一个完全没问题的元件是不实际的。

至于THREAD那就更加如此了，THREAD写作有很多技巧，即便是在THREAD中使用VCL也不是不行的，全部加上同步不如不用THREAD，楼主应该加强自我学习，不要把问题全部归结在元件、INDY、DELPHI、THREAD身上，这样只会误导新学的人让他们惧怕DELPHI，认为DELPHI这里不好那里不好。要知道目前市面上很多大型软件均出自于DELPHI。

該網址連不上


===================引 用 文 章===================
軟體的網址在 : http://www.microbean.com.tw/ 歡迎大家來坐坐

敝人也有寫過自訂通訊規格的 Server +cleint 的應用,


心得是,這些東東如果一個人弄,

功能要弄得很完整的應用機制等,


還挺累的.

因為規格還需常修改擴充,或新需求等,

一改下去,經常兩邊都要改,很多功能要測,

完整的 UI 介面也會滿花時間.


如果,兩個人,一個主server,一個主client, 應該會比較輕鬆許多.


其實,如果要功能完整,
這應該是1個 Team 會比較適當.






Indy 有個好處有 kylix 版 現成的,

改天要在Linux 上發展就不用花心思去了解linux的 socket 跟 windows 有哪些差異,及一些處理..

編輯記錄

楼主提到的问题，有一些是因为网络通讯的问题，而不是 Indy 的问题。有一些是因为对 Indy 的内部运作不熟悉导致的问题。有一些是楼主不熟悉 Thread 导致的。

就我用 Indy 9 的经验来看，Indy 还是很稳定的。我现在写的程序，用 Indy9，里面有很多线程在协调，非常稳定。

在这里，我说一个小小的心得：

假如你用 Indy 的 TIdTcpClient 作为 TCP 的客户端，通常要读数据，就会用： IdTCP.ReadLn() 或者类似的 ReadStream 等方法。这个方法是阻塞的。也就是说，在没有读到东西前，整个执行这个代码的 Thread 会停在这里。这是 Indy 专门提供的功能。因为阻塞的状态下，程序可以写得很简单。

那么，如果你在 Delphi 的主线程（Application 的 Thread）里，比如，在按钮 OnClick 里面写 IdTCP.ReadLn() ，如果服务器端没有数据到来，程序整个就阻塞在这里，就会对键盘和鼠标没反应了。所以，这个应该是写道一个单独的 threaad 里。

然后，问题就是一个 Thread 如何和主线程交换数据了。这里，就要定义一个主线程和thread 都能读写的缓冲区。假设你读出来的数据是 stirng，那么，我们可以采用一个全局的 TStringList 来保存从网络上读来的 string。

然后就是，线程把读到的 string 保存到那个 StringList 里，然后发消息通知主线程去 stringList 里取。要注意的是读/写都最好加上临界区。

发消息，加临界区...这些工作也可以用 delphi 帮我们做好的，也就是在 TThread 里的一个方法：Synchronize，看delphi 的Help：
<textarea cols="60" rows="10" class="delphi" name="code"> procedure TMyThread.PushTheButton; begin Button1.Click(); end; procedure TMyThread.Execute; begin ... Synchronize(PushTheButton); ... end; 上述例子改造一下，假设有一个 FStringList: TStringList 是 Thread 和 主线程都能看到的： procedure TMyThread.PushData; var S: string; begin S := FStringList[0]; Label1.Caption := S; end; procedure TMyThread.Execute; var S: string; begin ... S := idTcp.ReadLn(); FStringList.Add(S); Synchronize(PushData); end; 上述代码就在一个 thread 里读 tcp，然后把读到的字符串显示到 Label1 上。这样不会阻塞主线程。 </textarea>

其實我對Indy一直存有很好的感覺，只是市面上有關這方面的技術資料，尤其是中文的實在少之又少，我有個自私的想法，如果書商一直不肯支持(其實也真的很困難，因為Delphi欲振乏力)，不知肯尼兄是否願意採用網路發表方式逐篇發表，或是用期刊方式刊登發售，或者透過ktop的力量，大家合力出資購買(但不以實體出版，而是以電子書方式)，只要是價格合理，我想很多網友是極期待的!