Здравствуйте, есть приложение, использующее udp сокеты. В приложении bind с адресом AnyIPv4.
Также есть функция, посылающая в LocalHost данные в размере 72 байт в виде счётчика (по 64 байта).
Посылаемые данные представляют собой изображение, разбитое на блоки размером по 64 байта.
Изображение имеет размеры в 320х256 пикселов ( =81920 пикселов). Посылается 1280 блоков по 72 байта,
из которых данными являются 1280 блоков по 64 байта.
При посылке 1280 блоков по 72 байта принимается только 58304 байта (три четверти от посылаемых данных).
Вопрос: как добиться приема всей последовательности данных?
Здравствуйте, milkpot, Вы писали: M>При посылке 1280 блоков по 72 байта принимается только 58304 байта (три четверти от посылаемых данных). M>Вопрос: как добиться приема всей последовательности данных?
Qt тут не причем. UDP не гарантирует доставку. Видимо, не влезает в буфера, и отбрасывается. Надо смотреть в сторону сокет опшнс, SO_*. Но если в общем случае размер суперблока данных произвольный, то это не поможет.
Не отсылать сразу все, отсылать с паузой, сделать паузу до подтверждения приема
Здравствуйте, milkpot, Вы писали:
M>При посылке 1280 блоков по 72 байта принимается только 58304 байта (три четверти от посылаемых данных). M>Вопрос: как добиться приема всей последовательности данных?
Принимают их на венде?
У венды на UDP-сокете по умолчанию очень маленький приемный буфер, и его легко переполнить. См. в сторону SO_RCVBUF
Но UDP все равно не гарантирует надежной доставки, хоть 25% потерь, это, конечно, перебор. Зачем тебе UDP? Используй TCP и не ищи себе приключений.
M>Фрагменты программного кода:
M>void Window::readPendingDatagrams() M>{ M> ... M> QByteArray buffer; M> .... M> emit writeUdpData(buffer); M> } M>} M>[/ccode]
Осторожнее: в случае если сигнал и слот в разных потоках или явного использования Qt::QueuedConnection в connect данные будут скопированы.
В общем случае сетевые операции и GUI лучше делать в разных потоках:
* отедельный поток случает сеть и записывает данные в кольцевой буфер
* потом отправляет сигнал-уведомление о новых данных
* GUI берет данные из кольцевого буфера
M>
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, milkpot, Вы писали:
M>>При посылке 1280 блоков по 72 байта принимается только 58304 байта (три четверти от посылаемых данных). M>>Вопрос: как добиться приема всей последовательности данных?
Pzz>Принимают их на венде?
Pzz>У венды на UDP-сокете по умолчанию очень маленький приемный буфер, и его легко переполнить. См. в сторону SO_RCVBUF
Pzz>Но UDP все равно не гарантирует надежной доставки, хоть 25% потерь, это, конечно, перебор. Зачем тебе UDP? Используй TCP и не ищи себе приключений.
M>>Фрагменты программного кода:
Pzz>Не буду я читать твой код, уж извини
Программа выполняется под Windows.
При посылке данных я вставил задержку
теперь все посланные данные принимаются.
Хотя скорее надо работать с размером приемного буфера.
От устройства идет Udp. По ТЗ должен быть Udp протокол.
Здравствуйте, milkpot, Вы писали:
M>теперь все посланные данные принимаются. M>Хотя скорее надо работать с размером приемного буфера. M>От устройства идет Udp. По ТЗ должен быть Udp протокол.
Я принимал видеопоток на венде. По UDP. Чтобы добиться небольшого процента потерь, пришлось сделать буфер по-максимуму и задрать до потолка приоритет принимающей нити. Иначе при наличии более-менее заметной графической активности (напр, перетаскивание окошек с места на место) все равно время от времени принимающий поток мог терять процессор на единицы миллисекунд, и этого хватало, чтобы потерять часть пакетов.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, milkpot, Вы писали:
M>>теперь все посланные данные принимаются. M>>Хотя скорее надо работать с размером приемного буфера. M>>От устройства идет Udp. По ТЗ должен быть Udp протокол.
Pzz>Я принимал видеопоток на венде. По UDP. Чтобы добиться небольшого процента потерь, пришлось сделать буфер по-максимуму и задрать до потолка приоритет принимающей нити. Иначе при наличии более-менее заметной графической активности (напр, перетаскивание окошек с места на место) все равно время от времени принимающий поток мог терять процессор на единицы миллисекунд, и этого хватало, чтобы потерять часть пакетов.
Получается, принимать и посылать данные надо в рабочей нити?
Здравствуйте, milkpot, Вы писали:
M>Получается, принимать и посылать данные надо в рабочей нити?
Ну, посылать тебе может и не обязательно с такими требованиями.
Но я, да, имел отдельную нитку именно чтобы данные из UDP выгребать. Она работала с очень высоким приоритетом, но поскольку у нее не так уж и много было работы, особо не мешалась. Но разок, из-за моей ошибки, она зациклилась, в компьютере отвалилось практически всё.
Здравствуйте, milkpot, Вы писали:
M>Здравствуйте, есть приложение, использующее udp сокеты. В приложении bind с адресом AnyIPv4. M>Также есть функция, посылающая в LocalHost данные в размере 72 байт в виде счётчика (по 64 байта). M>Посылаемые данные представляют собой изображение, разбитое на блоки размером по 64 байта. M>Изображение имеет размеры в 320х256 пикселов ( =81920 пикселов). Посылается 1280 блоков по 72 байта, M>из которых данными являются 1280 блоков по 64 байта. M>При посылке 1280 блоков по 72 байта принимается только 58304 байта (три четверти от посылаемых данных). M>Вопрос: как добиться приема всей последовательности данных?
M>Фрагменты программного кода:
M>