深刻理解Linux进程间通信(IPC):(下)

5. 信号灯

简介: 信号灯与其他进程间通信方式不大相同,它主要提供对进程间共享资源访问控制机制。相当于内存中的标志,进程可以根据它判定是否能够访问某些共享资源,同时,进程也可以修改该标志。除了用于访问控制外,还可用于进程同步。

5.1. 信号灯概述

信号灯与其他进程间通信方式不大相同,它主要提供对进程间共享资源访问控制机制。相当于内存中的标志,进程可以根据它判定是否能够访问某些共享资源,同时,进程也可以修改该标志。除了用于访问控制外,还可用于进程同步。信号灯有以下两种类型:

  • 二值信号灯:最简单的信号灯形式,信号灯的值只能取0或1,类似于互斥锁。 
    注:二值信号灯能够实现互斥锁的功能,但两者的关注内容不同。信号灯强调共享资源,只要共享资源可用,其他进程同样可以修改信号灯的值;互斥锁更强调进程,占用资源的进程使用完资源后,必须由进程本身来解锁。
  • 计算信号灯:信号灯的值可以取任意非负值(当然受内核本身的约束)。

5.2. Linux信号灯

linux对信号灯的支持状况与消息队列一样,在red had 8.0发行版本中支持的是系统V的信号灯。因此,本文将主要介绍系统V信号灯及其相应API。在没有声明的情况下,以下讨论中指的都是系统V信号灯。

注意,通常所说的系统V信号灯指的是计数信号灯集。

5.3. 信号灯与内核

1、系统V信号灯是随内核持续的,只有在内核重起或者显示删除一个信号灯集时,该信号灯集才会真正被删除。因此系统中记录信号灯的数据结构(struct ipc_ids sem_ids)位于内核中,系统中的所有信号灯都可以在结构sem_ids中找到访问入口。

2、下图说明了内核与信号灯是怎样建立起联系的:

其中:structipc_ids sem_ids是内核中记录信号灯的全局数据结构;描述一个具体的信号灯及其相关信息。

其中,struct sem结构如下:

struct sem{

int semval; // current value

int sempid // pid of last operation

}

从上图可以看出,全局数据结构structipc_ids sem_ids可以访问到structkern_ipc_perm的第一个成员:structkern_ipc_perm;而每个structkern_ipc_perm能够与具体的信号灯对应起来是因为在该结构中,有一个key_t类型成员key,而key则唯一确定一个信号灯集;同时,结构struct kern_ipc_perm的最后一个成员sem_nsems确定了该信号灯在信号灯集中的顺序,这样内核就能够记录每个信号灯的信息了。kern_ipc_perm结构参见《Linux环境进程间通信(三):消息队列》。struct sem_array见附录1。

5.4. 操作信号灯

对消息队列的操作无非有下面三种类型:

1、打开或创建信号灯 
与消息队列的创建及打开基本相同,不再详述。

2、信号灯值操作 
linux可以增加或减小信号灯的值,相应于对共享资源的释放和占有。具体参见后面的semop系统调用。

3、获得或设置信号灯属性: 
系统中的每一个信号灯集都对应一个struct sem_array结构,该结构记录了信号灯集的各种信息,存在于系统空间。为了设置、获得该信号灯集的各种信息及属性,在用户空间有一个重要的联合结构与之对应,即union semun。

联合semun数据结构各成员意义参见附录2

信号灯API

1、文件名到键值

#include <sys/types.h>

#include <sys/ipc.h>

key_t ftok (char*pathname, char proj);

它返回与路径pathname相对应的一个键值,具体用法请参考《Linux环境进程间通信(三):消息队列》。

2、 linux特有的ipc()调用:

int ipc(unsigned int call, int first, intsecond, int third, void *ptr, long fifth);

参数call取不同值时,对应信号灯的三个系统调用: 
当call为SEMOP时,对应int semop(int semid, struct sembuf *sops, unsigned nsops)调用; 
当call为SEMGET时,对应int semget(key_t key, int nsems,int semflg)调用; 
当call为SEMCTL时,对应int semctl(int semid,int semnum,int cmd,union semun arg)调用; 
这些调用将在后面阐述。

注:本人不主张采用系统调用ipc(),而更倾向于采用系统V或者POSIX进程间通信API。原因已在Linux环境进程间通信(三):消息队列中给出。

3、系统V信号灯API

系统V消息队列API只有三个,使用时需要包括几个头文件:

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

1)int semget(key_t key, int nsems, int semflg) 
参数key是一个键值,由ftok获得,唯一标识一个信号灯集,用法与msgget()中的key相同;参数nsems指定打开或者新创建的信号灯集中将包含信号灯的数目;semflg参数是一些标志位。参数key和semflg的取值,以及何时打开已有信号灯集或者创建一个新的信号灯集与msgget()中的对应部分相同,不再祥述。 
该调用返回与健值key相对应的信号灯集描述字。 
调用返回:成功返回信号灯集描述字,否则返回-1。 
注:如果key所代表的信号灯已经存在,且semget指定了IPC_CREAT|IPC_EXCL标志,那么即使参数nsems与原来信号灯的数目不等,返回的也是EEXIST错误;如果semget只指定了IPC_CREAT标志,那么参数nsems必须与原来的值一致,在后面程序实例中还要进一步说明。

2)int semop(int semid, struct sembuf *sops, unsigned nsops); 
semid是信号灯集ID,sops指向数组的每一个sembuf结构都刻画一个在特定信号灯上的操作。nsops为sops指向数组的大小。
sembuf结构如下:

struct sembuf {

unsigned short sem_num; /* semaphore index in array */

short sem_op; /* semaphore operation */

short sem_flg; /* operation flags */

};

sem_num对应信号集中的信号灯,0对应第一个信号灯。sem_flg可取IPC_NOWAIT以及SEM_UNDO两个标志。如果设置了SEM_UNDO标志,那么在进程结束时,相应的操作将被取消,这是比较重要的一个标志位。如果设置了该标志位,那么在进程没有释放共享资源就退出时,内核将代为释放。如果为一个信号灯设置了该标志,内核都要分配一个sem_undo结构来记录它,为的是确保以后资源能够安全释放。事实上,如果进程退出了,那么它所占用就释放了,但信号灯值却没有改变,此时,信号灯值反映的已经不是资源占有的实际情况,在这种情况下,问题的解决就靠内核来完成。这有点像僵尸进程,进程虽然退出了,资源也都释放了,但内核进程表中仍然有它的记录,此时就需要父进程调用waitpid来解决问题了。 
sem_op的值大于0,等于0以及小于0确定了对sem_num指定的信号灯进行的三种操作。具体请参考linux相应手册页。 
这里需要强调的是semop同时操作多个信号灯,在实际应用中,对应多种资源的申请或释放。semop保证操作的原子性,这一点尤为重要。尤其对于多种资源的申请来说,要么一次性获得所有资源,要么放弃申请,要么在不占有任何资源情况下继续等待,这样,一方面避免了资源的浪费;另一方面,避免了进程之间由于申请共享资源造成死锁。 
也许从实际含义上更好理解这些操作:信号灯的当前值记录相应资源目前可用数目;sem_op>0对应相应进程要释放sem_op数目的共享资源;sem_op=0可以用于对共享资源是否已用完的测试;sem_op<0相当于进程要申请-sem_op个共享资源。再联想操作的原子性,更不难理解该系统调用何时正常返回,何时睡眠等待。 
调用返回:成功返回0,否则返回-1。

3) int semctl(int semid,int semnum,int cmd,union semun arg) 
该系统调用实现对信号灯的各种控制操作,参数semid指定信号灯集,参数cmd指定具体的操作类型;参数semnum指定对哪个信号灯操作,只对几个特殊的cmd操作有意义;arg用于设置或返回信号灯信息。 
该系统调用详细信息请参见其手册页,这里只给出参数cmd所能指定的操作。

IPC_STAT

获取信号灯信息,信息由arg.buf返回;

IPC_SET

设置信号灯信息,待设置信息保存在arg.buf中(在manpage中给出了可以设置哪些信息);

GETALL

返回所有信号灯的值,结果保存在arg.array中,参数sennum被忽略;

GETNCNT

返回等待semnum所代表信号灯的值增加的进程数,相当于目前有多少进程在等待semnum代表的信号灯所代表的共享资源;

GETPID

返回最后一个对semnum所代表信号灯执行semop操作的进程ID;

GETVAL

返回semnum所代表信号灯的值;

GETZCNT

返回等待semnum所代表信号灯的值变成0的进程数;

SETALL

通过arg.array更新所有信号灯的值;同时,更新与本信号集相关的semid_ds结构的sem_ctime成员;

SETVAL

设置semnum所代表信号灯的值为arg.val;

调用返回:调用失败返回-1,成功返回与cmd相关:

Cmd

return value

GETNCNT

Semncnt

GETPID

Sempid

GETVAL

Semval

GETZCNT

Semzcnt

5.5. 信号灯的限制

1、一次系统调用semop可同时操作的信号灯数目SEMOPM,semop中的参数nsops如果超过了这个数目,将返回E2BIG错误。SEMOPM的大小特定与系统,redhat 8.0为32。

2、信号灯的最大数目:SEMVMX,当设置信号灯值超过这个限制时,会返回ERANGE错误。在redhat 8.0中该值为32767。

3、系统范围内信号灯集的最大数目SEMMNI以及系统范围内信号灯的最大数目SEMMNS。超过这两个限制将返回ENOSPC错误。redhat 8.0中该值为32000。

4、每个信号灯集中的最大信号灯数目SEMMSL,redhat 8.0中为250。 SEMOPM以及SEMVMX是使用semop调用时应该注意的;SEMMNI以及SEMMNS是调用semget时应该注意的。SEMVMX同时也是semctl调用应该注意的。

5.6. 竞争问题

第一个创建信号灯的进程同时也初始化信号灯,这样,系统调用semget包含了两个步骤:创建信号灯;初始化信号灯。由此可能导致一种竞争状态:第一个创建信号灯的进程在初始化信号灯时,第二个进程又调用semget,并且发现信号灯已经存在,此时,第二个进程必须具有判断是否有进程正在对信号灯进行初始化的能力。在参考文献[1]中,给出了绕过这种竞争状态的方法:当semget创建一个新的信号灯时,信号灯结构semid_ds的sem_otime成员初始化后的值为0。因此,第二个进程在成功调用semget后,可再次以IPC_STAT命令调用semctl,等待sem_otime变为非0值,此时可判断该信号灯已经初始化完毕。下图描述了竞争状态产生及解决方法:


实际上,这种解决方法也是基于这样一个假定:第一个创建信号灯的进程必须调用semop,这样sem_otime才能变为非零值。另外,因为第一个进程可能不调用semop,或者semop操作需要很长时间,第二个进程可能无限期等待下去,或者等待很长时间。

5.7. 信号灯应用实例

本实例有两个目的:1、获取各种信号灯信息;2、利用信号灯实现共享资源的申请和释放。并在程序中给出了详细注释。

#include <linux/sem.h>

#include <stdio.h>

#include <errno.h>

#define SEM_PATH "/unix/my_sem"

#define max_tries 3

int semid;

main()

{

int flag1,flag2,key,i,init_ok,tmperrno;

struct semid_ds sem_info;

struct seminfo sem_info2;

union semun arg; //union semun: 请参考附录2

struct sembuf askfor_res, free_res;

flag1=IPC_CREAT|IPC_EXCL|00666;

flag2=IPC_CREAT|00666;

key=ftok(SEM_PATH,'a');

//error handling for ftok here;

init_ok=0;

semid=semget(key,1,flag1);

//create a semaphore set that only includes one semphore.

if(semid<0)

{

tmperrno=errno;

perror("semget");

if(tmperrno==EEXIST)

//errno is undefined after a successful library call( including perror call)

//so it is saved in tmperrno.

{

semid=semget(key,1,flag2);

//flag2 只包含了IPC_CREAT标志, 参数nsems(这里为1)必须与原来的信号灯数目一致

arg.buf=&sem_info;

for(i=0; i<max_tries; i++)

{

if(semctl(semid, 0, IPC_STAT, arg)==-1)

{ perror("semctl error"); i=max_tries;}

else

{

if(arg.buf->sem_otime!=0){ i=max_tries; init_ok=1;}

else sleep(1);

}

}

if(!init_ok)

// do some initializing, here we assume that the first process that creates the sem

// will finish initialize the sem and run semop in max_tries*1 seconds. else it will

// not run semop any more.

{

arg.val=1;

if(semctl(semid,0,SETVAL,arg)==-1) perror("semctl setval error");

}

}

else

{perror("semget error, process exit"); exit(); }

}

else //semid>=0; do some initializing

{

arg.val=1;

if(semctl(semid,0,SETVAL,arg)==-1)

perror("semctl setval error");

}

//get some information about the semaphore and the limit of semaphore in redhat8.0

arg.buf=&sem_info;

if(semctl(semid, 0, IPC_STAT, arg)==-1)

perror("semctl IPC STAT");

printf("owner's uid is %d\n", arg.buf->sem_perm.uid);

printf("owner's gid is %d\n", arg.buf->sem_perm.gid);

printf("creater's uid is %d\n", arg.buf->sem_perm.cuid);

printf("creater's gid is %d\n", arg.buf->sem_perm.cgid);

arg.__buf=&sem_info2;

if(semctl(semid,0,IPC_INFO,arg)==-1)

perror("semctl IPC_INFO");

printf("the number of entries in semaphore map is %d \n", arg.__buf->semmap);

printf("max number of semaphore identifiers is %d \n", arg.__buf->semmni);

printf("mas number of semaphores in system is %d \n", arg.__buf->semmns);

printf("the number of undo structures system wide is %d \n", arg.__buf->semmnu);

printf("max number of semaphores per semid is %d \n", arg.__buf->semmsl);

printf("max number of ops per semop call is %d \n", arg.__buf->semopm);

printf("max number of undo entries per process is %d \n", arg.__buf->semume);

printf("the sizeof of struct sem_undo is %d \n", arg.__buf->semusz);

printf("the maximum semaphore value is %d \n", arg.__buf->semvmx);

//now ask for available resource:

askfor_res.sem_num=0;

askfor_res.sem_op=-1;

askfor_res.sem_flg=SEM_UNDO;

if(semop(semid,&askfor_res,1)==-1)//ask for resource

perror("semop error");

sleep(3);

//do some handling on the sharing resource here, just sleep on it 3 seconds

printf("now free the resource\n");

//now free resource

free_res.sem_num=0;

free_res.sem_op=1;

free_res.sem_flg=SEM_UNDO;

if(semop(semid,&free_res,1)==-1)//free the resource.

if(errno==EIDRM)

printf("the semaphore set was removed\n");

//you can comment out the codes below to compile a different version:

if(semctl(semid, 0, IPC_RMID)==-1)

perror("semctl IPC_RMID");

else printf("remove sem ok\n");

}

注:读者可以尝试一下注释掉初始化步骤,进程在运行时会出现何种情况(进程在申请资源时会睡眠),同时可以像程序结尾给出的注释那样,把该程序编译成两个不同版本。下面是本程序的运行结果(操作系统redhat8.0):

owner's uid is 0

owner's gid is 0

creater's uid is 0

creater's gid is 0

the number of entries in semaphore map is 32000

max number of semaphore identifiers is 128

mas number of semaphores in system is 32000

the number of undo structures system wide is 32000

max number of semaphores per semid is 250

max number of ops per semop call is 32

max number of undo entries per process is 32

the sizeof of struct sem_undo is 20

the maximum semaphore value is 32767

now free the resource

remove sem ok

Summary:信号灯与其它进程间通信方式有所不同,它主要用于进程间同步。通常所说的系统V信号灯实际上是一个信号灯的集合,可用于多种共享资源的进程间同步。每个信号灯都有一个值,可以用来表示当前该信号灯代表的共享资源可用(available)数量,如果一个进程要申请共享资源,那么就从信号灯值中减去要申请的数目,如果当前没有足够的可用资源,进程可以睡眠等待,也可以立即返回。当进程要申请多种共享资源时,linux可以保证操作的原子性,即要么申请到所有的共享资源,要么放弃所有资源,这样能够保证多个进程不会造成互锁。Linux对信号灯有各种各样的限制,程序中给出了输出结果。另外,如果读者想对信号灯作进一步的理解,建议阅读sem.h源代码,该文件不长,但给出了信号灯相关的重要数据结构。

附录1: struct sem_array如下:

/*系统中的每个信号灯集对应一个sem_array 结构 */

struct sem_array {

struct kern_ipc_perm sem_perm; /* permissions .. see ipc.h */

time_t sem_otime; /* last semop time */

time_t sem_ctime; /* last change time */

struct sem *sem_base; /* ptr to first semaphore in array */

struct sem_queue *sem_pending; /* pending operations to be processed */

struct sem_queue **sem_pending_last; /* last pending operation */

struct sem_undo *undo; /* undo requests on this array */

unsigned long sem_nsems; /* no. of semaphores in array */

};

其中,sem_queue结构如下:

/* 系统中每个因为信号灯而睡眠的进程,都对应一个sem_queue结构*/

struct sem_queue {

struct sem_queue * next; /* next entry in the queue */

struct sem_queue ** prev;

/* previous entry in the queue, *(q->prev) == q */

struct task_struct* sleeper; /* this process */

struct sem_undo * undo; /* undo structure */

int pid; /* process id of requesting process */

int status; /* completion status of operation */

struct sem_array * sma; /* semaphore array for operations */

int id; /* internal sem id */

struct sembuf * sops; /* array of pending operations */

int nsops; /* number of operations */

int alter; /* operation will alter semaphore */

};

附录2:union semun是系统调用semctl中的重要参数:

union semun {

int val; /* value for SETVAL */

struct semid_ds *buf; /* buffer for IPC_STAT & IPC_SET */

unsigned short *array; /* array for GETALL & SETALL */

struct seminfo *__buf; /* buffer for IPC_INFO */ //test!!

void *__pad;

};

struct seminfo {

int semmap;

int semmni;

int semmns;

int semmnu;

int semmsl;

int semopm;

int semume;

int semusz;

int semvmx;

int semaem;

};

5.8. 参考资料

[1] UNIX网络编程第二卷:进程间通信,作者:W.Richard Stevens,译者:杨继张,清华大学出版社。对POSIX以及系统V信号灯都有阐述,对Linux环境下的程序开发有极大的启发意义。

[2] linux内核源代码情景分析(上),毛德操、胡希明著,浙江大学出版社,给出了系统V信号灯相关的源代码分析,尤其在阐述保证操作原子性方面,以及阐述undo标志位时,讨论的很深刻。

[3]GNU/Linux编程指南,第二版,Kurt Wall等著,张辉译

[4]semget、semop、semctl手册

6. 共享内存(上)

简介: 共享内存可以说是最有用的进程间通信方式,也是最快的IPC形式。两个不同进程A、B共享内存的意思是,同一块物理内存被映射到进程A、B各自的进程地址空间。进程A可以即时看到进程B对共享内存中数据的更新,反之亦然。由于多个进程共享同一块内存区域,必然需要某种同步机制,互斥锁和信号量都可以。

采用共享内存通信的一个显而易见的好处是效率高,因为进程可以直接读写内存,而不需要任何数据的拷贝。对于像管道和消息队列等通信方式,则需要在内核和用户空间进行四次的数据拷贝,而共享内存则只拷贝两次数据[1]:一次从输入文件到共享内存区,另一次从共享内存区到输出文件。实际上,进程之间在共享内存时,并不总是读写少量数据后就解除映射,有新的通信时,再重新建立共享内存区域。而是保持共享区域,直到通信完毕为止,这样,数据内容一直保存在共享内存中,并没有写回文件。共享内存中的内容往往是在解除映射时才写回文件的。因此,采用共享内存的通信方式效率是非常高的。

Linux的2.2.x内核支持多种共享内存方式,如mmap()系统调用,Posix共享内存,以及系统V共享内存。linux发行版本如Redhat 8.0支持mmap()系统调用及系统V共享内存,但还没实现Posix共享内存,本文将主要介绍mmap()系统调用及系统V共享内存API的原理及应用。

6.1. 内核怎样保证各个进程寻址到同一个共享内存区域的内存页面

1、page cache及swap cache中页面的区分:一个被访问文件的物理页面都驻留在page cache或swap cache中,一个页面的所有信息由struct page来描述。struct page中有一个域为指针mapping ,它指向一个struct address_space类型结构。page cache或swap cache中的所有页面就是根据address_space结构以及一个偏移量来区分的。

2、文件与address_space结构的对应:一个具体的文件在打开后,内核会在内存中为之建立一个struct inode结构,其中的i_mapping域指向一个address_space结构。这样,一个文件就对应一个address_space结构,一个address_space与一个偏移量能够确定一个page cache 或swap cache中的一个页面。因此,当要寻址某个数据时,很容易根据给定的文件及数据在文件内的偏移量而找到相应的页面。

3、进程调用mmap()时,只是在进程空间内新增了一块相应大小的缓冲区,并设置了相应的访问标识,但并没有建立进程空间到物理页面的映射。因此,第一次访问该空间时,会引发一个缺页异常。

4、对于共享内存映射情况,缺页异常处理程序首先在swap cache中寻找目标页(符合address_space以及偏移量的物理页),如果找到,则直接返回地址;如果没有找到,则判断该页是否在交换区(swap area),如果在,则执行一个换入操作;如果上述两种情况都不满足,处理程序将分配新的物理页面,并把它插入到page cache中。进程最终将更新进程页表。 
注:对于映射普通文件情况(非共享映射),缺页异常处理程序首先会在page cache中根据address_space以及数据偏移量寻找相应的页面。如果没有找到,则说明文件数据还没有读入内存,处理程序会从磁盘读入相应的页面,并返回相应地址,同时,进程页表也会更新。

5、所有进程在映射同一个共享内存区域时,情况都一样,在建立线性地址与物理地址之间的映射之后,不论进程各自的返回地址如何,实际访问的必然是同一个共享内存区域对应的物理页面。 
注:一个共享内存区域可以看作是特殊文件系统shm中的一个文件,shm的安装点在交换区上。

上面涉及到了一些数据结构,围绕数据结构理解问题会容易一些。

6.2. mmap()及其相关系统调用

mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后,进程可以向访问普通内存一样对文件进行访问,不必再调用read(),write()等操作。

注:实际上,mmap()系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式,进程可以像读写内存一样对普通文件的操作。而Posix或系统V的共享内存IPC则纯粹用于共享目的,当然mmap()实现共享内存也是其主要应用之一。

1、mmap()系统调用形式如下:

void* mmap ( void * addr , size_t len , intprot , int flags , int fd , off_t offset ) 
参数fd为即将映射到进程空间的文件描述字,一般由open()返回,同时,fd可以指定为-1,此时须指定flags参数中的MAP_ANON,表明进行的是匿名映射(不涉及具体的文件名,避免了文件的创建及打开,很显然只能用于具有亲缘关系的进程间通信)。len是映射到调用进程地址空间的字节数,它从被映射文件开头offset个字节开始算起。prot 参数指定共享内存的访问权限。可取如下几个值的或:PROT_READ(可读) , PROT_WRITE (可写), PROT_EXEC (可执行), PROT_NONE(不可访问)。flags由以下几个常值指定:MAP_SHARED , MAP_PRIVATE ,MAP_FIXED,其中,MAP_SHARED, MAP_PRIVATE必选其一,而MAP_FIXED则不推荐使用。offset参数一般设为0,表示从文件头开始映射。参数addr指定文件应被映射到进程空间的起始地址,一般被指定一个空指针,此时选择起始地址的任务留给内核来完成。函数的返回值为最后文件映射到进程空间的地址,进程可直接操作起始地址为该值的有效地址。这里不再详细介绍mmap()的参数,读者可参考mmap()手册页获得进一步的信息。

2、系统调用mmap()用于共享内存的两种方式:

(1)使用普通文件提供的内存映射:适用于任何进程之间; 此时,需要打开或创建一个文件,然后再调用mmap();典型调用代码如下:

fd=open(name, flag, mode);

if(fd<0)

...

ptr=mmap(NULL, len , PROT_READ|PROT_WRITE,MAP_SHARED , fd , 0); 通过mmap()实现共享内存的通信方式有许多特点和要注意的地方,我们将在范例中进行具体说明。

(2)使用特殊文件提供匿名内存映射:适用于具有亲缘关系的进程之间; 由于父子进程特殊的亲缘关系,在父进程中先调用mmap(),然后调用fork()。那么在调用fork()之后,子进程继承父进程匿名映射后的地址空间,同样也继承mmap()返回的地址,这样,父子进程就可以通过映射区域进行通信了。注意,这里不是一般的继承关系。一般来说,子进程单独维护从父进程继承下来的一些变量。而mmap()返回的地址,却由父子进程共同维护。 
对于具有亲缘关系的进程实现共享内存最好的方式应该是采用匿名内存映射的方式。此时,不必指定具体的文件,只要设置相应的标志即可,参见范例2。

3、系统调用munmap()

int munmap( void * addr, size_t len ) 
该调用在进程地址空间中解除一个映射关系,addr是调用mmap()时返回的地址,len是映射区的大小。当映射关系解除后,对原来映射地址的访问将导致段错误发生。

4、系统调用msync()

int msync ( void * addr , size_t len, intflags) 
一般说来,进程在映射空间的对共享内容的改变并不直接写回到磁盘文件中,往往在调用munmap()后才执行该操作。可以通过调用msync()实现磁盘上文件内容与共享内存区的内容一致。

6.3. mmap()范例

下面将给出使用mmap()的两个范例:范例1给出两个进程通过映射普通文件实现共享内存通信;范例2给出父子进程通过匿名映射实现共享内存。系统调用mmap()有许多有趣的地方,下面是通过mmap()映射普通文件实现进程间的通信的范例,我们通过该范例来说明mmap()实现共享内存的特点及注意事项。

范例1:两个进程通过映射普通文件实现共享内存通信

范例1包含两个子程序:map_normalfile1.c及map_normalfile2.c。编译两个程序,可执行文件分别为map_normalfile1及map_normalfile2。两个程序通过命令行参数指定同一个文件来实现共享内存方式的进程间通信。map_normalfile2试图打开命令行参数指定的一个普通文件,把该文件映射到进程的地址空间,并对映射后的地址空间进行写操作。map_normalfile1把命令行参数指定的文件映射到进程地址空间,然后对映射后的地址空间执行读操作。这样,两个进程通过命令行参数指定同一个文件来实现共享内存方式的进程间通信。

下面是两个程序代码:

/*-------------map_normalfile1.c-----------*/

#include <sys/mman.h>

#include <sys/types.h>

#include <fcntl.h>

#include <unistd.h>

typedef struct{

char name[4];

int age;

}people;

main(int argc, char** argv) // map a normal file as shared mem:

{

int fd,i;

people *p_map;

char temp;

fd=open(argv[1],O_CREAT|O_RDWR|O_TRUNC,00777);

lseek(fd,sizeof(people)*5-1,SEEK_SET);

write(fd,"",1);

p_map = (people*) mmap( NULL,sizeof(people)*10,PROT_READ|PROT_WRITE,

MAP_SHARED,fd,0 );

close( fd );

temp = 'a';

for(i=0; i<10; i++)

{

temp += 1;

memcpy( ( *(p_map+i) ).name, &temp,2 );

( *(p_map+i) ).age = 20+i;

}

printf(" initialize over \n ");

sleep(10);

munmap( p_map, sizeof(people)*10 );

printf( "umap ok \n" );

}

/*-------------map_normalfile2.c-----------*/

#include <sys/mman.h>

#include <sys/types.h>

#include <fcntl.h>

#include <unistd.h>

typedef struct{

char name[4];

int age;

}people;

main(int argc, char** argv) // map a normal file as shared mem:

{

int fd,i;

people *p_map;

fd=open( argv[1],O_CREAT|O_RDWR,00777 );

p_map = (people*)mmap(NULL,sizeof(people)*10,PROT_READ|PROT_WRITE,

MAP_SHARED,fd,0);

for(i = 0;i<10;i++)

{

printf( "name: %s age %d;\n",(*(p_map+i)).name, (*(p_map+i)).age );

}

munmap( p_map,sizeof(people)*10 );

}

map_normalfile1.c首先定义了一个people数据结构,(在这里采用数据结构的方式是因为,共享内存区的数据往往是有固定格式的,这由通信的各个进程决定,采用结构的方式有普遍代表性)。map_normfile1首先打开或创建一个文件,并把文件的长度设置为5个people结构大小。然后从mmap()的返回地址开始,设置了10个people结构。然后,进程睡眠10秒钟,等待其他进程映射同一个文件,最后解除映射。

map_normfile2.c只是简单的映射一个文件,并以people数据结构的格式从mmap()返回的地址处读取10个people结构,并输出读取的值,然后解除映射。

分别把两个程序编译成可执行文件map_normalfile1和map_normalfile2后,在一个终端上先运行./map_normalfile2 /tmp/test_shm,程序输出结果如下:

initialize over

umap ok

在map_normalfile1输出initialize over 之后,输出umap ok之前,在另一个终端上运行map_normalfile2/tmp/test_shm,将会产生如下输出(为了节省空间,输出结果为稍作整理后的结果):

name: b age 20; name: c age 21; name: d age 22; name: e age 23; name: f age 24;

name: g age 25; name: h age 26; name: I age 27; name: j age 28; name: k age 29;

在map_normalfile1输出umap ok后,运行map_normalfile2则输出如下结果:

name: b age 20; name: c age 21; name: d age 22; name: e age 23; name: f age 24;

name: age 0; name: age 0; name: age 0; name: age 0; name: age 0;

从程序的运行结果中可以得出的结论

1、最终被映射文件的内容的长度不会超过文件本身的初始大小,即映射不能改变文件的大小;

2、可以用于进程通信的有效地址空间大小大体上受限于被映射文件的大小,但不完全受限于文件大小。打开文件被截短为5个people结构大小,而在map_normalfile1中初始化了10个people数据结构,在恰当时候(map_normalfile1输出initialize over 之后,输出umap ok之前)调用map_normalfile2会发现map_normalfile2将输出全部10个people结构的值,后面将给出详细讨论。 
注:在linux中,内存的保护是以页为基本单位的,即使被映射文件只有一个字节大小,内核也会为映射分配一个页面大小的内存。当被映射文件小于一个页面大小时,进程可以对从mmap()返回地址开始的一个页面大小进行访问,而不会出错;但是,如果对一个页面以外的地址空间进行访问,则导致错误发生,后面将进一步描述。因此,可用于进程间通信的有效地址空间大小不会超过文件大小及一个页面大小的和。

3、文件一旦被映射后,调用mmap()的进程对返回地址的访问是对某一内存区域的访问,暂时脱离了磁盘上文件的影响。所有对mmap()返回地址空间的操作只在内存中有意义,只有在调用了munmap()后或者msync()时,才把内存中的相应内容写回磁盘文件,所写内容仍然不能超过文件的大小。

范例2:父子进程通过匿名映射实现共享内存

#include <sys/mman.h>

#include <sys/types.h>

#include <fcntl.h>

#include <unistd.h>

typedef struct{

char name[4];

int age;

}people;

main(int argc, char** argv)

{

int i;

people *p_map;

char temp;

p_map=(people*)mmap(NULL,sizeof(people)*10,PROT_READ|PROT_WRITE,

MAP_SHARED|MAP_ANONYMOUS,-1,0);

if(fork() == 0)

{

sleep(2);

for(i = 0;i<5;i++)

printf("child read: the %d people's age is %d\n",i+1,(*(p_map+i)).age);

(*p_map).age = 100;

munmap(p_map,sizeof(people)*10); //实际上,进程终止时,会自动解除映射。

exit();

}

temp = 'a';

for(i = 0;i<5;i++)

{

temp += 1;

memcpy((*(p_map+i)).name, &temp,2);

(*(p_map+i)).age=20+i;

}

sleep(5);

printf( "parent read: the first people,s age is %d\n",(*p_map).age );

printf("umap\n");

munmap( p_map,sizeof(people)*10 );

printf( "umap ok\n" );

}

考察程序的输出结果,体会父子进程匿名共享内存:

child read: the 1 people's age is 20

child read: the 2 people's age is 21

child read: the 3 people's age is 22

child read: the 4 people's age is 23

child read: the 5 people's age is 24

parent read: the first people,s age is 100

umap

umap ok

6.4. 对mmap()返回地址的访问

前面对范例运行结构的讨论中已经提到,linux采用的是页式管理机制。对于用mmap()映射普通文件来说,进程会在自己的地址空间新增一块空间,空间大小由mmap()的len参数指定,注意,进程并不一定能够对全部新增空间都能进行有效访问。进程能够访问的有效地址大小取决于文件被映射部分的大小。简单的说,能够容纳文件被映射部分大小的最少页面个数决定了进程从mmap()返回的地址开始,能够有效访问的地址空间大小。超过这个空间大小,内核会根据超过的严重程度返回发送不同的信号给进程。可用如下图示说明:

注意:文件被映射部分而不是整个文件决定了进程能够访问的空间大小,另外,如果指定文件的偏移部分,一定要注意为页面大小的整数倍。下面是对进程映射地址空间的访问范例:

#include <sys/mman.h>

#include <sys/types.h>

#include <fcntl.h>

#include <unistd.h>

typedef struct{

char name[4];

int age;

}people;

main(int argc, char** argv)

{

int fd,i;

int pagesize,offset;

people *p_map;

pagesize = sysconf(_SC_PAGESIZE);

printf("pagesize is %d\n",pagesize);

fd = open(argv[1],O_CREAT|O_RDWR|O_TRUNC,00777);

lseek(fd,pagesize*2-100,SEEK_SET);

write(fd,"",1);

offset = 0; //此处offset = 0编译成版本1;offset = pagesize编译成版本2

p_map = (people*)mmap(NULL,pagesize*3,PROT_READ|PROT_WRITE,MAP_SHARED,fd,offset);

close(fd);

for(i = 1; i<10; i++)

{

(*(p_map+pagesize/sizeof(people)*i-2)).age = 100;

printf("access page %d over\n",i);

(*(p_map+pagesize/sizeof(people)*i-1)).age = 100;

printf("access page %d edge over, now begin to access page %d\n",i, i+1);

(*(p_map+pagesize/sizeof(people)*i)).age = 100;

printf("access page %d over\n",i+1);

}

munmap(p_map,sizeof(people)*10);

}

如程序中所注释的那样,把程序编译成两个版本,两个版本主要体现在文件被映射部分的大小不同。文件的大小介于一个页面与两个页面之间(大小为:pagesize*2-99),版本1的被映射部分是整个文件,版本2的文件被映射部分是文件大小减去一个页面后的剩余部分,不到一个页面大小(大小为:pagesize-99)。程序中试图访问每一个页面边界,两个版本都试图在进程空间中映射pagesize*3的字节数。

版本1的输出结果如下:

pagesize is 4096

access page 1 over

access page 1 edge over, now begin to access page 2

access page 2 over

access page 2 over

access page 2 edge over, now begin to access page 3

Bus error //被映射文件在进程空间中覆盖了两个页面,此时,进程试图访问第三个页面

版本2的输出结果如下:

pagesize is 4096

access page 1 over

access page 1 edge over, now begin to access page 2

Bus error //被映射文件在进程空间中覆盖了一个页面,此时,进程试图访问第二个页面

结论:采用系统调用mmap()实现进程间通信是很方便的,在应用层上接口非常简洁。内部实现机制区涉及到了linux存储管理以及文件系统等方面的内容,可以参考一下相关重要数据结构来加深理解。在本专题的后面部分,将介绍系统v共享内存的实现。

6.5. 参考资料

[1] Understanding the Linux Kernel, 2ndEdition, By Daniel P. Bovet, Marco Cesati , 对各主题阐述得重点突出,脉络清晰。

[2] UNIX网络编程第二卷:进程间通信,作者:W.Richard Stevens,译者:杨继张,清华大学出版社。对mmap()有详细阐述。

[3] Linux内核源代码情景分析(上),毛德操、胡希明著,浙江大学出版社,给出了mmap()相关的源代码分析。

[4]mmap()手册

7. 共享内存(下)

简介:在共享内存(上)中,主要围绕着系统调用mmap()进行讨论的,本部分将讨论系统V共享内存,并通过实验结果对比来阐述两者的异同。系统V共享内存指的是把所有共享数据放在共享内存区域(IPC sharedmemory region),任何想要访问该数据的进程都必须在本进程的地址空间新增一块内存区域,用来映射存放共享数据的物理内存页面。

系统调用mmap()通过映射一个普通文件实现共享内存。系统V则是通过映射特殊文件系统shm中的文件实现进程间的共享内存通信。也就是说,每个共享内存区域对应特殊文件系统shm中的一个文件(这是通过shmid_kernel结构联系起来的),后面还将阐述。

7.1. 系统V共享内存原理

进程间需要共享的数据被放在一个叫做IPC共享内存区域的地方,所有需要访问该共享区域的进程都要把该共享区域映射到本进程的地址空间中去。系统V共享内存通过shmget获得或创建一个IPC共享内存区域,并返回相应的标识符。内核在保证shmget获得或创建一个共享内存区,初始化该共享内存区相应的shmid_kernel结构注同时,还将在特殊文件系统shm中,创建并打开一个同名文件,并在内存中建立起该文件的相应dentry及inode结构,新打开的文件不属于任何一个进程(任何进程都可以访问该共享内存区)。所有这一切都是系统调用shmget完成的。

注:每一个共享内存区都有一个控制结构struct shmid_kernel,shmid_kernel是共享内存区域中非常重要的一个数据结构,它是存储管理和文件系统结合起来的桥梁,定义如下:

struct shmid_kernel /* private to the kernel */

{

struct kern_ipc_perm shm_perm;

struct file * shm_file;

int id;

unsigned long shm_nattch;

unsigned long shm_segsz;

time_t shm_atim;

time_t shm_dtim;

time_t shm_ctim;

pid_t shm_cprid;

pid_t shm_lprid;

};

该结构中最重要的一个域应该是shm_file,它存储了将被映射文件的地址。每个共享内存区对象都对应特殊文件系统shm中的一个文件,一般情况下,特殊文件系统shm中的文件是不能用read()、write()等方法访问的,当采取共享内存的方式把其中的文件映射到进程地址空间后,可直接采用访问内存的方式对其访问。

这里我们采用[1]中的图表给出与系统V共享内存相关数据结构:

正如消息队列和信号灯一样,内核通过数据结构struct ipc_ids shm_ids维护系统中的所有共享内存区域。上图中的shm_ids.entries变量指向一个ipc_id结构数组,而每个ipc_id结构数组中有个指向kern_ipc_perm结构的指针。到这里读者应该很熟悉了,对于系统V共享内存区来说,kern_ipc_perm的宿主是shmid_kernel结构,shmid_kernel是用来描述一个共享内存区域的,这样内核就能够控制系统中所有的共享区域。同时,在shmid_kernel结构的file类型指针shm_file指向文件系统shm中相应的文件,这样,共享内存区域就与shm文件系统中的文件对应起来。

在创建了一个共享内存区域后,还要将它映射到进程地址空间,系统调用shmat()完成此项功能。由于在调用shmget()时,已经创建了文件系统shm中的一个同名文件与共享内存区域相对应,因此,调用shmat()的过程相当于映射文件系统shm中的同名文件过程,原理与mmap()大同小异。

7.2. 系统V共享内存API

对于系统V共享内存,主要有以下几个API:shmget()、shmat()、shmdt()及shmctl()。

#include <sys/ipc.h>

#include <sys/shm.h>

shmget()用来获得共享内存区域的ID,如果不存在指定的共享区域就创建相应的区域。shmat()把共享内存区域映射到调用进程的地址空间中去,这样,进程就可以方便地对共享区域进行访问操作。shmdt()调用用来解除进程对共享内存区域的映射。shmctl实现对共享内存区域的控制操作。这里我们不对这些系统调用作具体的介绍,读者可参考相应的手册页面,后面的范例中将给出它们的调用方法。

注:shmget的内部实现包含了许多重要的系统V共享内存机制;shmat在把共享内存区域映射到进程空间时,并不真正改变进程的页表。当进程第一次访问内存映射区域访问时,会因为没有物理页表的分配而导致一个缺页异常,然后内核再根据相应的存储管理机制为共享内存映射区域分配相应的页表。

7.3. 系统V共享内存限制

在/proc/sys/kernel/目录下,记录着系统V共享内存的一下限制,如一个共享内存区的最大字节数shmmax,系统范围内最大共享内存区标识符数shmmni等,可以手工对其调整,但不推荐这样做。

在[2]中,给出了这些限制的测试方法,不再赘述。

7.4. 系统V共享内存范例

本部分将给出系统V共享内存API的使用方法,并对比分析系统V共享内存机制与mmap()映射普通文件实现共享内存之间的差异,首先给出两个进程通过系统V共享内存通信的范例:

/***** testwrite.c *******/

#include <sys/ipc.h>

#include <sys/shm.h>

#include <sys/types.h>

#include <unistd.h>

typedef struct{

char name[4];

int age;

} people;

main(int argc, char** argv)

{

int shm_id,i;

key_t key;

char temp;

people *p_map;

char* name = "/dev/shm/myshm2";

key = ftok(name,0);

if(key==-1)

perror("ftok error");

shm_id=shmget(key,4096,IPC_CREAT);

if(shm_id==-1)

{

perror("shmget error");

return;

}

p_map=(people*)shmat(shm_id,NULL,0);

temp='a';

for(i = 0;i<10;i++)

{

temp+=1;

memcpy((*(p_map+i)).name,&temp,1);

(*(p_map+i)).age=20+i;

}

if(shmdt(p_map)==-1)

perror(" detach error ");

}

/********** testread.c ************/

#include <sys/ipc.h>

#include <sys/shm.h>

#include <sys/types.h>

#include <unistd.h>

typedef struct{

char name[4];

int age;

} people;

main(int argc, char** argv)

{

int shm_id,i;

key_t key;

people *p_map;

char* name = "/dev/shm/myshm2";

key = ftok(name,0);

if(key == -1)

perror("ftok error");

shm_id = shmget(key,4096,IPC_CREAT);

if(shm_id == -1)

{

perror("shmget error");

return;

}

p_map = (people*)shmat(shm_id,NULL,0);

for(i = 0;i<10;i++)

{

printf( "name:%s\n",(*(p_map+i)).name );

printf( "age %d\n",(*(p_map+i)).age );

}

if(shmdt(p_map) == -1)

perror(" detach error ");

}

testwrite.c创建一个系统V共享内存区,并在其中写入格式化数据;testread.c访问同一个系统V共享内存区,读出其中的格式化数据。分别把两个程序编译为testwrite及testread,先后执行./testwrite及./testread 则./testread输出结果如下:

name: b age 20; name: c age 21; name: d age 22; name: e age 23; name: f age 24;

name: g age 25; name: h age 26; name: I age 27; name: j age 28; name: k age 29;

通过对试验结果分析,对比系统V与mmap()映射普通文件实现共享内存通信,可以得出如下结论:

1、系统V共享内存中的数据,从来不写入到实际磁盘文件中去;而通过mmap()映射普通文件实现的共享内存通信可以指定何时将数据写入磁盘文件中。注:前面讲到,系统V共享内存机制实际是通过映射特殊文件系统shm中的文件实现的,文件系统shm的安装点在交换分区上,系统重新引导后,所有的内容都丢失。

2、系统V共享内存是随内核持续的,即使所有访问共享内存的进程都已经正常终止,共享内存区仍然存在(除非显式删除共享内存),在内核重新引导之前,对该共享内存区域的任何改写操作都将一直保留。

3、通过调用mmap()映射普通文件进行进程间通信时,一定要注意考虑进程何时终止对通信的影响。而通过系统V共享内存实现通信的进程则不然。 注:这里没有给出shmctl的使用范例,原理与消息队列大同小异。

7.5. 结论

共享内存允许两个或多个进程共享一给定的存储区,因为数据不需要来回复制,所以是最快的一种进程间通信机制。共享内存可以通过mmap()映射普通文件(特殊情况下还可以采用匿名映射)机制实现,也可以通过系统V共享内存机制实现。应用接口和原理很简单,内部机制复杂。为了实现更安全通信,往往还与信号灯等同步机制共同使用。

共享内存涉及到了存储管理以及文件系统等方面的知识,深入理解其内部机制有一定的难度,关键还要紧紧抓住内核使用的重要数据结构。系统V共享内存是以文件的形式组织在特殊文件系统shm中的。通过shmget可以创建或获得共享内存的标识符。取得共享内存标识符后,要通过shmat将这个内存区映射到本进程的虚拟地址空间。

7.6. 参考资料

[1] Understanding the Linux Kernel, 2ndEdition, By Daniel P. Bovet, Marco Cesati , 对各主题阐述得重点突出,脉络清晰。

[2] UNIX网络编程第二卷:进程间通信,作者:W.Richard Stevens,译者:杨继张,清华大学出版社。对mmap()有详细阐述。

[3] Linux内核源代码情景分析(上),毛德操、胡希明著,浙江大学出版社,给出了mmap()相关的源代码分析。

[4]shmget、shmat、shmctl、shmdt手册

8. 套接口

简介: 在本专题的前面几个部分,如消息队列、信号灯、共享内存等,都是基于SysV的IPC机制进行讨论的,它们的应用局限在单一计算机内的进程间通信;基于BSD套接口不仅可以实现单机内的进程间通信,还可以实现不同计算机进程之间的通信。本文将主要介绍BSD套接口(sockets),以及基于套接口的重要而基本的API。

一个套接口可以看作是进程间通信的端点(endpoint),每个套接口的名字都是唯一的(唯一的含义是不言而喻的),其他进程可以发现、连接并且与之通信。通信域用来说明套接口通信的协议,不同的通信域有不同的通信协议以及套接口的地址结构等等,因此,创建一个套接口时,要指明它的通信域。比较常见的是unix域套接口(采用套接口机制实现单机内的进程间通信)及网际通信域。

8.1. 背景知识

linux目前的网络内核代码主要基于伯克利的BSD的unix实现,整个结构采用的是一种面向对象的分层机制。层与层之间有严格的接口定义。这里我们引用[1]中的一个图表来描述linux支持的一些通信协议:

我们这里只关心IPS,即因特网协议族,也就是通常所说的TCP/IP网络。我们这里假设读者具有网络方面的一些背景知识,如了解网络的分层结构,通常所说的7层结构;了解IP地址以及路由的一些基本知识。

目前linux网络API是基于BSD套接口的(系统V提供基于流I/O子系统的用户接口,但是linux内核目前不支持流I/O子系统)。套接口可以说是网络编程中一个非常重要的概念,linux以文件的形式实现套接口,与套接口相应的文件属于sockfs特殊文件系统,创建一个套接口就是在sockfs中创建一个特殊文件,并建立起为实现套接口功能的相关数据结构。换句话说,对每一个新创建的BSD套接口,linux内核都将在sockfs特殊文件系统中创建一个新的inode。描述套接口的数据结构是socket,将在后面给出。

8.2. 重要数据结构

下面是在网络编程中比较重要的几个数据结构,读者可以在后面介绍编程API部分再回过头来了解它们。

(1)表示套接口的数据结构struct socket

套接口是由socket数据结构代表的,形式如下:

struct socket

{

socket_state state; /* 指明套接口的连接状态,一个套接口的连接状态可以有以下几种

套接口是空闲的,还没有进行相应的端口及地址的绑定;还没有连接;正在连接中;已经连接;正在解除连接。 */

unsigned long flags;

struct proto_ops ops; /* 指明可对套接口进行的各种操作 */

struct inode inode; /* 指向sockfs文件系统中的相应inode */

struct fasync_struct *fasync_list; /* Asynchronous wake up list */

struct file *file; /* 指向sockfs文件系统中的相应文件 */

struct sock sk; /* 任何协议族都有其特定的套接口特性,该域就指向特定协议族的套接口对

象。 */

wait_queue_head_t wait;

short type;

unsigned char passcred;

};

(2)描述套接口通用地址的数据结构struct sockaddr

由于历史的缘故,在bind、connect等系统调用中,特定于协议的套接口地址结构指针都要强制转换成该通用的套接口地址结构指针。结构形式如下:

struct sockaddr {

sa_family_t sa_family; /* address family, AF_xxx */

char sa_data[14]; /* 14 bytes of protocol address */

};

(3)描述因特网地址结构的数据结构struct sockaddr_in(这里局限于IP4):

struct sockaddr_in

{

__SOCKADDR_COMMON (sin_); /* 描述协议族 */

in_port_t sin_port; /* 端口号 */

struct in_addr sin_addr; /* 因特网地址 */

/* Pad to size of `struct sockaddr'. */

unsigned char sin_zero[sizeof (struct sockaddr) -

__SOCKADDR_COMMON_SIZE -

sizeof (in_port_t) -

sizeof (struct in_addr)];

};

一般来说,读者最关心的是前三个域,即通信协议、端口号及地址。

8.3. 套接口编程的几个重要步骤

(1)创建套接口,由系统调用socket实现:

int socket( int domain, int type, int ptotocol);

参数domain指明通信域,如PF_UNIX(unix域),PF_INET(IPv4),PF_INET6(IPv6)等;type指明通信类型,如SOCK_STREAM(面向连接方式)、SOCK_DGRAM(非面向连接方式)等。一般来说,参数protocol可设置为0,除非用在原始套接口上(原始套接口有一些特殊功能,后面还将介绍)。

注:socket()系统调用为套接口在sockfs文件系统中分配一个新的文件和dentry对象,并通过文件描述符把它们与调用进程联系起来。进程可以像访问一个已经打开的文件一样访问套接口在sockfs中的对应文件。但进程绝不能调用open()来访问该文件(sockfs文件系统没有可视安装点,其中的文件永远不会出现在系统目录树上),当套接口被关闭时,内核会自动删除sockfs中的inodes。

(2)绑定地址

根据传输层协议(TCP、UDP)的不同,客户机及服务器的处理方式也有很大不同。但是,不管通信双方使用何种传输协议,都需要一种标识自己的机制。

通信双方一般由两个方面标识:地址和端口号(通常,一个IP地址和一个端口号常常被称为一个套接口)。根据地址可以寻址到主机,根据端口号则可以寻址到主机提供特定服务的进程,实际上,一个特定的端口号代表了一个提供特定服务的进程。

对于使用TCP传输协议通信方式来说,通信双方需要给自己绑定一个唯一标识自己的套接口,以便建立连接;对于使用UDP传输协议,只需要服务器绑定一个标识自己的套接口就可以了,用户则不需要绑定(在需要时,如调用connect时[注1],内核会自动分配一个本地地址和本地端口号)。绑定操作由系统调用bind()完成:

int bind( int sockfd, const struct sockaddr * my_addr, socklen_t my_addr_len)

第二个参数对于Ipv4来说,实际上需要填充的结构是struct sockaddr_in,前面已经介绍了该结构。这里只想强调该结构的第一个域,它表明该套接口使用的通信协议,如AF_INET。联系socket系统调用的第一个参数,读者可能会想到PF_INET与AF_INET究竟有什么不同?实际上,原来的想法是每个通信域(如PF_INET)可能对应多个协议(如AF_INET),而事实上支持多个协议的通信域一直没有实现。因此,在linux内核中,AF_***与PF_***被定义为同一个常数,因此,在编程时可以不加区分地使用他们。

注1:在采用非面向连接通信方式时,也会用到connect()调用,不过与在面向连接中的connect()调用有本质的区别:在非面向连接通信中,connect调用只是先设置一下对方的地址,内核为本地套接口记下对方的地址,然后采用send()来发送数据,这样避免每次发送时都要提供相同的目的地址。其中的connect()调用不涉及握手过程;而在面向连接的通信方式中,connect()要完成一个严格的握手过程。

(3)请求建立连接(由TCP客户发起)

对于采用面向连接的传输协议TCP实现通信来说,一个比较重要的步骤就是通信双方建立连接(如果采用udp传输协议则不需要),由系统调用connect()完成:

int connect( int sockfd, const struct sockaddr * servaddr, socklen_t addrlen)

第一个参数为本地调用socket后返回的描述符,第二个参数为服务器的地址结构指针。connect()向指定的套接口请求建立连接。

注:与connect()相对应,在服务器端,通过系统调用listen(),指定服务器端的套接口为监听套接口,监听每一个向服务器套接口发出的连接请求,并通过握手机制建立连接。内核为listen()维护两个队列:已完成连接队列和未完成连接队列。

(4)接受连接请求(由TCP服务器端发起)

服务器端通过监听套接口,为所有连接请求建立了两个队列:已完成连接队列和未完成连接队列(每个监听套接口都对应这样两个队列,当然,一般服务器只有一个监听套接口)。通过accept()调用,服务器将在监听套接口的已连接队列头中,返回用于代表当前连接的套接口描述字。

int accept( int sockfd, struct sockaddr * cliaddr, socklen_t * addrlen)

第一个参数指明哪个监听套接口,一般是由listen()系统调用指定的(由于每个监听套接口都对应已连接和未连接两个队列,因此它的内部机制实质是通过sockfd指定在哪个已连接队列头中返回一个用于当前客户的连接,如果相应的已连接队列为空,accept进入睡眠)。第二个参数指明客户的地址结构,如果对客户的身份不感兴趣,可指定其为空。

注:对于采用TCP传输协议进行通信的服务器和客户机来说,一定要经过客户请求建立连接,服务器接受连接请求这一过程;而对采用UDP传输协议的通信双方则不需要这一步骤。

(5)通信

客户机可以通过套接口接收服务器传过来的数据,也可以通过套接口向服务器发送数据。前面所有的准备工作(创建套接口、绑定等操作)都是为这一步骤准备的。

常用的从套接口中接收数据的调用有:recv、recvfrom、recvmsg等,常用的向套接口中发送数据的调用有send、sendto、sendmsg等。

int recv(int s, void *

buf, size_t

len, int

flags)

int recvfrom(int s, void *

buf, size_t

len, int

flags, struct sockaddr *

from, socklen_t *

fromlen)

int recvmsg(int s, struct msghdr *

msg, int

flags)

int send(int s,const void *

msg, size_t

len, int

flags)

int sendto(int s, const void *

msg, size_t

len, int

flags const struct sockaddr *

to, socklen_t

tolen)

int sendmsg(int s, const struct msghdr *

msg, int

flags)

这里不再对这些调用作具体的说明,只想强调一下,recvfrom()以及recvmsg()可用于面向连接的套接口,也可用于面向非连接的套接口;而recv()一般用于面向连接的套接口。另外,在调用了connect()之后,就应给调用send()而不是sendto()了,因为调用了connect之后,目标就已经确定了。

前面讲到,socket()系统调用返回套接口描述字,实际上它是一个文件描述符。所以,可以对套接口进行通常的读写操作,即使用read()及write()方法。在实际应用中,由于面向连接的通信(采用TCP传输协议)是可靠的,同时又保证字节流原有的顺序,所以更适合用read及write方法。而非面向连接的通信(采用UDP传输协议)是不可靠的,字节流也不一定保持原有的顺序,所以一般不宜用read及write方法。

(6)通信的最后一步是关闭套接口

由close()来完成此项功能,它唯一的参数是套接口描述字,不再赘述。

8.4. 典型调用代码

到处可以发现基于套接口的客户机及服务器程序,这里不再给出完整的范例代码,只是给出它们的典型调用代码,并给出简要说明。

(1)典型的TCP服务器代码:

... ...

int listen_fd, connect_fd;

struct sockaddr_in serv_addr, client_addr;

... ...

listen_fd = socket ( PF_INET, SOCK_STREAM, 0 );

/* 创建网际Ipv4域的(由PF_INET指定)面向连接的(由SOCK_STREAM指定,

如果创建非面向连接的套接口则指定为SOCK_DGRAM)

的套接口。第三个参数0表示由内核确定缺省的传输协议,

对于本例,由于创建的是可靠的面向连接的基于流的套接口,

内核将选择TCP作为本套接口的传输协议) */

bzero( &serv_addr, sizeof(serv_addr) );

serv_addr.sin_family = AF_INET ; /* 指明通信协议族 */

serv_addr.sin_port = htons( 49152 ) ; /* 分配端口号 */

inet_pton(AF_INET, " 192.168.0.11", &serv_addr.sin_sddr) ;

/* 分配地址,把点分十进制IPv4地址转化为32位二进制Ipv4地址。 */

bind( listen_fd, (struct sockaddr*) serv_addr, sizeof ( struct sockaddr_in )) ;

/* 实现绑定操作 */

listen( listen_fd, max_num) ;

/* 套接口进入侦听状态,max_num规定了内核为此套接口排队的最大连接个数 */

for( ; ; ) {

... ...

connect_fd = accept( listen_fd, (struct sockaddr*)client_addr, &len ) ; /* 获得连接fd. */

... ... /* 发送和接收数据 */

}

注:端口号的分配是有一些惯例的,不同的端口号对应不同的服务或进程。比如一般都把端口号21分配给FTP服务器的TCP/IP实现。端口号一般分为3段,0-1023(受限的众所周知的端口,由分配数值的权威机构IANA管理),1024-49151(可以从IANA那里申请注册的端口),49152-65535(临时端口,这就是为什么代码中的端口号为49152)。

对于多字节整数在内存中有两种存储方式:一种是低字节在前,高字节在后,这样的存储顺序被称为低端字节序(little-endian);高字节在前,低字节在后的存储顺序则被称为高端字节序(big-endian)。网络协议在处理多字节整数时,采用的是高端字节序,而不同的主机可能采用不同的字节序。因此在编程时一定要考虑主机字节序与网络字节序间的相互转换。这就是程序中使用htons函数的原因,它返回网络字节序的整数。

(2)典型的TCP客户代码:

... ...

int socket_fd;

struct sockaddr_in serv_addr ;

... ...

socket_fd = socket ( PF_INET, SOCK_STREAM, 0 );

bzero( &serv_addr, sizeof(serv_addr) );

serv_addr.sin_family = AF_INET ; /* 指明通信协议族 */

serv_addr.sin_port = htons( 49152 ) ; /* 分配端口号 */

inet_pton(AF_INET, " 192.168.0.11", &serv_addr.sin_sddr) ;

/* 分配地址,把点分十进制IPv4地址转化为32位二进制Ipv4地址。 */

connect( socket_fd, (struct sockaddr*)serv_addr, sizeof( serv_addr ) ) ; /* 向服务器发起连接请求 */

... ... /* 发送和接收数据 */

... ...

对比两段代码可以看出,许多调用是服务器或客户机所特有的。另外,对于非面向连接的传输协议,代码还有简单些,没有连接的发起请求和接收请求部分。

8.5. 网络编程中的其他重要概念

下面列出了网络编程中的其他重要概念,基本上都是给出这些概念能够实现的功能,读者在编程过程中如果需要这些功能,可查阅相关概念。

(1)、I/O复用的概念

I/O复用提供一种能力,这种能力使得当一个I/O条件满足时,进程能够及时得到这个信息。I/O复用一般应用在进程需要处理多个描述字的场合。它的一个优势在于,进程不是阻塞在真正的I/O调用上,而是阻塞在select()调用上,select()可以同时处理多个描述字,如果它所处理的所有描述字的I/O都没有处于准备好的状态,那么将阻塞;如果有一个或多个描述字I/O处于准备好状态,则select()不阻塞,同时会根据准备好的特定描述字采取相应的I/O操作。

(2)、Unix通信域

前面主要介绍的是PF_INET通信域,实现网际间的进程间通信。基于Unix通信域(调用socket时指定通信域为PF_LOCAL即可)的套接口可以实现单机之间的进程间通信。采用Unix通信域套接口有几个好处:Unix通信域套接口通常是TCP套接口速度的两倍;另一个好处是,通过Unix通信域套接口可以实现在进程间传递描述字。所有可用描述字描述的对象,如文件、管道、有名管道及套接口等,在我们以某种方式得到该对象的描述字后,都可以通过基于Unix域的套接口来实现对描述字的传递。接收进程收到的描述字值不一定与发送进程传递的值一致(描述字是特定于进程的),但是特们指向内核文件表中相同的项。

(3)、原始套接口

原始套接口提供一般套接口所不提供的功能:

  • 原始套接口可以读写一些用于控制的控制协议分组,如ICMPv4等,进而可实现一些特殊功能。
  • 原始套接口可以读写特殊的IPv4数据包。内核一般只处理几个特定协议字段的数据包,那么一些需要不同协议字段的数据包就需要通过原始套接口对其进行读写;
  • 通过原始套接口可以构造自己的Ipv4头部,也是比较有意思的一点。

创建原始套接口需要root权限。

(4)、对数据链路层的访问

对数据链路层的访问,使得用户可以侦听本地电缆上的所有分组,而不需要使用任何特殊的硬件设备,在linux下读取数据链路层分组需要创建SOCK_PACKET类型的套接口,并需要有root权限。

(5)、带外数据(out-of-band data)

如果有一些重要信息要立刻通过套接口发送(不经过排队),请查阅与带外数据相关的文献。

(6)、多播

linux内核支持多播,但是在默认状态下,多数linux系统都关闭了对多播的支持。因此,为了实现多播,可能需要重新配置并编译内核。具体请参考[4]及[2]。

结论:linux套接口编程的内容可以说是极大丰富,同时它涉及到许多的网络背景知识,有兴趣的读者可在[2]中找到比较系统而全面的介绍。

至此,本专题系列(linux环境进程间通信)全部结束了。实际上,进程间通信的一般意义通常指的是消息队列、信号灯和共享内存,可以是posix的,也可以是SYS v的。本系列同时介绍了管道、有名管道、信号以及套接口等,是更为一般意义上的进程间通信机制。

8.6. 参考资料

  • Understanding the Linux Kernel, 2nd Edition, By Daniel P. Bovet, Marco Cesati , 对各主题阐述得重点突出,脉络清晰。网络部分分析集中在TCP/IP协议栈的数据连路层、网络层以及传输层。
  • UNIX网络编程第一卷:套接口API和X/Open传输接口API,作者:W.Richard Stevens,译者:杨继张,清华大学出版社。不仅对套接口网络编程有极好的描述,而且极为详尽的阐述了相关的网络背景知识。不论是入门还是深入研究,都是不可多得的好资料。
  • Linux内核源代码情景分析(下),毛德操、胡希明著,浙江大学出版社,给出了unix域套接口部分的内核代码分析。
  • GNU/Linux编程指南,入门、应用、精通,第二版,Kurt Wall等著,张辉译
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值