回顧了一下以前的實驗，一直不理解為什麼在訊息佇列中要使用ftok，比如下面的乙個例項
if((key=ftok(".",'a'))==-1)
qid=msgget( key, ipc_creat | 0666 )； /*建立乙個訊息佇列*/
if ( qid < 0 )
printf ("created queue id : %d \n", qid ); /* 輸出訊息佇列的id */
key_t ftok( const char * fname, int id )
fname就是你指定的檔名（已經存在的檔名），一般使用當前目錄，如：
key_t key;
key = ftok(".", 1); 這樣就是將fname設為當前目錄。
id是子序號。
在一般的unix實現中，是將檔案的索引節點號取出，前面加上子序號得到key_t的返回值。
如指定檔案的索引節點號為65538，換算成16進製為0x010002，而你指定的id值為38，換算成16進製為0x26，則最後的key_t返回值為0x26010002。
為什麼要使用ftok()函式(可以如此記憶：file to key)把乙個已存在的路徑名和乙個整數識別符號轉換成乙個key_t值？我的理解就是：現在假如有兩個應用程式處於同一目錄下，並且這兩個應用程式要通過乙個訊息佇列進行通訊，現在第乙個應用程式開起來，通過msgget()得到了乙個訊息佇列id，而第二個應用程式怎麼知道是使用這個訊息佇列id進行通訊呢？
第一種方法如下所示：
./send ,讓這個程序輸出它所建立的訊息佇列id，比如輸出11111. 再./receive 11111，執行第二個程式，11111當成引數傳入。在receive這個程式裡面要將argv[1]當成訊息佇列的id，這種方法缺點很明顯，每次都要手動輸入。
第二種方法就是ftok了，利用ftok得到乙個鍵值，這個鍵值只和inode有關，並且在第二應用程式裡面也寫上例項中的**，則兩個應用程式能得到相同的鍵值，之後通過這個鍵值能得到核心中的訊息佇列的id，而msgget()的引數單獨使用ipc_creat時，要麼返回乙個新建立的訊息佇列的識別符號，要麼返回具有相同關鍵字值的佇列的識別符號。所以第乙個程式呼叫msgget()會根據這個鍵值建立出訊息佇列id，而第二個程式使用相同的鍵值呼叫msgget()能得到這個鍵值對應的訊息佇列的id，這樣就不用向方法一那樣手動輸入了。
總結下就是訊息佇列id是乙個程序的內部名，自己建立的乙個訊息佇列id其他程序怎麼會知道呢！所以為使得多個合作程序能夠在同乙個訊息佇列物件上會合，需要乙個外部名方案，那就是使用了鍵(key)，對於相同的路徑每個程序能得到相同的鍵值，核心再根據這個鍵值能得到訊息佇列id。
對於STL的理解
stl standard template library stl是一些 容器 的集合，這些 容器 有list,vector,set,map等，stl也是演算法和其他一些元件的集合。這裡的 容器 和演算法的集合指的是世界上很多聰明人很多年的傑作。stl的目的是標準化元件，這樣就不用重新開發，可以使用...
對於Zookeeper的理解
zookeeper是google 的chubby乙個開源的實現，是hadoop 的分布式協調服務。它包含乙個簡單的原語集，分布式應用程式可以基於它實現同步服務，配置維護和命名服務等。zookeeper包括乙個leader和多個follower。為什麼使用zookeeper？大部分分布式應用需要乙個主...
對於mvc的理解
經常有人混淆mvc和軟體的三層架構，經過一年多的工作，說一下自己的理解。mvc，是一種設計思想，只是個指導方針。這個方針是 乙個工程可以分為表現層，控制器，資料模型。控制器就是乙個轉接頭，兩邊對接表現層和資料模型。比如mvc的一種表現形式 26個英文本母就是26個資料模型，組合出的單詞就是無數個表現...