Potrzebuję pomocy w zrozumieniu tego, co na pewno jest podstawową koncepcją w systemie Linux: limit otwartych plików. W szczególności jestem zdezorientowany, dlaczego otwarte gniazda mogą liczyć się do całkowitej liczby „otwartych plików” w systemie.
Czy ktoś może wyjaśnić, dlaczego? Rozumiem, że prawdopodobnie chodzi o całą zasadę „wszystko jest plikiem” w Linuksie, ale wszelkie dodatkowe szczegóły byłyby mile widziane.
Odpowiedzi:
Limit „otwartych plików” nie dotyczy tak naprawdę tylko plików. Jest to ograniczenie liczby uchwytów jądra, których pojedynczy proces może użyć jednocześnie. Historycznie jedyną rzeczą, którą programy zwykle otwierały wiele plików były pliki, więc stało się to znane jako ograniczenie liczby otwartych plików. Istnieje ograniczenie, które pomaga zapobiegać powiedzeniu procesów, otwieraniu dużej liczby plików i przypadkowemu zapomnieniu ich zamknięcia, co ostatecznie spowoduje problemy ogólnosystemowe.
Połączenie przez gniazdo jest również uchwytem jądra. Zatem te same ograniczenia obowiązują z tych samych powodów - proces może otwierać połączenia sieciowe i zapomnieć o ich zamknięciu.
Jak zauważono w komentarzach, uchwyty jądra są tradycyjnie nazywane deskryptorami plików w systemach uniksopodobnych.
read/ write, który jest sercem tego, co oznacza bycie plikiem.
shutdown(2)na nich syscall, ale nie na plikach i nie możesz czytać z gniazda za pomocą cat- to jest powód netcat, dla którego stworzono. Powiedziałbym, że (na szczęście) gniazda w jądrach uniksowych zachowują się jak pliki pod względem I / O, ale podobieństwo się kończy. (Szczerze mówiąc, chciałbym również usłyszeć od kogoś z doświadczeniem w Planie 9, ponieważ słyszałem, że ujednolicono te rzeczy dalej niż tradycyjne jednorożce).
Powodem dlaczego deskryptory plików użycie TCP / IP Sockets jest to, że gdy interfejs gniazd został po raz pierwszy zaprojektowany i wdrożony ( w BSD Unix, w 1983 roku ), jego projektanci uważali, że połączenie sieciowe było analogiczne do pliku - można read, writei closezarówno i pasowałoby to do uniksowego pomysłu „wszystko jest plikiem”.
Inne implementacje stosu sieciowego TCP / IP niekoniecznie integrują się z podsystemem wejścia / wyjścia systemu operacyjnego, na przykład MacTCP . Ale ponieważ interfejs gniazd BSD był tak popularny, nawet te inne implementacje zdecydowały się na replikację interfejsu API gniazda z jego funkcjami podobnymi do Uniksa, więc otrzymałeś „deskryptory plików”, używane tylko do komunikacji TCP / IP, w systemach, które inaczej nie miały mieć deskryptory plików.
Inną częścią twojego pytania jest to, dlaczego istnieje limit? Jest tak, ponieważ najszybszym sposobem zaimplementowania tabeli wyszukiwania deskryptorów plików jest użycie tablicy. Historycznie limit był mocno zakodowany w jądrze.
Oto kod w wersji Unix 7 (1979) z zakodowanym limitem 20 deskryptorów plików na proces:
struct file *u_ofile[NOFILE]#define NOFILE 20Dla porównania Linux dynamicznie przydziela miejsce dla tabeli deskryptorów plików procesu. Domyślny limit bezwzględny to 8192, ale możesz ustawić to na co tylko chcesz. Mój system wyświetla listę 191072 w/proc/sys/fs/file-max .
alloc_fdtable()struct fdtable#define NR_FILE 8192Pomimo, że nie ma już absolutnego limitu w Linuksie, nie chcemy jednak pozwolić programom zwariować, więc administrator (lub pakiet dystrybucyjny) ogólnie określa limity zasobów. Spójrz /etc/security/limits.conflub biegnij ulimit -n.
Pliki to nie tylko pliki na dysku lub w pamięci; są to strumienie danych, z których są to tylko dwa przykłady.
Zdalne punkty końcowe to trzeci przykład i możesz wchodzić w interakcje z tymi, które używają gniazd.