困擾 |
尚未結案
|
小貓
一般會員 發表:14 回覆:23 積分:12 註冊:2002-07-04 發送簡訊給我 |
|
conundrum
尊榮會員 發表:893 回覆:1272 積分:643 註冊:2004-01-06 發送簡訊給我 |
|
Jasonwong
版主 發表:49 回覆:931 積分:581 註冊:2006-10-27 發送簡訊給我 |
我倒有不同的想法... 在我心目中沒有誰才是王道的觀念 什麼東西在你手中...你能玩出什麼花樣...就能展現出你的功力... 就看你了不了解 INDY 的運作原理跟底層的 WINDOWS SOCKET 並不是要寫通訊程式都要去寫 WINDOWS SOCKET 才行 INDY 跟 WINDOWS SOCKET 各有各的缺點 就像 WINDOWS 跟 LINUX 一樣 誰比較好 我想並沒有一定結論 有人說 VB 不好 可是你知道 WINDOWS XP 是用 VB 寫出來的嗎 以上又代表什麼 什麼東西在你手中...你能玩出什麼花樣...就能展現出你的功力... 以上只是我的一些看法跟想法 --
聰明的人,喜歡猜心;雖然每次都猜對了,卻失去了自己的心
傻氣的人,喜歡給心;雖然每次都被笑了,卻得到了別人的心
------
聰明的人,喜歡猜心;雖然每次都猜對了,卻失去了自己的心 傻氣的人,喜歡給心;雖然每次都被笑了,卻得到了別人的心 |
小貓
一般會員 發表:14 回覆:23 積分:12 註冊:2002-07-04 發送簡訊給我 |
|
conundrum
尊榮會員 發表:893 回覆:1272 積分:643 註冊:2004-01-06 發送簡訊給我 |
Jasonwong 版主 所說是一般用法
indy的問題 很簡單 就如delphi以將一般理論性完成程式化
但是當你寫到 如要突破NAT或多方交即時INDY將會因元件本身的問題
造成系統無法流暢廣播與接收 這時你再看看Windows Sockets 規範
將會好像與INDY反道而行 當然如果底子好的寫INDY 可能將此修改重新導向 不過這樣的工程
決不會比原使用 Windows Sockets 規範來的輕鬆
因為當你使用許多功能時 就會有被INDY綁住的困境
寫下去好像功能越多 越無法令人接受 資源越是耗損 改寫Windows Sockets 規範又覺的好像不符時間效應 2難之中 所以當你使用INDY時 最好先將各網路功能區分 盡量以多緒來處理
比較不會有上述情況 假設 如使用截圖轉jpeg將會把CUP資源耗盡等等
要自己寫bmp轉jaep的vcl又是一門浩大工程 我的說法是 使用INDY 一般需求是快速之道 並非一味抹煞INDY
使用Windows Sockets 規範來寫 除了一開始門檻高 後續的將不會帶來太多 Windows Sockets 規範資料在MSDN是最多資料的
連KTOP也是少之又少 範例也是少 TTcpServer, TTcpClient
就是接收端與發送端
|
Ktop_Robot
站務副站長 發表:0 回覆:3511 積分:0 註冊:2007-04-17 發送簡訊給我 |
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |