Les connexions max du socket d'écoute sont atteintes rapidement, tout en augmentant la limite.

Question

J'ai une simple prise d'écoute, qui arrête d'accepter le socket, en retenant EN_FILE après seulement les connexions . J'ai essayé d'utiliser sysctl de la manière suivante:

$ sysctl kern.maxfiles 
kern.maxfiles: 12288 
$ sysctl kern.maxfilesperproc 
kern.maxfilesperproc: 10240 
$ sudo sysctl -w kern.maxfiles=1048600 
kern.maxfiles: 12288 -> 1048600 
$ sudo sysctl -w kern.maxfilesperproc=1048576 
kern.maxfilesperproc: 10240 -> 1048576 
$ ulimit -S -n 
256 
$ ulimit -S -n 1048576 
$ ulimit -S -n 
1048576 

Mais cela ne semble pas résoudre le problème, un redémarrage est nécessaire spécifiquement sur OSX? J'ai besoin pour un test singulier, donc je ne prévoyais pas le rendre permanent dans /etc/sysctl.conf

création Socket:

#if os(Linux) 
      fileDescriptor = Glibc.socket(AF_INET, Int32(SOCK_STREAM.rawValue), 0) 
     #else 
      fileDescriptor = Darwin.socket(AF_INET, SOCK_STREAM, 0) 
     #endif 

Et la partie accepter:

let result = withUnsafePointer(to: &address) { 
      $0.withMemoryRebound(to: sockaddr.self, capacity: 1) { sockAddress in 
       // Do nothing 
       bind(fileDescriptor, sockAddress, UInt32(MemoryLayout<sockaddr_in>.size)) 
      } 
     } 

'

let clientFD = accept(fileDescriptor, nil, nil) 
     if(clientFD == EMFILE || clientFD == ENFILE) { 
      print("[\(type(of: self))] WARNING: Maximum number of open connections has been reached") 
      close(clientFD) 
      return nil 
     } 

Remarques

libtls (LibreSSL 2.5.5) est utilisé après accept().

EN_FILE est la valeur retournée, où je pense personnellement EM_FILE

Answer 1

Vous comparez le descripteur de fichier accepté contre les codes d'erreur. Cela n'a pas de sens. Étant donné que les descripteurs de fichiers et les codes d'erreur sont généralement de petits entiers, bien sûr, vous obtiendrez une «correspondance» par la suite.

Vous souhaitez comparer clientFD à -1, puis vérifier errno par rapport à EMFILE ou ENFILE.