Início / unix / Perguntas / 420001
Accepted
joseph M'Bimbi-Bene
Asked: 2018-01-28 00:47:39 +0800 CST

sudo netstat -antp não mostrando PID

  • 772

estou testando coisas com soquetes e encontrei esse caso estranho:

Eu codifiquei um servidor tcp muito simples em c, bloqueei depois de aceitar (), apenas para ver o que acontece ao aceitar várias tentativas de conexão ao mesmo tempo:

Aqui está um trecho do código do servidor:

//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);

quando o servidor pede ao usuário para inserir um número inteiro, tento conectar vários clientes com telnet.

Para o primeiro, está tudo 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

mas depois do primeiro, mesmo sendo root, existem algumas conexões que não consigo ver o processo que o possui e seu 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

um terceiro:

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

Tentei novamente alguns dias depois com netstat -antpe como root e aqui está o que consegui:

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

como é que um processo ou uma conexão pode ter um inode de 0? Alguém pode me explicar o que está acontecendo?

socket netstat

1 respostas

  1. Best Answer

    O código do servidor chama accept()apenas uma vez. Assim, apenas a primeira tentativa de conexão é efetivamente aceita e as demais conexões do cliente são mantidas em uma fila de solicitações de conexão que reside no espaço do kernel. A próxima conexão do cliente será recuperada da fila quando accept()for chamada novamente.

    Nenhum processo possui conexões de cliente enquanto permanecem no espaço do kernel, porque vários processos ou threads podem aceitar legalmente conexões de um par exclusivo de endereço e porta se habilitarem SO_REUSEPORTa opção em todos os descritores de soquete participantes.

    Você mesmo pode testar a SO_REUSEPORTopção adicionando o seguinte trecho de código antes da bind()chamada e executando mais de um servidor. Você descobrirá que o kernel distribuirá as solicitações entre eles.

    {
    int enabled = -1;
    if (setsockopt (sockd, SOL_SOCKET, SO_REUSEPORT,
        (void*) &enabled, sizeof (enabled)) < 0) {
        perror ("setsockopt");
    }
}

    Referência de man 2 accept:

    A chamada de sistema accept(sockfd) é usada com tipos de soquete baseados em conexão (SOCK_STREAM, SOCK_SEQPACKET). Ele extrai a primeira requisição de conexão na fila de conexões pendentes para o soquete de escuta, sockfd , cria um novo soquete conectado e retorna um novo descritor de arquivo referente a esse soquete. O soquete recém-criado não está no estado de escuta. O socket original sockfd não é afetado por esta chamada.

    Referência de man 7 socket:

    SO_REUSEPORT (desde Linux 3.9)

    Permite que vários soquetes AF_INET ou AF_INET6 sejam vinculados a um endereço de soquete idêntico. Esta opção deve ser definida em cada soquete (incluindo o primeiro soquete) antes de chamar bind(2) no soquete. Para evitar o sequestro de porta, todos os processos vinculados ao mesmo endereço devem ter o mesmo UID efetivo. Esta opção pode ser empregada com soquetes TCP e UDP.

    Para soquetes TCP, esta opção permite que a distribuição de carga accept(2) em um servidor multiencadeado seja aprimorada usando um soquete de escuta distinto para cada encadeamento. Isso fornece distribuição de carga aprimorada em comparação com as técnicas tradicionais, como usar um único thread de aceitação(2) que distribui conexões ou ter vários threads que competem para aceitar(2) do mesmo soquete.

    Para soquetes UDP, o uso dessa opção pode fornecer melhor distribuição de datagramas de entrada para vários processos (ou threads) em comparação com a técnica tradicional de ter vários processos competindo para receber datagramas no mesmo soquete.

    • 0

relate perguntas