1
前一段时间使用IOCP开发一个服务器后,在公网测试效果非常不理想,考虑到后面得项目采用Linux完成,IOCP暂告一段落了。后来在看一些流行得服务器架构中,多数采用select模型,深感不解,经过深入找资料,略有所唔。其效率也非常高。已经夜半了,无所事事,四处瞎逛,翻起一篇老帖,心中泛起无数波澜,得来全不费工夫。
代码下载:
下载文件 (已下载 350 次)
THE WORLD OF SELECT()
So just why am I so hyped on select()?
One traditional way to write network servers is to have the main server block on accept(), waiting for a connection. Once a connection comes in, the server fork()s, the child process handles the connection and the main server is able to service new incoming requests.
With select(), instead of having a process for each request, there is usually only one process that "multi-plexes" all requests, servicing each request as much as it can.
So one main advantage of using select() is that your server will only require a single process to handle all requests. Thus, your server will not need shared memory or synchronization primitives for different 'tasks' to communicate.
One major disadvantage of using select(), is that your server cannot act like there's only one client, like with a fork()'ing solution. For example, with a fork()'ing solution, after the server fork()s, the child process works with the client as if there was only one client in the universe -- the child does not have to worry about new incoming connections or the existence of other sockets. With select(), the programming isn't as transparent.
Okay, so how do you use select()?
select() works by blocking until something happens on a file descriptor (aka a socket). What's 'something'? Data coming in or being able to write to a file descriptor -- you tell select() what you want to be woken up by. How do you tell it? You fill up a fd_set structure with some macros.
Most select()-based servers look pretty much the same:
Quit with the pseudo-code, show me some real code!
Okay, let's take a look at a sample server included with Vic Metcalfe's Socket Programming FAQ (my comments are in red):
Okay, so maybe that wasn't the best example...
Got some suggests? Corrections? Please let me know.
In the mean time, here's some references to other sources of information about select():
Socket FAQ Question about select()
Straight from the excellent socket FAQ.
Unix Programming FAQ Question about select()
Straight from the other excellent FAQ.
Unix Socket Programming FAQ Examples
The above nbserver.c sample code and more socket stuff.
thttpd - tiny/turbo/throttling HTTP server
Nifty little single-threaded, non-fork()'ing, select() based Web server.
BOA
Another single-threaded, select() based Web server.
代码下载:
下载文件 (已下载 350 次)THE WORLD OF SELECT()
So just why am I so hyped on select()?
One traditional way to write network servers is to have the main server block on accept(), waiting for a connection. Once a connection comes in, the server fork()s, the child process handles the connection and the main server is able to service new incoming requests.
With select(), instead of having a process for each request, there is usually only one process that "multi-plexes" all requests, servicing each request as much as it can.
So one main advantage of using select() is that your server will only require a single process to handle all requests. Thus, your server will not need shared memory or synchronization primitives for different 'tasks' to communicate.
One major disadvantage of using select(), is that your server cannot act like there's only one client, like with a fork()'ing solution. For example, with a fork()'ing solution, after the server fork()s, the child process works with the client as if there was only one client in the universe -- the child does not have to worry about new incoming connections or the existence of other sockets. With select(), the programming isn't as transparent.
Okay, so how do you use select()?
select() works by blocking until something happens on a file descriptor (aka a socket). What's 'something'? Data coming in or being able to write to a file descriptor -- you tell select() what you want to be woken up by. How do you tell it? You fill up a fd_set structure with some macros.
Most select()-based servers look pretty much the same:
引用
Fill up a fd_set structure with the file descriptors you want to know when data comes in on.
Fill up a fd_set structure with the file descriptors you want to know when you can write on.
Call select() and block until something happens.
Once select() returns, check to see if any of your file descriptors was the reason you woke up. If so, 'service' that file descriptor in whatever particular way your server needs to (i.e. read in a request for a Web page).
Repeat this process forever.
Fill up a fd_set structure with the file descriptors you want to know when you can write on.
Call select() and block until something happens.
Once select() returns, check to see if any of your file descriptors was the reason you woke up. If so, 'service' that file descriptor in whatever particular way your server needs to (i.e. read in a request for a Web page).
Repeat this process forever.
Quit with the pseudo-code, show me some real code!
Okay, let's take a look at a sample server included with Vic Metcalfe's Socket Programming FAQ (my comments are in red):
Okay, so maybe that wasn't the best example...
Got some suggests? Corrections? Please let me know.
In the mean time, here's some references to other sources of information about select():
Socket FAQ Question about select()
Straight from the excellent socket FAQ.
Unix Programming FAQ Question about select()
Straight from the other excellent FAQ.
Unix Socket Programming FAQ Examples
The above nbserver.c sample code and more socket stuff.
thttpd - tiny/turbo/throttling HTTP server
Nifty little single-threaded, non-fork()'ing, select() based Web server.
BOA
Another single-threaded, select() based Web server.
winsock for game[好文一篇,不敢独享]
unix/linux select faq


2008/01/26
02:41
5067

1


