Какой процесс слушает сокет?

← →
BreakPoint © (2009-08-03 16:12) [0]

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

← →
Сергей М. © (2009-08-03 17:06) [1]

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

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

← →
BreakPoint © (2009-08-03 17:28) [2]

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

← →
Сергей М. © (2009-08-04 10:35) [3]

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

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

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

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

см. AllocateAndGetTcp/UdpExTableFromStack

← →
BreakPoint © (2009-08-04 11:33) [4]

> см. 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... - что это как не выдергивание всей таблицы?

← →
Сергей М. © (2009-08-04 12:40) [5]

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

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

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

← →
BreakPoint © (2009-08-04 13:17) [6]

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

← →
Сергей М. © (2009-08-04 13:35) [7]

> о сырых

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

← →
BreakPoint © (2009-08-04 13:50) [8]

да

← →
Сергей М. © (2009-08-04 14:02) [9]

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

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

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

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

← →
BreakPoint © (2009-08-04 14:57) [10]

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

← →
Сергей М. © (2009-08-04 15:19) [11]

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

Ни по какому.

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

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

← →
Rouse_ © (2009-08-04 15:27) [12]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какой процесс слушает сокет? Найти похожие ветки