Создание игрового сервера

[broken]

Добрый день!
Netty на Java не работает с UnitySocketIO без дополнительных надстроек?
Проект под Web player.
Если я правильно понимаю, то сервер должен иметь надстройку для Socket.IO?
Планирую работать с Netty сервером, какую библиотеку для Unity3d/C# лучше использовать по работе с сокетами? Видел такие как SuperSocket Client. Посоветуйте

[Woolf]

Добрый день!
Netty на Java не работает с UnitySocketIO без дополнительных надстроек?
Проект под Web player.
Если я правильно понимаю, то сервер должен иметь надстройку для Socket.IO?
Планирую работать с Netty сервером, какую библиотеку для Unity3d/C# лучше использовать по работе с сокетами? Видел такие как SuperSocket Client. Посоветуйте

Долго вчитывался и не могу врубиться, каким боком netty относится к юнити? Я уж молчу, что нетти на java, а юня c java не работает.

[broken]

Прошу прощения, возможно криво написал.
Для создания игрового сервера выбирали между SmartFoxServer и самописным сервером. Решили писать свой сервер, за основу решили выбрать Netty (http://netty.io/) Собственно вопрос был в том какую либу лучше использовать для работы с сокетами в Unity/c# или использовать дефолтные средства c#.
Не совсем понял почему Unity не может комуницировать с Java сервером посредством сокетов? Сегодня проверял, из редактора во всяком случае работало.

[Woolf]

Прошу прощения, возможно криво написал.
Для создания игрового сервера выбирали между SmartFoxServer и самописным сервером. Решили писать свой сервер, за основу решили выбрать Netty (http://netty.io/) Собственно вопрос был в том какую либу лучше использовать для работы с сокетами в Unity/c# или использовать дефолтные средства c#.
Не совсем понял почему Unity не может комуницировать с Java сервером посредством сокетов? Сегодня проверял, из редактора во всяком случае работало.

А, я думал вы на стороне юнити нетти хотите прикрутить. А зачем вам какие-то либы на клиентской стороне? По мне, так обычных сокетов вполне хватает. Тем более, что у нетти никаких особых заморочек с форматом пакетов вроде нет. Единственное что, придется немного повозиться с преобразованиями Little- Big-Endian. На юнити запустите два треда, в одном отправляйте, в другом принимайте. Поскольку юнити должна работать в основном потоке, синхронизируйте обмен данными между тредами при помощи защищенных очередей. Обрабатывать инфу можно на апдейте или фикседапдейте. Ну вот как-то так.

[broken]

Спасибо за ответ. По поводу сторонних либ просто интересно было вдруг есть что-то уже более менее готовое для юнити, включающее различного рода оптимизации, разбиение по потокам и тп.
Что касается стандартных c# сокетов, вы подразумевали использование модели синхронных сокетов? Смотрел в инете но так и не понял какая модель сокетов предпочтительнее в unity - sync или async, чистые Sockets или враппер TcpClient.
И еще один вопрос, наткнулся на упоминание в статьях protobuf для сериализации данных, не приходилось использовать? И намного ли затратнее использовать тот же json или BinaryFormatter?

[Sality]

Я не использовал BinaryFormatter, юзаю обычно json/ Но как попробовал protobuf я офигел. Быстро работает, пакет мало весит потому что бинарный, и самое важное для меня просто шикарно удобно. Мне не приходится разбирать данные, я получаю сразу структуру с данными.

Что касается синхронки или асинхронки, я сделал вывод что перепрыгнуть через 15 мс (частота обновления кадра) я немогу, и если учесть что .net в общем медленный, в синхронном режиме получается даже быстрее чем в асинхронном. То есть приходит пакет, для передачи его в основной поток используем буфер, который читается не быстрее 15 мс. (15 уже просрали), далее упираемся в медленный .net и на обработку пакета тратим например 5 мс. Ну и на отправку можно чуть потратить, но тут можно с хитрить вобщем не считаем. Получается всего на отработку запроса на клиенте 20 мс. В синхронке же мы потратим только 5 мс на отработку запроса.

Вот так вот)

Ой, я подумал про клиент реч идет. На серваке лучше асинхронно и многопоточно) Только если у вас поумному сделано работа с БД, иначе вся куча потоков будет застревать в одном потоке БД и толку будет столько же, как и от 1 поточного сервера.

[Woolf]

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

Ну, я использую фотон с бинарным форматом. Лично мне нравится. Но он платный.

[broken]

Я не использовал BinaryFormatter, юзаю обычно json/ Но как попробовал protobuf я офигел. Быстро работает, пакет мало весит потому что бинарный, и самое важное для меня просто шикарно удобно. Мне не приходится разбирать данные, я получаю сразу структуру с данными.

Что касается синхронки или асинхронки, я сделал вывод что перепрыгнуть через 15 мс (частота обновления кадра) я немогу, и если учесть что .net в общем медленный, в синхронном режиме получается даже быстрее чем в асинхронном. То есть приходит пакет, для передачи его в основной поток используем буфер, который читается не быстрее 15 мс. (15 уже просрали), далее упираемся в медленный .net и на обработку пакета тратим например 5 мс. Ну и на отправку можно чуть потратить, но тут можно с хитрить вобщем не считаем. Получается всего на отработку запроса на клиенте 20 мс. В синхронке же мы потратим только 5 мс на отработку запроса.

Вот так вот)

Ой, я подумал про клиент реч идет. На серваке лучше асинхронно и многопоточно) Только если у вас поумному сделано работа с БД, иначе вся куча потоков будет застревать в одном потоке БД и толку будет столько же, как и от 1 поточного сервера.

Окей, спасибо. Я именно про клиент спрашивал в последнем сообщении. Значит твоя рекомендация сводится к использованию дефолтных Socket (или TcpClient), синхронный режим и сериализацию protobuf.

[Sality]

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

[gnoblin]

photon cloud

[broken]

photon cloud

Сейчас диалог идет в контексте создания своего сервера на java и выборе инструмента для работы с сокетами на клиенте.
Вы имели ввиду photon cloud + pun? Под сервер на java/netty?

[Woolf]

photon cloud

Так а причем тут PUN? Как я понял, у человека стоит задача авторитарный сервер использовать.
Для TC - мой совет таков, не изобретайте велосипед. Берите готовое решение и используйте его. С самописными серверами куча мороки да и пахнет это изобретением велосипедов. Сейчас есть с десяток вполне нормальных решений. Если не стоит задачи именно java, толучший на сегодняшний день, это Photon (на сишарпе), но есть и java решения, тот же ES5, SmartFox и другие. У всех серверов есть бесплатная триалка на какое-то количество коннектов. На время разработки 100 бесплатных коннектов вам выше крыши, а когда придет пора запуска, думаю, что деньги найти можно, тем более что у того-же фотона сейчас есть "повременные" лицензии за $30-100 долларов в месяц. Ну а если запуститесь и игра будет стоящей, то донатом можно уже выбирать любые лицензии, денег должно хватить.

[broken]

Да, спасибо за ответ. К сожалению решение о написании своего сервера на java/netty уже принято, сервером занимается отдельный java разработчик. Вот я и интересовался есть ли что-то из готовых либ под c#/unity позволяющие нормально обрабатывать события сервера по сокетам, чтобы акцентировать усилия на разработку самой игры, а не написание нового велосипедного обработчика сокетов с оптимизациями.

[HacKeR]

Что бы не создавать отдельную тему спрошу здесь:
Какой вариант лучше для сервера:
1) Сервер на синхронных ТСР сокетак, где каждому клиенту выделяется свой сокет и он читает/отправляет данные в своем потоке?
2) Сервер на синхронных UDP сокетах, где каждому клиенту выделяется свой сокет и он читает/отправляет данные в своем потоке?
3) Другой вариант?

Ибо написал сервер/клиент на ТСР сокетах но видно небольшую задержку между приемом данных. Проверяю очень просто - отправляю местоположение 1 игрока другому и когда приходят данные - я перемещаю игрокак в то место.
1 Игрок на экране второго очень дергается.

Еще 1 вопрос: Как лучше всего отправлять данные (в каком виде)? Сейчас же все отправляю в байтах.

[Guyver]

1) Сервер на синхронных ТСР сокетак, где каждому клиенту выделяется свой сокет и он читает/отправляет данные в своем потоке?

- плохо. много потоков - смерть.

2) Сервер на синхронных UDP сокетах, где каждому клиенту выделяется свой сокет и он читает/отправляет данные в своем потоке?

- что за любовь к отдельным потокам ?

3) Другой вариант?

- да
.асинхронные сокеты .... ?
.синхронные сокеты - select/poll и таск пул из нескольких тредов, которые поровну делят нагрузку по соединениям

Ибо написал сервер/клиент на ТСР сокетах но видно небольшую задержку между приемом данных.

- проверьте ещё включен ли Нагл (нужно отключить .. или почитать про него, чтобы понимать зачем он)

Еще 1 вопрос: Как лучше всего отправлять данные (в каком виде)? Сейчас же все отправляю в байтах.

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