Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 12 Feb 2010 15:37:00 +0300:
>> AP> Задача обмена данными через сокет включает в себя открытие сокета и >> AP> получение дескриптора. Вот ровно это и делают tcpserver и tcpclient >> AP> - без зависимостей, без сотен килобайт "нафаршированного" бинаря... >> >> А это ничего, что задача открытия сокета, которую может решать >> tcpclient, вообще-то есть быть суть десяток совершенно шаблонных строчек >> на C, а та, которую tcpserver - ну, два десятка? >> >> А на tcl, соответственно, одна и три? >> >> Ради этого громоздить бинарник, нафаршированный зависимостями от >> динамической загрузки? AP> Возьмите статическую сборку, с dietlib. Ога, и пересобирайте каждый раз, как кто-нибудь обнаружит уязвимость в оной. Кстати, резолвер-то в нее встроен, или сколько библиотек придется собирать статически и отслеживать их секьюрити апдейты? >> AP> socat не утилита, а монстр чуть ли не с опенофис. И с пучком >> зависимостей: >> Ну, да. Потому что оно умеет открыть не только тупой TCP-сокет. И как >> только тебе надо чуть больше, чем тупой TCP-сокет, твои tcpserver и >> tcpclient немедленно начинают исключительно занимать место на диске. А >> пользу приносить перестают. И все, что у тебя было завязано на их >> использование, тебе приходится переписывать на что-то более вменяемое. AP> А ничего, что tcpserver так и называется потому, что с tcp AP> работает? Надо вам другой сокет - возьмите другую утилиту. Или вы AP> за виндовый подход, когда каждая программа тащит в себе как можно AP> больше всего? Тогда не надо про юникс-вей говорить в этом AP> контексте, если требуете, чтобы утилита tcp... работала с udp, AP> юникс-сокетами, служила эмулятором терминала и проч. Не, я не требую. Утилита, которая так работает, называется socat. Я, собственно, ее и беру... >> А libreadline там затем же, зачем и libssl. Только для разных типов >> файловых дескрипторов. libssl - для SSL-сокета, а libreadline - для >> терминала с юзером. AP> С каких это пор в линуксе проблемы с терминалами, так что AP> приходится эту функциональность в socat пихать? Натуральный монстр, AP> по идеологии виндоус. Не "терминала", а "терминала с юзером". Ты, типа, не в курсе, что возможность нормального редактирования вводимой строки юзеру предоставляет ни разу не терминал? >> Ога, вот только этот интерпретатор без расширений нихрена не умеет >> сидеть сервером на UNIX socket'е. А на TCP - умеет. Поэтому, чтобы >> чуть-чуть расширить функциональность написанной на нем программы (а с >> точки зрения собственно программирования после открытия и первоначальной >> настройки разницы между UNIX и TCP сокетами - никакой), мне приходится >> либо искать это расширение, либо радикально менять схему работы. AP> Фактически unix-сокеты давно уже в состоянии deprecated, но в этом AP> явно не тикль виноват. А учитывая тенденции по монтированию AP> удаленных ФС по http-based протоколам, и вовсе. Судя по DBUS и AP> проч., юникс-сокеты скоро и с серверов пропадут. Я не говорю, что AP> это именно хорошо, но так уж есть. Не "фактически", а "у криворуких десктопных программистов". Нормальные же серверные программы очень нескоро перейдут от сокетов, спокойно тянущих весьма нехилую нагрузку, к дбасу, который десятка юзеров не выдерживает. -- /итд/почтопосылалка.нстрк (c) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
