2010-10-15 2 views
2

Я создаю карточную игру SilverLight, которая разговаривает на службу WCF с использованием дуплекса связыванияWCF Instance Management

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

И в ответ на обновленное состояние игры передается каждому клиенту

Хотя я тестировал, я имел Instancing настроить следующим образом

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.Single)] 

Это означает, что состояние игры сохраняется в памяти.

Теперь, если я хочу установить это для широкого использования (маловероятно, что он будет очень популярен, но позволяет предположить, что одновременно может быть воспроизведено более 1 игры), что было бы самым подходящим режимом WCF Instancing?

В настоящее время я думал, что сериализации состояния игры в базу данных документа после того, как каждый игрок своей очереди, затем retirieving его на будущих клиент порта связи

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

eg если есть 3 игры, происходящие одновременно, могут ли клиенты для игры A подключиться к одному экземпляру службы, а клиенты B для подключения к другому экземпляру?

Или это единственный способ передать каждому клиенту идентификатор игры и получить сериализованное состояние игры из БД или другого хранилища данных?

EDIT:

Я специально заинтересован в Sharable услуг - в этой статье http://msdn.microsoft.com/en-us/magazine/cc163590.aspx Но это, кажется, не в Доступно версии WCF, я использую. У меня только Single, Persession и PerCall

ответ

0

InstanceContextMode (как вы, вероятно, знаете) - PerSession, PerCall или Single. Ни один из них не поддерживает сценарий поддержки одного экземпляра для конкретной реализации службы. Вместо этого они ссылаются на характер подключения между сервисом и клиентом. Например, PerSession создаст новый экземпляр вашей реализации сервиса для каждого нового сеанса клиента.

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

Однако, если вы do необходимо реализовать что-то вдоль линий обмена экземплярами среди клиентов, то there is some documention on this.

+0

Да, и вопрос в том, как «держать текущие игры в памяти». Экземпляр singleton не подходит для хранения нескольких игр в памяти, отключает состояние игры, сериализованное/десериализованное по каждому запросу клиента. Я спрашиваю, можно ли хранить несколько экземпляров в памяти и иметь определенных клиентов для определенных экземпляров клиента. – ChrisCa

+2

@ Christo. Ссылка в вашем сообщении относится к некоторой устаревшей документации. InstanceContextMode.Shared никогда не выпускался. Я обновил свой ответ с возможным обходным решением. (Хотя я все еще не могу понять, почему Singleton не будет работать: сохранить состояние в словаре?) –

0

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

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

Есть много других вещей. Я бы рекомендовал загрузить тестовое решение, которое вы реализуете.

Смежные вопросы