Russian Qt Forum

Добрый день всем.
Когда-то писал прогу на Qt с использованием udp-сокета, все работало, передавалось туда-сюда... Но все было для одного девайса с обменом по одному порту.
Сейчас поставили мне задачу написать прогу, обменивающуюся по udp с несколькими девайсами (с разными адресами конечно же).
Причем работа с каждым из девайсов ведется по двум портам, по одному обмен командами, по другому обмен потоками данных.

Внимание, вопрос ( :)):
1. Для каждого девайса нужен отдельный QUdpSocket?
2. Для каждого из портов нужен свой отдельный QUdpSocket?

Я могу, конечно и сам поискать в нете, порыть в доках (чем в ближайшее время и займусь), но может у кого есть такой опыт и он подтолкнет в нужном направлении, буду очень рад (скажу СПАСИБО).

Всё зависит от протокола вашего. А так можно спокойно сделать менеджер отправки/приёма с общими портами.

Протокол таков, что инициатором входящего (ну и исходящего :)) потока является моя прога.

Про менеджера немного не понял, это типа при обмене с каждым из девайсов делать ДЕбинд для предыдущего и биндиться с нужным, и т.д. ??

Один сокет можно в одно и то же время соединить через bind только с одним хостом и портом.
Надо несколько - делаем по одному сокету на подключение.
Только скорее всего вам придется еще каждый объект в отдельном потоке обрабатывать, но это уже от частоты передачи данных зависит.

А если делать опрос по-очереди, то можно ли используя ОДИН сокет биндить его к разным адресам/портам в нужное время?
Т.е. поработали с одним адресом/портом, переключились на другой адрес/порт и т.д.
Или это не айс? Не в нормальном стиле?

UPD: подойдет ли такой вариант, если от всех устройств идут постоянные потоки данных? Не получится ли получение неполного пакета или коллизии?

Вы страдаете херней )
Без знания вашего протокола конкретику сказать нельзя.
Но постоянные потоки данных могут идти только по РАЗНЫМ портам.

У вас каждый девайс это физическое устройство с отдельным IP адресом.
Что запрещает сделать по сокету на устройство?
Вернее, не так. Зачем извращаться с одним сокетом? Что это даст, кроме проблем?

Спасибо за советы.
Буду делать отдельные сокеты для устройств.

1 Сокет на порт обмена командами + его обработчик события получения пакета
2 Сокет на порт обмена данными + его обработчик события получения пакета
При приходе пакета есть его источник
Плодить еще сокеты смысла не вижу

Постоянные потоки данных.
Добавляем протокол - UDP с его негарантированной доставкой.
Эти слова меняют твою точку зрения, qate?

Если у нас есть N девайсов и каждое использует M портов, то нам надо N * M сокетов.
Что тут обсуждать?

как это может поменять мою точку зрения ?
у ТС железяка работает по UDP, разве чтото возможно иное без переделки железа ?

слушающих сокетов достаточно M на адрес 0.0.0.0 - что тут обсуждать ?

Последний ответ очень интересен, с таким пока не встречался, поищу на этот счет чего-нибудь.

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

Но тут опять же надо смотреть на протокол ТСса, возможно ему подойдёт и вариант qate, но тут не угадаешь :)

У автора N физических устройств. У каждого отделый айпи. При чем тут адрес 0?

Адрес 0.0.0.0 - запуск на всех интерфейсах. Даже если будет 100500 устройств, все они будут подключены к одному сетевому интерфейсу и проблемным местом при непрерывной передаче данных будет не обработка внутри программы (при условии, что она реагирует на входящие с разумной скоростью), а сетевая инфраструктура - коммутаторы, сетевые адаптеры. Один простенький дешевый коммутатор, рассчитанный на нагрузку в домашней сети, сведет на нет всю обработку.