Pull to refresh

Comments 9

Выглядит интересно, сразу появляются вопросы:
На сколько быстро это работает?
Может ли быть рассинхронизация реплик? Какая стратегия при потере соединения, можно ли отследить?
Что с многопоточностью? Вся работа через слот-сигналы (и соответственно механизмы работы с потоками ими обусловленными), или есть прямые вызовы?
Вопросы интересные. Но к сожалению на большинство из них я не смогу вам ответить.

Замеров быстродействия не выполнял. Наверное быстродействие в первую очередь будет зависеть от того, насколько быстро работает транспорт, например именованный канал или TCP сокет.

По поводу рассинхронизации реплик — она однозначно может наступить, если соединение потеряно и реплика становится обособленной. Какого либо сигнала (на подобии disconnected) я не обнаружил — только метод isReplicaValid). В том месте, где обрабатываются ошибки QTcpSocket находится вот такой код:
    case QAbstractSocket::ConnectionRefusedError:
        //... TODO error reporting

что наталкивает на мысль, то никакой стратегии (как и обработки ошибки потери соединения) пока нет. В перечне дальнейших возможных улучшений модуля автором указан пункт «Record and replay». Что это такое, пока непонятно. Если будет записываться история изменения состояний объекта, чтобы эти изменения потом можно было воспроизвести в репликах, то возникают дополнительные вопросы, связанные, например, с тем, что реплика может менять состояние источника в ответ на входящие сигналы.

По поводу многопоточности — объекты взаимодействуют либо посредством QLocalSocket (named pipe в Windows и local domain socket в *nix) или с помощью QTcpSocket. Ну а взаимодействие с самим QObject со стороны кода приложения выполняется стандартными сигналами/слотами.
> Модуль создан в недрах Ford Motor Company

Энтепрайзным программистам даже стеклянный хрен давать нельзя: они и из него корбу замутят.
Это лучший комментарий всех времён на Хабрахабре. При прочтении статьи меня прямо не оставляла мысль о том, что «где-то я это уже видел» :)
Блин, не заметил Ваш комментарий сперва. Залез в исходники, посмотрел как все это работает… moc доведенный до корбы)
А мне CORBA напомнило. С той же необходимостью генерации файлов протокола.
А чем это лучше классического клиент-сервера? Ну или хотя бы связи через AMQP/ZeroMQ?
Хм… только наткнулся на данный топик.
Недавно делал одно тестовое задание, вкратце — синхронизация ui элементов Qt'шных окон, комбобоксов, всплывающих окон, текста, диалогов. Сделал за два дня, точнее два вечера заняло. Ограничился одним сервером и одним в данное время подключением клиента. Сделал даже очередь изменений в случае когда теряется связь с «сервером», а клиент в этом время изменяет состояние ui элементов. После подключения по очереди посылаются все состояния, тут конечно нужно было добавить фильтрацию однообразных, например, когда изменяется состояние одного и того же комбобокса, не имеет смысла хранить предыдущее состояние, так же как и открытие и закрытие диалоговых окон. Собственно, в коде добавил себе «TODO» на это и прекрасно о нем забыл, так и отправил тестовое.
А передавал я названия слотов ui элементов(Q_FUNC_INFO), после чего сервер получивший данные вызывал соответствующий метод у объекта описывающего ui по средством QMetaObjject->invoke(). Не скажу что эта была эффективная реализация, это было второе что пришло мне в голову, и показалось достаточно простым для тестового задания.

Уже на собеседовании обсуждались детали этого тестового и как бы я поступил в случае возможности синхронизировать одновременно несколько клиентов: очередность, выбор состоянии клиента чье изменение пришло позже в заданный промежуток времени… etc.
В принципе, если оказалось бы что на этой фирме нет никакой собственной реализации данной проблемы(синхронизации ui или чего другого) то подумывал потихоньку развить это тестовое в либу и выложить на гитхаб. А так — жду письма или звонка от них.

А тут вот оно что, в Qt'шных репах оказывается уже давно имеется свой вариант.
Sign up to leave a comment.

Articles