Есть ли гарантия последовательности выполнения RPC?

[megafanat]

Предположим есть такая ситуация: два игрока одновременно бегут в сторону power-up`а и хватают его одновременно. Или почти одновременно, с разницей по времени меньшей чем время передачи данных по сети. При этом по правилам игры если один игрок уже ухватил power-up, то тот исчезает, и второй игрок ухватить его уже не сможет.
В момент хватания power-up игрок инициирует соответствующий RPC. То есть в этой ситуации получается, что один игрок инициирует RPC хватания power-up до того, как он узнает что другой игрок тоже инициировал RPC хватания power-up.

Вопрос: гарантирует ли Unity , что на компьютерах обоих игроков RPC будут выполнены в одинаковой последовательности? Или возможна ситуация, что на одном компьютере RPC будут выполнены в одной последовательности, а на другом в другой?

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

[Guyver]

я не вникал в сеть Юньки но такую ситуацию я бы разруливал метками времени действий в UTC в пакете вместе с действиями и сервер уже решает кто поднял этот PowerUP... так мне кажется правильно.. только нинаю укладывается ли это в сетевую концепцию Юньки.

п.с. сам юзаю Socket`ы и выделенный серв на шарпе.

надеюсь помог хотябы идеей.

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

[Zaicheg]

п.с. сам юзаю Socket`ы и выделенный серв на шарпе.

А как такая схема работает? В самых общих чертах, если не затруднит.

[Neodrop]

Очерёдность RPC гарантирована. Как и описано в справке, на сколько я помню. Но, при выполнении буферизованных вызовов (AllBuffered) (это когда кто-то подключился позже и получает список событий) я видел нарушения очереди. Правда давно, ещё на Unity 2.5. Не знаю, как с этим сейчас.

[Guyver]

я тут думал про метки времени ... наверно бред всёж .. потенциально можно слать пакеты с действиями и метками времени какими угодно ... и будут читы =(

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

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

на клиенте в юньке просто на шарпе сокеты...
я не использую геометрию уровней и физику (просто её нет по гейм плею) поэтому всё просто и прозрачно.

надеюсь понятно написал и ответил на твой вопрос.

[megafanat]

Я сделал тестовый проект. В этом проекте объект по таймеру сам у себя вызывает RPC с параметром RPCMode.All.

Выяснилось, что никакой гарантии последовательности нет. Возможна ситуация когда на сервере сначала выполняется функция вызванная сервером, а затем клиентом. А на клиенте наоборот.

Как пользоваться примером:
- Создать две копии проекта.
- Открыть обе копии в двух экземплярах Unity.
- Запустить один экземпляр и нажать кнопку Start Server
- Запустить второй экземпляр и нажать кнопку Connect to Server
- После этого в консолях обоих экземпляров начнут печататься строки вида "AB" или "BA".

Если "АВ" - то сперва вызывается процедура вызванная сервером, а потом клиентом.
Если "BA" - то сперва вызывается процедура вызванная клиентом, а потом сервером.

На моем компьютере уже на втором сообщении на клиенте и сервере эти строки расходились.

[Neodrop]

NetworkStateSynchronization

Почитайте справку. Может поможет от дурости поспешных выводов.

Я третий год с сетью работаю и как то не заметил таких вот неприятностей. Видать старею.

[megafanat]

Не понял.
Вы имеете в виду это: http://unity3d.com/support/documentatio ... ation.html ?
Или это: http://unity3d.com/support/documentatio ... ation.html ?

Вроде в этом топике речь идет о Remote Procedure Calls.

Каким образом State Synchronization связана с Remote Procedure Calls? Вроде даже в статье про RPC прямо написано

The Network View's State Synchronization can be set to Off, unless you are using State Synchronization with the same Network View.

Подскажите пожалуйста, как State Synchronization может помочь решить проблему в тестовом проекте. Или в чем состоит неправильность этого тестового проекта?

[Neodrop]

RPC работают через NetworkView
NetworkStateSynchronization - параметр, настраивающий режим синхронизации NetworkView
В справке читаем :

If it is just for the RPC function, state synchronization should be turned off and the observed property can be set to none.

У вас установлено?
Читаем далее :

RPC calls are always guaranteed to be executed in the same order as they are sent.

Разве не в этом вопрос топика?

Если вопрос в очерёдности прихода сообщений - то почему вы ждёте их от Сервера? PRC доставляет тот, кто их посылает и, само-собой разумеется, что посылая их самому себе, вы вправе ожидать получения вызова раньше остальных
Вот, ещё малость из справки :

A client could send RPC calls to everyone to signal that he picked up an item.

Если вам необходимо, чтобы что-то шло ко всем исключительно через Сервер - вызовите RPC на сервере и пусть он уже разошлёт её всем.
И напоследок : посылать RPC самому себе, мне кажется излишеством

[megafanat]

1. Собственно в NetworkView State Synchronization стоит в off.

2. По поводу

RPC calls are always guaranteed to be executed in the same order as they are sent.

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

3. Собственно как раз в самом начале я и формулировал вопрос насчет подбора предметов. Меня интересовало, работоспособна ли схема, кода экземпляры одного предмета у разных игроков равноправны и при подборе одним игроком экземпляр предмета рассылает остальным RPC о том, что этот предмет подобран. И что произойдет если в двух экземплярах игры два игрока одновременно подберут один и тот же предмет.

Получается что в этой схеме два игрока могут подобрать один и тот же предмет. То есть эта схема неработоспособна.

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

4. Ну а по поводу рассылки RPC самому себе - этим достигается единообразие. Одно и то же действие реализовано в одной функции. А не в двух.

[Neodrop]

Проще всего, чтобы сам предмет определял, кто его подобрал

[Phoenics]

Проще всего, чтобы сам предмет определял, кто его подобрал

Это не выход, т.к. у каждого клиента свой экземпляр объекта и каждый из них (экземплров) может выполнить действие до того как узнает о том, что другой пользователь уже выполнил это действие (0.01 допустим секунду назад) в прошлом.
Сервер должен определять такие вещи. Клиенты должны только слать серверу какие действия предпринимает игрок (хочет бежать/прыгнуть/выстрелить/повернутся), а сервер уже определяет может ли это сделать игрок и рассылает клиентам уведомления о факте события. Тоже самое с батарейкой, клиенты шлют серверу команды что они бегут к батарейке, но на стороне сервера только один из них успеет первым он и получит уведомление о том что он подобрал Power Up, а второй получит уведомление что он неуспел. Только так можно обеспечить зажиту от читов и взломанных клиентов, если клиент сам будет определять состояние игры, свои координаты и с какими предметами он взаимодействует, то ничто не помешает ему взломать клиента таким образом тчо бы повесить на хоткей себе подбор любого нужного предмета, автоприцел с гарантированным хедшотом, вИдение сквозь стены, телепортацию куда надо и т.д. и т.п.

[Neodrop]

Я уже советовал вам не говорить не подумав.
networkView.isMine вам в помощь.
Или
Network.peerType
или ещё пара вариантов проверки на уникальность или на Сервер.