Является ли сервер по существу фоновым процессом, выполняющим бесконечный цикл, прослушивающий порт? Например:
while(1){
command = read(127.0.0.1:xxxx);
if(command){
execute(command);
}
}
Когда я говорю сервер, я, очевидно, не имею в виду физический сервер (компьютер). Я имею в виду сервер MySQL, или Apache и т.д.
Полное раскрытие информации - у меня не было времени пробивать какой-либо исходный код. Фактические примеры кода были бы замечательными!
Это более или менее то, что обычно делает серверное программное обеспечение.
Обычно это становится более сложным, потому что бесконечный цикл "только" принимает соединение, и каждое соединение часто может обрабатывать несколько "команд" (или то, что они вызывают в используемом протоколе), но основная идея примерно такая.
Существует три вида "серверов" - разветвление, потоки и однопоточные (неблокирующие). Все они, как правило, работают так, как вы показываете, разница в том, что происходит, когда есть что-то, что нужно обслуживать.
Служба разветвления - это просто. Для каждого запроса вызывается fork(), создавая новый дочерний процесс, который обрабатывает запрос, а затем выходит (или остается живым для обработки последующих запросов, в зависимости от дизайна).
Служба потоковой передачи похожа на службу forking, но вместо целого нового процесса создается новый поток для обслуживания запроса. Как вилки, иногда потоки остаются вокруг, чтобы обрабатывать последующие запросы. Разница в производительности и занимаемой площади - это просто разница между витками и вилками. В зависимости от использования памяти, которая не обслуживает клиента (и подвержена изменениям), обычно лучше не клонировать все адресное пространство. Единственная дополнительная сложность здесь - синхронизация.
Один процесс (один-на-один) сервер будет вилка только один раз для daemonize. Он не будет порождать новые потоки, он не будет порождать дочерние процессы. Он будет продолжать опрос() сокета, чтобы узнать, когда файловый дескриптор готов к приему данных или данные доступны для обработки. Данные для каждого соединения хранятся в своей структуре, идентифицируются различными состояниями (запись, ожидание ACK, чтение, закрытие и т.д.). Это может быть чрезвычайно эффективный дизайн, если все сделано правильно. Вместо того, чтобы блокировать несколько дочерних элементов или потоков, ожидая выполнения работы, у вас есть один запрос на обработку процесса и событий, когда они готовы.
Существуют случаи, когда однопоточные службы порождают несколько потоков, однако дополнительные потоки не работают при обслуживании входящих запросов, можно было бы (например) настроить локальный сокет в потоке, который позволяет администратору получить статус все соединения.
Небольшой поисковый запрос для не блокирующего HTTP-сервера даст некоторые интересные ручные веб-серверы, написанные как проблемы с кодом для гольфа.
Короче говоря, разница заключается в том, что происходит, когда вводится бесконечный цикл, а не только бесконечный цикл:)
В разговоре, да. Сервер - это просто то, что "пеет навсегда" и служит. Однако, как правило, вы обнаружите, что "демоны" делают такие вещи, как открытые STDOUT и STDERR для файлов или /dev/null вместе с двойными вилками, среди прочего. В некотором смысле ваш код является очень упрощенным "сервером".