Abram

Попробуйте детально изложить проблему на noc@gts.dp.ua . Сразу можно копию на noc@triolan.com .

Если выбирать прямо уж между VirtualBox и ESXi - то ESXi. Но лучше KVM. Можно Proxmox, кстати.

kvm. Сеть и диск вешать на virtio.

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

Высший пилотаж - найти работу в удаленном аутсорсе и отдать её на удалённый аутсорс. Ещё круче - в ту же контору.

Раньше его недолюбливал, но последние годы активно пользуюсь на десктопе. Действительно удобно. Умеет всё - даже Интертелекомовские CDMA-модемы сам запускает, нужно только выбрать "Украина" и "Intertelecom".

В Ubuntu такие вещи следует делать из Network Manager. Если пользоваться ТОЛЬКО им - всё просто чудненько.

Просто уберите кабель и повесьте сбоку муфту. С одной стороны - вы не имели права вешать там кабель. С другой стороны - хозяин участка не имеет права самовольно повредить ваш кабель (всё-таки он ваш, хоть и на его территории). Хотя, конечно, может и костёр развести - докажи, что это специально. Но если он пойдёт на принцип и заставит вас перенести кабель в судебном порядке - вам это обойдется на порядок дороже, чем просто взять и перетащить.

Ну если специфики /25 - то слабо решают, конечно же . Но вообще спецификами лучше не рулить. Баловство это.

и ямы роютСебе.

Вы где-то видели админа, который занимается поддержкой хомячков?

Существует асинхронный клиент. И есть обертки - например, twisted предлагает выносить mysql в отдельный поток (собственно, и выносит), где будет всё говно, а в основном потоке будет асинхронный код, который будет работать с асинхронным интерфейсом (оберткой) MySQL. Хрень, конечно, но всё равно получается на порядок шустрее, чем синхронный код.

Покажи мне асинхронный MySQL запрос Я что-то не припомню таковой реализации в мускуле, как и в других СУБД. Запрос сам по себе синхронный, но это не должно никого волновать . Грубо говоря, соединение с MySQL - это сокет. В сокет можно написать что-то и благополучно на него забить болт до того времени, пока что-то оттуда не придёт. В асинхронном программировании логика такова: отправил в MySQL запрос, пнул реактор (слышь ты, вот есть fd/socket, придёт чего-то вызовещь вот эту ф-цию) и всё - функция завершилась, возвращаемся в реактор. Дальше реактор запускает следующую функцию (или не запу

Фильтр еще добавить.

SQL для апликухи - это самый что ни на есть i/o, который можно не ждать, а заняться в это время своими делами (обслуживать другой запрос, например). Да, именно это же делает ОС, если использовать потоки/процесы, но практика показала, что накладные расходы на это настолько высоки, что часто один асинхронный процес может обслужить больше клиентов, чем несколько синхронных. Вообще асинхронное программирование лично мне напоминает жонглирование: бросил мяч и забыл о нем до тех пор, пока он не прилетит к тебе назад. В это время можно сделать много чего ещё полезного (бросить/поймать другие м

Поднять пиринг с соседом, originate default, фильтр в сторону соседа: отправлять только дефолт, принимать только его подсети. Фильтры отправляемы в сторону аплинков маршрутов (они ведь есть? ): добавить сети соседа.

Если сервис асинхронный - то это очень годная тактика.FreeRADIUS НЕ асинхронный и никогда им не был.

IPMG http://ipmedia.net.ua/ Тут на форуме был их представитель.

Если сильно нужно - решаемо. Сам понимаешь .

тут немного другой принцип заносятся все адреса по одной записи в таблицу а что делает этот блок ? `u`.`lastBlock` <= %s Вот именно от этого принципа я у себя и отказался.lastBlock - последнее время блокировки адреса. В %s там подставляется текущий unixtimestamp минус 60 секунд вроде бы. Суть такова: при авторизации делается UPDATE ... SET lastBlock = %s (%s = timestamp), т.е. пометка, что этот ещё 60 секунд использовать нельзя. Если за 60 секунд (это я взял с запасом) сессия не появится в dv_calls - адрес уже считается свободным. Если интересно - вот полностью ф-ция: http://pa

Вообщем-то локи в целом плохо, лучше когда без них, но без них навряд получится нормально... Мне кажется, можно обойтись каким-нибудь атомарным select for update. Или быстренько заблокировать, select-нуть, update - обозначить, что этот адрес используется, и unlock.Кстати, насчет моей таблицы с используемыми IP: благодаря ей у меня получилось обойтись без вот такой конструкции (перебор занятых IP адресов): for (my $i = 0 ; $i <= $#pools_arr ; $i++) { %pool = %{ $pools_arr[$i] }; foreach my $ip (@$list) { if (exists($pool{ $ip->[0] })) { delete($pool{ $ip->[0]

А теперь ситуация - клиент начинает долбить авторизацию в 100500 потоков, но не согласовывается с сервером и режектится. В случае с записями таблице сессий - в худшем варианте займется N адресов по кол-ву брасов (при реконнекте на брас клиента с тем же CID/логином ему выдается старый ип), в твоем случае - засирается временный пул адресов. А чтобы их не было - и используется лок. Алгоритм по сути тот же, разница - в том, куда и как пишется. Кстати, надо будет и у себя лок прикрутить - атомарность это правильно, тогда коллизий не сможет быть в принципе. Не проблема, записывай вместе с бл

Ну сессия создается при авторизации, занимая ип. Если аккаунтинг не пришел - сессия умирает. Если я ничего не попутал в алгоритме (давно ковырял код). А должна создаваться при первом Accounting. Когда-то с этим была проблема; был даже от тебя патч. У я себя решил так: есть с IP-адресами, где записывается время последней выдачи адреса. Адрес считается свободным, если его нет в dv_calls и последняя выдача была больше n секунд назад. Таблица полностью сразу заполняется адресами и update-ится только время выдачи. Из всех рассмотренных вариантов этот оказался самым быстрым. Коллизии возможн

IP ищется при авторизации, а вносится при первом аккаунтинге. Возможен вариант, когда авторизация придёт, а аккаунтинг - нет (NAS по каким-либо причинам не поднял сессию - например, в случае PPP не согласовал с клиентом шифрование, в случае DHCP - клиент не откликнулся на OFFER).

~AsmodeuS~, Да без проблем. Соберите опять новые пакеты. Можно даже организовать свой репозиторий и подключать его у клиентов.