crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Обрыв соединения QTcpSocket
Введите ваше имя
Подтвердите код

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

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
OrSOn Дата 25.2.2010, 12:44
  Увы, при перемещении я не могу рвать коннект, в том и суть, что надо передавать подключенным) Сейчас так и сделал, пока все работает, ошибок вызвать не получилось еще... Может и прокатит..
BRE Дата 25.2.2010, 12:14
  Пока я вижу один момент с перетягиванием объектов между потоками.
Qt на основании информации о расположении объекта принимает решение о том, какой тип подключения использовать при connect. Если при перемещении объекта разрывать все коннекты, а при назначении в новый поток подключать их вновь, то возможно все будет работать.
Попробуй поэкспериментировать с этим.
OrSOn Дата 25.2.2010, 9:47
  А почему это я не смогу вернуть их в главный поток? А насчет родителя - всегда можно сделать setParent().

Попробовал только что, все работает вроде. Но вопрос остается открытым, могут ли быть какие-то проблемы в этой работе? Все же, я очень сомневаюсь, что разработчики Qt предусматривали использование moveToThread() для постоянной переброски объекта между потоками..
SABROG Дата 25.2.2010, 2:43
 
Цитата(OrSOn @ 24.2.2010, 16:10) *
а затем также отправляем его в главный поток?


Поместив однажды объект в другой поток ты его уже обратно не сможешь вернуть в первоначальный.

Цитата(OrSOn @ 24.2.2010, 16:10) *
Сокеты создаются по-прежнему в главном потоке, но не имеют родителя.


Сокеты возвращенные из метода QTcpServer::nextPendingConnection() являются детьми QTcpServer'a, стало быть и родитель у них есть.
OrSOn Дата 24.2.2010, 16:10
  А такой вопрос еще... А можно ли рассматривать как вариант такой подход:

Сокеты создаются по-прежнему в главном потоке, но не имеют родителя. А когда нам надо отдать сокет на обработку, мы ему задаем moveToThread() в нужный поток, а затем также отправляем его в главный поток? По-идее, должно сработать, но что-то я не уверен в правильности такой работы. Подскажите плиз, есть шанс на успех или лучше так не делать?
OrSOn Дата 24.2.2010, 10:30
  Спасибо, сейчас буду пробовать все посоветованное..))
BRE Дата 19.2.2010, 16:53
 
Цитата(SABROG @ 19.2.2010, 16:19) *
В общем QIODevice и так использует QRingBuffer (internal class), поэтому можно просто завести буфер на базе QByteArray для каждого сокета, ловить сигнал bytesWritten() и просить (emit signal) поток подгрузить новую порцию данных, если клиенту были отправлены все данные. Поток сам очистит буффер и поместит следующий блок, затем оповестит (emit signal) об этом сокет. Сокет уже их будет писать, а поток продолжит читать данные из файлов для других сокетов и эмитить им сигналы как прочитает.

Я немного про другое... Qt-сокеты кешируют отправляемые данные. Если же из-за каких-то проблем с сетью или низкой скорости работы принимающей стороны, реально данные по сети не уходят (буфер отправки tcp-стека переполнен), то они будут скапливаться в памяти. А сервер вместо того, что бы заниматься теми клиентами, которые готовы принимать данные, будет периодически загружать все новые куски для "тормозящего" клиента и складывать их в памяти.

Хотя... Если bytesWritten отправляется только после реальной отправки данных, то все будет нормально. Полез смотреть. :)

Да, вместо QSocketNotifier можно использовать сигнал bytesWritten().
SABROG Дата 19.2.2010, 16:19
 
Цитата(BRE @ 19.2.2010, 15:06) *
А если принимающая сторона (клиент) сидит на узком канале и не успевает выбирать данные, которые ему пихают.


В общем QIODevice и так использует QRingBuffer (internal class), поэтому можно просто завести буфер на базе QByteArray для каждого сокета, ловить сигнал bytesWritten() и просить (emit signal) поток подгрузить новую порцию данных, если клиенту были отправлены все данные. Поток сам очистит буффер и поместит следующий блок, затем оповестит (emit signal) об этом сокет. Сокет уже их будет писать, а поток продолжит читать данные из файлов для других сокетов и эмитить им сигналы как прочитает.
BRE Дата 19.2.2010, 15:06
 
Цитата(SABROG @ 19.2.2010, 14:37) *
Думаю вместо того, чтобы данные передавать с сигналом можно использовать кольцевой буффер (circular buffer, ring buffer). Можно посмотреть как он реализован в Wait Conditions Example.

А если принимающая сторона (клиент) сидит на узком канале и не успевает выбирать данные, которые ему пихают.

OrSOn
Вот новый архив, асинхронный сервер лежит в server-async. Для работы используется QSocketNotifier.
SABROG Дата 19.2.2010, 14:37
  Думаю вместо того, чтобы данные передавать с сигналом можно использовать кольцевой буффер (circular buffer, ring buffer). Можно посмотреть как он реализован в Wait Conditions Example.
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 28.3.2024, 23:08