p2p: Ограничение количества юзеров в группе
 

Можно ли (как?) ограничить количество юзеров в группе? К примеру что бы была возможность обмениваться данными только у n-го числа пользователей в группе, а из остальных формировалась новая группа и т.д. - разделить по песочницам? Возможно ли это без привлечения дополнительных серверных ресурсов (кроме stratus/cirrus)?

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

Я с p2p раньше не работал, вот решил восполнить пробел. Интересует как именно прекратить добавлению новых юзеров в группу? Как формировать название (id?) новой группы, если доступ к исходной запрещен? Интересна как теоретическая, так и практическая сторона вопроса. Гугл на эту тему достаточно скуп. ...или искал не так.

Хм. Помню, как-то эксперментировал с п2п. Двойственные впечатления остались: с одной стороны очень классно, что не нужно держать сервер, с другой стороны — тот же пинг.

Где-то здесь, на форуме, уже описывал свои соображения, не получается найти только. В общем, идея была следующая: фактически существует одна группа, но внутри нее есть подгруппы, изолированые друг от друга. Каждый клиент знает, какое максимальное кол-во клиентов может быть в подгруппе (можно считать игровой комнатой) и, когда добавляется новый клиент — он запрашивает данные о подгруппе и, соответственно, узнает, в какую подгруппу ему определиться. Если же нужны "администраторы", то есть клиенты с расширенными правами или те, которые централизовано что-либо делают, то они выбираются автоматически среди клиентов. Визуально пользователь будет даже и не знать, что его флэшка на экране отвечает за состояние игры, например. Механизм выбора "админа" прост: прогоняем всех клиентов на Math.random() и ищем минимальное (или максимальное) полученное значение. Кто победил — тот и админ. Если "админ" дисконнектится, соответственно, запускаем механизм заново.

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

Как я это вижу. У каждого пользователя есть некий id. В общей группе есть 2 типа пользователей: те, кто заявляет о создании группы и те, кто подключается к заявленным. Если создатель группы получает данные от желающего присоединиться пользователя - он создает уникальное id группы и они оба (или большее кол-во) коннектятся друг к другу. Соответственно присоединяющийся получает имя группы и также коннектится. Профит. Т.е. необходимо что бы id группы было всегда уникально, что решается на основании id обоих игроков и random-а. То что технология (в т.ч. и как и сам флеш, как клиентское приложение) не достаточно секьюрна - понятно, но я нигде не допустил откровенных дыр в безопасности? Хотелось бы какого-то контроля за обменом данными внутри приватной группы. В принципе каждый из участников может автоматически получать данные от оппонента(ов) и проверять их на валидность. А есть ли смысл в такой проверке? Наверное нет. Но это уже мысли вслух.
Hauts, спасибо.
Если будут еще какие мысли по теме - было бы интересно почитать.

Все таки нужен сервак, который будет следить за группами, и по подключению, отдавать юзеру имя, куда можно тыкаться. ИМХО конечно.

GBee, в случае наличия сервера необходимость использования p2p - отдельный разговор. Хотя если разделить задачи с целью снижения нагрузки на сервер... Но тогда опять же, что, при наличии сервера, можно выделить в p2p?

я не знаю зачем п2п вообще нужен. То есть чатики там понятно. А игры? Логику поломать можно если не будет сервера - контроллера.

если посомтреть пример stratus/cirrus на сайте адоби, то видно, что они скриптом собирают все айдишки приконнекченных юзеров, чтобы обмениваться ими через обычный веб-сервер. что мешает хранить как раз эти айдишки с идентификатором группы? зашли первые 10 юзеров, присваиваем им группу 0, и веб-сервер раздает "контакты" этой группы только в приделах группы итд.

Вот он, камень преткновения. Но все равно спасибо за отзыв.