0 .with regards to you
1 .Thank you for reading letter
2 .a Server call sleep(20) after listern(fd,5) . When the Server is in asleep,a Client connect() to it successful and send a lot of appointed data .
3 .Why ? I think that the server is in sleep (beasue I call sleep()) , it donot block at accept() , how can client connect it successful ,

You can't do that.

Your accept() should be able to either block or not block at your control. If you turned on a non-blocking option on the socket, then yes your accept() call will return an error if there are no pending connections. If you then decide to sleep(), then any connections that arrive while your server is asleep will become become pending connections. After the sleep(), it could re-issue the accept() and establish a connection.

Turning on a non-blocking option and then polling from time to time is supposed to work. But I have never seen it done. I would not sleep for 300 seconds though. That is a very long time to keep a connection waiting for a connect.

But the usual method is to allow accept() to block and wait for a connection to occur.

If your accept() is not blocking then somehow you must have asked it not to. The usual way of doing this would be to have set O_NONBLOCK.

If your accept() call does not behave as I described, then it must be broken. But I find that hard to believe. Never blocking would be a very serious problem.

1 . with regards to Perderabo and thanks to everyone who read the post
2 . I do a experiment :
Server call socket() bind() listern() in sequence , and call sleep(30) behind listen and before I call accept() .When the Server is in sleep ,the Client connect() the sleeping Server sucessful and send a lot of appointed data to the sleeping Server ,and then block because the recvive buffer of Server has been full(the Server is asleep)
3 . I refer to <<Unix Network Programming >> volume 1 (author : W.Richard Stevens) later .
I found that accept() only "return the next completed connection from the front of the completed connection queue) .the listen() function do "......... , Data that arrives after the three-way handshake completes,but before the server call accept(),should be queued by the server TCP,up to the size of connected socket's receive buffer"
4 . Then I think that : IN SERVER side , after we call listen() ,the Server application register an appointed socket to the kernel ,then the kernel will monitor the appointed port number and wait for the Client to connect .
Then another question arise :
5 . How does the kernel monitor the appointed port when the Server application do other thing(ie. call sleep() after listen() or not occupy the processor at that point) and
6 . How doese the kernel to notify which process that the data came if many Server application let the kernel to monitory different port

2) That is interesting! I always thought that the kernel waited for the accept() to establish a connection. Just goes to show that I don't know everything.

5) The port has an open socket associated with it. And the kernel know which port goes to which socket. The TCP/IP code has the job of making the data available to the socket.

6) If the process is using O-NONBLOCK (or equivalent) as yours is, the kernel does nothing. The hope is that the process will eventually decide to issue the accept() or the read() or whatever. If the process has blocked waiting for for data on the socket, it will be "awoken" when data arrives. This will put it on the run queue. And when a cpu runs it, the system call will finally complete.