Параметры hide-aka, present-aka и limit-rate

Oleg Pevzner написал(а) к All в Nov 15 15:29:23 по местному времени:

Нello All!

В новых версиях бинкда появились сабжевые параметры. Вопрос: эти параметры
являются глобальными или могут быть использованы при описании каждого линка отдельно? Логика подсказывает, что именно так должно быть, но что-то не могу найти их в описаниях линка. Или читать не умею? :)

WBR, Oleg Wednesday November 04 2015
E-Mail: omp<no-spam>omp.dp.ua

--- XStation

Pavel Gulchouck написал(а) к Oleg Pevzner в Nov 15 16:10:34 по местному времени:

Нi Oleg!

04 Nov 15, Oleg Pevzner ==> All:

OP> В новых версиях бинкда появились сабжевые параметры. Вопрос: эти параметры являются глобальными или могут быть
OP> использованы при описании каждого линка отдельно? Логика подсказывает, что именно так должно быть, но что-то не могу найти
OP> их в описаниях линка. Или читать не умею? :)

hide-aka и present-aka появились давно, в 2003, и есть в нынешнем stable (1.0).
Они хоть глобальные, но там можно задавать номер узла или маску:

# Нide or present the specified AKAs if remote AKAs match the address mask
# hide-aka <my-aka> [!]<mask>
# present-aka <add-aka> [!]<mask>
# Mask is compared to the 5d-form of address string, '*' matches any number
# of any symbols (so you have to write '2:5020/' but not '5020/')
# Use '!' to invert the mask
# These rules apply in the same order as in config, you can present any address
#
#hide-aka 2:5020/999. !2:@fidonet # hide aka from all but fido zone 2
#present-aka 2:5047/999.1 2:5047/.0 # present aka to all nodes in 2:5047

Лично мне реализация представляется неидеальной, в ней заложены некоторые проблемы, но в простых случаях они вполне применимы.

rate-limit тоже глобальный параметр (появился в 2004), и тоже можно задавать адрес или маску для узлов, к которым он относится:

# Limit bandwidth (rate):
# limit-rate [all|listed|unlisted|secure|unsecure] <rate>[kM%]|- <mask>...
#
# <rate> is a max allowed rate in bytes-per-second (k=kbytes, M=Mbytes).
# If '%' is specified, the node -bw rate will be multiplied by this value
# in percents, if '-' is specified, then rate will be unlimited.
# <mask> is a filename mask to apply this rule to.
#
# limit-rate rules are checked in the order they appear in config, first
# matching rule is applied.
#
# IMPORTANT! If a node has no explicitly defined bandwidth limit, the
# defnode's limit will be used. If defnode has no limit, rate will be unlimited.
#
#limit-rate unsecure - *.pkt
#limit-rate unsecure 2k *

Для работы limit-rate binkd должен быть собран с поддержкой этой фичи. Под windows обычно распространяются сборки с включенными всеми опциональными фичами.

Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5

Oleg Pevzner написал(а) к Pavel Gulchouck в Nov 15 18:25:55 по местному времени:

Нello Pavel!

Sunday November 08 2015 16:10, you wrote to me:

PG> hide-aka и present-aka появились давно, в 2003, и есть в нынешнем
PG> stable (1.0). Они хоть глобальные, но там можно задавать номер узла
PG> или маску:

Ну да, спасибо, именно это я и читал в описании конфига, но оно и вызвало
исходный вопрос. У меня задача такая: мне крайне желательно иметь возможность выборочно, каждому линку прописывать свой список адресов, который будет ему доступен для предъявления.
В том же T-Mail, например, эта задача легко решается через конфигурационный файл подстановок subst.lst, где в строках описаний ноды
можно указывать параметры Aka (по смыслу present-aka) и hideAka. Комбинируя их
между собой, можно получать очень гибкие конфигурации линков. Подумалось, что и
в бинкде такое должно по аналогии быть, но столкнулся с тем, что параметры hide-aka и present-aka оказываются глобальными. Да, там, конечно, есть маски адресов, но как-то пока не чувствую, смогу ли использовать их для своего случая.

PG> Лично мне реализация представляется неидеальной, в ней заложены
PG> некоторые проблемы, но в простых случаях они вполне применимы.

Согласен, конечно, но смотря что считать таким простым случаем. Вот
описанный мною случай простой или сложный? :) Конкретно: мой узел сегодня имеет
один основной адрес 2:464/5555 и, кроме него, может предъявлять в качестве AKA
еще адреса 2:464/89, 2:464/400, 2:464/0, 2:46/0 и 2:46/9999. Иногда мне бывает
важно скрыть от линка ненужные ему AKA, особенно, если у него они прописаны с
паролями, отличными от пароля на 2:464/5555. Могу ли я это сделать текущими штатными средствами бинкда? Причем так, чтобы одному узлу разрешалось видеть одну часть списка моих адресов, другому - другую часть и т.п.?

PG> rate-limit тоже глобальный параметр (появился в 2004), и тоже можно
PG> задавать адрес или маску для узлов, к которым он относится:

Понятно, спасибо, с этим более-менее ясно.

PG> Для работы limit-rate binkd должен быть собран с поддержкой этой фичи.
PG> Под windows обычно распространяются сборки с включенными всеми
PG> опциональными фичами.

Да-да, спасибо большое, понятно.

WBR, Oleg Sunday November 08 2015
E-Mail: omp<no-spam>omp.dp.ua

--- XStation

Pavel Gulchouck написал(а) к Oleg Pevzner в Nov 15 07:20:20 по местному времени:

Нi Oleg!

08 Nov 15, Oleg Pevzner ==> Pavel Gulchouck:

PG>> hide-aka и present-aka появились давно, в 2003, и есть в нынешнем
PG>> stable (1.0). Они хоть глобальные, но там можно задавать номер узла
PG>> или маску:

OP> Ну да, спасибо, именно это я и читал в описании конфига, но оно и вызвало исходный вопрос. У меня задача такая: мне
OP> крайне желательно иметь возможность выборочно, каждому линку прописывать свой список адресов, который будет ему доступен
OP> для предъявления. В том же T-Mail, например, эта задача легко решается через конфигурационный файл подстановок subst.lst,
OP> где в строках описаний ноды можно указывать параметры Aka (по смыслу present-aka) и hideAka. Комбинируя их между собой,
OP> можно получать очень гибкие конфигурации линков. Подумалось, что и в бинкде такое должно по аналогии быть, но столкнулся с
OP> тем, что параметры hide-aka и present-aka оказываются глобальными. Да, там, конечно, есть маски адресов, но как-то пока не
OP> чувствую, смогу ли использовать их для своего случая.

А в чём проблема с их использованием?

PG>> Лично мне реализация представляется неидеальной, в ней заложены
PG>> некоторые проблемы, но в простых случаях они вполне применимы.

OP> Согласен, конечно, но смотря что считать таким простым случаем. Вот описанный мною случай простой или сложный? :)
OP> Конкретно: мой узел сегодня имеет один основной адрес 2:464/5555 и, кроме него, может предъявлять в качестве AKA еще
OP> адреса 2:464/89, 2:464/400, 2:464/0, 2:46/0 и 2:46/9999. Иногда мне бывает важно скрыть от линка ненужные ему AKA,
OP> особенно, если у него они прописаны с паролями, отличными от пароля на 2:464/5555. Могу ли я это сделать текущими штатными
OP> средствами бинкда? Причем так, чтобы одному узлу разрешалось видеть одну часть списка моих адресов, другому - другую часть
OP> и т.п.?

Да, конечно. Например,

hide-aka 2:46/0 2:463/68@fidonet
hide-aka 2:464/0 2:5020/*
hide-aka 2:46/999 2:292/854@fidonet
hide-aka 2:464/0 2:292/854@fidonet

и т.д., как душе угодно. Таких строк может быть сколько угодно.
Можно и наоборот, через present-aka.

Нужно учесть, что при входящих сессиях эти параметры проверяются для всех предъявляемых удалённой стороной адресов, а для исходящих - только для того адреса, на который ты звонишь.

Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5

Oleg Pevzner написал(а) к Pavel Gulchouck в Nov 15 14:00:45 по местному времени:

Нello Pavel!

Monday November 09 2015 07:20, you wrote to me:

PG> А в чём проблема с их использованием?

Наверное, никаких. :) Просто недоглядел второй параметр. :)

OP>> Могу ли я это сделать текущими штатными средствами бинкда? Причем
OP>> так, чтобы одному узлу разрешалось видеть одну часть списка моих
OP>> адресов, другому - другую часть и т.п.?

PG> Да, конечно. Например,

PG> hide-aka 2:46/0 2:463/68@fidonet
PG> hide-aka 2:464/0 2:5020/*
PG> hide-aka 2:46/999 2:292/854@fidonet
PG> hide-aka 2:464/0 2:292/854@fidonet

PG> и т.д., как душе угодно. Таких строк может быть сколько угодно.
PG> Можно и наоборот, через present-aka.

Угу. Здесь для меня второй параметр важен. Почему-то переклинило, я его совершенно иначе прочитал. :) Спасибо, все Ok.

WBR, Oleg Monday November 09 2015
E-Mail: omp<no-spam>omp.dp.ua

--- XStation