Pull to refresh
9.7
Karma
0
Rating

Пользователь

  • Followers 1
  • Following 2

I2P over Yggdrasil: анонимность в меш-сетях

Подскажите, позволяет ли Yggdrasil / cjdns сделать VPN? Допустим, у меня друг в другой стране, и я и хочу иногда обходить баны, можно ли частичный роутинг для забанненыных ресурсов сделать через него? (Сейчас используется tinc, но он сложноват в настройке)

Знакомство с EXtensible Server Core (exsc)

Я бы сказал, что это фреймворк, а не библиотека, т.к. вы запускаете серверный поток, который, как я понял, создаёт (!) отдельные треды для подключенных клиентов, а на них уже будут выполняться клиентский код (типа exsc_recv).


Т.о. на тредах, которые не создавал пользователь, выполняется пользовательский код. Это фреймворк, больше ).

Порт GUI фреймворка с Python на Go. Анализ граблей и плюшек

Не совсем понятно — это нативный GUI или веб?

Обзор последних изменений в rotor'е (v0.10… v0.14)

Спасибо за добрые слова!


rotor ещё не настолько battle-proven как sobjectizer, но я сравниваю с ним, т.к. он ближе всего, по сравнению с тем же caf'ом, а всё познаётся в сравнении.

Не хочется ждать в очереди? Напишем свой диспетчер для SObjectizer с приоритетной доставкой

Так что, как только возникают приоритеты, то мы практически сразу начинаем говорить о каких-то специальных ситуациях. ИМХО.

Тут я полностью согласен.


Часть этих заявок идут от клиентов, которые прямо сейчас находятся в он-лайне, а часть заявок выдается какой-то системой по расписанию.

Хороший пример. В данном случае "приоретизация" сообщий от онлайн-клиентов — это скорее техническое решение "как?" более общей постановки вопроса, что "запросы от онлайн-клиентов должны, по возможности, обрабатываться раньше, чем от офлайн-автоматики".


Чисто акторное тоже техническое решение, которое напрашивается, это актор-сортировщик, к которому стекаются все заявки, а он уже внутри себя раздаёт их на обработку: если есть онлайн-заяки, отдаём на обработку их, иначе — офлайн.

Не хочется ждать в очереди? Напишем свой диспетчер для SObjectizer с приоритетной доставкой

И нам бы хотелось, чтобы когда в очереди уже стоит 900 сообщений msg_status новое сообщение msg_result вставало не в конец очереди, а в самое ее начало.

Насколько это корретно в общем случае? Нарушается последовательность событий, и событие msg_result произойдёт "в будущем" относительно msg_progress "в прошлом", но порядок получения событий не соотвествует (как я понимаю) порядку их возникновения.


Я могу себе представить пример, когда msg_progress уже неважны после получения msg_result и по сути отбрасываются приёмником. Но тогда, msg_result имеет ещё и семантику отмены (cancellation) предыдущих сообщений.


Есть ли пример, когда это не выполняется, т.е. когда msg_progress всё ещё важны, даже после получения msg_result ?

Open Book: проект по сборке свободного eReader с паяльником в руках

Автор молодец, респект! Но я вот больше всё с телефона читаю: удобней, маленький, рука меньше устаёт, когда в постели читаешь, ночью подсвечивает и т.п.

Ричард Столлман и будущее инноваций в ПО

Не вижу экономических стимулов для корпораций переходить на такую модель. Власть = деньги, в данном случае; предлагается поделиться "властью" (информацией), и, следовательно, потерять деньги.


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


Ну и технический вопрос: как мерж отрытых состояний будет делаться? Как будут конфликты разрешаться? Имхо, это нетривиальная задача, и возложить её на пользователя… ну такое.

Про пользу E2E тестирования

Поясните, пожалуйста, как E2E расшифровывается?

DeFi — обзор рынка: скамы, цифры, факты, перспективы

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

DeFi — обзор рынка: скамы, цифры, факты, перспективы

Так в чём проблема написать "DeFi — это блокчейн"? сразу всем понятно о чём речь.


А когда пишут на картинке "DeFi — это вам не ICO", это отрицательное опредение, т.к. из тезиса "ABC — не DEF", ничего непотяно, что такое ABC.

DeFi — обзор рынка: скамы, цифры, факты, перспективы

Почитал первые несколько первых и последних абзацев и не понял. Нету предложения "Defi — это ..."

What's new in rotor v0.09

Thanks a lot for explanation. I have published the update to the article, fixing sobjectizer related corrections, based on your comments. The Russian version of the article will be published with fixed information.


I completely agree with your statements.


The underlying reason for rotor that it's initialization and shutdown phases where asynchronous since the beginning, because subscription to addresses was made as messaging too, which is non-atomic; especially if address belongs to to different threads/event loops. I consider this as on of the rotor features, however if you don't need it it brings unneeded complexity, and then better to use sobjectizer :)

What's new in rotor v0.09

Agents in SObjectizer also have I- and S-phases.

I think there is some misunderstanding… The so_evt_start in sobjectizer (and on_start in rotor) are not designed to be part of the initialization, instead, the method purpose it to let agent (actor) play trigger some activity, e.g. request something or do some I/O. Otherwise, without the methods, as actors are passive/reactive by their nature, there will be nobody to initiate activity.


So, the so_define_agent is the only proper location for initialization and resources acquisition. However, since so_define_agent and so_evt_start they are passive (from the agent perspective, as they are called outside) — they are just a lifetime callbacks, not phases.


Let me give an abstract example, what I mean:


struct actor_t {
    void on_init() { ... }
    void on_start() { ... }
}

Here is the on_init method. After it the actor is either initialized or not, is has no chance to do "long" (aka asynchonous) initialization. This is because it is simple callback, not a phase/process. Any resources, if needed, can be acquired synchously only. Contrary, the following actor:


struct actor_async_t {
    void on_start() { ... }
    void on_init(init_token_t t) {
        ...; // subscribe to messages or trigger I/O on event loop
        token = t;
    }

    void on_message_or_event_loop_event(...) {
        token.init_complete();
    }

    void on_other_message_or_fail_event_loop_event(...) {
        token.init_fail(error_code);
    }`

    init_token_t token;
}

After on_init the asynс actor is still initializing, and might postpones the initialization decision, until it gets the whole picture (i.e. until it receives enough messages/events to make init-decision).


Here is a more concrete example: I'm writing torrent-like client. There is a protocol: the client should announce self in the remote server, before searching other peers. The announce message contains public endpoint (i.e. reacheable IP:port pair, which must be previously opened on the router via UPNP-protocol).


Using the init-phase it could be done as following. The communiactor_actor (which announces self and searches for other peers), during initialization phase discovers and links to upnp_actor (alternative: it can spawn & link to upnp_actor), and then makes an request for the public endpoint to the upnp_actor. The upnp_actor actually makes an HTTP-request, receives HTTP-response, parses it and replies back to the communiactor_actor. If everything is OK, communiactor_actor announces self, and only then completes its initialization (and then can be asked for searching peers). The entire process is async and non-blocking.


In the reality, there might be a few other layers of indirection, like adding resolver_actor and http_actor, which also participate in the I-phase of upnp_actor. So, I-phase is scalable in that sense; as well as you can see it is a process, not a single callback invokation.


I really don't know how to achieve that with the simple actor lifetime callbacks. The only way I see it to do in so_define_agent() is drop actors layering/communication (because it is not part of the Environment), and do HTTP-request, synchronously (including resolving and connecting), and synchronously wait for HTTP-response.


That's why in the article it is told, that shutdowner in sobjectizer mimics the S-phase in rotor, because it is "long lasting" and not a simple callback.

What's new in rotor v0.09

Yes, you correctly catch the issue and the solution about virtual linking. However, usage pattern is slightly wrong, as there is no need of direct shipping of reply_to in the messages (it is indirectly included if request/response pattern is used.) For regular messages it would look like;


namespace payload {
struct do_something_t { ... };
}

namespace message {
using do_something_t = rotor::message_t<payload::do_something_t>;
}

struct client_actor_t {
   void configure(...) {
        // discover and link to server;  
   } 

  void on_start() {
     // safe to do as it is already linked to server
     send<payload:: do_something_t>(server, ...);
  }

  rotor::address_ptr_t server;
};

struct server_actor_t {
  void configure(...) {
      // register self in a registry and subscribe
  }

  void on_do_something(message::do_something_t) {
      ...;
  }
};

In the case of request/response it will be changed a litte bit:


namespace payload {
struct request_t { ... };
struct response_t { ... };
}

namespace message {
using request_t = rotor::request_traits_t<payload::request_t>::request::message_t;
using response_t = rotor::request_traits_t<payload::response_t>::response::message_t;
}

struct client_actor_t {
   void configure(...) {
        // discover and link to server;  subscribe
   } 

  void on_start() {
     // safe to do as it is already linked to server
     request<payload::request_t>(server, ...).send(timeout);
  }

  void on_response(message::response_t) {
    ...
  }

  rotor::address_ptr_t server;
};

struct server_actor_t {
  void configure(...) {
      // register self in a registry and subscribe
  }

  void on_request(message::request_t& req) {
    ...;
    // usually it is safe to reply
    reply(req, ...);
  }
;}

What's new in rotor v0.09

While it is not documented how to allow user write own plugins, it is supposed that a user will use the shipped plugins, e.g. as in the example below:


resources->acquire(resource::db_connection);

You are right in the sense, that it is part of actor API, and not of it's underlying implementation (plugin API).

What's new in rotor v0.09

The Russian version of the article is coming, so, I'll add to it missing pictures, thanks for the advice.


Let me answer the 2nd question here. The abstract answer to the question "What is a plugin", is: actor is a behavioral aspect of an actor, i.e. how actor reacts on particular message (or group of related messages), may be exposing some convenient API for sending messages.


It's better to give a few examples of build-in plugins: The address_maker plugin is a shortcut for asking actor's supervisor for creating a new address; the init_shutdown plugin does proper actor housekeeping on init and shutdown requests (messages); the child_manager is a supervisor-specific plugin, which allows to spawn child-actors, as well as reacts on their init- and shutdown- responses.


Can a user write its own plugin? Yes, but from my experience there is no need of that, as the resources_plugin covers actor with external event-loop interactions, and all other plugins are quite rotor-internals specific. There is a nuance, when you'd like to inspect messages flow, and the build-in messages dumper is not OK for your (e.g. you'd like to enable messages traffic only for a specific supervisor, or add your own filtering logic or decorations for your custom messages) — in that case, you'd need to write a plugin (and own supervisor, and insert it there). Again, this is depths of the rotor, and currently, I'd tend to view plugin system is not a public API, hence, it is not documented.


Yes, please, clarify sobjectizer related parts… I'll update the current article as well as the planed Russian one. I think it would be valuable for users of the both — of sobjectizer and rotor.

Поиск линии корешка на фотографиях книжных разворотов

Расскажите, пожалуйста, как восстанавливать (реконструировать) параграфы из отдельных слов.

Information

Rating
Does not participate
Works in
Registered
Activity