хочу организовать multicast на платформе jxta,там когда приходит сообщениие вызывается calback функция которая принимает это сообщение. есть несколько вопросов:
1)как сделать так,чтобы клиент знал что сервер окончил передачу пакетов и организацию пакетов в правельном порядке?

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

2)какая должна быть периодичность опроса?(секунды,минуты?).Т.е сколько времени клиент должен считать,что пакеты еще идут а не потерялись в пути и передача со стороны сервера закончилась? 

Сервер передает клиенту пакеты, очевидно, по протоколу TCP, поэтому порядок соблюдается, не надо добавлять порядковый номер. 

Нет,multicast основывается на udp

multicast обычно используют только для поиска активных узлов в сети (как правило, локальной). Когда сетевые адреса известны, узлы между собой устанавливают tcp соединение. UDP нет смысла использовать в peer-2-peer коммуникациях.

В моем случае сеть не локальная.Делаю видео трансляцию,главный сервер первый посылает пакет всем кто в группе,каждый получивший пакет,отсылает его сного всем кто в группе(таким образом думаю уменьшит время для получения всех пакетов),TTL пакета ограничу,чтобы не перегружать сеть. А если делать по TCP,как я себе это вижу, главный сервер посылает udp пакет и наверное большинство пиров установят tcp соединения с ним(а там их тысячи), разбить их на группы тоже не получится,при установки проги не должно делаться никаких настроек.Может я просто не понимаю какая должна быть архетектура сети чтобы использовать ваш вариант?

Это не мой вариант - я предположил, что в jxta используется tcp для обмена. Это общий случай. Но для видео, конечно, используют  udp, потому что не боятся потерять отдельные пакеты. Тогда, действительно, ответственность за порядок пакетов лежит на приложении. Насколько подходит jxta для этого? Особенно учитывая, что клиенты - в интернете. Некоторые из них из-за наличия файерволов смогут использовать только http для общения со своей группой и только через сервер. Это предусмотрено в jxta?

в jxta есть возможность связываться с пирами лежащими за файрволом или nat. мне кажется,что jxta вполне подходит.

Я почитал в википедии о jxta. Этот протокол предполагает обмен xml сообщениями. Для передачи видео/аудио потока это врядли эффективно. Все примеры использования - это обмен документами.

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

Пока не могу.
  
Я делал систему, которая передает потоковые данные от сервера клиентам. Мне интересно разобраться с jxta.
 
Для потока принципиальным является соблюдение порядка передачи сообщений в реальном времени. То, что обеспечивает tcp протокол. Не бинарность, хотя никому в голову не придет передавать поток из xml текстов. В торрентах порядок загрузки не важен. Это не поток.

То, что вы хотите, похоже на функциональность Skype. Так? 


Есть только два способа. Или сервер вначале отправляет размер всего сообшения. Или в конце отправляет сигнал "конец". Вы упоминали "callback". Наверное, когда данные закончились, то callback должен вернуть нечто, имеющее смысл "конец". А с какой частотой опрашивать сервер - это зависит синхронный или асинхронный запрос. Если асинхронные запросы, то сервер иногда будет отвечать "данные не готовы". Значит надо сделать паузу. Если запросы синхронные, то следующий запрос надо делать сразу после получения ответа. 

Это сообщение отредактировал(а) COVD - 19.4.2012, 17:34

Так давайте разбираться вместе!Да в принципе это похоже на Skype. Передовать символ конца,не подходит,потому что udp пакеты могут прийти не в том порядке в каком их послали. Пока делаю так,передаю java объект в котором есть два дополнительных поля,размер пакета и номер пакета. Время окончания передачи буду расчитовать ttl пакета * кол-во пакетов.

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

я как раз вообще не хочу опрашивать сервер,я хочу чтобы клиент после определенного времени проверил все ли у него пакеты а затем отослал на сервер уже по udp или tcp каких пакетов у него нет. 

Таким образом Вы убьете напрочь сеть. Ибо если у Вас 100 узлов и каждый (!) по получении пакета его разошлет обратно в широковещательном режиме - Вы получите 101 пакет вместо одного. И никакой TTL Вам не поможет - при пересылке пакеты будут формироваться заново. А учитывая Ваше



- Вы увеличите нагрузку в тысячи раз.

UDP для того и выбран для трансляции видео, что потеря данных тут не очень важна. 25 кадров в секунду, при потери части кадра будут кратковременные изменения качества изображения. И только. 

А Вы хотите и шороковещательную рассылку, и гарантированную доставку. Это Вам надо смотреть в сторону Negative ACKnowledgement protocol смотреть. Но больно хлопотное это дело - на java подменять собой сетевой протокол.

Это сообщение отредактировал(а) Skipy - 26.4.2012, 10:45

Да,скорее всего вы правы,будем думать дальше