以前只知道一个端口用同一个协议只能有一个进程来监听;fork会继承文件描述符。
遂有疑惑,若先listen,再fork,后accept,哪个进程得到客户端的链接?
通过实验,得出结论:
fork之后两个进程会抢占accept的机会,没抢到的进程会阻塞,等待有权accept的进程死掉,然后去accept。
过程:
当启动进程后,用netstat命令查看到在监听的pid,只能看到一个pid在那监听;
然后,用浏览器去链接这个端口,这时在监听的进程接收消息,然后sleep,再用netstat查看,在监听端口的pid没变;
sleep时间到,进程结束,这时用nentstat查看,pid变成了另一个
应用:
用于多进程提供服务是不行的,但是,可以用于防服务进程挂掉,一旦主服务进程挂掉,备份马上就会顶上去,只要备份进程再去fork一个子进程作为备份进程,就可以形成一个“永不结束”的进程。一来避免了服务器死掉再人工启动的反应时间,二来,不必等待监听的进程挂掉后释放端口的时间。