Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Код делает следующее (цепочку проследил многочисленными дебагами): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. Т.е. при исходящем телефонном вызове номер телефона "0074951234567" ну или там "84951234567" передается в ф-цию PIPSocket::GetHostAddress (зачем-то), а в итоге первым параметром в WIN32 API getaddrinfo function Ф-ция getaddrinfo думает ни много ни мало аж 2 секунды с хвостом после чего разрожается с ошибкой: localErrNo=11001 Windows Sockets Error Codes 11001WSAHOST_NOT_FOUND 11001 Host not found. No such host is known. The name is not an official host name or alias, or it cannot be found in the database(s) being queried. This error may also be returned for protocol and service queries, and means that the specified name could not be found in the relevant database. По логике библиотеки такой результат не является ошибкой. Но ожидание в 2 секунды на практике означает что будет задержка в 2 секунды между нажатием на кнопку "звонить" и началом набора номера, что неприемлимо (категорически, если есть очередь из большого к-ва вызовов что надо сделать). Как убрать задержку в getaddrinfo("0074951234567",...) до выдачи ошибки? Комментарий: Я написал автору: давай вообще уберем проверку PIPSocket::IsLocalHost в ApplyRouteTable, типа дебилизм какой-то набираемый номер с хостом сравнивать. Он ответил: если хочешь у себя убирай, но так надо, код 10 лет не менялся, PIPSocket::IsLocalHost вызывается во многих местах, и он не уверен что это не породит каких то еще проблем. Я ему говорю: давай тогда проверять что в user.Left(user.Find(':')) есть что-то кроме цифр, и только тогда вызывать PIPSocket::IsLocalHost. Он возражает: авторUnfortunately no. Years ago it did exactly this, had done right from the beginning. Then I got a customer that had host names generated from the machines Ethernet MAC address in hex. This worked well, right up until they had a card that did not have a-f anywhere in it's address. Bang, all stopped working. Big argument over RFC 952 and RFC 1123. Had to allow for all numeric host name.Дословно, он тоже так считал, но был у него клиент который свои хосты именовал по MAC-адресам сетевых карт, но досталась ему раз карта с мак-адресом вообще без ABCDEF (одни цифры), и все разом гавкнулось. И аргументирует тем, что по RFC не запрещается именовать хосты "только цифрами". Здесь еще замечу, что библиотека кроссплатформенная, т.е. непонятно из ответа на какой системе гавкнулось: Win Mac или Linux. Но в любом случае он меня пока типа отговорил от "тупого комментирования" этой проверки. Посему вопрос как я его задал. Можно ли убрать 2-х секундное ожидание в getaddrinfo("0074951234567",...) и как это сделать? В MSDN очень много информации, сразу не догонишь. Либо надо делать тест-проект чисто на исследование getaddrinfo. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 21:36 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Программного решения я не знаю, но можно попробовать админский вариант. Что служит DNS-сервером для этого компа? Этот софт должен работать на определенных компах или на произвольных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 22:22 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Дмитрий77, вряд-ли можно ускорить работу DNS протокола в случае "промаха". Там навреное участвует цепочка серверов. Но ты можешь сам кешировать результат работы этой функции если договоришся сам с собой что у тебя другой DNS и отбивать несуществующие записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 22:47 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
А я бы пошел по пути регекспа (или настраиваемого списка регекспов). Удовлетворяет текст шаблону? Значит это номер. Не удовлетворяет - значит хост. Ну или наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 22:58 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Дмитрий77В MSDN очень много информации, сразу не догонишь. не там по этому поводу никакой информации ожидание убрать нельзя, разве что свой резолвер подсунуть,что вряд ли приемлемо из извращений - писать перед обращением к бидлиотеке искомый адрес в hosts ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 23:05 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
White OwlУдовлетворяет текст шаблону? патчить опал придётся - стоит смириться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 23:06 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
miksoftЭтот софт должен работать на определенных компах или на произвольных? Естественно на произвольных. maytonвряд-ли можно ускорить работу DNS протокола в случае "промаха". Ну, промах получается 100-процентный. Скажем так, до 10 знаков (4951234567, либо короткие Ext. типа 101,102) Opal как-то отсекает, а начиная с 11 знаков (как раз минимальная длина полноценного номера 84951234567 0074951234567) дурит перекидывая на "getaddrinfo" maytonТам навреное участвует цепочка серверов. Но ты можешь сам кешировать результат". Opal кэширует. Т.е. повторные вызовы на тот же 0074951234567 идут без задержек, а стоит поменять одну цифру 007495123456 4 и опять 2 секунды. White OwlА я бы пошел по пути регекспа (или настраиваемого списка регекспов). Удовлетворяет текст шаблону? Значит это номер. Не удовлетворяет - значит хост. Ну или наоборот. Вот я и предложил отключать проверку для цифровых юзернеймов, а он мне привел пример из жизни с хостом из мака сетевухи (в которой "выпали три семерки" без буков). Изопропилпатчить опал придётся - стоит смириться. Патч элементарный. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Самое сложное было додебажить до этого места. Потом уткнулись в getaddrinfo. Предположений про эти 2 секунды была куча. Так вот позиция автора: так делать НИЗЯ. (мне то это сделать никто не запрещает) А с getaddrinfo он тоже ничего сделать не может. авторThe delay really has to be in the socket call like getaddrinfo() or gethostbyname(). And if it is deep inside getaddrinfo() I have no idea how to fix it. А с др. стороны я не понимаю зачем эта проверка IsLocalHost(username) именно там нужна. Я нарочно настроил роутинг, чтоб все звонки шли на IP соседнего компа. И стал звонить на 127.0.0.1 (в качестве номера т.е. на sip:127.0.0.1@<tagretcomp IP>), на имя компа с которого звоню -без проверки IsLocalHost("127.0.0.1"). И все звонки прекрасно прошли. Но это еще надо быть совсем дебилом, чтоб набирать такие "алиасы". Я не поленился и сделал тест-проект на VB6 (мне так проще): Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. На любую фигню Err.11001 со стабильной задержкой 2250 (миллисекунд) - с кварцевой точностью. А ведь если это реальный хост (googl.com, yandex.ru, да хоть ЮжныйПолюс.блин), то ответ приходит гораздо быстрее, нечто похожее на команду ping. Я к тому что где-то этот надуманный таймаут все же есть. Кстати есть еще GetAddrInfoEx, GetAddrInfoExCancel надо б почитать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 02:09 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Дмитрий77, 2 cекунды на промах в локальном кеше означает что либо большая задержка до сервера DNS либо сам сервер проксирует запрос на другой сервер до которого такая задержка. В любом случае это какая-то аномально высокая задержка. Проверяйте корректность конфига сервера имен. Для начала попробуйте переключиться на какой-нибудь публичный сервер, который точно работает - например гугловский 8.8.8.8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 03:00 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyДмитрий77, Проверяйте .... Для начала попробуйте переключиться на какой-нибудь публичный сервер, который точно работает - например гугловский 8.8.8.8. У меня Билайн (бывшая корбина), получение DNS -динамически Сейчас в роутере пишет DNS : 213.234.192.7 85.21.192.5 В настройках сетевухи компа - тоже динамически. От того что я поменял в сетевухе на 8.8.8.8 -ничего не поменялось. Я приложил свой VB6 тестовый проект (код выше), exe-шник если что внутри есть (скомпилированный, выводит время в msgbox). Почему б не проверить на других компах. Перед тем как грешить на то что у меня все плохо. У меня на 3-х компах результат одинаковый, на win 8.1 даже чуть больше 2300+ и гуляет. (т.е. про ==2500 я погорячился) А ради интереса, проверьте кому не влом . Но лечить чего то у себя в сети я точно не хочу - как потребителя инета меня все в целом устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 03:39 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Я вот тут код накатал как смог. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. На XP GetAddrInfoEx function понятно не работает, поэтому тестировал на 8.1 Результаты: getaddrinfo -такой же как и ранее 11001 (~2500) GetAddrInfoEx - нижняя часть кода 11001, но время в 2,5 раза быстрее (~850) Интересно, почему? средняя часть -почему-то не работает WSAEINVAL 10022 Invalid argument. Some invalid argument was supplied (for example, specifying an invalid level to the setsockopt function). In some instances, it also refers to the current state of the socket—for instance, calling accept on a socket that is not listening. Я пытаюсь задать таймаут. В MSDN написано: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. timeout [in, optional] An optional parameter indicating the time, in milliseconds, to wait for a response from the namespace provider before aborting the call. This parameter is only supported when the UNICODE or _UNICODE macro has been defined in the sources before calling the GetAddrInfoEx function. Otherwise, this parameter is currently reserved and must be set to NULL since a timeout option is not supported. Что ей не хватает? UNICODE под нос ей подсунул как просят. (хотя не понимаю, в VC++2010 где мне это удалось скомпилировать проект и так юникодный). Структуру limit вроде правильно задал. Что ей еще надо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 07:08 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
GetAddrInfoEx - нижняя часть кода 11001, но время в 2,5 раза быстрее (~850) Интересно, почему? Я ошибся думаю. Код: plaintext 1. 2. Ровно столько же она тратит на поиск. Таймаут бы как-то установить, не получается. Запутался уже с этими звездочками и амперсандами, кучу вариантов перепробовал. Либо игнорирует, либо крашит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 09:07 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
[quot Дмитрий77] Первый способ: Вынести резольвер в отдельный поток, и изменить дизайн приложения с учётом резольвинга адресов асинхронно. Можно ставить запросы на резольвинг в одну очередь, и с другой забирать результаты. Второй: В glibc есть асинхроннный резольвер getaddrinfo_a Не знаю, может в winapi есть такое же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 09:54 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Дмитрий77Таймаут бы как-то установить, не получается. Запутался уже с этими звездочками и амперсандами, кучу вариантов перепробовал. Либо игнорирует забей, асинхронные варианты этого хозяйства работают в 8-ке и 12 сервере (а таймаут и на 12 сервере не заработал ) По существу - если требуется резолвинг имени, 2 секунды - нормальный таймаут. если нужно его уменьшать - значит реально резолвинг не требуется, либо алгоритм резолвинга не завязан на стандартные службы DNS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 12:27 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Изопропилзабей, ... если требуется резолвинг имени, 2 секунды - нормальный таймаут. если нужно его уменьшать - значит реально резолвинг не требуется, либо алгоритм резолвинга не завязан на стандартные службы DNS Конечно, забью. Закомментирую и забью. Надоело. Я вообще не понимаю зачем конкретно там нужен этот резолвинг. Чтобы проверить что пользователь не дурак? А все умные сидят 2 сек в дураках. А 2,5 секунды задержки в наборе номера за просто так - это ненормальный таймаут. Типичный пример когда увлечение обработкой малоНЕвероятных ошибок заумными алгоритмами приводит к реальным плохо отлавливаемым проблемам. Т.е. если ты на мобильнике жмешь "звонить", а он 2-3 сек думает - ты на это внимание не обращаешь. И я так понимаю в Opal на это никто и не обращает внимание Я лично через 5 лет работы с библиотекой это накопал. Причем когда по локалке тестируешь с короткими номерами типа 100,101 - то задержки нет (Opal отсекает), а когда звонишь на SIP провайдера, ну типичная мысль: провайдер далеко, некачественный, и т.п. - вот и задержка - а оказывается собака в getaddrinfo, и ладно бы он имя сервера проверял, так он именно набираемый номер проверяет (то что до @ а не после). А если у тебя система на 50 линий, ты бухаешь 50 заданий и говоришь "звонить", то 50-й вызов пойдет с задержкой 50*(2-3сек)=2-3 минуты, за которые половина вызовов уже закончатся. И мой самый тупой алгоритм с таймерами и погрешностью размещения задания в системе в 300-500миллисекунд против этих 2 секунд отдыхает. Разработчик уперся рогом против моего патча "резать к чертовой матери", зацепился за мою же идею делать параллельные вызовы из разных потоков, но я то эту идею быстро отмел - это лишние потенциальные глюки (типа 2*50 последовательно =100сек, а 2*50 параллельно =2сек ) и делает у себя какие-то фиксы типа: Moved the possibly time consuming PIPSocket::IsLocalHost() outside of the route table mutex, so does not serialise all the delays Ни к чему, кроме как к запутыванию врагов еще больше я считаю это привести не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 16:50 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Дмитрий77А если у тебя система на 50 линий, ты бухаешь 50 заданий и говоришь "звонить", то 50-й вызов пойдет с задержкой 50*(2-3сек)=2-3 минуты, за которые половина вызовов уже закончатся. И мой самый тупой алгоритм с таймерами и погрешностью размещения задания в системе в 300-500миллисекунд против этих 2 секунд отдыхает. Если ты делаеш все 50 VoIP соединений как батч в одной нити то тебе нужно попробовать себя в чем то другом, далеком от программирования. Nothing personal. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 17:13 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
lockedЕсли ты делаеш все 50 VoIP соединений как батч в одной нити то тебе нужно попробовать себя в чем то другом, далеком от программирования. Сто процентов. Задача из этой ветки-просто эталонный пример для учебника, иллюстрирующий необходимость и задачи для использования многопоточности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 17:23 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
lockedЕсли ты делаеш все 50 VoIP соединений как батч в одной нити то тебе нужно попробовать себя в чем то другом, далеком от программирования. А кто тебе сказал что все вызовы - одна нить. Одна нить - эта только ф-ция manager->SetUpCall которая возвращает token вызова, и она, без учета обсуждаемой здесь задержки getaddrinfo отрабатывает мгновенно (и именно так и задумано в Opal), максимум несколько миллисекунд. И никакой необходимости делать SetUpCall в отдельном потоке я не вижу, тем более что manager все равно один на все Application. А делать мультипотоки там где это НЕ НАДО, извините. Не говоря о том, что это без патчей типа тех что сейчас (зачем-то) пытается сделать автор Opal (см. ссылку моим постом выше) "параллельность" не обеспечит. Что ж ты тогда не предложишь касательно таймаута getaddrinfo не запускать его в отдельном потоке и не грохать по "таймауту" из основного потока? Давай потоки каскадами вешать. Только это батенька уже полный дурдом будет. Так что твое замечание в духе "Ты дурак, но ничего личного" ни к месту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 18:55 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Дмитрий77А 2,5 секунды задержки в наборе номера за просто так - это ненормальный таймаут. но это совершенно нормальный таймаут при резолве доменного имени ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 19:13 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
ИзопропилДмитрий77А 2,5 секунды задержки в наборе номера за просто так - это ненормальный таймаут. но это совершенно нормальный таймаут при резолве доменного имени При резолве доменного имени - наверно нормальный. А при наборе телефонного номера - ненормальный. Чего гадать. Берем стандартный софтфон типа X-LITE и звоним. Задержки нет. Значит он не занимается фигней. Отсюда вывод: нефиг резолвить номер телефона как доменное имя. Патч: "резать к чертовой матери". Точка. Подпись. Печать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 19:39 |
|
||
|
А возможно убрать задержку (около 2 секунд) в API-ф-ции getaddrinfo?
|
|||
|---|---|---|---|
|
#18+
Дмитрий77Так что твое замечание в духе "Ты дурак, но ничего личного" ни к месту.Если вам так дорого время, то вы должны быть готовы заплатить за его (времени) экономию. Две секунды для "host not found" - совсем немного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 19:40 |
|
||
|
|

start [/forum/topic.php?fid=57&gotonew=1&tid=2019570]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
10ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 144ms |

| 0 / 0 |
