Почему сокеты TCP/IP считают “открытыми файлами”?
Я заметил при попытке запустить Linux от карты флэш-памяти с интерфейсом USB, что на некотором ПК (кажется, главным образом более старый Dell), что через некоторое время что-то происходит, где система думает, что диск разъединяется, даже при том, что это физически не разъединяется.
У меня есть старый ноутбук Inspiron, например, где, приблизительно после дня или таким образом работая от карты с интерфейсом USB, это происходит, и все отказывает, потому что внезапно Linux не может найти свой корневой объем.
Я не сделал достаточного поиска и устранения неисправностей, чтобы определить, был ли это флеш-накопитель (Kingston на 4 ГБ), то, что это - флеш-накопитель и не включенный в USB жесткий диск, и т.д. но видело это на других Dell PC. Я не знаю, является ли это тонкая проблема в чипсете, драйверы Linux не составляют, некоторое возможное взаимодействие с ACPI, или что.
Несколько лет назад то, когда я использовал старый HP Pavillion в качестве сервера, у меня будут проблемы, где USB присоединил диски, прекратит распознаваться, как соединено. Только физически разъединение и повторное подключение их заставили бы их быть распознанными Linux снова. Я использовал плату PCI Belkin USB 2.0 в то время. Я поместил ту же карту в Dell PowerEdge 2500 и выполнял диски в течение многих месяцев прочь ее без проблем.
Можно попытаться делить жесткий диск, или установить второй жесткий диск в системе и запустить Linux от этого.
Ограничение на «открытые файлы» на самом деле касается не только файлов. Это ограничение на количество дескрипторов ядра , которые один процесс может использовать одновременно. Исторически сложилось так, что единственное, что программы обычно открывали много, были файлы, поэтому это стало известно как ограничение на количество открытых файлов. Существует предел, который помогает предотвратить открытие большого количества файлов и случайное забывание их закрытия процессами, что в конечном итоге вызовет общесистемные проблемы.
Соединение сокета также является дескриптором ядра. Таким образом, одни и те же ограничения применяются по тем же причинам - процесс может открыть сетевые соединения и забыть их закрыть.
Как отмечено в комментариях, дескрипторы ядра традиционно называются файловыми дескрипторами в Unix-подобных системах.
Файлы - это не просто файлы на диске или в памяти; это потоки данных, которые являются лишь двумя примерами.
Удаленные конечные точки - третий пример, и вы взаимодействуете с теми, кто использует сокеты.
Причина того, что сокеты TCP / IP используют файловые дескрипторы , заключается в том, что, когда интерфейс сокетов был впервые разработан и реализован ( в BSD Unix в 1983 году ), его разработчики считали, что сетевое соединение было аналогично файлу - вы можете прочитать , записать и закрыть оба, и что это хорошо согласуется с идеей Unix "все это файл ".
Другие реализации сетевого стека TCP / IP не обязательно интегрировались с подсистемой файлового ввода-вывода их ОС, например MacTCP . Но поскольку интерфейс сокетов BSD был настолько популярен, даже эти другие реализации решили реплицировать API сокетов с его Unix-подобными функциями, так что вы получили «файловые дескрипторы», используемые только для связи TCP / IP, в системах, которые иначе не работали. имеют файловые дескрипторы.
Другая часть вашего вопроса: Почему существует ограничение? Это потому, что самый быстрый способ реализовать таблицу поиска файловых дескрипторов - использовать массив. Исторически ограничение было жестко запрограммировано в ядре.
Вот код в Unix версии 7 (1979) с жестко заданным ограничением в 20 файловых дескрипторов на процесс:
Для сравнения, Linux динамически выделяет пространство для таблицы файловых дескрипторов процесса. Абсолютный предел по умолчанию равен 8192, но вы можете установить его как угодно. Моя система перечисляет 191072 в / proc / sys / fs / file-max .
- fs / file.c :
alloc_fdtable () - fdtable.h :
struct fdtable - fs.h :
#define NR_FILE 8192
Несмотря на то, что в Linux больше нет абсолютных ограничений, мы, тем не менее, не хотим позволять программам сходить с ума, поэтому администратор (или упаковщик дистрибутива) обычно устанавливает ограничения ресурсов. Взгляните на /etc/security/limits.conf или запустите ulimit -n .