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

Большинство серверных фреймворков/примеров, использующих сокеты и порты завершения ввода-вывода, делают уведомления таким образом, что я не мог полностью понять цель.

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

Проблема заключается в том, что сокет закрывается изящно или по ошибке. Я видел в обеих ситуациях, и снова о.с. планировщик потоков, уведомление о закрытии может быть отправлено приложению (т. е. http-серверу, использующему фреймворк) «до» уведомления о ранее прочитанных данных.

Я думаю, что уведомление о закрытии должно быть поставлено в очередь таким образом, чтобы приложение получало его после предыдущего чтения.

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


iocp
person Mauro H. Leggieri    schedule 23.01.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

То, что вы предлагаете, имеет смысл, и я полагаю, что любой код, который обрабатывает изящное закрытие (чтение, возвращающее 0 байтов), будет делать это, обрабатывая его после любого успешного чтения. Ошибки, возникающие из GetQueuedCompletionStatus(), такие как ошибки сброса соединения и т. д., труднее интегрировать в поток приема, поскольку они возникают вне диапазона в отношении принимаемых данных. Ваш вопрос немного расплывчатый и во многом зависит от кода, который вы используете, и от того, как вы (или люди, которые написали этот код) хотите обрабатывать эти вещи. Нет единственно правильного способа, ИМХО.

person Len Holgate    schedule 23.01.2015
comment
На самом деле я делаю базовый движок для использования во встроенном http-сервере, но тот же базовый код будет использоваться для HTTP-запросов клиента. Но в прошлом у меня возникали проблемы с HTTP-запросами клиента, хотя я получал полное тело, в большинстве случаев соединение не закрывалось сервером корректно. В таких случаях я реализовал обходной путь, поэтому, если уведомление об ошибке возникает в середине прочитанных пакетов, но в конце тело завершено, я игнорирую ошибку. - person Mauro H. Leggieri; 24.01.2015
comment
Спасибо @Лен. У меня появились новые идеи для реализации - person Mauro H. Leggieri; 26.01.2015