ну да. Я прошелся по clib/inet кэширования не нашел. Буду писать свое

https://tproger.ru/explain/domain-name-system/ А что будет кэшировать то что вы собираетесь написать? Тоже с такой проблемой столкнулись

Да мне на kamailio надо чтобы не гонять каждый раз к dns закэшить имя и его ip. По факту просто внутри сервиса мап хранить имя=>ip

Да мне на kamailio надо чтобы не гонять каждый раз к dns закэшить имя и его ip. По факту просто внутри сервиса мап хранить имя=>ip

Да мне на kamailio надо чтобы не гонять каждый раз к dns закэшить имя и его ip. По факту просто внутри сервиса мап хранить имя=>ip

А не пробовали завести локальный dns сервер и обращаться к нему? Чтоб не писать свой велосипед

Да нет там никакого велосипеда. Простая функция которая резолвит через socket.dns.toip и потом складывает это во внутренний кэш сервиса. Каш с таймером. Там уже все есть. Остаётся только при обращении к фенкции делать запрос кэш и смотреть есть ли там значение. Если нет то заново резолвит. Всё в себе. Без 3d party service. Удобнее

А зачем локальный кэш DNS в приложухе? У вас получится кэш в приложении и кэш на сервере куда отправляются запросы при резолве dns. Зачем два кэша?

Чтобы не ходить на сервер куда Отправлю с запросы лишний раз.

DNS запросы одни из самых быстрых, в чем оверхед в вашем случае?

В их наличии

А как вы определили что эти запросы можно характеризовать как оверхед? Какие именно параметры вас привели к такому решению? У нас в офисе холивар на эту тему и пока не пришли к общему решению, может быть у вас есть какие то реальные данные и расчеты?

Ну у меня банально есть выбор слать запрос или нет) чтобы отправить запрос системе как минимум нужно собрать пакет и отправить его через сетевой интерфейс. В случае кэша - этого делать не нужно. Как то так)

Это копеечные затраты

Ну у меня банально есть выбор слать запрос или нет) чтобы отправить запрос системе как минимум нужно собрать пакет и отправить его через сетевой интерфейс. В случае кэша - этого делать не нужно. Как то так)

Ну так вам все равно придется делать запрос к вашему внутреннему кэшу, пусть этот кэш висит в памяти например, вам все равно не обойтись без этого запроса, и для того что бы принять решение обычно берут и сравнивают время или ресурсы, в вашем случае необходимо и то и другое, кэш имеет свойства "расти" и "занимать какое то место", ну и скорость запрос/ответ вы наверняка хотел ли бы сравнить, неужели вам безразличны эти параметры?

Если я могу даже копеечных затрат избежать то почему нет? Вообще мне непонятна честно Говоря суть дискуссии. Мне надо. Я сделал. Кому не надо тот не далает. В чем вопрос?

А кешите только A или ещё и AAAA? Весь рекордсет? Уважаете ttl записей?

Ну у меня банально есть выбор слать запрос или нет) чтобы отправить запрос системе как минимум нужно собрать пакет и отправить его через сетевой интерфейс. В случае кэша - этого делать не нужно. Как то так)

На практике кэширование данных всегда работает быстрее. У меня были ситуации когда дело упиралось в dns. Кэширование в этом плане снимал проблему. Запросов у меня много - это sip сервер со своим блэкджеком и куптизанками. Трафика там много. Сессии сложнее чем в http. Запрос к локальной памяти выходит быстрее чем запрос к сетевому ресурсу. Как то так.

а не думали поставить локальный тот же bind например, чтобы честно кешировал на время TTL? Запрос будет к локальному ресурсу на том же хосте. ИМХО проще, чем смотреть на TTL и кешировать по нему.

да, только кеш не стоит хранить дольше TTL. А то может получиться некрасиво

У меня внутренний кэш с таймером. Кэшу только А. Кэшу на 10 минут.

Нет у меня возможности биндить локально. Есть определённые ограничения

а не думали поставить локальный тот же bind например, чтобы честно кешировал на время TTL? Запрос будет к локальному ресурсу на том же хосте. ИМХО проще, чем смотреть на TTL и кешировать по нему.

А как же ipv6 и ttl?

Лучше unbound

У вас нет возможности поднимать что то локально рядом с вашим sip?

Мне не нужен 3d service. Функции в 10 строчек хватает

А как вы спланировали объем кэша? С kamailio и огромным количеством запросов в короткое время - кэш наверняка будет не из пяти записей состоять, и как быть в пиковые часы? Хватит ли ресурсов держать "вот это вот все" в локальном map ?

Мне не нужен 3d service. Функции в 10 строчек хватает

Учитывая что у меня там лежит только 1 сервис для метрики (в кэше) то там 1 запись по факту валяется. Кэш ограничен по объёму занимаемой памяти

Никто не может вас заставить не писать эти 10 строк, но, например, мне интересно на чем основан ваш выбор, так как на работе примерно такая же проблема и у нас нет шанса на ошибку, если завалится то нам грозит "тазик, ноги, бетон, река"

1 запись в кэше? Это как?

Есть сервис доступный по доменному имени. Задача не резолвит его при прохождении каждого пакета. Как можно быстрее отправить данные и продолжить выполнение

Есть сервис доступный по доменному имени. Задача не резолвит его при прохождении каждого пакета. Как можно быстрее отправить данные и продолжить выполнение

прописать в файл хостс?

Есть сервис доступный по доменному имени. Задача не резолвит его при прохождении каждого пакета. Как можно быстрее отправить данные и продолжить выполнение

Я уже писал выше что у меня нет варианта ни в hosts ни в 3d сервис

Обращаяться по IP с хедером хост

А на каком уровне у вас происходит резолв этого домена сейчас?

С каким хедером хост? Куда обращаться? У меня там udp голый который херачет безудержно пакеты в сторону сервиса сбора метрик.

а ты по ип тогда кидай туда данные, нахера тебе резолвить доменное имя?

Потому что нет у меня изначально ip

Да. Я не знаю его ip изначально. Был бы ip и вопроса не стояло

Так меняется ip у домена? Или ip постоянный? Может узнать заранее ip домена и указать его в место домена?

Он может поменяться. Блин) я 3 раз уже пишу что единственный вариант узнать ip - сделать резолв. В моем случае)

резолв как делаешь?

https://tproger.ru/digest/sysadmin-compilation/#17

socket.dns.toip()

не проще написать этот резолвер отдельно? т.е. чтобы он чекал раз в секунду

С каким хедером хост? Куда обращаться? У меня там udp голый который херачет безудержно пакеты в сторону сервиса сбора метрик.

Ужас какой. Метрики по udp :(

В чем ужас?

_гарантии доставки_

_гарантии доставки_

это метрики епт

И что? У тебя 30% метрик потерялось, норм же, да? )

Вообще насрать

Я последние 8 лет очень плотно работаю с UDP. Если в процентном соотношении посчитать сколько данных было не доставлено - то это примерно 0,0000000000000001%