vsb>Можно ли быть уверенными, что сетевые драйверы в Windows гарантируют упорядоченность пакетов после того, как они их приняли, если в буфере место не кончилось?
Конечно же нет, драйверы в винде имеют асинхронную природу обработки запросов на прерывание — пришедший пакет генерирует IRP на обработку, первичный обработчик прерывания может вызваться на определенном процессоре, и пока он не завершится, другой пакет может интерраптнуть совсем другой процессор, и вот они будут примерно паралелльно исполняться, и каждый из них в какой то момент обычно инициирует DPC которая добавиться в очередь соответствующего процессора. DPC начнет исполнится в тот момент когда все остальные DPC стоящие в очереди завершаться. Далее вовсе не обязательно что эта DPC доделает все что надо и данные наконецто придут в юзермод. Она может породить APC а та например может вообще постучаться в юзермодный процесс файрволла чтобы тот сказал — нормуль ли пакет. И вот после всего этого та APC вызовет IoCompleteRequest завершив таким образом обработку IRP.
Тут уже как минимум 3 места где видны гонки между двумя последовательными пакетами:
1) Процессоры могут исполнять обработчики прерывания не одинаково быстро — кеши то у них свои, так что все задержки обращения к памяти могут отработать по разному. Кроме того нынче пришла мода на несиметтричным мультипроцессинг, когда соседние процессоры вообще на разных частотах работают.
2) Очерелдь DPC у каждого из процессоров на момент помещения в нее DPC на обработку пакета может иметь различное количество других запросов от других драйверов которые еще и сами по себе могут исполняться очент различное время.
3) Если в дело примется файрволл то он может вообще жевать каждый конкретный IRP сколько ему угодно времени. Может ему в каком нить пакете первые два байта затриггерят какую нить усиленную проверку сигнатур и он будет полсекунды ковыряться в своей базе...

vsb>Можно ли быть уверенными, что сетевые драйверы в Windows гарантируют упорядоченность пакетов после того, как они их приняли, если в буфере место не кончилось?
Конечно же нет, драйверы в винде имеют асинхронную природу обработки запросов на прерывание — пришедший пакет генерирует IRP на обработку, первичный обработчик прерывания может вызваться на определенном процессоре, и пока он не завершится, другой пакет может интерраптнуть совсем другой процессор, и вот они будут примерно паралелльно исполняться, и каждый из них в какой то момент обычно инициирует DPC которая добавиться в очередь соответствующего процессора. DPC начнет исполнятся в тот момент когда все остальные DPC стоявшие в этой очереди завершатся. Далее вовсе не обязательно что эта DPC доделает все что надо и данные наконецто придут в юзермод. Она может породить APC а та например может вообще постучаться в юзермодный процесс файрволла чтобы тот сказал — нормуль ли пакет. И вот после всего этого та APC вызовет IoCompleteRequest, завершив таким образом обработку IRP.
Тут уже как минимум 3 места где видны гонки между двумя последовательными пакетами:
1) Процессоры могут исполнять обработчики прерывания не одинаково быстро — кеши то у них свои, так что все задержки обращения к памяти могут отработать по разному. Кроме того нынче пришла мода на несимметричный мультипроцессинг, когда соседние процессоры вообще на разных частотах работают.
2) Очерелдь DPC у каждого из процессоров на момент помещения в нее DPC на обработку пакета может иметь различное количество других запросов от других драйверов которые еще и сами по себе могут исполняться очент различное время.
3) Если в дело примется файрволл то он может вообще жевать каждый конкретный IRP сколько ему угодно времени. Может ему в каком нить пакете первые два байта затриггерят какую нить усиленную проверку сигнатур и он будет полсекунды ковыряться в своей базе...

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