今天看到mobile01上有人推薦用SuperBeam在手機間傳輸資料,試了一下,確實非常方便。SuperBeam是通過Wi-Fi Direct在手機之間傳輸資料,所以速度非常快,實測能達到15 ~ 30Mbps,是藍芽的十多倍了。雖然使用Wi-Fi Direct傳資料的軟體並不少見,但SuperBeam的特色是跨品牌、跨型號,這就十分給力了。並且支援NTC和二維碼兩種方式的快速分享,非常方便,如果以後能在系統中整合一個這種軟體就方便了。Eprice上有一篇比較詳盡的評測,感興趣的朋友可以看看:
串連的三向交握用戶端向伺服器發送SYN請求伺服器發送ACK回應請求,並同時發送一個SYN的請求給用戶端用戶端回應ACK應答關閉的四次握手對於關閉流程,一共有三種情況:用戶端主動關閉,伺服器端主動關閉,用戶端和伺服器端同時主動關閉。這裡僅僅以用戶端主動關閉為例列出。用戶端主動關閉,發送FIN請求伺服器回應ACK應答伺服器被動關閉,發送FIN請求用戶端回應ACK應答對於關閉流程,伺服器端和用戶端是對等的地位,其它兩種情境處理過程類似。需要注意的是,由於對端是是可以主動關閉的,因此在代碼中需要加上被動
在WCF服務中,有時我們要儲存工作階段狀態。例如,對於一個用戶端來說,需要儲存它是否登入的狀態,從而提供不同的服務。在WCF中,對於登入服務來說,我們可以通過如下方式實現: [ServiceContract] publicinterfaceIService1 { [OperationContract] void Login(); [OperationContract] bool IsLoggedIn(); }
在C++中,我們可以通過 __declspec(dllexport) 將函數匯出為Dll中供其它程式使用,例如: _declspec(dllexport) int add(int a, int b);
同步Timerasio中提供的timer名為deadline_timer,它提供了逾時計時的功能。首先以一個最簡單的同步Timer為例來示範如何使用它。 #include<iostream> #include<boost/asio.hpp> int main() { boost::asio::io_serviceio; boost::asio::deadline_timertimer(io,
在ie中經常看見在url欄中有類似“%CC%EC%CF%C2h”的字樣,那是 URL
這是一篇轉載,可能對大家很有用啊。摘要 本文簡單介紹了SMTP協議(RFC2554)發送郵件的過程,並討論了在 .NET 中使用SMTP發送郵件由簡到繁的三種不同方案、各自可能遇到的問題及其解決辦法。--------------------------------------------------------------------------------目錄簡介 .NET的SMTP類 .使用CDO組件發送郵件 .使用Socket撰寫郵件發送程式 .總結 .更多的資訊 ------------
由於最近baidu和360又開始互咬了,從其它搜尋引擎搜尋到百度的結果時又變不能直接存取了,會出現如下介面。 需要手動點擊這個連結才能訪問,讓人非常不爽。因此我寫了一個chrome擴充解決這個問題,原理很簡單:當遇到這種需要跳轉的頁面時,根據url分析目的地址,然後直接轉到的地址。當訪問這種需要跳轉的頁面時,會自動跳轉到目的網頁。使用者是感覺不到中途的這個需要點擊的頁面的。這個擴充不會常駐記憶體,只有在訪問百度相關頁面是才會載入,對chrome的速度應該沒有什麼影響。需要的朋友可以點擊這個連
以前我在文章《WCF入門(六)——回調》中介紹了在WCF中通過回調的方式實現雙工通訊,然而在回調的時候是非常容易出現死結的,本文就簡單的介紹幾種常見的死結的方式和解決方案。一、伺服器端死結 對於如下服務: [ServiceContract(CallbackContract = typeof(INotify))] publicclassDownloadService { [OperationContract] publicvoid Download()
作為良好的開發習慣,對於長期開發的項目,就算是一個人寫的代碼,也應該用源碼管理器控制起來,並且做好異地容災,這麼做帶來的好處就不解釋了。源碼控制的工具有很多,比較流行的是SVN和GIT。其中和VisualStudio整合得最好的還屬TFS了。TFS本身的功能非常強大,並不單單是個源碼管理,不過個人用起來一般也就主要用其源碼管理功能。另外,微軟對於個人或小團隊也推出了免費的TFS Express版,雖然它是免費的,倒也功能齊全,主要提供如下功能:原始程式碼控制 工作項目跟蹤 自動化產生
隨著現在電子裝置越來越多,PC、手機、平板等一個都不能少,由於手機、平板等行動裝置的儲存空間往往比較小,因此就催生了無線儲存共用的需求。本文就簡單的談下目前的幾種無線儲存共用的解決方案。 台式機共用 由於台式機的儲存空間夠大夠便宜,並且功能強大、效能強勁,因此是作為共用伺服器的最廉價而強大的選擇。方式很簡單:在台式機上通過網路位置等方式共用檔案,接入無線路由器,這樣使用該無線網路的行動裝置就都能訪問其資源了。硬體成本:無缺點:
由於檔案系統是和作業系統相關聯的,並且在Windows平台和unix平台的api大相徑庭。因此,對於檔案操作對於擴平台開發的c++程式員來說一直是一個非常頭疼的問題。雖然在STL的<iostream>庫中提供簡單的檔案操作(僅限於建立、刪除檔案),但遠遠無法滿足我們的需求。因此,boost.filesystem庫中提供了一個跨平台的檔案庫,以方便程式員的開發。註:boost.filesystem已經被納入TR2中,雖然還沒有沒有正式標準化,但在vc11和gcc中都是支援的,可以直接使
今天寫了一個小程式,用到了TPL Dataflow,結果在部署的時候發現了一個問題:客戶的伺服器中有win2003的機器,2003是不支援.net 4.5的,但TPL Dataflow卻只能在.net 4.5的程式上使用。在網上搜了一下,MSDN論壇上有人討論這個問題,結論是雖然MS是打算支援.net 4.0的,但目前仍沒有相應的版本發出,反倒是最初發布的一個版本支援.net
建立buffer在io操作中,對資料的讀寫大都是在一個緩衝區上進行的,在asio架構中,可以通過asio::buffer函數建立一個緩衝區來提供資料的讀寫。buffer函數本身並不申請記憶體,只是提供了一個對現有記憶體的封裝。 char d1[128]; size_t bytes_transferred = sock.receive(asio::buffer(d1));直接用字串做buffer也是常見的形式: string str = " hello world " ;
現在很多flv和mkv視頻都是採用的h264封裝,行動裝置往往並不支援這些格式的檔案,但卻對h264封裝的mp4支援良好。因此,為了視頻能在電腦和行動裝置間共用,我通常會將其轉換成h264封裝的mp4檔案。由於視頻轉碼非常耗時間和cpu,如果flv和mkv本來就是採用的h264封裝,完全不需要轉碼,只需要把h264視頻和音頻檔案分離出來,重新混流一次即可,十幾秒內即可完成,非常快速,並且由於沒有轉碼操作,也避免了轉碼過程的畫面損失。下面我就介紹幾種將h264格式的flv和mkv無損轉換為mp4的
今天發現用securecrt登陸時,gcc編譯出錯時會出現亂碼,但直接在主機的視窗介面下用Shell編譯卻沒有亂碼。查看了一下當時的錯誤描述,發現它的引號是中文引號,導致在SecureCRT中顯示出錯: main.c:1:1: error: expected identifier or '(' before numeric constant在網上查了一下,可以通過修改LC_CTYPE=zh_CN.GBK解決這個問題,具體的方法有兩個:1. 通過export命令修改LC_CTYPE變數的值
asio的主要用途還是用於socket編程,本文就以一個tcp的daytimer服務為例簡單的示範一下如何?同步和非同步tcp socket編程。用戶端用戶端的代碼如下: #include <iostream> #include<boost/array.hpp> #include<boost/asio.hpp> using boost::asio::ip::tcp; int main(intargc, char* argv[])
當發生一次WCF要求-回應操作時,會經過如下幾個步驟WCF Client想WCF Server發送一個服務要求 WCF Server建立WCF服務物件 WCF Server調用WCF服務物件介面,將結果返回給WCF用戶端。 操作過程中就牽涉到了服務物件的建立,但由於WCF服務物件是WCF架構管理,一般的時候並不關注它何時建立,何時回收。對於無需訪問成員變數的狀態無關的服務來說,這個並不影響我們的功能實現。但是,許多時候我們也需要提供與狀態相關的服務,這個時候需要通過服務物件的成員變數來儲存狀態。
IO模型io_service對象是asio架構中的調度器,所有非同步io事件都是通過它來分發處理的(io對象的建構函式中都需要傳入一個io_service對象)。 asio::io_service io_service; asio::ip::tcp::socket socket(io_service);在asio架構中,同步的io主要流程如下: 應用程式調用IO對象成員函數執行IO操作IO對象向io_service 提出請求.io_service
一般來說,在如下情境中我們需要用到迭代器的方式訪問序列而不是一次性返回所有序列:序列內容較多,一次性全部返回需要佔用大量記憶體 返回所有序列所需時間較長,需要快速響應 無需讀取所有序列,只需要找到關鍵的資料後即可終止遍曆