[Решено] UDP сервер для многих клиентов?, Ну а на самом деле просто быстрый сервер Опции

[Norrius]

Хорошо. Будет возможность - проверю.

[Norrius]

Проблема решена, действительно я идиот)

Как показало наблюдение за tcpSocket->bytesAvailable(), в буфере чтения скапливались данные, что объясняет и высокое время отклика, и его регрессию. Добавил

do { /*чтение пакетов*/ } while (!waiting && tcpSocket->bytesAvailable() > 0);

...и все работает.

Отключение алгоритма буферизации, как и сказано в документации, толком не влияет на скорость обмена. С flush() та же история, в общем, разобрался со всем (:

Спасибо за подробные разъяснения. Замечательный форум, мне уже который раз помогают разобраться в идиотских ошибках

[Iron Bug]

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

[Norrius]

Ожидающие чтения данные довольно быстро исчерпываются, поэтому с условием (tcpSocket->bytesAvailable() > 0) ни о какой бесконечной загрузке ЦП речи не идет.

У меня и используется система событий. Но, как выясняется, может придти несколько пакетов данных между предыдущим чтением буфера и чтением, которое будет вызвано этими пакетами. Поэтому нужно при каждом получении readyRead() считывать действительно все данные, а не только первую порцию.

Сообщение отредактировал Norrius - 26.8.2012, 16:30

[Алексей1153]

Мне нужна быстрая реакция на каждый пакет. Ждать, пока сообщений по 5-10 байт наберется на два килобайта, не получится.

где у меня про 5-10 байт ? Я говорю - слать пакетами по 2 кБ (не больше. Меньше - пожалуйста).

Насчёт сжирания проца поллингом: вычитывать данные нужно тогда, когда есть что-то новое. Если нет, делать паузу в, скажем, 1 мс. Я делал такую вещь, прекрасно работает (в отдельном потоке)

Сообщение отредактировал Алексей1153 - 27.8.2012, 11:07