国产亚洲精品资源在线26u,天天综合亚洲色在线精品,亚洲国产一成久久精品国产成人综合

關(guān)于P2P下載的思考

1、使用多路復(fù)用或者異步I/O模型，這本是服務(wù)器段常用的技術(shù)，但在P2P應(yīng)用，每臺機(jī)器既是服務(wù)器，又是客戶端，共享了一個(gè)十分受歡迎的文件，可能會(huì)有很多希望連接者，或者你下載一個(gè)受歡迎文件時(shí)，可能搜索到數(shù)百上千的Peer，此時(shí)就很有必要采用多路復(fù)用或者異步I/O技術(shù)，降低應(yīng)用程序所占用的資源。

2、支持傳統(tǒng)的協(xié)議，包括HTTP和FTP，其實(shí)這兩種技術(shù)能夠和P2P網(wǎng)絡(luò)集成，其中一種辦法就是，在提供下載地址的同時(shí)提供一個(gè)種子文件下載，例如服務(wù)器中提供了ABC.rar文件，同時(shí)提供一個(gè)ABC.rar.md5文件允許下載，這樣P2P下載工具下載時(shí)，通過md5在P2P網(wǎng)絡(luò)中搜索更多的資源，這樣客戶能夠獲得更好的速度，服務(wù)器端也可能降低下載的網(wǎng)絡(luò)流量。

3、流行的P2P網(wǎng)絡(luò)協(xié)議支持，包括BT和emule，這兩種都是公開協(xié)議了，都有開源的實(shí)現(xiàn)，可以參考并重寫，要支持并不困難。

4、健壯性。如同emule一樣，將文件分塊（piece）的同時(shí)，把每一塊摘要一個(gè)piece_ID，將所有的piece_ID再摘要成一個(gè)總的ID，成為AICH。其實(shí)這也是一種很簡單的技術(shù)，實(shí)現(xiàn)起來并不困難，做法可以多種多樣。

5、對大型局域網(wǎng)有特別支持。現(xiàn)實(shí)中，存在很多大型的局域網(wǎng)，局域網(wǎng)之間的擁有高速的帶寬。對局域網(wǎng)的特別支持辦法也有很多的，例如，類似BT那樣，在局域網(wǎng)里建立一個(gè)Tracker Server。若是基于JXTA，可以在局域網(wǎng)里部署聚合點(diǎn)（Rendezvous）

6、支持P2P目錄共享，現(xiàn)在流行的P2P下載工具，都不支持以目錄為單位實(shí)現(xiàn)P2P共享和下載。其實(shí)支持P2P目錄共享也不困難，在提供共享時(shí)，提供一個(gè)目錄結(jié)構(gòu)信息就可以了。目錄結(jié)構(gòu)信息dir_info可以這樣記錄：子文件或子目錄路徑偏移量長度。當(dāng)然把目錄壓縮然后提供下載也是可以的，不過這樣會(huì)浪費(fèi)共享者的磁盤空間。目錄共享，要考慮共享之后文件進(jìn)行修改，添加新文件等事情，使用dir_info能夠更好解決這種問題。

7、關(guān)于通告。一個(gè)P2P共享資源（包括文件和目錄），應(yīng)該包括三個(gè)ID：content_id、aich_id、dir_info_id。其中content_id是整個(gè)資源的摘要，aich_id是每塊id進(jìn)行摘要產(chǎn)生的id，dir_info_id是dir_info的摘要id。
content_id可用資源搜索，建議采用MD5摘要產(chǎn)生，因?yàn)楝F(xiàn)在很多網(wǎng)上提供下載的文件，都提供一個(gè).md5后綴的校驗(yàn)文件。
aich_id用于校驗(yàn)和智能恢復(fù)
dir_info_id。如果計(jì)算content_id時(shí)，dir_info獨(dú)立計(jì)算，則需要提供dir_info_id，用于校驗(yàn)dir_info。理論上dir_info可以作為content的一部分，但是我覺得dir_info獨(dú)立計(jì)算會(huì)帶來很多好處。

8、關(guān)于傳輸。資源的傳輸，應(yīng)該包括三部分，hashset的傳輸、dir_info的傳輸、內(nèi)容數(shù)據(jù)的傳輸。內(nèi)容傳輸是分塊傳輸?shù)模矣X得采用BT的默認(rèn)值256K一塊挺好的。每一塊(piece)摘要計(jì)算一個(gè)piece_id，所有的piece_id放在一起，就是一個(gè)hashset，hashset這個(gè)名字不大好，不直觀，但既然emule協(xié)議是這樣會(huì)說，我也這樣說好了。dir_info是可選的，文件共享不帶dir_info。

9、P2P下載技術(shù)的應(yīng)用范圍應(yīng)該擴(kuò)展，程序的安裝更新都應(yīng)該加入P2P的支持，將會(huì)大大提高程序的用戶體驗(yàn)。

10、P2P的平臺應(yīng)該具備良好的擴(kuò)展性。當(dāng)我們構(gòu)建起一個(gè)龐大的P2P平臺時(shí)，不單單只是在其上共享文件，有很多應(yīng)用可以部署在其上，包括現(xiàn)在很流行的P2P視頻，分布式計(jì)算等等。即時(shí)通訊也是可以構(gòu)建在P2P網(wǎng)絡(luò)上的。面對眾多的應(yīng)用需求，我們需要一個(gè)具備良好擴(kuò)展性的協(xié)議，不應(yīng)該像BT和emule那樣，除了下載，別無它用。可能基于JXTA是一種較好的選擇。

11、安全。P2P網(wǎng)絡(luò)應(yīng)該支持安全特性，一些團(tuán)體，一些企業(yè)，需要限定范圍內(nèi)共享資源。例如NASA的衛(wèi)星數(shù)據(jù)共享項(xiàng)目SAXTA，采用JXTA，就是因?yàn)镴XTA支持安全特性。我想很多的P2P應(yīng)用場景，都需要安全，例如，企業(yè)只希望內(nèi)部員工之間實(shí)現(xiàn)P2P資源共享等等。

溫少 2007-03-25 05:47 發(fā)表評論

posted @ 2007-03-25 05:47 溫少的日志閱讀(224) | 評論 (0) | 編輯收藏

關(guān)于文件目錄的P2P共享問題

1、通用的唯一ID，使用MD5或者SHA1等摘要算法。
2、需要引入類似emule AICH機(jī)制，防止惡意客戶端搗亂，或者用戶修改數(shù)據(jù)之后，無意上傳錯(cuò)誤數(shù)據(jù)。
3、引入文件結(jié)構(gòu)。描述文件在整個(gè)共享內(nèi)容中的位置，整個(gè)共享項(xiàng)包括那些文件等等。
4、總共的ID應(yīng)該包括：唯一ID、AICH_ID、文件結(jié)構(gòu)摘要三個(gè)。如果使用JXTA的方式，需要在ContentAdv中包括這三個(gè)ID。
5、如果采用類似BT種子文件的方式，可以把三個(gè)ID、AICH_HashSet、FILE_LIST_INFO全部放在一起。

在做一個(gè)基于JXTA的實(shí)現(xiàn)，當(dāng)然支持目錄P2P共享的，已經(jīng)實(shí)現(xiàn)的差不多了，自我感覺很酷！！

溫少 2007-03-20 01:15 發(fā)表評論

posted @ 2007-03-20 01:15 溫少的日志閱讀(332) | 評論 (1) | 編輯收藏

慶祝一下，基于JXTA的P2P文件共享傳輸文件測試成功。

jxta.org上也有一個(gè)資源共享的項(xiàng)目，jxta-cm，但是這個(gè)項(xiàng)目作的不夠好。

我重新設(shè)計(jì)了傳輸協(xié)議，參考了BT的傳輸協(xié)議。

存儲本地信息，不像jxta-cm那樣簡單，序列化一個(gè)本地磁盤文件，而是引入了Derby數(shù)據(jù)庫。我本想用Berkeley DB的，我很喜歡Berkeley DB，但是由于版權(quán)協(xié)議的問題，不得不放棄了。

當(dāng)然與jxta-cm還有其他很多地方不同，包括一邊下載一邊上傳等等。

今天文件傳輸測試成功了，隨后將會(huì)進(jìn)行更多的測試，保證穩(wěn)定。

希望4月1日能夠出一個(gè)愚人節(jié)版本。

溫少 2007-03-13 21:08 發(fā)表評論

posted @ 2007-03-13 21:08 溫少的日志閱讀(1024) | 評論 (2) | 編輯收藏

java Class File Format筆記

Java SE 6.0的改變包括了ClassFile格式的改變。

新的版本的ClassFile中major_version為0x0032，也就是50。
Java SE 6 : 0x0032?? （用自己寫的ClassFileParser分析過證實(shí)）
Java SE 5 : 0x0031??（用自己寫的ClassFileParser分析過證實(shí)）
JDK 1.4?? : （未經(jīng)證實(shí)是0x0030）?
JDK 1.3?? :? （未經(jīng)證實(shí)是0x002F）
JDK 1.2?? : 0x002E
JDK 1.1?? : 0x002D??

每次JDK大版本升級，ClassFile格式都改變，然后版本加1。

6.0增加了StackMapTable的Attribute。

要提一下三個(gè)byte code處理庫：
ObjectWeb ASM
Apache BCEL
sourceforge SERP

ASM目前版本為3.0。其2.1版本開始支持StackMapTableAttribute。
其中ASM 2.1支持StackMapTableAttribute，BCEL 5.2似乎只支持JDK 1.3，SERP 1.12只支持JDK 5.0。

Aapche BCEL支持JDK 1.3，是從代碼中猜測的，沒有從文檔中看到，但其中5.2版本的ClassParser的確是不支持StackMapTable Attribute，其代碼中的StackMap和Java SE 6.0的StackMapTable Attribute沒有任何關(guān)系。BCEL中的對象和ClassFile中的各項(xiàng)對應(yīng)，用于學(xué)習(xí)分析方便。

ASM號稱更小，速度更快。現(xiàn)在流行的Eclipse插件bytecode outline也是其中的子項(xiàng)目。

ASM可以直接cvs訪問，提供的代碼是一個(gè)Eclipse Project，十分方便，我很喜歡！
http://forge.objectweb.org/projects/asm/

在規(guī)范4.10.1中的這一段話有些疑問：
If the class file version number is 51.0 or above, then neither the jsr opcode or the jsr_w opcode may appear in the code array.
class file version number is 51.0 or above，什么意思？Java SE 6.0編譯出倆的結(jié)果應(yīng)該是50.x，這是怎么回事？

規(guī)范是一個(gè)186頁的PDF，沒有文檔大綱，看暈了

posted @ 2006-11-26 02:54 溫少的日志閱讀(1405) | 評論 (0) | 編輯收藏

關(guān)于sun JDK nio在linux下的實(shí)現(xiàn)。

這是6.0之前的poll模型。
solaris\native\sun\nio\ch\SocketChannelImpl.c

JNIEXPORT?jint?JNICALL
Java_sun_nio_ch_SocketChannelImpl_checkConnect(JNIEnv?*env,?jobject?this,
???????????????????????????jobject?fdo,?jboolean?block,
???????????????????????????????????????????????jboolean?ready)
{
????int?error?=?0;
????int?n?=?sizeof(int);
????jint?fd?=?fdval(env,?fdo);
????int?result?=?0;
????struct?pollfd?poller;

????poller.revents?=?1;
????if?(!ready)?{
????????poller.fd?=?fd;
????????poller.events?=?POLLOUT;
????????poller.revents?=?0;
????????result?=?poll(&poller,?1,?block???-1?:?0);
????????if?(result?<?0)?{
????????????JNU_ThrowIOExceptionWithLastError(env,?"Poll?failed");
????????????return?IOS_THROWN;
????????}
????if?(!block?&&?(result?==?0))
????????return?IOS_UNAVAILABLE;
????}

????if?(poller.revents)?{
????????errno?=?0;
????????result?=?getsockopt(fd,?SOL_SOCKET,?SO_ERROR,?&error,?&n);
????????if?(result?<?0)?{
????????????handleSocketError(env,?errno);
????????????return?JNI_FALSE;
????????}?else?if?(error)?{
????????????handleSocketError(env,?error);
????????????return?JNI_FALSE;
????????}
????????return?1;
????}
????return?0;
}

6.0缺省的模型是使用epoll
E:\Java\jdk-6-rc-src\j2se\src\solaris\native\sun\nio\ch\EPollArrayWrapper.c

JNIEXPORT?void?JNICALL
Java_sun_nio_ch_EPollArrayWrapper_init(JNIEnv?*env,?jclass?this)?
{
????epoll_create_func?=?(epoll_create_t)?dlsym(RTLD_DEFAULT,?"epoll_create");
????epoll_ctl_func????=?(epoll_ctl_t)????dlsym(RTLD_DEFAULT,?"epoll_ctl");
????epoll_wait_func???=?(epoll_wait_t)???dlsym(RTLD_DEFAULT,?"epoll_wait");
???????????????????????????????????????????????????????????????????????????????????????????????????
????if?((epoll_create_func?==?NULL)?||?(epoll_ctl_func?==?NULL)?||
????????(epoll_wait_func?==?NULL))?{
????????JNU_ThrowInternalError(env,?"unable?to?get?address?of?epoll?functions,?pre-2.6?kernel?");
????}
}

具體程序的流程我還是不夠清楚，還有待進(jìn)一步深入了解。

posted @ 2006-11-22 01:34 溫少的日志閱讀(5531) | 評論 (2) | 編輯收藏

關(guān)于java nio在windows下實(shí)現(xiàn)

java 1.4提供了nio，也就是之前我的一片博客中所說的multiplexed non-blocking I/O。這種模型比阻塞模型的并發(fā)性能要好一些，Java很多的網(wǎng)絡(luò)應(yīng)用都因此重寫了底層模塊，包括Tomcat、Jetty等等，也出現(xiàn)了基于nio的框架mina、國產(chǎn)的cindy等等。

java nio帶來的影響是巨大的，得到了很多擁護(hù)和贊賞。

不過有一些是謠言，例如windows下的實(shí)現(xiàn)是Windows中并發(fā)性能最好的I/O模型IOCP，但事實(shí)上是這樣么？

JDK 6.0 RC版提供了源碼下載，下載路徑：http://www.java.net/download/jdk6/jdk-6-rc-src-b104-jrl-01_nov_2006.jar

我們看最終Windows的實(shí)現(xiàn)：
j2se\src\windows\native\sun\nio\ch\WindowsSelectorImpl.c

82行開始：

????/*?Call?select?*/

????if?((result?=?select(0?,?&readfds,?&writefds,?&exceptfds,?tv))?

?????????????????????????????????????????????????????????????==?SOCKET_ERROR)?{

????????/*?Bad?error?-?this?should?not?happen?frequently?*/

????????/*?Iterate?over?sockets?and?call?select()?on?each?separately?*/

????????FD_SET?errreadfds,?errwritefds,?errexceptfds;

????????readfds.fd_count?=?0;

????????writefds.fd_count?=?0;

????????exceptfds.fd_count?=?0;

????????for?(i?=?0;?i?<?numfds;?i++)?{

????????????/*?prepare?select?structures?for?the?i-th?socket?*/

????????????errreadfds.fd_count?=?0;

????????????errwritefds.fd_count?=?0;

????????????if?(fds[i].events?&?POLLIN)?{

???????????????errreadfds.fd_array[0]?=?fds[i].fd;

???????????????errreadfds.fd_count?=?1;

????????????}

????????????if?(fds[i].events?&?(POLLOUT?|?POLLCONN))?{

????????????????errwritefds.fd_array[0]?=?fds[i].fd;

????????????????errwritefds.fd_count?=?1;

????????????}

????????????errexceptfds.fd_array[0]?=?fds[i].fd;

????????????errexceptfds.fd_count?=?1;

????????????/*?call?select?on?the?i-th?socket?*/

????????????if?(select(0,?&errreadfds,?&errwritefds,?&errexceptfds,?&zerotime)?

?????????????????????????????????????????????????????????????==?SOCKET_ERROR)?{

????????????????/*?This?socket?causes?an?error.?Add?it?to?exceptfds?set?*/

????????????????exceptfds.fd_array[exceptfds.fd_count]?=?fds[i].fd;

????????????????exceptfds.fd_count++;

????????????}?else?{

????????????????/*?This?socket?does?not?cause?an?error.?Process?result?*/

????????????????if?(errreadfds.fd_count?==?1)?{

????????????????????readfds.fd_array[readfds.fd_count]?=?fds[i].fd;

????????????????????readfds.fd_count++;

????????????????}

????????????????if?(errwritefds.fd_count?==?1)?{

????????????????????writefds.fd_array[writefds.fd_count]?=?fds[i].fd;

????????????????????writefds.fd_count++;

????????????????}

????????????????if?(errexceptfds.fd_count?==?1)?{

????????????????????exceptfds.fd_array[exceptfds.fd_count]?=?fds[i].fd;

????????????????????exceptfds.fd_count++;

????????????????}

????????????}

????????}

????}????????????

這就是廣泛應(yīng)用在Winsock中使用的select模型，也眾所周知，并發(fā)性能不是很好。而且FD_SETSIZE不能超過Windows下層提供者的限制，這個(gè)限制通常是1024。也就是說Windows下，JDK的nio模型，不能超過1024個(gè)連接，這個(gè)跟我之前做的測試結(jié)果相似。

而且，如果FD_SETSIZE很大的話，例如是1000，調(diào)用select之前，必須設(shè)置1000個(gè)socket，返回之后又必須檢查這1000個(gè)socket。

也就說，Windows下使用SUN JDK java的nio，并不能提高很好的并發(fā)性能。

posted @ 2006-11-22 00:35 溫少的日志閱讀(7944) | 評論 (1) | 編輯收藏

Java aio和JSR 203

回顧一下Unix的5種I/O模型

1、阻塞I/O
2、非阻塞I/O
3、I/O復(fù)用（select、poll、linux 2.6種改進(jìn)的epoll）
4、信號驅(qū)動(dòng)IO（SIGIO）
5、異步I/O（POSIX的aio_系列函數(shù)）

同步I/O和異步IO

POSIX把這兩個(gè)術(shù)語定義如下：
同步I/O操作導(dǎo)致請求進(jìn)程阻塞，直至操作完成
異步I/O操作不導(dǎo)致請求阻塞。

根據(jù)上述定義，前四種I/O模型都是同步I/O，第5種才是異步I/O。

select不允許多于一個(gè)的線程在同一個(gè)描述符集上等待。這使得反應(yīng)式模型不適用于高性能應(yīng)用，因?yàn)樗鼪]有有效地利用硬件的并行性。
異步I/O通常能夠提高更好的性能，windows的iocp通過內(nèi)核線程調(diào)度，也能提供很好的并發(fā)性能，但不是真正的異步。

Java nio和多路復(fù)用

java 1.4 nio提供的select，這是一種多路復(fù)用I/O（multiplexed non-blocking I/O）模型，底層是使用select或者poll。I/O復(fù)用就是，阻塞在select或者poll系統(tǒng)調(diào)用的某一個(gè)之上，而不是阻塞在真正的I/O系統(tǒng)調(diào)用之上。JDK 5.0 update 9和JDK 6.0在linux下支持使用epoll，可以提高并發(fā)idle connection的性能（http://blogs.sun.com/alanb/entry/epoll）。

以前看到有人猜測Windows下nio使用了IOCP，那應(yīng)該是錯(cuò)的，畢竟IOCP不是多路復(fù)用I/O模型。從JavaOne 2006的幻燈片來看，aio才會(huì)使用IOCP來實(shí)現(xiàn)的。

Java aio和JSR 203

2003年，就有了JSR 203（http://jcp.org/en/jsr/detail?id=203），但是一直沒有實(shí)現(xiàn)。

終于，JSR 203的spec lead說，將會(huì)在Java SE 7.0中完成JSR 203，Java SE 6.0已經(jīng)是RC，很快正式版就會(huì)發(fā)布，然后就是Java SE 7.0，估計(jì)我們不需要等太久了。
http://blogs.sun.com/alanb/entry/what_is_happening_with_jsr

asynchronous I/O對于Java的影響，將不會(huì)低于當(dāng)年JDK 1.4 nio引入multiplexed non-blocking I/O的影響，很多的Java應(yīng)用都會(huì)重寫。如同Linux 2.6支持AIO，DB2、Oracle數(shù)據(jù)庫都會(huì)發(fā)布新版本，說支持使用AIO，性能提高多少多少云云（主要是AIO的文件操作部分）。

對asynchronous I/O的支持，Java程序就能夠支撐大并發(fā)網(wǎng)絡(luò)應(yīng)用了，在IO模型方面，對于C/C++等語言不再存在“C/C++能做，但是Java不能做的事情”。

這個(gè)是Java One 2006上的幻燈片。
http://blogs.sun.com/roller/resources/alanb/bof0895.pdf
提到了：
需要新的channel types支持異步I/O模型
使用Native機(jī)制，例如Windows IO Completion ports。

posted @ 2006-11-21 00:34 溫少的日志閱讀(6881) | 評論 (2) | 編輯收藏

JDK 在linux下支持epoll了

文章：
http://blogs.sun.com/alanb/entry/epoll

JDK 6.0 nio支持epoll，對并發(fā)idle connection會(huì)有大幅度的性能提升，這就是很多網(wǎng)絡(luò)服務(wù)器應(yīng)用程序需要的。

One of the updates in build 59 of Mustang (Java^TM SE 6) is that the New I/O Selector implementation will use the epoll event notification facility when running on the Linux 2.6 kernel.

JDK 5.0 update 9也支持了。

The epoll SelectorProvider will be included in 5.0 update 9. To enable it requires setting the system property java.nio.channels.spi.SelectorProvider to the value sun.nio.ch.EPollSelectorProvider.

5種IO模型：
阻塞IO
非阻塞IO
多路復(fù)用
信號驅(qū)動(dòng)IO
異步IO

最好性能的還是異步IO，目前Java只能支持到多路復(fù)用一級，期待著以后Java 7.0/8.0支持異步IO，6.0是沒有希望了。

posted @ 2006-11-20 02:17 溫少的日志閱讀(6350) | 評論 (3) | 編輯收藏

[導(dǎo)入]linux下工作的感受

買了個(gè)新硬盤安裝ubuntu，把所有的工作遷移到linux下進(jìn)行。

沒感到什么不方便的，畢竟最常用的工具是Eclipse、Firefox、UltraEdit。UltraEdit在linux下的替代品為vi和gedit，一切都好。

聽音樂的播放器要比windows下要差一些，也沒關(guān)系，將就著用。

字體有些難看，也能用，可以將就。

開發(fā)環(huán)境，在Ubuntu下配置ACE、boost等庫的環(huán)境是在太方便的，比windows下方便多了。

唯一的缺陷就是系統(tǒng)不穩(wěn)定，用linux作服務(wù)器是很穩(wěn)定的，但是linux的桌面系統(tǒng)穩(wěn)定性就比較差勁了，仿佛回到
windows 98的那種年代，系統(tǒng)經(jīng)常死機(jī)。

總之，了系統(tǒng)不穩(wěn)定之外，一切都好。

溫少 2006-10-25 01:50 發(fā)表評論

11月26日北京程序員聚會(huì) 用友急聘.NET工程師

文章來源:http://www.cnblogs.com/jobs/archive/2006/10/25/538989.html

posted @ 2006-11-20 02:08 溫少的日志閱讀(206) | 評論 (0) | 編輯收藏

[導(dǎo)入]該拒絕MSN Messager了

一直以來，都是使用兩種即時(shí)通訊工具QQ和MSN，最近越來越討厭MSN，而覺得QQ越作越好。

1、MSN是明文傳輸數(shù)據(jù)，偷窺、監(jiān)聽都是極為簡單的事情。查看別人MSN是某些網(wǎng)管的樂趣，而且是普遍的現(xiàn)象。
2、MSN任何時(shí)候的聊天數(shù)據(jù)都是明文經(jīng)過服務(wù)器的，這個(gè)動(dòng)機(jī)非常值得懷疑。明文傳輸而且通過服務(wù)器，為了使得海量監(jiān)聽更有效率？
3、MSN在貼圖、群方面功能缺乏，聊天記錄沒有等等，不好用，不方便。
4、騷擾很多，一些交友網(wǎng)站的騷擾煩死人。
5、MSN的語音傳輸效果很差，而且經(jīng)常建立不了連接。
6、文件傳輸很慢。

QQ雖然也不是極好，但比MSN還是強(qiáng)一些。
1、QQ聊天數(shù)據(jù)傳輸是使用TEA加密的，雖然并不是非常高強(qiáng)度的加密，但至少是經(jīng)過加密的。
2、QQ聊天數(shù)據(jù)，雙方都在線的時(shí)候，不經(jīng)過服務(wù)器。如果對方不在線，聊天記錄經(jīng)過服務(wù)器，會(huì)受到監(jiān)聽審查。但比MSN要好一些。
3、QQ功能比MSN完備，使用方便。

這兩種工具的官方版本都是廣告一大堆，解決辦法就是使用第三方的客戶端。例如lumaQQ、gaim來替代他。

在中文世界中，越來越多人使用QQ，包括一些海外的朋友，終有一天在中文世界里，MSN就如ICQ一樣，微不足道，這是一個(gè)可以預(yù)見的趨勢，我也將很樂見看到這個(gè)結(jié)果。

因?yàn)檫€有一些朋友只使用MSN，現(xiàn)在只能是少用MSN，最終將會(huì)不再使用MSN。

溫少 2006-11-08 08:51 發(fā)表評論

11月26日北京程序員聚會(huì) 用友急聘.NET工程師

文章來源:http://www.cnblogs.com/jobs/archive/2006/11/08/553714.html

posted @ 2006-11-20 02:08 溫少的日志閱讀(272) | 評論 (0) | 編輯收藏

僅列出標(biāo)題