Есть IP адресс и порт. Надо определить какой процесс слушает этот порт. Фактически это надо для мониторинга трафика, надо узнать какой пакет идет к какому приложению (как в  HttpAnalyzer). Есть идея через GetExtendedTcpTable, но это както некрасиво, может в АПИ есть функции которые позволяют эту задачу напрямую решить?

> в АПИ есть функции которые позволяют эту задачу напрямую
> решить?


GetExtendedTcpTable - это тоже API-функция.
Какую еще "прямую" функцию ты хотел увидеть ? Чем эта крива и некрасива ?

Тем, что для каждого пакета выдергивать всю таблицу искать в ней IP не есть рационально.

> для каждого пакета


Про какие пекты идет речь ?


> выдергивать всю таблицу


Не надо ничего "выдергивать"

см. AllocateAndGetTcp/UdpExTableFromStack

> см. AllocateAndGetTcp/UdpExTableFromStack

Курим МСДН:
The GetTcpTable or GetExtendedTcpTable functions should be used to retrieve the TCP connection table instead of using the AllocateAndGetTcpExTableFromStack function.

> Не надо ничего "выдергивать"

The AllocateAndGetTcpExTableFromStack function retrieves the TCP connection table... - что это как не выдергивание всей таблицы?

> BreakPoint ©   (04.08.09 11:33) [4]

http://www.xakep.ru/magazine/xa/098/122/1.asp

А ты о каких пакетах ведешь речь ?

о сырых
статейка устарела, курите МСДН

> о сырых


Т.е. ты нюхаешь сет.интерфейсы на предмет прохождения через них IP-дейтаграмм, относящихся к TCP/UDP-сервисам, и для каждой из них желаешь получать инф-цию о локальном процессе, пославшем/принявшем эту дейтаграмму, при этом не желая всякий раз запрашивать снапшоты TCP/UDP-таблиц, так ? Я правильно понял ?

да

Ну и зачем при этом всякий раз запрашивать снапшот ?

Любой приличное ПО, реализующее подобную функциональность, как правило включает в себя т.е. connection tracking.

Суть этого механизма, касаемая твоей задачи, такова: запрос снапшота требуется лишь для пакетов со статусом соединения new, related и invalid, для пакетов же со статусом соединения established информация о процессе уже доступна, поскольку ранее этот процесс передавал или принимал пакет со статусом соединения new, т.е. ты уже запрашивал ранее снапшот и ничего нового ты в очередном снапшоте не увидишь вполоть до завершения соединения.

Кури коннекшн-трекинг технологию)

Буду весьма признателен, если вы укажете по какому смещению в сыром пакете находится указанная вами информация. С особым нетерпением жду информации об UDP ))

> по какому смещению


Ни по какому.

В традиционных CTS принято считать, что UDP-соединение установлено (т.е. ему присваивается статус established) если обнаружена пара следующих друг за другом пакетов :

SRC                    DST
адрес1:порт1 -> адрес2:порт2
адрес2:порт2 -> адрес1:порт1

Вот тут я года три назад чего-то ваял, можешь посмотреть принцип: http://rouse.front.ru/trafficinspector.zip

> Rouse_ ©   (04.08.09 15:27) [12]


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

Ну тут принцип сам, код сам видишь не причесанный ни разу, собран из нескольких разных демок буквально на коленке :)

> Ни по какому.

)) Это и так ясно.

> если обнаружена пара следующих друг за другом пакетов :

а кто гарантирует, что эти пакеты придут друг за другом? следовательно нужны дополнительные правила, в итоге этих правил окажется столько, что GetExtendedTcpTable медом покажется.

> Ну тут принцип сам


Да принцип-то этот и автору понятен)
Он ДРГОЕ хочет: не лазить всякий раз за снапшотом, но при этом иметь оперативную инф-цию о локальном процессе-владельце порта, фигурирующего в качве источника или приемника в IP-дейтаграмме, которую он унюхал ро-сокетом)

> кто гарантирует, что эти пакеты придут друг за другом?


А где это видано, чтобы в каком-либо диалоге ответ следовал раньше вопроса ?)


> нужны дополнительные правила, в итоге этих правил окажется
> столько, что GetExtendedTcpTable медом покажется


Приличные файрволы с CTS-функциональностью их как раз и реализуют) .. И ничего - работают и каши не просят)