Perdonami se questo non è il miglior forum per questa domanda, ma sembra più rilevante per il kernel che per la programmazione stessa.
Sto scrivendo uno script che interroga il sistema per le porte aperte in modo da poter rappresentare graficamente e monitorare le statistiche. Per questo, sto usando il comando "ss" dal pacchetto iproute. Se esegui ss -s|grep estab riceverai un output simile a questo:
TCP: 296 (estab 6, closed 238, orphaned 0, synrecv 0, timewait 238/0), ports 0
La mia domanda ha a che fare con la variabile timewait, che mostra i socket calcolati nello stato TIME_WAIT. Quando ho cercato di capire quale numero fosse referenziato dopo la barra, è diventata un'avventura vorticosa di ricerca del codice sorgente che alla fine mi ha portato a trovare il seguente snippet:
printf("TCP: %d (estab %d, closed %d, orphaned %d, synrecv %d, timewait %d/%d), ports %d\n",
s.tcp_total + slabstat.tcp_syns + s.tcp_tws,
sn.tcp_estab,
s.tcp_total - (s.tcp4_hashed+s.tcp6_hashed-s.tcp_tws),
s.tcp_orphans,
slabstat.tcp_syns,
s.tcp_tws, slabstat.tcp_tws,
slabstat.tcp_ports
);
Devo ammettere che la mia ricerca di cosa avrebbe dovuto significare "slabstat" alla fine mi ha portato a conoscere le cache slab e la loro interfaccia di reporting su /proc/slabinfo.
La domanda:cosa ha a che fare lo slabtable con i calcoli del socket TIME_WAIT? Non riesco a capire perché questo numero viene segnalato, poiché ogni volta che ho eseguito il comando su tutti i server su cui l'ho provato, il numero è sempre stato zero.
Risposta accettata:
Sembra tcp_tw_buckets è ciò che viene infine sottoposto a polling, che è una struttura rimossa a partire da Linux 2.6.12
Quindi l'ultimo numero sarebbe probabilmente sempre 0 a meno che non sia su kernel di 7 anni.
Per quanto riguarda l'interrogazione di slab, per quanto ne so, è ridicolmente più veloce degli altri metodi disponibili.