Russian Qt Forum
Июнь 17, 2024, 22:32 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Russian Qt Forum > Forum > Qt > Работа с сетью > Необходимость нового потока для очередно
Страниц: [1] 2 3   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: Необходимость нового потока для очередно  (Прочитано 18597 раз)
brucemax
Гость
« : Декабрь 14, 2012, 10:58 »
Здравствуйте! Программа создаёт набор подключений (сокетов..  около 10)  для обмена инфой с другими устройствами.  Насколько важно создавать отдельный поток для каждого подключения (сокета)?  Первая мысль, что это зависит от тяжести операция при обмене данными..  тогда как судить об этой тяжести..  хватит ли одного потока для всех подключений..?  или не мучиться с вопросом "хватит/не хватит"  и сразу делать многопоточную архитектуру!?!  Непонимающий
Записан
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #1 : Декабрь 14, 2012, 11:57 »
А что за обмен? На сколько интенсивен?
Записан
1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
brucemax
Гость
« Ответ #2 : Декабрь 14, 2012, 12:26 »
Цитата: Пантер от Декабрь 14, 2012,  11:57
А что за обмен? На сколько интенсивен?
Tcp.. Инфа о состоянии тех устройств к которым подключаемся.. их мониторинг плюс небольшое управление (команды).  Точно пока не смогу сказать насколько часто посылки буду осуществляться..  возможно около раза в пол секунды для одного подключения.. хотя в будущем возможно и чаще.
Записан
Bepec
Гость
« Ответ #3 : Декабрь 14, 2012, 12:36 »
Ыыы... раз  в 500 мс. пстц. Я тут за 20 мс борюсь на приём/ответ/обработку, а они... эхх... многопоточная архитектура...
Записан
brucemax
Гость
« Ответ #4 : Декабрь 14, 2012, 12:53 »
Цитата: Bepec от Декабрь 14, 2012,  12:36
Ыыы... раз  в 500 мс. пстц. Я тут за 20 мс борюсь на приём/ответ/обработку, а они... эхх... многопоточная архитектура...
Наверное это я погорячился..  будет чаще. Мне б просто эту грань научиться видеть..  многопоточная/немногопоточная..
Записан
Bepec
Гость
« Ответ #5 : Декабрь 14, 2012, 13:00 »
Мну раз в 20 мс приходят уходят. Нужды в многопоточности не вижу. (1 поток гуи, 1 поток работа, чтоб гуи не застывало).
Записан
brucemax
Гость
« Ответ #6 : Декабрь 14, 2012, 13:18 »
Цитата: Bepec от Декабрь 14, 2012,  13:00
Мну раз в 20 мс приходят уходят. Нужды в многопоточности не вижу. (1 поток гуи, 1 поток работа, чтоб гуи не застывало).
А вдруг потом заказчику что в голову стукнет  и он скажет "а давайка ещё сообщения об этом и об этом впихнём!!" и придётся переделывать всё архитектуру. 
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #7 : Декабрь 14, 2012, 13:26 »
Цитата: brucemax от Декабрь 14, 2012,  10:58
Насколько важно создавать отдельный поток для каждого подключения (сокета)? 
Это также перетиралось здесь много раз, общий вывод: эта схема не годится для высоко нагруженных серверов, хотя и удобна/проста в реализации
Записан
Bepec
Гость
« Ответ #8 : Декабрь 14, 2012, 13:28 »
Я те по секрету скажу - у меня примерно 8 линий по 120 устройств Веселый
И протокол собственный разработанный. И он позволяет обеспечивать работу их всех с приёмлимой задержкой.
А уж места под "развёртывание" у него дохренища. Ещё ровно 4 мс есть под новый функционал Веселый

Хотя у меня чуть иная ситуация, у меня RS-485 линии + коммутаторы. Быстродействие требуется максимальное.

PS а вот у тебя меньше 50 устройств планируется. Вот и не мучайся.

PPS вот только у меня организация. Веселый
Записан
brucemax
Гость
« Ответ #9 : Декабрь 14, 2012, 16:11 »
Цитата: Bepec от Декабрь 14, 2012,  13:28
Я те по секрету скажу - у меня примерно 8 линий по 120 устройств Веселый
И протокол собственный разработанный. И он позволяет обеспечивать работу их всех с приёмлимой задержкой.
А уж места под "развёртывание" у него дохренища. Ещё ровно 4 мс есть под новый функционал Веселый

Хотя у меня чуть иная ситуация, у меня RS-485 линии + коммутаторы. Быстродействие требуется максимальное.

PS а вот у тебя меньше 50 устройств планируется. Вот и не мучайся.

PPS вот только у меня организация. Веселый
Солидно =)  А можете с архитектурой подсказать.. так как опыта в этом у меня совсем мало..  вот думаю, что будет класс описывающий само утройство: допустим CDevice (до 10 экземпляров), который для создания подключения обращается к классу отвечающему за сетевые подключения CNetworkProvider(наверно целесообразно сделать его cинглтоном), который и будет хранить в себе  объекты подключения (сокеты, или объекты отвечающие за сокеты и содержащие их: CTcpConnection) которые будут привязаны сигналами каждый к своему экземпляру CDevice.  Теперь..  CNetworkProvider стартует в себе новый поток куда впоследствии и отправляются методом moveToThread()  созданные подключения (сокеты или объекты CTcpConnection).   
Вообщем стоит ли дальше развивать такую архитектуру или это совсем бредовые мысли?))  Может пример на эту тему есть!?  Направьте на путь истинный пожалуйста..  Улыбающийся
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #10 : Декабрь 14, 2012, 16:40 »
Цитата: Bepec от Декабрь 14, 2012,  13:28
Я те по секрету скажу - у меня примерно 8 линий по 120 устройств Веселый
Не стоит красоваться "голым числом"  Улыбающийся Напр 100 линий по 1000 устройств могут быть относительно легкой задачей. И наоборот, всего 5 линий всего по 10 - очень трудной. Все зависит от того что считать "приемлЕмой задержкой"
Записан
Fregloin
Супер
******
Offline Offline

Сообщений: 1025


Просмотр профиля
« Ответ #11 : Декабрь 14, 2012, 16:44 »
Попробуй пул потоков, может это то что нужно для тебя?
Записан
brucemax
Гость
« Ответ #12 : Декабрь 14, 2012, 16:58 »
Цитата: Fregloin от Декабрь 14, 2012,  16:44
Попробуй пул потоков, может это то что нужно для тебя?
Да я как-то изучал этот пул с его QRunnable.. да в чём-то облегчает жизнь, но всё-таки решил пользоваться QThread.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #13 : Декабрь 14, 2012, 17:31 »
Цитата: brucemax от Декабрь 14, 2012,  16:11
Вообщем стоит ли дальше развивать такую архитектуру или это совсем бредовые мысли?))  Может пример на эту тему есть!?  Направьте на путь истинный пожалуйста..  Улыбающийся
А с чего Вы взяли что такой путь есть вообще? Улыбающийся Все зависит от конкретной задачи, только простые/типовые сводятся к переписанному и (кое-как) измененному примеру, остальные требуют мЫшления и самостоятельных решений. Это кому нравится, кому нет.

С точки зрения многопоточности "идеальная архитектура" давно известна. Число ниток = числу ядер + 1. Однако мало кто горит желанием делать "идеальную", т.к. обычно это сводится к выделению независимых подзадач которые могут быть скормлены любой их рабочих ниток. Это очень трудно и составляет 90% работы.

Поэтому часто идут на упрощения, напр/типа 1 коннект = 1 нитка. Да, это конечно "до определенного предела" - дальше все время ОС будет тратить на переключения между нитками. Но до того это будет работать вполне хорошо - и это сократит время разработки во много (может в десятки) раз. Отсюда и рекомендации типа "да не парься" - они имеют реальный, практический смысл.
Записан
Bepec
Гость
« Ответ #14 : Декабрь 14, 2012, 17:36 »
Я бы посоветовал, да незнаю задачи и устройств Улыбающийся У меня к примеру охранка.Там скорость обработки важна + наивысший приоритет тревог. А у тебя я незнаю что Улыбающийся


to Igors:
Ну дай, ну дай мне похвастаться Веселый Я может быть ради этого момента на форуме регистрировался Веселый

PS и вообще мы на OPC переходим. Хоть и дороговат, но от головной боли по проектированию избавляет.
Записан
Страниц: [1] 2 3   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


Страница сгенерирована за 0.054 секунд. Запросов: 22.