1

i am testing stuff with sockets and i encountered that strange case :

i coded i very simple tcp server in c, i made it block after accept(), just to see what happen when accepting multiple connection attempts at the same time :

Here is an excerpt of code of the server :

//listen()
if( (listen(sock,5)) == -1) {
  perror("listen");
  exit(-1);
}

//accept()
if( (cli = accept(sock, (struct sockaddr *) &client, &len)) == 1 ){
  perror("accept");
  exit(-1);
}

printf("entrez un int : ");
scanf("%d",&toto);

when the server asks the user to enter an integer, i try to connect multiple clients with telnet.

Fort the first one, evrything is ok :

root@[...] :/home/[...]/workspace/sockets# netstat -antp | grep 10003
tcp        0      0 0.0.0.0:10003           0.0.0.0:*               LISTEN      25832/toto      
tcp        0      0 127.0.0.1:10003         127.0.0.1:51166         ESTABLISHED 25832/toto      
tcp        0      0 127.0.0.1:51166         127.0.0.1:10003         ESTABLISHED 25845/telnet

but then after the first one, even though i am root, there are some connections i can't see the process owning it and its pid :

root@[...] :/home/[...]/workspace/sockets# netstat -antp | grep 10003
tcp        0      0 0.0.0.0:10003           0.0.0.0:*               LISTEN      25832/toto      
tcp        0      0 127.0.0.1:10003         127.0.0.1:51166         ESTABLISHED 25832/toto      
tcp        0      0 127.0.0.1:51166         127.0.0.1:10003         ESTABLISHED 25845/telnet    
tcp        0      0 127.0.0.1:10003         127.0.0.1:51168         ESTABLISHED -               
tcp        0      0 127.0.0.1:51168         127.0.0.1:10003         ESTABLISHED 25852/telnet

a third one :

root@[...] :/home/[...]/workspace/sockets# netstat -antp | grep 10003
tcp        0      0 0.0.0.0:10003           0.0.0.0:*               LISTEN      25832/toto      
tcp        0      0 127.0.0.1:10003         127.0.0.1:51166         ESTABLISHED 25832/toto      
tcp        0      0 127.0.0.1:51166         127.0.0.1:10003         ESTABLISHED 25845/telnet    
tcp        0      0 127.0.0.1:10003         127.0.0.1:51172         ESTABLISHED -               
tcp        0      0 127.0.0.1:10003         127.0.0.1:51168         ESTABLISHED -               
tcp        0      0 127.0.0.1:51168         127.0.0.1:10003         ESTABLISHED 25852/telnet    
tcp        0      0 127.0.0.1:51172         127.0.0.1:10003         ESTABLISHED 25860/telnet

I tried again a few days later with netstat -antpe as root and here is what i got :

root@[...] :/home/[...]/workspace/sockets# netstat -antpe | grep 10003
tcp        0      0 0.0.0.0:10003           0.0.0.0:*               LISTEN      1000       327680      22399/toto      
tcp        0      0 127.0.0.1:33286         127.0.0.1:10003         ESTABLISHED 1000       417202      22884/telnet    
tcp        0      0 127.0.0.1:10003         127.0.0.1:33046         ESTABLISHED 0          0           -               
tcp        0      0 127.0.0.1:10003         127.0.0.1:33286         ESTABLISHED 0          0           -               
tcp        0      0 127.0.0.1:33044         127.0.0.1:10003         ESTABLISHED 1000       332810      22402/telnet    
tcp        0      0 127.0.0.1:33046         127.0.0.1:10003         ESTABLISHED 1000       331200      22410/telnet    
tcp        0      0 127.0.0.1:10003         127.0.0.1:33044         ESTABLISHED 1000       332801      22399/toto

how comes a process or a connection can have an inode of 0 ? Can someone explain me what is going on ?

2
  • What is the backlog for the accept? I suspect it is 2. Commented Jan 27, 2018 at 11:17
  • If i understand correctly and the backlog is the size of the queue of pending incomming connections, then as the code indicates, it is 5. By the way, i also realized that the server can establish a connection with 2 more clients than specified in the backlog, i will probably post another question relative to that Commented Jan 27, 2018 at 11:48

1 Answer 1

0

Linux uses a two-queue approach to the listen backlog. This means, that in addition to the complete connections (5 as in your code) there can be a queue of incomplete connestions, where the 3way handshake is not yet completed.

Connections in this state are not yet assigned to a process, so they belong to the kernel only resulting in a process ID of 0. This bit me on a Mono/.NET application, where I was searching for a bug in Mono, that was actually behaviour by design of the kernel.

See here for the two-queue approach details.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .