不是東西的東西

微軟Asp.net2.0 Ajax 一. Asp.net 2.0 Ajax 執行環境需求： Framework 2.0 IIS 開發環境： VS2005 C#.net (or VB.net) 微軟 Ajax 套件 (需另外下載) 1.下載套件: http://ajax.asp.net/ 於首頁 按下 Download ASP.NET AJAX v1.0 會進入下一個頁面 點下 Download ASP.NET Extensions V1.0 即可 下載 安裝完成後 開啟 VS2005 新增專案  選擇(VB 或 C#) Asp.net Ajax-Enabled Web Application 開啟後會發現 多了 1組元件在 工具箱 (Ajax Extensions) 2.介紹AJAX Extensions ASP.NET AJAX v1.0 使用微軟自定的 Client Script Libery 1.ScriptManager控制項 – 整個 Asp.net Ajax 的核心 ,所有要使用Ajax的功能均必須使用該元件 ,負責建立User端的javascript ,使用Ajax功能時只能有一個ScriptManager控制項。 2.UpdatePanel控制項 – 與ScriptManager搭配使用後 ,可以簡單建立完成Ajax功能。 3.UpdateProgress控制項 – 與UpdatePanel 配合 ,用來顯示 非同步postback的處理狀況 ,或將非同步postback中斷。 4.Timer 控制項 – 就如同windows應用程式所使用的Timer 元件 ,可定時於page中重整 ,但時間設定太短可能會增加Server的負擔。 5.ScriptManagerProxy 控制項 – 在Asp.net Ajax的page裡只能用一個ScriptManager, 於Asp.net MasterPage(類似Html 的框架頁)會有多個Asp.net page,如果同時間有2個以上的網頁要使用Ajax功能需使用到 ScriptManager 則子版面必須使用ScriptManagerProxy 範例(一) AspNetAJAXdemo.aspx 配合 Asp.Net 2.0 的MasterPage 解說 這5大Asp.Net Ajax 控制項 的使用方...

這幾天再寫jabber component 時發生一個奇怪的問題, 伺服器與component 固定一段時間就會終止通訊,然而連線此時還是存在的,伺服器或客乎端都沒有當掉,而且一般的jabber client 連接在上面也沒有問題,惟獨自己實做的server與client 無法通訊,後來發現;幾個socket 重要的參數,當client需要樣長時間連線時這些參數格外重要: setsockopt SOL_SOCKET, SO_KEEPALIVE setsockopt IPPROTO_TCP, TCP_KEEPIDLE setsockopt IPPROTO_TCP, TCP_KEEPCNT setsockopt IPPROTO_TCP, TCP_KEEPINTVL 程式再加了這些tcp 參數設定後,症狀完全消失

http://pugs.blogs.com/talks/osdctw2007-perl510.pdf 看來這個承先啟後的版本做了不少的改變,在這些改變中,呵呵...台灣還佔有一席之地

其中比較有趣的是 1. Mail::SpamAssassin::Spamd::Apache2 -- mod_perl2 module, implementing spamd as a mod_perl module, contributed as a Google Summer of Code project by Radoslaw Zielinski. 沒錯apache2 已不像過去,只是一個web server,他可以在上面發展其他的protocol,除了之前看過的smtp/ftp現在又多了spamd,但之前在apache2 上開發 lprd protocol 卻發現他的效率似乎沒有比自己寫伺服器來的好,至於穩不穩定,可能要有實際的數據支持 2. sa-compile: compilation of SpamAssassin rules into a fast parallel-matching DFA, implemented in native code 這個技術我還沒時間仔細去trace,不過他應該是將spamassassin 使用的rules, 透過這個工具轉成c , 然後透過 xs 讓perl 來使用,這應該很有研究價值

http://wiki.jabbercn.org/space/start 另一個不錯的相關網站 http://hi.baidu.com/jabber/blog/category/Jep iq:roster 的交易過程真是複雜的可以 http://64.233.179.104/translate_c?hl=zh-TW&sl=zh-CN&u=http://www.linuxboy.net/jabber/004.html&prev=/search%3Fq%3Diq:roster%26complete%3D1%26hl%3Dzh-TW%26pwst%3D1

一. 我會接觸Erlang的緣由 1.RFID Middleware 2.jabber (xml::stream http://zh.wikipedia.org/wiki/Jabber) 3.ejabber (http://www.process-one.net/en/ ) 二. 現在的商業環境(web server)所面臨的問題 1.連線的數量不斷的攀升 2.連線的時間很長 傳統上httpd 使用Prefork的方式來解決,短時間時密集連線的問題,在現在的環境愈到了嚴重的挑戰,比如: HTTP_Streaming、Server Push、COMET 這些需要長時間連線的架構,使得httpd 能夠服務的連線變少了,而fork process 最大的問題是,他所需要佔用記憶體的空間過於龐大,於是其他的伺服器架構崛起(lighthttpd ghttpd …) The C10K problem( http://www.kegel.com/c10k.html ) It's time for web servers to handle ten thousand clients simultaneously, don't you think? After all, the web is a big place now. And computers are big, too. You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1200 or so. Let's see - at 20000 clients, that's 50KHz, 100Kbytes, and 50Kbits/sec per client. It shouldn't take any more horsepower than that to take four kilobytes from the disk and send them to the network once a second for each of twenty thousand clients. (That works out to $0.08 per client,...

最近在寫jabber server, jabber 是建構在xmpp protocol 上的一個IM,因為RFC的規格制定曠日費時,所以;jabber 以xmpp 為基礎,自己又定義了約200 個協定XEP-0001~0214,而 xmpp 主要由五個protocol所組成,分別是RFC-3920~3923 RFC-4622 我目前的進度已經可以讓像 Exodus or Pandion(IM Client) 連接上我自己實做的jabber server,預計下星期我就能讓im client 直接在上面talk,且訂閱彼此的狀態...在寫的過程成中越來越覺得他的複雜,其實,這大概是我目前寫過最複雜的伺服器,不過有一點心得可以先分享給大家,其實有一些人有一個疑問,jabber長的像什麼? 如果我們撇開他在IM的實做(處理訊息的傳遞也是一種運算資源),我們可以把它看成是一家公司,一家公司會有他對客戶的服務,而當產品要製作時,它需要資源,需要應徵人員,每個應徵的人員需要依照公司的制度來運行(component plug-in),每個人員應徵後需要報到,然後正式工作,依照給個人的專業知識分派工作 ....循環不已,當新的產品要製作時,這個公司可以再應徵新的 不同專業領域的資源,而且可以重新制定新的工作規則...而公司組織裡的這些運行其實都是靠制度,而這個制度相對於jabber 就是他的protocol,所以我把xmpp形容成是一個資源/運算的分散者,因此他可以建構一個基本的Grid Computing 環境,把每個運算工作分散到無限台機器上....如果你要問他可以做什麼? 事實上在jabber 的protocol 裡幾乎定義了絕大部分 的應用,voip 影音...,所有的運算資源都可以在事後 plug in 進去,google_talk 所實做的部份可能還不到整個jabber 的1/20,由此;我們可以看出他的規模/擴充性之大... 總之把他想成是一個有組織的公司,只是公司的規模有大有小罷了,xmpp 的工作資源分配真的跟這個描述很像,有機會自己實做一次體會一下囉!