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. – Eugen Rieck Jan 27 '18 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 – joseph M'Bimbi-Bene Jan 27 '18 at 11:48
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.