Linux環境處理序間通訊（三）訊息佇列

Linux環境處理序間通訊（三）訊息佇列

訊息佇列（也叫做報文隊列）能夠克服早期unix通訊機制的一些缺點。作為早期unix通訊機制之一的訊號能夠傳送的資訊量有限，後來雖然 POSIX 1003.1b在訊號的即時性方面作了拓廣，使得訊號在傳遞資訊量方面有了相當程度的改進，但是訊號這種通訊方式更像"即時"的通訊方式，它要求接受訊號 的進程在某個時間範圍內對訊號做出反應，因此該訊號最多在接受訊號進程的生命週期內才有意義，訊號所傳遞的資訊是接近於隨進程持續的概念（process-persistent），見
附錄 1；管道及有名管道及有名管道則是典型的隨進程持續IPC，並且，只能傳送無格式的位元組流無疑會給應用程式開發帶來不便，另外，它的緩衝區大小也受到限制。

訊息佇列就是一個訊息的鏈表。可以把訊息看作一個記錄，具有特定的格式以及特定的優先順序。對訊息佇列有寫入權限的進程可以向中按照一定的規則添加新訊息；對訊息佇列有讀許可權的進程則可以從訊息佇列中讀走訊息。訊息佇列是隨核心持續的（參見附錄 1）。

目前主要有兩種類型的訊息佇列：POSIX訊息佇列以及系統V訊息佇列，系統V訊息佇列目前被大量使用。考慮到程式的可移植性，新開發的應用程式應盡量使用POSIX訊息佇列。

在本系列專題的序（深刻理解Linux處理序間通訊（IPC））中，提到對於訊息佇列、號誌、以及共用記憶體區來說，有兩個實現版本：POSIX的以及系統V的。Linux核心（核心2.4.18）支援POSIX號誌、POSIX共用記憶體區以及POSIX訊息佇列，但對於主流 Linux發行版本之一redhad8.0（核心2.4.18），還沒有提供對POSIX處理序間通訊API的支援，不過應該只是時間上的事。

因此，本文將主要介紹系統V訊息佇列及其相應API。 在沒有聲明的情況下，以下討論中指的都是系統V訊息佇列。

一、訊息佇列基本概念

1. 系統V訊息佇列是隨核心持續的，只有在核心重起或者顯示刪除一個訊息佇列時，該訊息佇列才會真正被刪除。因此系統中記錄訊息佇列的資料結構（struct ipc_ids msg_ids）位於核心中，系統中的所有訊息佇列都可以在結構msg_ids中找到訪問入口。
2. 訊息佇列就是一個訊息的鏈表。每個訊息佇列都有一個隊列頭，用結構struct msg_queue來描述（參見
   附錄 2）。隊列頭中包含了該訊息佇列的大量資訊，包括訊息佇列索引值、使用者ID、組ID、訊息佇列中訊息數目等等，甚至記錄了最近對訊息佇列讀寫進程的ID。讀者可以訪問這些資訊，也可以設定其中的某些資訊。
3. 說明了核心與訊息佇列是怎樣建立起聯絡的：
   其中：struct ipc_ids msg_ids是核心中記錄訊息佇列的全域資料結構；struct msg_queue是每個訊息佇列的隊列頭。

從可以看出，全域資料結構 struct ipc_ids msg_ids 可以訪問到每個訊息佇列頭的第一個成員：structkern_ipc_perm；而每個struct kern_ipc_perm能夠與具體的訊息佇列對應起來是因為在該結構中，有一個key_t類型成員key，而key則唯一確定一個訊息佇列。 kern_ipc_perm結構如下：

struct kern_ipc_perm{   //核心中記錄訊息佇列的全域資料結構msg_ids能夠訪問到該結構；             key_t   key;    //該索引值則唯一對應一個訊息佇列             uid_t   uid;             gid_t   gid; uid_t   cuid; gid_t   cgid; mode_t  mode; unsigned long seq; }

 

回頁首

二、操作訊息佇列

對訊息佇列的操作無非有下面三種類型：

1、 開啟或建立訊息佇列
訊息佇列的核心持久性要求每個訊息佇列都在系統範圍內對應唯一的索引值，所以，要獲得一個訊息佇列的描述字，只需提供該訊息佇列的索引值即可；

註：訊息佇列描述字是由在系統範圍內唯一的索引值產生的，而索引值可以看作對應系統內的一條路經。

2、 讀寫操作

訊息讀寫操作非常簡單，對開發人員來說，每個訊息都類似如下的資料結構：

struct msgbuf{ long mtype; char mtext[1]; };

 

mtype成員代表訊息類型，從訊息佇列中讀取訊息的一個重要依據就是訊息的類型；mtext是訊息內容，當然長度不一定為1。因此， 對於發送訊息來說，首先預置一個msgbuf緩衝區並寫入訊息類型和內容，調用相應的發送函數即可；對讀取訊息來說，首先分配這樣一個msgbuf緩衝 區，然後把訊息讀入該緩衝區即可。

3、 獲得或設定訊息佇列屬性：

訊息佇列的資訊基本上都儲存在訊息佇列頭中，因此，可以分配一個類似於訊息佇列頭的結構(struct msqid_ds，見
附錄 2)，來返回訊息佇列的屬性；同樣可以設定該資料結構。

訊息佇列API

1、檔案名稱到索引值

#include <sys/types.h> #include <sys/ipc.h> key_t ftok (char*pathname, char proj)；

 

它返回與路徑pathname相對應的一個索引值。該函數不直接對訊息佇列操作，但在調用ipc(MSGGET,…)或msgget()來獲得訊息佇列描述字前，往往要調用該函數。典型的調用代碼是：

key=ftok(path_ptr, 'a');     ipc_id=ipc(MSGGET, (int)key, flags,0,NULL,0);     …

 

2、linux為作業系統V處理序間通訊的三種方式（訊息佇列、號誌、共用記憶體區）提供了一個統一的使用者介面：
int ipc(unsigned int call, int first, int
second,int third, void * ptr, long
fifth);

第一個參數指明對IPC對象的操作方式，對訊息佇列而言共有四種操作：MSGSND、MSGRCV、MSGGET以及MSGCTL，分別代表向訊息佇列發送訊息、從訊息佇列讀取訊息、開啟或建立訊息佇列、控制訊息隊列；first參數代表唯一的IPC對象；下面將介紹四種操作。

• int ipc( MSGGET, intfirst, intsecond,
  intthird, void*ptr, longfifth);
  
  與該操作對應的系統V調用為：int msgget( (key_t)first，second)。
• int ipc( MSGCTL, intfirst, intsecond,
  intthird, void*ptr, longfifth)
  
  與該操作對應的系統V調用為：int msgctl( first，second, (struct msqid_ds*) ptr)。
• int ipc( MSGSND, intfirst, intsecond,
  intthird, void*ptr, longfifth);
  
  與該操作對應的系統V調用為：int msgsnd( first, (struct msgbuf*)ptr, second, third)。
• int ipc( MSGRCV, intfirst, intsecond,
  intthird, void*ptr, longfifth);
  
  與該操作對應的系統V調用為：int msgrcv( first，(struct msgbuf*)ptr, second, fifth,third)，

 

註：本人不主張採用系統調用ipc()，而更傾向於採用系統V或者POSIX處理序間通訊API。原因如下：

• 雖然該系統調用提供了統一的使用者介面，但正是由於這個特性，它的參數幾乎不能給出特定的實際意義（如以first、second來具名引數），在一定程度上造成開發不便。
• 正如ipc手冊所說的：ipc()是linux所特有的，編寫程式時應注意程式的移植性問題；
• 該系統調用的實現不過是把系統V IPC函數進行了封裝，沒有任何效率上的優勢；
• 系統V在IPC方面的API數量不多，形式也較簡潔。

 

3.系統V訊息佇列API
系統V訊息佇列API共有四個，使用時需要包括幾個標頭檔：

#include <sys/types.h> #include <sys/ipc.h> #include <sys/msg.h>

 

1）int msgget(key_t key, int msgflg)

參數key是一個索引值，由ftok獲得；msgflg參數是一些標誌位。該調用返回與健值key相對應的訊息佇列描述字。

在以下兩種情況下，該調用將建立一個新的訊息佇列：

• 如果沒有訊息佇列與健值key相對應，並且msgflg中包含了IPC_CREAT標誌位；
• key參數為IPC_PRIVATE；

 

參數msgflg可以為以下：IPC_CREAT、IPC_EXCL、IPC_NOWAIT或三者的或結果。

調用返回：成功返回訊息佇列描述字，否則返回-1。

註：參數key設定成常數IPC_PRIVATE並不意味著其他進程不能訪問該訊息佇列，只意味著即將建立新的訊息佇列。

2）int msgrcv(int msqid, struct msgbuf*msgp, int msgsz, long msgtyp, int msgflg);

該系統調用從msgid代表的訊息佇列中讀取一個訊息，並把訊息儲存在msgp指向的msgbuf結構中。

msqid為訊息佇列描述字；訊息返回後儲存在msgp指向的地址，msgsz指定msgbuf的mtext成員的長度（即訊息內容的長度），msgtyp為請求讀取的訊息類型；讀訊息標誌msgflg可以為以下幾個常值的或：

• IPC_NOWAIT 如果沒有滿足條件的訊息，調用立即返回，此時，errno=ENOMSG
• IPC_EXCEPT 與msgtyp>0配合使用，返回隊列中第一個類型不為msgtyp的訊息
• IPC_NOERROR 如果隊列中滿足條件的訊息內容大於所請求的msgsz位元組，則把該訊息截斷，截斷部分將丟失。

 

msgrcv手冊中詳細給出了訊息類型取不同值時(>0; <0; =0)，調用將返回訊息佇列中的哪個訊息。

msgrcv()解除阻塞的條件有三個：

1. 訊息佇列中有了滿足條件的訊息；
2. msqid代表的訊息佇列被刪除；
3. 調用msgrcv（）的進程被訊號中斷；

 

調用返回：成功返回讀出訊息的實際位元組數，否則返回-1。

3）int msgsnd(int msqid, struct msgbuf*msgp, int msgsz, int msgflg);

向msgid代表的訊息佇列發送一個訊息，即將發送的訊息儲存在msgp指向的msgbuf結構中，訊息的大小由msgze指定。

對發送訊息來說，有意義的msgflg標誌為IPC_NOWAIT，指明在訊息佇列沒有足夠空間容納要發送的訊息時，msgsnd是否等待。造成msgsnd()等待的條件有兩種：

• 當前訊息的大小與當前訊息佇列中的位元組數之和超過了訊息佇列的總容量；
• 當前訊息佇列的訊息數（單位"個"）不小於訊息佇列的總容量（單位"位元組數"），此時，雖然訊息佇列中的訊息數目很多，但基本上都只有一個位元組。

 

msgsnd()解除阻塞的條件有三個：

1. 不滿足上述兩個條件，即訊息佇列中有容納該訊息的空間；
2. msqid代表的訊息佇列被刪除；
3. 調用msgsnd（）的進程被訊號中斷；

 

調用返回：成功返回0，否則返回-1。

4）int msgctl(int msqid, int cmd,struct msqid_ds *buf);

該系統調用對由msqid標識的訊息佇列執行cmd操作，共有三種cmd操作：IPC_STAT、IPC_SET 、IPC_RMID。

1. IPC_STAT：該命令用來擷取訊息佇列資訊，返回的資訊存貯在buf指向的msqid結構中；
2. IPC_SET：該命令用來設定訊息佇列的屬性，要設定的屬性儲存區在buf指向的msqid結構中；可設定屬性包括：msg_perm.uid、msg_perm.gid、msg_perm.mode以及msg_qbytes，同時，也影響msg_ctime成員。
3. IPC_RMID：刪除msqid標識的訊息佇列；

 

調用返回：成功返回0，否則返回-1。

回頁首

三、訊息佇列的限制

每個訊息佇列的容量（所能容納的位元組數）都有限制，該值因系統不同而不同。在後面的應用執行個體中，輸出了redhat 8.0的限制，結果參見
附錄 3。

另一個限制是每個訊息佇列所能容納的最大訊息數：在redhad 8.0中，該限制是受訊息佇列容量制約的：訊息個數要小於訊息佇列的容量（位元組數）。

註：上述兩個限制是針對每個訊息佇列而言的，系統對訊息佇列的限制還有系統範圍內的最大訊息佇列個數，以及整個系統範圍內的最大訊息數。一般來說，實際開發過程中不會超過這個限制。

回頁首

四、訊息佇列應用執行個體

訊息佇列應用相對較簡單，下面執行個體基本上覆蓋了對訊息佇列的所有操作，同時，程式輸出結果有助於加深對前面所講的某些規則及訊息佇列限制的理解。

#include <sys/types.h> #include <sys/msg.h> #include <unistd.h> void msg_stat(int,struct msqid_ds ); main() { int gflags,sflags,rflags; key_t key; int msgid; int reval; struct msgsbuf{         int mtype;         char mtext[1];     }msg_sbuf; struct msgmbuf     {     int mtype;     char mtext[10];     }msg_rbuf; struct msqid_ds msg_ginfo,msg_sinfo; char* msgpath="/unix/msgqueue"; key=ftok(msgpath,'a'); gflags=IPC_CREAT|IPC_EXCL; msgid=msgget(key,gflags|00666); if(msgid==-1) {     printf("msg create error\n");     return; } //建立一個訊息佇列後，輸出訊息佇列預設屬性 msg_stat(msgid,msg_ginfo); sflags=IPC_NOWAIT; msg_sbuf.mtype=10; msg_sbuf.mtext[0]='a'; reval=msgsnd(msgid,&msg_sbuf,sizeof(msg_sbuf.mtext),sflags); if(reval==-1) {     printf("message send error\n"); } //發送一個訊息後，輸出訊息佇列屬性 msg_stat(msgid,msg_ginfo); rflags=IPC_NOWAIT|MSG_NOERROR; reval=msgrcv(msgid,&msg_rbuf,4,10,rflags); if(reval==-1)     printf("read msg error\n"); else     printf("read from msg queue %d bytes\n",reval); //從訊息佇列中讀出訊息後，輸出訊息佇列屬性 msg_stat(msgid,msg_ginfo); msg_sinfo.msg_perm.uid=8;//just a try msg_sinfo.msg_perm.gid=8;// msg_sinfo.msg_qbytes=16388; //此處驗證超級使用者可以更改訊息佇列的預設msg_qbytes //注意這裡設定的值大於預設值 reval=msgctl(msgid,IPC_SET,&msg_sinfo); if(reval==-1) {     printf("msg set info error\n");     return; } msg_stat(msgid,msg_ginfo); //驗證設定訊息佇列屬性 reval=msgctl(msgid,IPC_RMID,NULL);//刪除訊息佇列 if(reval==-1) {     printf("unlink msg queue error\n");     return; } } void msg_stat(int msgid,struct msqid_ds msg_info) { int reval; sleep(1);//只是為了後面輸出時間的方便 reval=msgctl(msgid,IPC_STAT,&msg_info); if(reval==-1) {     printf("get msg info error\n");     return; } printf("\n"); printf("current number of bytes on queue is %d\n",msg_info.msg_cbytes); printf("number of messages in queue is %d\n",msg_info.msg_qnum); printf("max number of bytes on queue is %d\n",msg_info.msg_qbytes); //每個訊息佇列的容量（位元組數）都有限制MSGMNB，值的大小因系統而異。在建立新的訊息佇列時，//msg_qbytes的預設值就是MSGMNB printf("pid of last msgsnd is %d\n",msg_info.msg_lspid); printf("pid of last msgrcv is %d\n",msg_info.msg_lrpid); printf("last msgsnd time is %s", ctime(&(msg_info.msg_stime))); printf("last msgrcv time is %s", ctime(&(msg_info.msg_rtime))); printf("last change time is %s", ctime(&(msg_info.msg_ctime))); printf("msg uid is %d\n",msg_info.msg_perm.uid); printf("msg gid is %d\n",msg_info.msg_perm.gid); }

 

程式輸出結果見
附錄 3。

 

回頁首

小結：

訊息佇列與管道以及有名管道相比，具有更大的靈活性，首先，它提供有格式位元組流，有利於減少開發人員的工作量；其次，訊息具有類型，在實際應用中，可作為優先順序使用。這兩點是管道以及有名管道所不能比的。同樣，訊息佇列可以在幾個進程間複用，而不管這幾個進程是否具有親緣關係，這一點與 有名管道很相似；但訊息佇列是隨核心持續的，與有名管道（隨進程持續）相比，生命力更強，應用空間更大。

附錄 1： 在參考文獻[1]中，給出了IPC隨進程持續、隨核心持續以及隨檔案系統持續的定義：

1. 隨進程持續：IPC一直存在到開啟IPC對象的最後一個進程關閉該對象為止。如管道和有名管道；
2. 隨核心持續：IPC一直持續到核心重新自舉或者顯示刪除該對象為止。如訊息佇列、號誌以及共用記憶體等；
3. 隨檔案系統持續：IPC一直持續到顯示刪除該對象為止。

 

附錄 2：
結構msg_queue用來描述訊息佇列頭，存在於系統空間：

struct msg_queue {     struct kern_ipc_perm q_perm;     time_t q_stime;         /* last msgsnd time */     time_t q_rtime;         /* last msgrcv time */     time_t q_ctime;         /* last change time */     unsigned long q_cbytes;     /* current number of bytes on queue */     unsigned long q_qnum;       /* number of messages in queue */     unsigned long q_qbytes;     /* max number of bytes on queue */     pid_t q_lspid;          /* pid of last msgsnd */     pid_t q_lrpid;          /* last receive pid */     struct list_head q_messages;     struct list_head q_receivers;     struct list_head q_senders; };

 

結構msqid_ds用來設定或返回訊息佇列的資訊，存在於使用者空間；

struct msqid_ds {     struct ipc_perm msg_perm;     struct msg *msg_first;      /* first message on queue,unused  */     struct msg *msg_last;       /* last message in queue,unused */     __kernel_time_t msg_stime;  /* last msgsnd time */     __kernel_time_t msg_rtime;  /* last msgrcv time */     __kernel_time_t msg_ctime;  /* last change time */     unsigned long  msg_lcbytes; /* Reuse junk fields for 32 bit */     unsigned long  msg_lqbytes; /* ditto */     unsigned short msg_cbytes;  /* current number of bytes on queue */     unsigned short msg_qnum;    /* number of messages in queue */     unsigned short msg_qbytes;  /* max number of bytes on queue */     __kernel_ipc_pid_t msg_lspid;   /* pid of last msgsnd */     __kernel_ipc_pid_t msg_lrpid;   /* last receive pid */ };

 

//可以看出上述兩個結構很相似。

 

附錄 3： 訊息佇列執行個體輸出結果：

current number of bytes on queue is 0 number of messages in queue is 0 max number of bytes on queue is 16384 pid of last msgsnd is 0 pid of last msgrcv is 0 last msgsnd time is Thu Jan  1 08:00:00 1970 last msgrcv time is Thu Jan  1 08:00:00 1970 last change time is Sun Dec 29 18:28:20 2002 msg uid is 0 msg gid is 0 //上面剛剛建立一個新訊息佇列時的輸出 current number of bytes on queue is 1 number of messages in queue is 1 max number of bytes on queue is 16384 pid of last msgsnd is 2510 pid of last msgrcv is 0 last msgsnd time is Sun Dec 29 18:28:21 2002 last msgrcv time is Thu Jan  1 08:00:00 1970 last change time is Sun Dec 29 18:28:20 2002 msg uid is 0 msg gid is 0 read from msg queue 1 bytes //實際讀出的位元組數 current number of bytes on queue is 0 number of messages in queue is 0 max number of bytes on queue is 16384   //每個訊息佇列最大容量（位元組數） pid of last msgsnd is 2510 pid of last msgrcv is 2510 last msgsnd time is Sun Dec 29 18:28:21 2002 last msgrcv time is Sun Dec 29 18:28:22 2002 last change time is Sun Dec 29 18:28:20 2002 msg uid is 0 msg gid is 0 current number of bytes on queue is 0 number of messages in queue is 0 max number of bytes on queue is 16388   //可看出超級使用者可修改訊息佇列最大容量 pid of last msgsnd is 2510 pid of last msgrcv is 2510  //對操作訊息佇列進程的跟蹤 last msgsnd time is Sun Dec 29 18:28:21 2002 last msgrcv time is Sun Dec 29 18:28:22 2002 last change time is Sun Dec 29 18:28:23 2002    //msgctl()調用對msg_ctime有影響 msg uid is 8 msg gid is 8

 

參考資料

• UNIX網路編程第二卷：處理序間通訊，作者：W.Richard Stevens，譯者：楊繼張，清華大學出版社。對POSIX以及系統V訊息佇列都有闡述，對Linux環境下的程式開發有極大的啟發意義。
• linux核心原始碼情景分析（上），毛德操、胡希明著，浙江大學出版社，給出了系統V訊息佇列相關的原始碼分析。
• http://www.fanqiang.com/a4/b2/20010508/113315.html，主要闡述linux下對檔案的操作，詳細介紹了對檔案的存取許可權位，對IPC對象的存取許可權同樣具有很好的借鑒意義。
• msgget、msgsnd、msgrcv、msgctl手冊

關於作者

鄭彥興，男，現攻讀國防科大電腦學院網路方向博士學位。您可以通過電子郵件mlinux@163.com和他聯絡。