Как организовать Messenger реального времени?

Здравствуйте. Я хочу написать свой mesenger(хорошо бы мультипротокольный, но это потом). И у меня появилось несколько вопросов
1. Опыта разработки приложений реального времени абсолютно нет. Как они организованы? Все, что идет в голову это 2. Организация получения/отправки сообщений. Отправку и получение сообщений я знаю. Но как организовать это в приложении реального времени? У меня есть только 2 варианта(возможно оба неправильные )
а) На каждый протокол создать 2 нити(или потока по другому). Один на отправку, другой на получение. Как тогда организовать взаимодействие нитей с основной программой? Через сигналы?
б) В цикле программы просто поочередно получать/отправлять сообщения. Думаю, сообщения будут долго доходить.

0

Насколько я понял, речь идёт о чём-то вроде ICQ клиента. Если так, то есть пара замечаний:

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

Во-вторых, пользователь вряд-ли будет засекать разницу между отправкой и приёмом сообщения, а если и будет, то даже разницу в целую секунду вряд-ли заметит. А за секунду даже на мобильнике, можно много чего обработать.

В-третьих, клиент на то и клиент, что бы отправлять запросы, а сервер на то и сервер, что бы на них отвечать.

Поэтому, даже при необходимости обновления истории сообщений в режиме реального времени, Вам достаточно завести таймер примерно на 50-500 мс (можно даже сделать такую настройку) и с соответствующей периодичностью отправлять запросы на сервер "А нет ли там новых сообщений". Геморроя куда меньше, а пользователь задержку в полсекунды всё равно не заметит.



PS: И ещё одна личная просьба: "Пожалуйста, не пихайте слипы куда попало, для этого ведь есть таймеры".

0

Я правильно все понял? Вместо цикла со sleep использовать повторяющийся сигнал alarm и поочередно получать/отправлять сообщения без нитей.
Чем вариант с нитями плох?

0

hVoltage, откройте любую книжку по разработке сетевых приложений и посмотрите как реализуется клиент-серверное взаимодействие. Хинт: сокеты, select, poll/epoll.

0

Всё зависит от требуемого времени отклика и трудоёмкости реализации. Сделать таймер с калбеком куда проще, чем синхронизировать все ваши потоки (тем более если на отправку и приём каждого протокола заводить отдельный поток). А вот результат (для данной конкретной задачи) будет одинаковый. Вот если бы Вы писали не клиент, а сервер, то, при ожидании большой вычислительной нагрузки, создание разных потоков имело бы смысл, так как всем клиентам нужно ответить поскорее. Но даже в таком случае нужно понимать, что:

* При количестве потоков равном количеству ядер ЦП Вы достигнете максимально возможной производительности.
* При количестве потоков вдвое больше количества ядер ЦП, скорее всего, мало что изманится.
* А вот при дальнейшем увеличении количества потоков Вы получите экспоненциальное снижение производительности из-за того, что процессор слишком часто будет менять контекст, создавая избыточную нагрузку на ОЗУ (которая работает на порядок медленнее ЦП).

0

Понятно. Слишком большой труд ради небольшой производительности.

А вот при дальнейшем увеличении количества потоков Вы получите экспоненциальное снижение производительности из-за того, что процессор слишком часто будет менять контекст, создавая избыточную нагрузку на ОЗУ (которая работает на порядок медленнее ЦП).

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

Никак не могу понять про какой таймер вы говорите.

0

В ЦП есть встроенные таймеры, которые можно и из ассемблера вызвать, но не нужно, так как у них полно высокоуровневых обёрток, в том числе и в C++.

Сообщение от hVoltage При переключении между потоками в рамках одного процесса, контекст не меняется

В процессоре куча регистров, кэш 1 уровня, конвейер команд, которые приходится перезагружать даже при смене потока, из-за чего происходят такие вещи как кэш-промахи и сброс конвейера команд (о смене процесса я вообще не говорю - это катастрофа для производительности). Поймите: все ваши выражения типа a = b + c и прочие операторы в ассемблере превращаются в операции с регистрами. Соответственно, даже для разных потоков в рамках одного процесса они разные и их нужно куда-то сгружать. С кэшем и командами примерно то-же. Плюс не забывайте, что ОЗУ медленнее ЦП и вся система работает слаженно только при условии, что заранее известно какие данные нужно загрузить из ОЗУ в кэш. Если Вы, вдруг, переключаетесь на другой поток, то вам нужны уже другие данные, а те, которые уже загружены в кэш не нужны.

Добавлено через 7 минут
Я имею ввиду те таймеры, которые спустя некоторое время вызывают калбек функцию. Если они реализованы за счет встроенных системных таймеров, то работать будут быстрее и, в отличие от слипа, не будут вешать поток на период ожидания. Сам я пишу на Qt поэтому сайчас так сходу не могу найти аналоги из стандартной библиотеки C++, но они там точно есть.

0

В процессоре куча регистров, кэш 1 уровня, конвейер команд...

Знал, что смена регистров и прочего занимает время, но не знал, чтобы настолько.

Sigalrm, думаю, подойдет как таймер.

Не совсем понял на счет слипа. Что значит, что встроенные таймеры не вешают поток?

0

Слип останавливает поток на время, а таймеры с калбеком нет. После слипа программа продолжит выполнение с того же места. А по прерыванию таймера вызовется функция, адрес которой Вы, скорее всего, передали таймеру во время настройки.
Смена контекста потока занимает не так уж и много времени, но если потоков уж очень много наплодить (не забывайте, что Ваш процесс в системе не единственный) то не сложно добиться ситуации в которой время на переключение больше времени выполнения полезных действий.
И ещё пара ситуаций из моей практики, когда я хотел убить человека за слипы в коде:

1) пару раз встречал программы, которые капитально вешались при открытии файла, к которому нет доступа. Вместо того, что бы завести таймер и раз в 10 секунд проверять доступность файла, некоторые программисты ставят sleep(10000), что капитально вешает программу до тех пор, пока она не получит таки свой файл. в то же время, если сделать это с помощью таймеров, то пока таймер считает, события пользовательского интерфейса нормально отрабатываются.

2) Как то раз видел самодельный сервер БД, которые запускал sleep(100) когда ему было нечего делать. Соответственно повесить такую БД простейшей DDos атакой было проще простого.

3) есть ещё куча историй, но мне надо уезжать, так что в следующий раз расскажу.

1

Точно. Совсем забыл, что пользователь еще и сообщения будет вводить. Sigalrm самое оно, действительно.

Спасибо, что разъяснили.

0

hVoltage, не надо слипов. И про таймеры пока подожди (но не откладывай, пригодятся). Сперва посмотри на функции select\poll\epoll (POSIX), WaitFor<Single\Multiple>Object (Win32API), на condition variable и по смежным ссылкам. Можно начать отсюда. Или отсюда. Потом сюда. Или сюда.

Добавлено через 2 минуты
Особенно хорошо расписано зачем это нужно и как применяется в мане по select. Даже если не используется unix, все равно рекомендую прочитать его целиком. Должно многое встать на места.

1