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

HTTP

JSON

AMQP?

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

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

> AMQP?

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

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

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

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

Вообще не в кассу. Будет hurd of daemons , причем локально, а не веб приложение.

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

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

>боеев

s/боеев/более в/

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

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

2. XML порицаю.

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

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

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

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

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

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

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

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

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

XML != human-readable.

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

Ну или RPC какой-нибудь. Например JSON-RPC.

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

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

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

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

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

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.

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

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

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

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

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

s-expression

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Ну при таком раскладе можно не мелочиться и смело подменять /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, куда твои перлопитоны не пролезут по вполне понятным причинам.

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

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

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

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

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

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

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

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

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

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

IRC, STOMP.

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

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

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

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

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

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

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

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

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

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

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

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

твистед + LineReceiver

> твистед + LineReceiver

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

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

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

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

Я бы взял бинарный 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

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

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

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

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

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

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

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

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

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

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

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

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

> Я бы взял бинарный 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 слабовато. А сервер там на чем, только яве? Или не нужен? А сервисы тоже все языковые биндинги держат?

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

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

Чегото в 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

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

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

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

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

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

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

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

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

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