On Mon, 16.03.2009 16:02:07 , Покотиленко Костик wrote: > В Пнд, 16/03/2009 в 14:40 +0300, Artem Chuprina пишет: > > Покотиленко Костик -> [email protected] @ Mon, 16 Mar 2009 > > 12:06:13 +0200: > > > > ПК> $ progA | ssh u...@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 тебе для этого > > придется громоздить изрядную конструкцию (фактически, разрабатывать > > половину перла). Оно окупится? У меня есть сомнения... > > Уже окупилось. На системе где так работает после таких оптимизаций прогу > передающую счётчики в snmpd в top'е не видно, а snmpd иногда до 10% CPU > тратит. Следующим шагом, там от snmp откажусь в пользу самописного > демона, проблема иссякнет. > > > >> Но если этот человек может алгоритмизовать некоторый набор > > >> своих действий - он поручает его программе, и API для этого у него уже > > >> есть. > > > > ПК> Да, но это тоже, что и бегать в чугунных сапогах. > > > > Результаты профайлинга предъяви, да? > > Есть конкретный пример? С профайлингом на <Ваш любимый скриптовый > язык>... Вы бы ESR-а всё-таки почитали, а то Артёму тут уже приходится некоторые места своими словами пересказывать и те же цитаты приводить, которые там уже приведены.
-- С уважением, Тихон Тарнавский. http://linuxforum.ru http://posix.ru -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
