polyakovyevgeniy: если возникают исключения, то логируйте их. В питоне есть замечательная библиотека logging. А уж по стектрейсу смотрите, что не так.
И да, это нормально, опрашивать один url. Можно с нескольких мест и очень-очень быстро, они для этого и созданы. А можно еще использовать long pooling технику, или websockets. Посмотрите примеры чатов на aiohttp, tornado или twisted/cyclone.io.
polyakovyevgeniy: ну, для ноды не скажу, а для питона - берете aiohttp или flask, вешаете сервер на localhost, и через json request-response гоняете все что захочется. Все есть в стандартных туториалах. В отличии от больших приложений, у вас просто крутится вебсервер на каком нибудь оригинальном порту типа 5577, принимает запросы от другого приложения. В питоне запросы можно посылать через requests, urllib2, aiohttp-client...
Увы, выбрали битрикс. Но это был выбор руководства.
Но теперь, после нескольких проектов на битрикс, я к нему подходить почти не хочу.
Новые проект сделали на flask. Теперь некоторые куски переводим на aiohttp.
База данных elasticsearch, именно как хранилище. В помошникхах redis, для счетчиков, корзинок, кешей и евего, что не жалко потерять и для скорости отдачи.
А битрикс редкостное говно, уж извините. Шаг влево-вправо, и в говне.
Павел Каптур: Ну, "глобальный класс" здесь совсем не нужен. А буферизицию лучше сделать через очередь сообщений. И эту ссылку на эту очередь передавать и в callback и в обработчик команд. В принципе это традиционная модель - consumer-producer. Если пишете на C++ с использование какого-то фреймворка, то наверняка уже есть готовые классы.
И "глобальный класс" обычно называется singleton. Но чтобы не делать именно один класс, обычно создают объект типа Context, и его передают во все нужные сущности. Единственное, позаботьтесь о синхронизации доступа через блокировки.
Павел Каптур: ну, если сообщения одинаковой длины, то просто читаем до ее достижения. Ну или пайпы вам не совсем подходят, или взять библиотеку типа zeromq и забить на пайпы. Они не для этого. Вообще-то в ipc есть еще shared memory и queue. Не то чтобы с ними удобнее, они есть как минимум. С ними проблема с переинициализацией. Ну или опять же zeromq и товарищи...
Павел Каптур: так я и спрашиваю как вы определяете количество! Код приведите. Скорее всего у вас не все помещается в буфер пайпа, ну и стандартно по возврату каретки буфер флашится.
Нет, переустановить ОС не совсем хороший выход, так как там куча всего установлено, и не хотелось бы рушить реестр.
Другими словами, образ диска с технологической установки, и нужно запустить ПО, желательно в неизменном виде.
Лчень желательно именно восстановить загрузку.
Ну и загрузочный раздел монтируется без ошибок.
Nube: Пожалуйста. Собственно я поэтому и говорил, что нужно взять некий протокол типа HTTP (в нетти он встроен), и уже через него гнать протобаф или джисон.
В принципе да, за одним но. Протокол обмена подразуменает немного большее, чем просто передача протобаф или json в сокет. И он как бы оборачивает ваш протокол сеарилизации в некую обертку, добавляя коды ответов, запросов, техническую информацию типа: размера сообщений, точкек запросов, типа сжатия, авторзацию и прочую мишуру, без которой в реальных приложениях не обойтись. А разрабатывать свой протокол, даже самый простой - реально дорого.
Другими словами, чтобы передать протобаф, хорошо бы передать также и размер сообщения, произвести авторизацию (и желательно с обеих сторон), а еще и предусмотреть коды ошибок, и несколько эндпоинтов (что-то типа адресации, кого и как вызываем)
А какие проблемы с http? Он же может работать на любом порту! Собственно это и есть сокеты, только уже с протоколом. Хотите, используюте websockets, хотите - json, или protobuf, или еще что. Вы просто не будете изобретать велосипед в виде протокола обмена, что поверьте, отъест у вас львиную долю времени! Да и инфраструктура модулей у вас уже будет, типа сервлетов. Ну и если уж деталь на яве, то смотрите в сторону netty. А если по простому, за 5 минут, берите легковесный jetty в качестве web-server.
Ну а я сейчас кошусь на goovy-lang.org и ratpack.io. Рекомендую присмотреться, оно вроде бы как и ява почти, с батарейками.
Нет, там проблема не в этом. Проблема в том, что можно бесконечно подставлять уже распознанную капчу!
Алгоритм такой:
1) забираем форму авторизации, на сервере генерируется session
2) забираем уже известную нам капчу с captcha_code, к которой мы просто глазками нашли captcha_word, сервер повторно генерирует запись в таблице для нашей старой капчи (при этом нам абсолютно все равно, какую капчу сгенерировал сервер при выдаче формы)
3) посылаем форму с нашим session и подменянными captcha_word и captcha_code
4) пользователь зарегистрирован, осталось сходить в почту и активировать аккауни
И да, это нормально, опрашивать один url. Можно с нескольких мест и очень-очень быстро, они для этого и созданы. А можно еще использовать long pooling технику, или websockets. Посмотрите примеры чатов на aiohttp, tornado или twisted/cyclone.io.