LINUX.ORG.RU

Нужен локальный ПРОСТОЙ клиент серверный текстовый протокол ...


0

0

... с реализациями на перле, питоне, пхп (да в принципе чем больше тем лучше. ) БЕЗ НЕОБХОДИМОСТИ бинарной библиотеки. Еще хотелось бы без XML но если не будет требовать библиотеки бинарные, хрен с ним, пусть бы и XML. Пакет который это все будет использовать не может требовать ничего сверх стандартных вещей, доступных в перлах/питонах. Особой производительности не требуется.

Собственно буду писать некую коллекцию демонов и утилит ими управляющих - то есть шлющих команды, получающих в ответ данные, какие то события и тп. Демоны могут обмениватся информацией друг с другом. Обмен через какие нибудь юниксовые сокеты, универсальность не так важна, важна простота и удобство, вплоть до тупости.

Хотелось бы протокол/средства работы с ним не выдумывать самому, вдохновляясь всякими Art of unix programming а взять некий готовый: заготовку для демонов на разных языках и заготовки для утилит.

★★☆

Ответ на: комментарий от linuxfan

Слишком низкоуровневый раз, нужно все равно свою обвязку чтобы его на unix socket вешать, это два.

Ps
Тут скорее более правильный ответ с твоей точки зрения будет не http, а xml rpc over http. :)

kernel ★★☆
() автор топика
Ответ на: комментарий от Macil

> AMQP?

Хммм. Что то в этом роде.

А не слишком сложный ? Хотелось бы простоты и тупости, хочу напомнить. То есть распаковал tgz с примерами perl/python/... пара хаков и я уже занимаюсь прикладной облдастью ?

Есть какие нибудть готовые perl+python библиотеки с ним работы не требующие библиотек на C.

Упрощенные реализации ?

kernel ★★☆
() автор топика
Ответ на: комментарий от kernel

1. Чем тебя не устраивает bind address 127.0.0.1

2. XML порицаю. Он практически нигде не нужен, тем боеев таком тонком месте, как передача потенциально нетекстовых данных.

linuxfan
()
Ответ на: комментарий от linuxfan

> 1. Чем тебя не устраивает bind address 127.0.0.1

На юникс сокет можно выставить права так что бы никто не пробрался, при необходимости. Ну и вообще не люблю вставлять интернет в любой форме где нужен только локальный доступ.

2. XML порицаю.


Я тоже его порицаю но люблю текстовые протоколы.

Он практически нигде не нужен, тем боеев таком тонком

месте, как передача потенциально нетекстовых данных.



Мне нужны скорее тестовые данные. Что было тупо и понятно а не очередной аттский ынтерпрайз. Тем более что нагрузок не предполагается: если будут нагрузки они пойдут более правильным способом через файлы или разделяемую память.

kernel ★★☆
() автор топика

Народ, ну неужели никто своих демонов не писал с контрольными утилитами ? Или просто каждый писал велосипеды ;) ?

kernel ★★☆
() автор топика
Ответ на: комментарий от kernel

>Ну и вообще не люблю вставлять интернет в любой форме где нужен только локальный доступ.

Я же русским по белому пишу: биндится к 127.0.0.1 — никакого «интернета», доступ только с локальной машины.

Я тоже его порицаю но люблю текстовые протоколы.

XML != human-readable.

Ты, кстати, не SNMP переизобрести собираешься?

linuxfan
()
Ответ на: комментарий от kernel

А не слишком сложный

Относительно сложный. Более того, требует наличия отдельного демона. Придется учить матчасть.

Библиотека на питоне бинарников не тянет. На преле - не смотрел.

пара хаков и я уже занимаюсь прикладной облдастью

Примерно так.

def callback(msg):
   blah-blah

conn = amqp.Connection(options.host, userid=options.userid, password=options.password, ssl=options.ssl)

ch = conn.channel()
ch.access_request('/data', active=True, read=True)

ch.exchange_declare('myfan', 'fanout', auto_delete=True)
qname, _, _ = ch.queue_declare()
ch.queue_bind(qname, 'myfan')
ch.basic_consume(qname, callback=callback)
# Loop as long as the channel has callbacks registered    
while ch.callbacks:
....ch.wait()

Плюсов для твоей предметной области - просто масса. Но может быть стоит посмотреть в сторону SNMP.

Macil ★★★★★
()
Ответ на: комментарий от pinachet

>Если не любишь XML то посмотри в сторону YAML

Враки. Тех, кто не любит XML, нужно заставлять изучать ASN.1.

Macil ★★★★★
()
Ответ на: комментарий от Macil

>Тех, кто не любит XML, нужно заставлять изучать ASN.1.

Не надо путать говноmarkup, не пригодный ни для чего, со вполне себе годным ASN.

linuxfan
()

s-expression

anonymous
()
Ответ на: комментарий от linuxfan

>со вполне себе годным ASN

А-а-а-а-а! Они среди нас! Нет, ::щелк-щелк::, живим вы меня не возьмете.

Macil ★★★★★
()

ГОСТ Р ИСО/МЭК 8824-1-2001

anonymous
()
Ответ на: комментарий от linuxfan

> Я же русским по белому пишу: биндится к 127.0.0.1 — никакого «интернета», доступ только с локальной машины.

Я тебя понял, не слепой. Только вот ты меня не понял. во первых правкой нескольких байт 127.0.0.1 превращается в 0.0.0.0. Что вполне способны осуществить всякие скрипт-киддисы (про права доступа можно не рассказывать :) ). во вторых работают *стандартные* снифферы. И таких мелочей скорее всего много. Слишком удобно для злобных дураков - тут это нафиг. Тем более что его надо поднимать при старте. У меня такая ситация может сложится что локалхоста не будет. Хотя конечно врядли :)

Если вдруг будет то что нужно но только на tcp/ip, ладно, хрен с ним. Но хотелось бы все альтернативы рассмотреть.

Ты, кстати, не SNMP переизобрести собираешься?


Ненене. Я в курсе про SNMP. Я же написал - локальный. Если понадобится выходить «в сеть» по той или иной нужде предполагается использовать совсем стандартные протоколы вроде SNMP. Как раз распределенных подобных протоколов довольно много - но сложных.

kernel ★★☆
() автор топика
Ответ на: комментарий от Macil

> Более того, требует наличия отдельного демона

А демон то как раз красивая хрень требующая make;make install ?

Сам по себе еще демон - хрен с ним. Но вот компилять чего нибудь совсем не хотелось бы.

Плюсов для твоей предметной области - просто масса. Но может быть стоит посмотреть в сторону SNMP.


И каким местом он приспособлен для локального доступа ?

kernel ★★☆
() автор топика
Ответ на: комментарий от kernel

Короче после чтения и гугления сформулировались ключевые слова в виде именно коротких слов а не описания как было.

А именно IPC, RPC(естественно через этот IPC) , просто/тупо, легко встраиваемое в свое приложение, если есть демон то тоже на perl(ну или на python, а еще лучше два разных и на перле и на питоне)

А еще точнее типа аналога DBUS только целиком на «скриптовых» языках, возможно еще проще и без бинарного протокола внутри. Что бы сервер реально занимал пару страниц перлового питонного кода если уж так нужен.

kernel ★★☆
() автор топика
Ответ на: комментарий от ntp

> STOMP? Простой, без XML, есть реализация клиент-серверов под все указанные языки.

O! Сейчас читаю.

Очень простой, без XML, реализация под «все» языки, серверы заточены под встраеваемость в приложение (bundle) .

Да, это ОЧЕНЬ близко к тому что нужно (если даже и не оно), спасибо.

kernel ★★☆
() автор топика
Ответ на: комментарий от kernel

>во первых правкой нескольких байт 127.0.0.1 превращается в 0.0.0.0.

Ну при таком раскладе можно не мелочиться и смело подменять /bin/sh или /sbin/iptables/ifconfig/по желанию.

во вторых работают *стандартные* снифферы.

Что очень ценно, как только полезут баги. Но вообще интересная у тебя система безопасности, в которой каждому дозволено tcpdump запускать и бинарники вне $HOME менять.

Слишком удобно для злобных дураков - тут это нафиг.

Перлопитоны с их доступным интерпретатором вообще очень удобны. Никаких buffer overflow не надо, только дырочку для eval'а.

У меня такая ситация может сложится что локалхоста не будет.

localhost есть всегда. Если только не embedded, куда твои перлопитоны не пролезут по вполне понятным причинам.

linuxfan
()
Ответ на: комментарий от linuxfan

> Ну при таком раскладе можно не мелочиться и смело подменять /bin/sh или /sbin/iptables/ifconfig/по желанию.

Сурово у тебя ifconfig лежит ;) И еще как директория запускается :)

Программа может стоять под каким то пользователем а не под рутом - это предполагается. Так что заменить системные может и не удастся.

Что очень ценно, как только полезут баги. Но вообще интересная у тебя система безопасности, в которой каждому дозволено tcpdump запускать и бинарники вне $HOME менять.


Каждому не дозволено. Но насчет того что unix socket позволяет закрыть к себе доступ правами unix, extended attibutes, etc ты мне так и не возразил. В отличие от tcp/ip где все это делает приложение и должно делать по уму, при каждом запросе.

И так же забыл что будет немного геморойно выяснять кто же шлет запрос - или вообще придется целиком полагаться на аутентификацию по паролю в ЛОКАЛЬНОМ ПРИЛОЖЕНИИ.

И порты надо будет захватывать с умом. Без race conditions.

Как раз сейчас в связи с этим думаю над STOMP. То есть всем почти хорош, только у меня внутри одной машины должно все быть, но с учетом того что юзеры могут быть разные, не все с правами.

Хотелось бы проверять uid процесса пославшего запрос. Если разработчики протокола об этом не думали - получается правка сервера :(

Перлопитоны с их доступным интерпретатором вообще очень удобны. Никаких buffer overflow не надо, только дырочку для eval'а.


Это вообще говоря полоразумевает что злобный человек будет читать код а не тупа запускать tcpdump

localhost есть всегда. Если только не embedded, куда твои перлопитоны не пролезут по вполне понятным причинам.


Явно не админ :) Локалхост поднимается скриптами :) - сокеты в ядре.

kernel ★★☆
() автор топика
Ответ на: комментарий от kernel

>Но насчет того что unix socket позволяет закрыть к себе доступ правами unix, extended attibutes

придется целиком полагаться на аутентификацию по паролю в ЛОКАЛЬНОМ ПРИЛОЖЕНИИ.

Ты сам-то хоть замечаешь, что сам себе противоречишь?

В отличие от tcp/ip где все это делает приложение и должно делать по уму, при каждом запросе.

В HTTP для этого, кстати, специальные заголовки запроса есть.

И порты надо будет захватывать с умом.

Еще раз: если ты биндишься к локалхосту, то ничего закрывать не надо.

Явно не админ :) Локалхост поднимается скриптами :)

Ну ты-то явно админ, раз собираешься локалхост от самого себя iptables'ами закрывать :D Про запуск tcpdump'а злоумышленником лучше даже не вспоминать.

linuxfan
()
Ответ на: комментарий от linuxfan

> Ты сам-то хоть замечаешь, что сам себе противоречишь?

Вторая фраза про tcp/ip первая про unix sockets. Где противоречие?

Тем более что я может неясно выразился, но в tcp/ip случае речь идет об упомянутом STOMP. Который держит «по паролю» но не держит «по uid»

В HTTP для этого, кстати, специальные заголовки запроса есть.


Есть. Но в любом случае их выставляют через механизмы парольной/криптографической аутентификации. Каковые подразумевают что юзеру нужно будет давать пароль/логин и делать поддержку этого в системе. В том месте где вполне, особенно в первых версиях , можно обойтись проверкой по uid. Если ты зашел по ssh под васей, значит ты вася и есть :) Как то так.

Еще раз: если ты биндишься к локалхосту, то ничего закрывать не надо.


Это ты про что? Про то что извне не зайдут? Ну да. Но юзеры то другие могут зайти с той же машины.

Явно не админ :) Локалхост поднимается скриптами :)


Ну ты-то явно админ, раз собираешься локалхост от самого себя iptables'ами закрывать :D


Я не знаю почему именно эта идея пришла тебе в голову , я об этом пока не думал ;) Но если подумать, то закрывать порт от другого пользователя на той же машине через iptables вполне возможно :)

Про запуск tcpdump'а злоумышленником лучше даже не вспоминать.


Я прекрасно понимаю бредовость, но сама идея tcp/ip для локальных приложений мне ПОЧЕМУТО :) не нравится. Уж не знаю почему. Админское чутье, ага ;)

kernel ★★☆
() автор топика
Ответ на: комментарий от kto_tama

> твистед + LineReceiver

Эээ , это же только под питон ?

kernel ★★☆
() автор топика

Короче скорее всего STOMP. У него есть, относительно задачи, некоторые мелкие недостатки, но достоинства (описанные в треде ) неоспоримы. Он тянет бинарные данные - по стандарту во всяком случае, хотя клиенты и имеют с этим проблемы.

Так что можно считать решенной проблему - хотя если еще будут идеи, кидайте! Я думаю что этот тред будет полезен всем юниксоидам еще вплотную не сталкивавшимся с подобной проблемой выбора.

kernel ★★☆
() автор топика
Ответ на: комментарий от kernel

Мда... А каким боком JSON привязан к веб-приложениям? А вот то, что парсеры есть под все языки - гарантировано. Да и как бы RFC стандарт. Собственно тебе рекомендовали JSON-RPC. Но велосипеды - это конечно правильнее.

anonymous
()

Я бы взял бинарный http://hessian.caucho.com/ , ибо официальные библиотеки под него есть под Java, Flash/Flex, Python, C++, .NET C#, D, Erlang, PHP, Ruby, Objective C... Так что можно взять готовое и не париться, как оно там внутри сделано.

Но если критична текстовость, то можно взять его менее известного XML-based родственника: http://www.caucho.com/resin-3.0/protocols/burlap.xtp

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Из бинарных - гугловский был ничего, protobuf кажется.

anonymous
()
Ответ на: комментарий от kernel

>Так что можно считать решенной проблему - хотя если еще будут идеи, кидайте! Я думаю что этот тред будет полезен всем юниксоидам еще вплотную не сталкивавшимся с подобной проблемой выбора.

есть еще zeromq2 оно не amqp но что-то близкое к нему, в применении довольно прост, есть биндинг на си, соответственно легко подружить с чем угодно, одна проблема, пока только альфа версия

cvb
()
Ответ на: комментарий от anonymous

> Мда... А каким боком JSON привязан к веб-приложениям?

Есть большая разница между «не-привязан в теории» и де-факто положением вещей. Посмотри насколько широко развит JSON для вебприложений, и на сколько для всего остального. В теории никак не привязан к вебприложениям, да. На практике для вебприложений у меня вообще пара строчек в коде, типо «хочу это через JSON» и все.

А на практике мне нужно собрать некий стек где внизу будет tcpip(со специальными требованиями)/unix_sockets потом STOMP (или чтото еще) а сверху прикладное, при чем иногда RPC(для которого вариантом является JSON-RPC, да, ТУТ ты прав. Но тут таким же вариантом будет SunRPC , ага).

И если такая штука есть готовая, ИЛИ есть способы как делают все остальные программисты для создания приложения из некой толпы демонов( причем без явы), то я хочу использовать этот способ. Что бы сделать пару вызовов функций и все. А не прикручивать парсер JSON к выбранному транспорту уровню.

А вот то, что парсеры есть под все языки - гарантировано. Да и как бы RFC стандарт. Собственно тебе рекомендовали JSON-RPC.


Мне рекомендовали без вникания в проблему, есть такое ощущение. Типа «засунь JSON-RPC в твою задницу, может поможет».

Но велосипеды - это конечно правильнее.


А еще правильней обоснованные мнения выдвигать, а не просто кинуть аббревиатурой.

Я против велосипедов, по этому и затеял тред. Но я скорее готов использовать чужой более подходящий велосипед, а не интернет стандарт.

kernel ★★☆
() автор топика
Ответ на: комментарий от KRoN73

> Я бы взял бинарный http://hessian.caucho.com/ , ибо официальные библиотеки под него есть под Java, Flash/Flex, Python, C++, .NET C#, D, Erlang, PHP, Ruby, Objective C... Так что можно взять готовое и не париться, как оно там внутри сделано.

О!

Но если критична текстовость, то можно взять его менее известного XML-based родственника: http://www.caucho.com/resin-3.0/protocols/burlap.xtp


Хм. Тоже добавил в список на изучение.

Текстовость не так критична, критична простота как самой технологии так и интерфейсов к ней. А еще хорошо бы без тяги к ява-ориентированности. Ну и bundle-ability.

Ты их использовал?

Чегото в hessian кстати с perl слабовато. А сервер там на чем, только яве? Или не нужен? А сервисы тоже все языковые биндинги держат?

kernel ★★☆
() автор топика
Ответ на: комментарий от kernel

>Ты их использовал?

Нет, только присматриваюсь.

Чегото в hessian кстати с perl слабовато. А сервер там на чем, только яве?


hessian - это протокол. Соответственно, ты просто пишешь пару программ - клиент и сервер. Библиотеки перечисленные имеют как клиентскую, так и серверную часть. Под Perl на офсайте, вроде, ничего нет, но раз под PHP написали, то под Perl переписать несложно будет :)

...

Впрочем, и нагугливается легко, скажем:
http://kobesearch.cpan.org/htdocs/Hessian-Client/Hessian/Client.html
и даже http://search.cpan.org/search?query=hessian&mode=all

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Нет, только присматриваюсь.

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

hessian - это протокол.


Да, я понял ;)

Соответственно, ты просто пишешь пару программ - клиент и сервер.


*просто* ;)

Хотя да, удобнее чем в STOMP где сервер сообщений(или как оно там, message broker) отдельно.

Библиотеки перечисленные имеют как клиентскую, так и серверную

часть. Под Perl на офсайте, вроде, ничего нет,



Да, это меня насторожило.

но раз под PHP написали, то под Perl переписать несложно будет :)


... переписать :)

Впрочем, и нагугливается легко, скажем:

http://kobesearch.cpan.org/htdocs/Hessian-Client/Hessian/Client.html


и даже http://search.cpan.org/search?query=hessian&mode=all


хотя, правда, сервер там не находится. Но есть



Я как раз погуглил и чегото не нашел сервера :(

сериалайзеры-десериалайзеры, от которых до сервера уже один шаг.

Принять пакет, скормить десериалайзеру, получить данные.



... и это просто, да ;)

kernel ★★☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.