Многосокетное приложение

Ресмус · 21.01.2014, 22:12

Может ли флеш приложение подключаться сразу к нескольким сокетам? Если да, то каким образом?

Вообще ситуация такая: игра(java сервер), много комнат и отдельный канал чата. Есть connectionHandler который проверяет входящие данные и отправляет куда надо. Но, если игрок в комнате, как-то нецелесообразно пропускать данные через connectionHandler, т.к. они идут почти все в комнату (или отдельный канал чата).

Есть ли смысл создавать для каждой комнаты (и общего чата) отдельный сокет, и приемлемо ли клиенту иметь несколько сокетных подключений одновременно. При входе-выходе из комнаты придется создавать/закрывать новое сокетное подключение, целесообразно ли это?

Какие вообще могут быть решения данной ситуации?

.?

caseyryan · 21.01.2014, 23:47

Нет, не имеет смысла (хотя технически возможно). Проще и лучше, распределять на сервере, куда послать сообщение. Для этого можно сделать диапазоны типа local_scope / global_scope и отравлять их в параметрах сообщений. Подключение клиента вообще не должно зависеть от комнат

Ресмус · 22.01.2014, 02:56

caseyryan, а нельзя ли более подробно и развернуто, а то я не очень понимаю о чем Вы?
Вот, например в pomelo.js вопрос расширяемости решается добавлением новых портов (это в их же примерах чата и игры). Или я чего-то недопонимаю?

bifidokk · 22.01.2014, 09:23

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

Ресмус · 22.01.2014, 15:24

bifidokk, ну это то понятно. Комнате можно просто передавать ссылку на соединения, и она сама решит че кому передавать и передаст. Проблема не в этом, а именно в приёме данных.
Ведь ситуация какая? Прежде чем попасть в комнату данные проходят через отбор в постороннем экземпляре (connectionHandler). Но если игрок играет в комнате, и 80-90% инфы идет именно к ней, такой подход выглядит неэффективным.
Думается так: при приёме данных, на сетевом уровне так или иначе нужно каждый раз определять в какой порт направлять инфу. Если направлять сразу в комнату, то можно обойти лишнее перенаправление в экземпляре connectionHandler. Экономия на лицо... Но так как предположительно комнат будет много, около сотни, то такое количество сокетов настораживает. Посему и интересуюсь, не слишком ли это круто?

caseyryan · 22.01.2014, 17:25

Что-то я так и не уловил в чем проблема. Зачем инфа идет комнате? Она должна идти клиенту. Соединение сервера и клиента ведь все равно идет через клиента, а не через комнату, в которой он находится.

Ресмус · 22.01.2014, 18:52

Логика игры на сервере обрабатывается, это не peer-to-peer.

caseyryan · 22.01.2014, 23:19

А кто здесь про p2p говорит?
У меня работает так:
Клиент коннектится к серверу. Сервер помещает его в общую карту, присваивая ему уникальный id (просто порядковый номер) и использует этот id как ключ карты
Дальше клиент (флеш) шлет данные на сервер, своему серверному аналогу и внутри кода клиента на сервере запрос обрабатывается. Из сообщения вытаскивается тип и диапазон сообщения.
Так как у клиента есть ссылка на комнату, в которой он находится, то если в диапазоне написано scope_room, то сообщение, пришедшее клиенту, рассылается всем остальным клиентам, которые находятся в этой комнате.
Помимо диапазона scope_room, есть еще scope_global и scope_local. Если диапазон global, то сообщение отправится всем клиентам, которые есть в онлайне, а если local, то только самому клиенту.
В соответствии с типом сообщения. в клиенте формируется соответствующее событие. Его можно слушать хоть в коде комнаты, хоть где-то в другом месте, где это необходимо.
Вот так выглядит основная логика. Все происходит на одном и том же порте 8999. Не понимаю зачем нужно что-то мудрить с кучей подключений на разные порты.

C4Grey · 22.01.2014, 23:29

Комната - понятие виртуальное...все что она должна уметь, IMHO, так это хранить список сессий + иметь воможность отправить широковещательное сообщение всем участникам(broadcast).
Что касается открытия лишних сокетов - это ненужная трата ресурсов(опять-таки, IMHO), особенно в случае работы с blocking I/O, где обычно на каждое сокет-подключение приходится свой поток.
Вот неплохой пример: https://github.com/menacher/java-gam...omSession.java

bifidokk · 23.01.2014, 09:29

Цитата:

Сообщение от Ресмус

bifidokk, ну это то понятно. Комнате можно просто передавать ссылку на соединения, и она сама решит че кому передавать и передаст. Проблема не в этом, а именно в приёме данных.
Ведь ситуация какая? Прежде чем попасть в комнату данные проходят через отбор в постороннем экземпляре (connectionHandler). Но если игрок играет в комнате, и 80-90% инфы идет именно к ней, такой подход выглядит неэффективным.
Думается так: при приёме данных, на сетевом уровне так или иначе нужно каждый раз определять в какой порт направлять инфу. Если направлять сразу в комнату, то можно обойти лишнее перенаправление в экземпляре connectionHandler. Экономия на лицо... Но так как предположительно комнат будет много, около сотни, то такое количество сокетов настораживает. Посему и интересуюсь, не слишком ли это круто?

а если у вас будет 100 комнат? будете 100 портов открывать?)