Адрес собственного интерфейса (UDP)

если для получения используется recvfrom, инфу можно дернуть из struct sockaddr (предпоследний аргумент recvfrom)

Я от тоже так подумал :) в результате тестовая прога выдает следующее: 1)127.2.0.128.1.127.0.0.1.0.0.0.0.0.0.0.0 2)172.2.0.128.12.172.30.77.118.0.0.0.0.0.0.0.0

В первом случае я лез к серверу ч-з lo на том же хосте, а во второй раз с 172.30.77.118. Как видно из вывода, адрес клиента в sockaddr присутствует, а вот адрес интерфеса на который послан пакет - отсутствует ( этот адрес 172.30.77.106 ). Нету даже индекса интерфейса :(((

а что, так сложно по адресу клиента вычислить интерфейс?

как вариант, можно по отдельному потоку на каждый интерфейс посадить.

>а что, так сложно по адресу клиента вычислить интерфейс? Не всегда это можно определить однозначно. У меня, например, на хосте адреса 172.30.77.106, 172.30.77.107, 172.30.77.108, а клиент сидит на 172.30.77.118 и время от времени кидает пакеты на любой из интерфейсов сервера. Только не спрашивай зачем такой изврат! Это все для подержки legacy ситсетмы.

Вариант с потоками конечно работоспособен, но его я оставлю на тот случай, если других путей не будет. (Потоков у меня дохренища выйдет :(( ).

по идее, можно использовать raw сокеты и самому ip фрейм разбирать.

Тоже не годится. У меня snmp агент. Я пока ч-з net-snmp до sockaddr добрался, запарился! Сечас мне непонятно только назначение первых трех байт в sockaddr. Думаю , в них должна содержаться полезная для меня инфа. ;)

еще вариант - на каждый интерфейс создать свой сокет и poll-ом или select-ом их мониторить

Мне лень столько писать, да еще и править под себя net-snmp :) Я лучше заюзаю getsockopt + IP_PKTINFO ;) Так тоже прийдется net-snmp править, но изменений будет меньше.