1. I wrote the tcp client which forks 100 times.
Each subprocess holds on pause(...) waiting for signal.
Afer receiving SIGHUP it continues and
a) connects to the server
b) sends 10 bytes
c) receives data form sockets
d) closes the sock

2. On the other side (another host) I wrote the server which does the following:
a) prepares listening socket
b) calls epoll_create(...) and epoll_ctl(...,EPOLL_CTL_ADD, listening_sock,...)
c) starts the infinite loop where the rest of tcp connetion(s) is done using epoll_wait(....)

The whole server code is similar to the sample from http://zhoulifa.bokee.com/6081520.html with translation from: http://translate.google.com/translat...m/6081520.html

The problem is that at the client host I can see a lot of sockets with 'SYN_SENT' status
but on the server side after fast receving (and servicing) about 40 requests the server "sometimes" handles the next one(s).
"Sometimes" means 2-3 requests per seconds.

If I decrease the number of forked clients to 10 averything is ok.
I'm am stuck now. I don't know where to look the reason...

It's really probable a better idea to "accept()" your connections one at a time, in a single thread.

Once the connection is established, *then* you can fork off a separate process or spawn a separate thread.

Handling multiple connections in parallel is OK. Trying to parallelize the "accept()" itself probably isn't.

IMHO .. PSM

PS:
Double-check the "backlog" parameter in your server's "listen()". But I doubt "backlog" is either the problem, or changing it the solution:
PS:
This is off-topic, but my sincere condolences to you, and all your fellow Poles for the tragedy that happened this weekend.

I've made some checks using different techniques:
a) server with preforked processes
b) server with select
c) server with epoll_wait.

For the first time both server and client(s) were working on the same host on 127.0.0.1.
I've measured the execution time of the request-answer for each client and.
The most important for me was the maxtime - the execution time of the slowestly handled request.

The results are below.
1. the best results were with epoll_wait
2. all processes finished with resonable max time and looked like the epoll_wait worked as expected (no "hanging" client's SYN_SENT existed)

Next I transferred the server program to another host and ... the problems appeared.

Same was with server based on preforked processes. (Thread techniques was not tested by me but I believe it shows the same problems).

So, in my opinion the problem is somewhere else rather than in the program concept.

The backlog value used in listen is 2000 and the /proc/sys/net/core/somaxconn is 10000.

Now I am testing 1000-times-forked client and the problem still exists.

Any other suggestions?