QTcpSocket несколько клиентов

@Algamon · Регистрация: 21.06.2013

Author24 — интернет-сервис помощи студентам

Имеется сервер к нему подключаются клиенты, проводят какой-то обмен информацией и отключаются. Сервер просто слушает порт (server->listen(QHostAddress::Any, 3333)), а клиенты используют connectionToHost и disconnecionFromHost. Собственно вопрос такой - когда подключаются одновременно несколько клиентов, что будет происходить? Будет ли сервер сам создавать очередь из клиентов, а клиенты ждать когда сервер закончит общение с одним клиентом и перейдет к следующему? Или при попытке подключиться к занятому хосту, будет ошибка? А если будет ошибка, как тогда самому организовать очередь?

@~~Digital_Cry~~ · 28.12.2017, 15:37

У тебя QTcpServer испускает сигнал incomingConnection во время подключения клиента, функцией nextPendingConnection ты получаешь сокет этого клиента, подключаешь этот сокет к чему нужно и возвращаешься из функци. Лагов быть не должно, пока ты работаешь с малым кол-вом клиентов, но их кол-во тебе никто не ограничевает и клиент всё равно сможет подключится и при новом подключение прилетит incomingConnection. Но обычно, каждого клиента обрабатывают в отдельном потоке, что бы загрузить все ядра серверного CPU, то есть каждый новый сокет кидают в новый поток и там с ним работают. Вот тут посмотри видео урок, он старый, но суть я думаю поймёшь

@Algamon · 28.12.2017, 16:16 **[ТС]**

Хорошо, а если у меня сервер работает с БД? Повесить мьютексов, семафоров? Клиент не будет отпадать не дождавшись ответа?

@Avazart · 28.12.2017, 16:24

Сообщение от Algamon

Хорошо, а если у меня сервер работает с БД? Повесить мьютексов, семафоров? Клиент не будет отпадать не дождавшись ответа?

Если ставить мютексы, то от многопоточности толку будет 0.

Для бд в каждом потоке нужно будет создавать свои экземпляры классов БД.
Успешность работы этого будет зависеть от БД, от длительности обработки запросов и самих запросов.

Очевидно что если клиенты одновременно будут обращаться к одним одним и тем же данным в БД, БД будет отшивать.

@Algamon · 28.12.2017, 16:29 **[ТС]**

Сообщение от Avazart

Очевидно что если будете одновременно обращаться к одним одним и тем же данным в БД, БД будет отшивать.

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

@Avazart · 28.12.2017, 16:37

Нужно понимать характер нагрузки, и исходить из этого.
Много потоков тоже нет смысла плодить, лучше использовать пул из N потоков.

@Algamon · 28.12.2017, 17:20 **[ТС]**

Сообщение от Avazart

Нужно понимать характер нагрузки, и исходить из этого.

Ну много клиентов ~50 которые время от времени бомбят сервер короткими запросами. При этом желательно, чтобы запросы долго не висели. Доступ к базе данных должен быть постедователен, т.к. клиенты пользуются одними и теми же данными и изменяют их.

@Avazart · 28.12.2017, 17:32

Да в таком случае нет смысла делать в потоках.

@~~Digital_Cry~~ · 28.12.2017, 18:14

Avazart, ты как знаток сетей, сажи такую вещь, вот если я в 100 сокетов в цикле write-ом залью по 100 мегабайт, эти сокеты будут проц грузить на 100 процентов, отсылая кусочками память на клиенты? Ну то есть как в винде на уровне ядра это организованно? На сервере один поток, я в нём в цикле заливаю во сто сокетов по 100 мегабайт в каждый. Это относительно быстро, намного быстрее, чем всё это отошлётся. Но как это будет отсылаться и что при этом вообще будет нагружено? По идее, драйвер должен грузить только сеть, а проц не особо, т.к. потоков всего 100 или нет?

@peter_irich · 28.12.2017, 20:46

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

Пётр.

@Avazart · 28.12.2017, 21:14

Сообщение от Digital_Cry

эти сокеты будут проц грузить на 100 процентов,

Да но скорее всего эти 100% будут только на одном ядре.

Если поток один то один клиент будет получать данные, другие же будут либо ждать либо идти лесом ... в зависимости от протокола.

@~~Digital_Cry~~ · 28.12.2017, 22:01

Сообщение от Avazart

Да но скорее всего эти 100% будут только на одном ядре.

Хмм... Но ведь сокет, это ж по идее просто блок памяти, то есть mamory mapped file так сказать, то есть допустим у тебя 100 сокетов, пусть даже ты в них пишешь в одном потоке, ты просто в разные участки памяти (хз ядра ОС наверное, или на уровне приложения) просто заливаешь данные, а уже ядро ОС как-то, зная что вон те то участки памяти - под сокеты, должна оттуда память стягивать и отсылать клиентам MTU пакетами... То есть фактические, тебе главное в память сокетов что-то залить, а ОС сама должна уже разбираться, как всё это передать, используя много ядер или одно (сетевая карта то как правило одна) ... Эх... тестилку что-ли накатать...

@Avazart · 28.12.2017, 22:07

Какая разница, что бы залить в сокет данные их нужно откуда то взять... это тоже работа.

@~~Digital_Cry~~ · 28.12.2017, 22:18

Сообщение от Avazart

Какая разница, что бы залить в сокет данные их нужно откуда то взять... это тоже работа.

Не, это-то понятно, но допустим, заливка данный в сокеты занимает намного меньше времени, нежели отправлять все эти данные со всех сокетов по сети, допустим 300 соектов, в каждый заливается по 1 мегабайту в цикле.
Вот, после того, как ты их залил туда, отсылаться оттуда они будут задействуя все ядра или же по одному, т.к. заливал ты их в одном потоке?

@Avazart · 28.12.2017, 22:20

В данном случае речь шла про БД так что тут совсем другая ситуация.

Сообщение от Digital_Cry

отсылаться оттуда они будут задействуя все ядра или же по одному, т.к. заливал ты их в одном потоке?

Вы же сами сказали - рулит ОС, а значит хз как.

@~~Digital_Cry~~ · 28.12.2017, 22:21

Сообщение от Avazart

Вы же сами сказали - рулит ОС

Ну это я предположил, так-то я не знаю :-) Надо в ветке WinAPI у Убеждённого спросить

@Avazart · 28.12.2017, 22:26

Да ответ очевиден - делать какие либо предположения по этому поводу - дело неблагодарное.

@~~Digital_Cry~~ · 28.12.2017, 22:31

Сообщение от Avazart

Да ответ очевиден

в смысле писать тестилку и проверять?

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.12.2017, 21:14	11
	Сообщение от Digital_Cry эти сокеты будут проц грузить на 100 процентов, Да но скорее всего эти 100% будут только на одном ядре. Если поток один то один клиент будет получать данные, другие же будут либо ждать либо идти лесом ... в зависимости от протокола. 0

@Algamon 28 / 28 / 1 Регистрация: 21.06.2013 Сообщений: 192
		1
	QTcpSocket несколько клиентов 28.12.2017, 11:38. Показов 5919. Ответов 17 Метки нет (Все метки) Имеется сервер к нему подключаются клиенты, проводят какой-то обмен информацией и отключаются. Сервер просто слушает порт (server->listen(QHostAddress::Any, 3333)), а клиенты используют connectionToHost и disconnecionFromHost. Собственно вопрос такой - когда подключаются одновременно несколько клиентов, что будет происходить? Будет ли сервер сам создавать очередь из клиентов, а клиенты ждать когда сервер закончит общение с одним клиентом и перейдет к следующему? Или при попытке подключиться к занятому хосту, будет ошибка? А если будет ошибка, как тогда самому организовать очередь? 0

@~~Digital_Cry~~ Заблокирован
	28.12.2017, 15:37	2
	У тебя QTcpServer испускает сигнал incomingConnection во время подключения клиента, функцией nextPendingConnection ты получаешь сокет этого клиента, подключаешь этот сокет к чему нужно и возвращаешься из функци. Лагов быть не должно, пока ты работаешь с малым кол-вом клиентов, но их кол-во тебе никто не ограничевает и клиент всё равно сможет подключится и при новом подключение прилетит incomingConnection. Но обычно, каждого клиента обрабатывают в отдельном потоке, что бы загрузить все ядра серверного CPU, то есть каждый новый сокет кидают в новый поток и там с ним работают. Вот тут посмотри видео урок, он старый, но суть я думаю поймёшь 1

@Algamon 28 / 28 / 1 Регистрация: 21.06.2013 Сообщений: 192
	28.12.2017, 16:16 [ТС]	3
	Хорошо, а если у меня сервер работает с БД? Повесить мьютексов, семафоров? Клиент не будет отпадать не дождавшись ответа? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.12.2017, 16:24	4
	Сообщение от Algamon Хорошо, а если у меня сервер работает с БД? Повесить мьютексов, семафоров? Клиент не будет отпадать не дождавшись ответа? Если ставить мютексы, то от многопоточности толку будет 0. Для бд в каждом потоке нужно будет создавать свои экземпляры классов БД. Успешность работы этого будет зависеть от БД, от длительности обработки запросов и самих запросов. Очевидно что если клиенты одновременно будут обращаться к одним одним и тем же данным в БД, БД будет отшивать. 1

@Algamon 28 / 28 / 1 Регистрация: 21.06.2013 Сообщений: 192
	28.12.2017, 16:29 [ТС]	5
	Сообщение от Avazart Очевидно что если будете одновременно обращаться к одним одним и тем же данным в БД, БД будет отшивать. Тогда многопоточный сервер не подходит. Видимо придётся организовывать очередь, но я не уверен, что и очередь будет работать как надо - если последний клиент в очереди не будет дожидаться ответа от бд и тупо падать в ошибке, тогда смысла во всём этом нет. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.12.2017, 16:37	6
	Нужно понимать характер нагрузки, и исходить из этого. Много потоков тоже нет смысла плодить, лучше использовать пул из N потоков. 0

@Algamon 28 / 28 / 1 Регистрация: 21.06.2013 Сообщений: 192
	28.12.2017, 17:20 [ТС]	7
	Сообщение от Avazart Нужно понимать характер нагрузки, и исходить из этого. Ну много клиентов ~50 которые время от времени бомбят сервер короткими запросами. При этом желательно, чтобы запросы долго не висели. Доступ к базе данных должен быть постедователен, т.к. клиенты пользуются одними и теми же данными и изменяют их. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.12.2017, 17:32	8
	Да в таком случае нет смысла делать в потоках. 0

@~~Digital_Cry~~ Заблокирован
	28.12.2017, 18:14	9
	Avazart, ты как знаток сетей, сажи такую вещь, вот если я в 100 сокетов в цикле write-ом залью по 100 мегабайт, эти сокеты будут проц грузить на 100 процентов, отсылая кусочками память на клиенты? Ну то есть как в винде на уровне ядра это организованно? На сервере один поток, я в нём в цикле заливаю во сто сокетов по 100 мегабайт в каждый. Это относительно быстро, намного быстрее, чем всё это отошлётся. Но как это будет отсылаться и что при этом вообще будет нагружено? По идее, драйвер должен грузить только сеть, а проц не особо, т.к. потоков всего 100 или нет? 0

@peter_irich 342 / 197 / 52 Регистрация: 18.10.2017 Сообщений: 1,943
	28.12.2017, 20:46	10
	Потоки можно организовать по-разному, сделать их столько, сколько есть ядер или вдвое больше и при этом не привязывать их к конкретному сокету, если сокетов больше, чем потоков. В этом случае перебирать потоки в порядке очереди и назначать потоку очередной сокет. Пётр. 0

	28.12.2017, 22:31

@~~Digital_Cry~~ Заблокирован
	28.12.2017, 22:01	12
	Сообщение от Avazart Да но скорее всего эти 100% будут только на одном ядре. Хмм... Но ведь сокет, это ж по идее просто блок памяти, то есть mamory mapped file так сказать, то есть допустим у тебя 100 сокетов, пусть даже ты в них пишешь в одном потоке, ты просто в разные участки памяти (хз ядра ОС наверное, или на уровне приложения) просто заливаешь данные, а уже ядро ОС как-то, зная что вон те то участки памяти - под сокеты, должна оттуда память стягивать и отсылать клиентам MTU пакетами... То есть фактические, тебе главное в память сокетов что-то залить, а ОС сама должна уже разбираться, как всё это передать, используя много ядер или одно (сетевая карта то как правило одна) ... Эх... тестилку что-ли накатать... 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.12.2017, 22:07	13
	Какая разница, что бы залить в сокет данные их нужно откуда то взять... это тоже работа. 0

@~~Digital_Cry~~ Заблокирован
	28.12.2017, 22:18	14
	Сообщение от Avazart Какая разница, что бы залить в сокет данные их нужно откуда то взять... это тоже работа. Не, это-то понятно, но допустим, заливка данный в сокеты занимает намного меньше времени, нежели отправлять все эти данные со всех сокетов по сети, допустим 300 соектов, в каждый заливается по 1 мегабайту в цикле. Вот, после того, как ты их залил туда, отсылаться оттуда они будут задействуя все ядра или же по одному, т.к. заливал ты их в одном потоке? 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.12.2017, 22:20	15
	В данном случае речь шла про БД так что тут совсем другая ситуация. Сообщение от Digital_Cry отсылаться оттуда они будут задействуя все ядра или же по одному, т.к. заливал ты их в одном потоке? Вы же сами сказали - рулит ОС, а значит хз как. 0

@~~Digital_Cry~~ Заблокирован
	28.12.2017, 22:21	16
	Сообщение от Avazart Вы же сами сказали - рулит ОС Ну это я предположил, так-то я не знаю :-) Надо в ветке WinAPI у Убеждённого спросить 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.12.2017, 22:26	17
	Да ответ очевиден - делать какие либо предположения по этому поводу - дело неблагодарное. 0

@~~Digital_Cry~~ Заблокирован
	28.12.2017, 22:31	18
	Сообщение от Avazart Да ответ очевиден в смысле писать тестилку и проверять? 0