Чатрулетка

[RedLizard]

Чисто в исследовательских целях решил сбацать свою Чатрулетку (соответственно с "блекджеком и шлюхами" ) Использую Stratus + Flash Builder 4. Т.е. предполагается что приложение будет работать как p2p.

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

[ZloyKinoman]

ну как получилось с чат рулеткой?

[NS11111]

Чат рулетку сбацать несложно.
А вот раскрутить - почти не возможно.
Надо же, чтоб люди туда заходили одновременно.
Человек 10-20 в минуту должно пастись одновременно.
То есть сразу надо 20*60=1200 чел в час * 24= ок. 30 тыс в сутки.
И сразу. Иначе хрен туда кто вернется после первого захода,
увидев что там никого нет.
Есть такие клоны чатрулетки - видел. Дохлые сайты.
Потраченное напрасно время и деньги.

А алгоритм...
Ну, что уж тут сложного?
Есть медиасервер, есть HTTP сервер.
На HTTP сервер каждый клиент раз в 1-2-3 секунды делает запрос "соедини меня"
Причем обязательно кто-то первый обслуживается на сервере,
даже если сотни людей шлют запросы в секунду.
Есть файл "ожидающих очереди".
Итак, первый пришедший локирует (делает LOCK - это в Линуксовой CGI-BIN программе) файла очереди. Никто другой этот файл изменить не может в это время.
Он пишет туда свои данные. В конце делает UNLOCK.
Заходит другой на сервер. Ага. Файл очереди не пустой.
Забирает себе партнера и т. п.
Естественно, все файлы при работе локируются - потом разлокируются.
Куча мелочей типа следующего.
Человек встал в очередь, но отвалилися - закрыл броусер.
Значит, должно быть время постановки в очередь.
Значит, надо всегда очищать файлы от мусора и тп.

Удачи.
Но успех чатрулетки , увы, не повторить!

[Crenth]

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

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

[NS11111]

Да нет же. Можно как раз обойтись без баз данных.
И нужно. Без мороки.
Первым пришел на сервер - оставил запись в списке ожидания.
Вторым пришел на сервер - забираешь первого.
И так далее: второй забирает первого.
Этим и определяется случайный выбор.

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

Ну, и еще раз: хрен раскрутишь такой сайт, где ОБЯЗАТЕЛЬНО присутствие нескольких парнеров ОДНОВРЕМЕННО.