Python-сообщество

Всем привет. Озадачились написанием онлайн игры (функционал - на уровне карточный игры) для iOS. Задача сервера - выдерживать 1000-5000 одновременно играющих игроков на сервере. Есть игрок, он отправляет запрос серверу на создание игры, сервер подбирает ему противников, обеспечивает обмен сообщениями и игровую логику, подведение результатов и сохранение всего прогресса в БД. Есть тут такие кто имеет опыт написания подобной системы? основные вопросы: 1) реально ли вообще? 2) нужно ли использовать многопоточность? 3) сколько сокетов нужно будет использовать? (1 слушает, остальные - прием/передача)
Заранее спасибо за ответы

1 да реально
2 не нужно
3. сокетов делайте сколько вам нужно.
4. UDP по смыслу вроде не очень подходит для вашей задачи. С TCP будет проще.

doza_and
4. UDP по смыслу вроде не очень подходит для вашей задачи. С TCP будет проще.

знаю что tcp будет проще, но уже наелись с неустойчивой связью при работы через 3g. Поэтому было решено делать UDP и вручную писать гарантированную доставку.
Тогда вопрос по сокетам (пока немного плаваю в этой теме). Есть ли разница что я создал 1 сокет, который обрабатывает все 5000 сообщений, или я создаю для каждого матча (рассчитан на 4 человека максимум) свой отдельный сокет и использую только его для этой группы игроков?

Megaman63
Есть ли разница

Да есть. В потреблении ресурсов ОС. Сокет обычный системный объект который требует ресурсов.

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

Megaman63
Поэтому было решено делать UDP и вручную писать гарантированную доставку.

Это большая работа, причем возможно бесполезная. Да вы сможете более гибко работать с timeout.

Можно это обсудить, если вы напишете чем ваш протокол гарантированной доставки будет лучше чем TCP протокол. В чем собственно ваша идея по улучшению TCP?

doza_and
Можно это обсудить, если вы напишете чем ваш протокол гарантированной доставки будет лучше чем TCP протокол. В чем собственно ваша идея по улучшению TCP?

UDP нам больше подходит из-за того что не нужно устанавливать соединение, и используя свой протокол гарантированной доставки я буду четче представлять доставлено ли на самом деле сообщение. Было множество случаев когда на телефоне свернули приложение, кто-то позвонил на телефон, телефон перешел из wi-fi сети в 3g, сменился айпи адрес или порт, и вот со всеми этими ситуациями были проблемы поддержания постоянного соединения. Так же не покидает нас мечта написать peer-to-peer, и здесь уже точно ни о каком TCP речи быть не может

Отредактировано Megaman63 (Май 11, 2016 19:27:06)

И совсем забыл про главную причину отказа от TCP - держать 1000-5000 TCP соединений сервер совершенно точно не сможет. Сейчас у нас имеется ТСР сервер который формирует группы по 4 игрока, и дальше отдает управление GameCenter'у который устанавливает p2p матч. В этой схеме все было прекрасно 1) ненагруженный ТСР сервер который только обеспечивает небольшой чат и подбор игроков 2) GameCenter который обеспечивает p2p UDP сеть. НО! походу тестирования выяснилась очень ненадежное соединение у GameCenter'a которое как раз постоянно отваливалось в вышеперечисленных ситуациях, а порой вовсе отказывался создавать матч когда одно устройство сидело на 3g, а другое на wi-fi

Megaman63
телефон перешел из wi-fi сети в 3g

WAT? это совершенно разные сетевые модули, телефон и там и там одновременно соединение держит.

Megaman63
5000 TCP соединений сервер совершенно точно не сможет.

А откуда такая информация?

Megaman63
peer-to-peer, и здесь уже точно ни о каком TCP речи быть не может

Да опять, откуда такая информация? Аськи p2p по tcp ходят.

Megaman63
устройство сидело на 3g, а другое на wi-fi

А тут дело не в сетях, а в том что оба за натом сидят, вы для того чтобы p2p сделать, должны иметь full cone nat с двух сторон иметь да ещё и пирами обменяться через STUN и сигнальный сервера.

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

Тут мне, кажется, нужно чтобы приложение проверяло доступность и выдавало ответ tcp а не свой tcp поверх udp писать с блек-джеком и прочим

noob_saibot
WAT? это совершенно разные сетевые модули, телефон и там и там одновременно соединение держит.

в том то и дело что разные сетевые модули, как только мы вышли из кафе где был wi-fi матч геймцентра непременно рухнет. Рухнет и соединение TCP. с UDP же телефон сразу отошлет проверочное сообщение на сервер и сервер запомнит новый адрес и порт телефона.

noob_saibot
А откуда такая информация?

Из собственного опыта и опыта других разработчиков. Сервер нормально держит 50-70 соединений, дальше начинаются лаги

noob_saibot
Да опять, откуда такая информация? Аськи p2p по tcp ходят.

Так же из личного опыта. Если телефон в 3г сети, то у него постоянно меняются порты и айпи адрес. Геймцентр у Эппла сделан на UDP, и поверх написана гарантированная доставка.

noob_saibot
А тут дело не в сетях, а в том что оба за натом сидят, вы для того чтобы p2p сделать, должны иметь full cone nat с двух сторон иметь да ещё и пирами обменяться через STUN и сигнальный сервера.

в том и дело что НАТ симметричный

Megaman63
кто-то позвонил на телефон, телефон перешел из wi-fi сети в 3g

это одно, а это

Megaman63
мы вышли из кафе где был wi-fi

другое. Конечно, при смене ip вы должны устанавливать соединение заново, к чему был первый комментарий о звонке?

Megaman63
с UDP же телефон сразу отошлет проверочное сообщение на сервер

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