Вынужден снова поднять тему получения ProcessID для пакета, перехваченного при помощи “WinpkFilter SDK”, которая была затронута в обсуждении по теме “Need to know what application is associated with a packet”.
SerpentFly для решения задачи порекомендовал дополнительно использовать “LocalHost SDK”, которая в отличие от “WinpkFilter SDK” предоставляет ProcessID для пакета, но не умеет его “дропать” (блокировать). Т.е. предложил использовать их совместно, а именно сопоставлять пакеты по IP-адресам и портам, локальным и удаленным собранные на одном уровне с пакетами на том уровне, где их можно “дропать”.
Идея вроде ясна. Но, данное сопоставление оказывается ненадежным вовсе не из-за портов (типа, надо просто локальные сравнивать), а из-за того, что пакет от “LocalHost” приходит позже, чем пакет от “WinpkFilter”. Т.е. возможно заблокировать только последующие пакеты, с опозданием, упустив их некоторое количество. Вроде и ничего, но возможна путаница, когда неблокируемое приложение займет локальный порт сразу за тем, как там пыталось работать то приложение, пакеты которого должны дропаться.
Заказчик хочет знать, возможно ли на данных компонентах построить более надежное решение, нежели описанное выше, чтобы решить переходить с “Individual”-лицензии “WinpkFilter” на девелоперскую или нет.
Будьте так добры, помогите разобраться.
.
