Re: Функционал и интерфейс
Покотиленко Костик -> debian-russian@lists.debian.org @ Mon, 16 Mar 2009 12:06:13 +0200:
ПК> $ progA | ssh user@host progB
ПК> progA записывает каманду в вывод, команда улетает мгновенно в буфер
ПК> ssh, в случае простого протокола, без подтверждения доставки progA
ПК> будет считать команду доставленной, хотя на самом деле это ещё не
ПК> так.
Если она так думает в локальном случае, ее автора пора лечить :-) Никто
никому никогда не гарантировал мгновенной доставки в случае с локальным пайпом.
ПК> Кроме того часто тяжело заставить команды приходить раздельными
ПК> порциями.
Это тоже от сети не зависит.
>> Потому что тогда не будет способа воспользоваться
>> функционалом :-)
>>
>> Так вот, у классической юниксовой CLI-программы интерфейс рассчитан на
>> юникс-юзера. Который ближе к разработчику, чем к энд-юзеру. И тем
>> самым просто является таким же API, что и у библиотеки.
ПК> Ну нет же. Разные они, если подробно разобраться. Учитывая
ПК> вышесказанное, API - для низкоуровнего (производительного и компактного)
ПК> программирования,
Преждевременная оптимизация - корень всех зол. (c) кто-то из великих.
ПК> CLI - для юникс-юзера и скриптов (по быстрому на коленке).
ПК> На пример, для сбора счётчиков правил iptables можно использовать
ПК> обёртку вокруг iptables -nvL | iptables-save типа:
ПК> iptables-save | grep "<условие>" | cut -d" " -fI
ПК> или такую конструкцию на Си:
ПК> ...
ПК> struct ipt_entry *ipt_e;
ПК> char *target;
ПК> for(ipt_e=iptc_first_rule(chain_name, &ipt_h); ipt_e;
ПК> ipt_e=iptc_next_rule(ipt_e, &ipt_h)) {
ПК> if(!ipt_e) {
ПК> printf("iptc_first_rule(): returned NULL pointer\n");
ПК> return(NULL);
ПК> }
ПК> if(!<условие>) continue;
ПК> target=iptc_get_target(ipt_e, &ipt_h);
ПК> printf("Source IP: %s/%s (iface: %s), Destination IP: %s/%s (iface: %
ПК> s), Target: %s, Counters: %llu bytes, %llu packets\n",
ПК> x_strcpy(inet_ntoa(ipt_e->ip.src)),
ПК> x_strcpy(inet_ntoa(ipt_e->ip.smsk)),
ПК> ipt_e->ip.iniface,
ПК> x_strcpy(inet_ntoa(ipt_e->ip.dst)),
ПК> x_strcpy(inet_ntoa(ipt_e->ip.dmsk)),
ПК> ipt_e->ip.outiface,
ПК> target,
ПК> ipt_e->counters.bcnt,
ПК> ipt_e->counters.pcnt
ПК> );
ПК> }
ПК> ...
ПК> Первый вариант делается за 5 минут, подойдёт для не частого сбора
ПК> небольшого числа счётчиков.
ПК> Второй вариант "страшный", пока первый раз не сделаешь. Подойдёт для
ПК> частого сбора сотен показаний.
Я бы уже задумался о том, что узкое место такой системы - не в сборе
показаний...
ПК> Дальше, если скармливать нужные счётчики и выводить их за один проход -
ПК> можно обрабатывать теоретически неограниченное количество счётчиков за
ПК> проход без дополнительных расходов.
Это как раз автомагически получается с iptables -L. На C тебе для этого
придется громоздить изрядную конструкцию (фактически, разрабатывать
половину перла). Оно окупится? У меня есть сомнения...
>> Но если этот человек может алгоритмизовать некоторый набор
>> своих действий - он поручает его программе, и API для этого у него уже
>> есть.
ПК> Да, но это тоже, что и бегать в чугунных сапогах.
Результаты профайлинга предъяви, да?
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Попрошу благородного дона не обобщать с утра пораньше! (С)энта
Reply to: