То есть не всё гладко?)))


Странно, может ntohs(cd->id) виновато?

Не понимаю, что было виной, но сначала он не хотел работать с константой, определенной как unsigned short const REQ_REQUEST = 0x0200; пытался определить ее по-другому - та ошибка пропала, но желаемого результата я не получил. Не уверен что ntohs(cd->id) виновато, потому что в операторе if оно отрабатывает. Да, не все гладко. При долгосрочном тесте почему-то программа виснет. Сейчас проверяю.

вот то, что у меня получилось: 


Это сообщение отредактировал(а) feodorv - 30.12.2012, 12:30

Так в том-то и дело, что не должен закрываться сокет после каждого url. Соединение действует постоянно.



Судя по всему, программа виснет, когда циска закрывает соединение (по каким причинам - тоже выяснить бы нужно, возможно, прочла из сокета некорректный ответ).
В этом случае recv возвращает 0. Проверки на этот случай в программе нет, а она нужна:




Кроме того, в случае возврата циске положительного решения подпрограмма process_socket явным образом не возвращает никакого значения (а, следовательно, возвращает случайный мусор, хотя обязана вернуть 1 или 0):



И довольно странный подход к указателю cd. Почему (*cd).id, а не cd->id?

Добавлено через 3 минуты и 54 секунды
Соответственно



Это сообщение отредактировал(а) feodorv - 27.11.2012, 12:08

Изменил то, на что вы указали - работает, спасибо! За 16 часов не вылетела ни разу, постоянно обрабатывает запросы. Подскажите еще, с помощью чего лучше реализовать регулярные выражения на С, чтобы разобрать url и сравнить с файлом, содержащим маски запрещенных ресурсов, и еще, есть ли смысл какие-то функции перенести на 64-битную ось. Я например не нашел 64 битного аналого функции recv, зато есть 64 битная функция open, что в данном случае будет лучше?

Очень хорошо!


А его и нету))) Если Вы задумались над 64-битной версией, то работа с сетью останется прежней, но в Вашем коде прежде всего нужно обратить внимание на структуру cisdata и pragma pack. Вообще структура этой структуры мне не нравится, ужасное выравнивание, в 64-битном окружении стоит переписать работу с ней.


Ну, для этого вопроса лучше всего открыть новую тему  

Это сообщение отредактировал(а) feodorv - 29.11.2012, 03:36

Еще маленький вопрос, все конечно работает, но сегодня заметил - не поступало запросов в течении часа - и программа не захотела закрывать сокет, весь час ждала запросов на этом сокете. Может как-то реализовать выход по таймауту? Я сегодня буду пытаться прикрутить многозадачность, а в таком случае это будет лишь бесконечное множество процессов))

вот так примерно пока у меня в голове многозадачность выглядит, пока правда не проверял, сегодня займусь.

И? Дальше-то работала?

Это нормальное поведение сервера. Не вижу причин для закрытия сокета. Зачем? 



Где-то так, только 

это самоубийство)))

Не нужен waitpid: Программирование сокетов в Linux  

Дальше работала, но у меня может быть до 1000, а может и больше, одновременных подключений, получается каждое подключение будет висеть незакрытым, рано или поздно закончатся файловые дескрипторы в системе. 

Честно говоря, моё терпение начинает подходить к концу))))



Почему Вы зависли на идее, что для каждого запроса нужно открывать новый сокет? Если так действовать, то, да, рано или поздно закончатся файловые дескрипторы. Посмотрите как следует код, в каких случаях происходит переоткрытие сокета, в каких случаях используется (многократно) уже созданный и уже присоединённый сокет nsd.

Извиняюсь, не понял Вас изначально до конца) А тогда если делать fork, то как я понимаю, процессы будут распараллеливаться, там тоже будет все нормально? Я как понял, по идее, в дочерней копии процесса происходит обработка, и если обработка завершена, процесс закроется, и управление вернется родительскому процессу, так?

Будет))) Только не нужно делать так:

Родительский процесс должен работать вне зависимости от дочернего