除了用c寫過hello world，資料結構，第一次寫這麼多行。高手請忽略我。
im實現的方式現在有很多，我挑了一種來實踐了一下。前端用jsonp發非同步還能跨域的長輪詢請求，後端用epoll寫了乙個支援長連線的chat server
前端方面
接收im訊息：發起乙個http請求，這個請求在伺服器端一直不返回，是個長連線。當伺服器有資訊反饋的時候，再傳送乙個長連線請求。
這個也叫長輪詢，是伺服器推實現方式的一種。
傳送im訊息：發起乙個http請求，將傳送文字發給伺服器，伺服器根據傳送物件，給出哪個長連線可以返回，這裡就是短連線了。
後端方面
前端客戶端
後端伺服器
開啟頁面的時候就發了個長連線請求，等待接收伺服器資料。
a頁面傳送了乙個i am a，b頁面傳送了乙個i am b
乙個完整的im server還應該考慮
1.超時問題
比如瀏覽器頁面關閉，或者網路出現問題等。導致長連線一直沒關閉從而占用伺服器epoll event，一種辦法是伺服器定期傳送心跳訊息。
2.後端負載
單機情況，隨著使用者的增張，epoll_size就需要更大。這樣肯定不行，估計就要考慮一些切分，應該和網遊的分服差不多。
其實經常看有些成熟的web im 都是在chat server和客戶端之間加一層php這種東西處理一些業務邏輯，用php來寫業務邏輯肯定比c好些，而且也好維護。盡量還是讓c這一層可以輕一些，以後好維護。
參考comet：基於 http 長連線的「伺服器推」技術
jsonp跨域原理和jquery.getjson用法
epoll 使用詳解
nextim
實現乙個Semaphore
其實這是我boss的想法,我一開始聽他這麼說也覺得比較差異,ms已經寫好了何必再自己寫乙個.答案有兩個 1ms寫的東西未必就是最好的,如完成埠,heap等.2semaphore是多執行緒程式設計中的核心元素所以有必要提速.我們都知道在多執行緒中ms提供的多個現成阻塞核心物件中critical mon...
乙個Redis Cache實現
應用中需要通過http呼叫遠端的資料，但是這個獲取過程需要執行較長時間，而且這個資料本身的變化也不頻繁，這種情況最適合用乙個cache來優化。前兩年在做短鏈結實現的時候，曾經用最好的語言php做過乙個redis cache實現 乙個簡單的redis應用 修訂版 但那個畢竟是乙個特定的實現，而且我現在...
實現乙個call
call是js最好用的函式之一，改變函式上下文是外掛程式編寫最經常使用的特性。var name 小鋼炮 var cat function say name say ketty 小鋼炮 ketty say.call cat,ketty 貓 ketty看下面 function say name var ...