совет по архитектуре клиент-сервер

Question

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

У меня есть опыт написания автономных приложений, я смоделировал приложение и написал клиент. Связь с сервером - это только заглушка.

Итак, теперь у меня есть протокол в виде интерфейса (C#) с вызовами метода.
Четыре из звонков предназначены для запроса информации и два для передачи данных на сервер.
Данные находятся в классах, которые я хотел бы заморозить и восстановить на другой стороне.

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

Я также хотел бы обновить данные на клиенте с неопределенным интервалом. Сегодня я не знаю, как это сделать.
Мое приложение однопоточный, Windows Forms

Мои предположения что:
* Я буду использовать TCP/IP в той или иной форме ниже всего. Я должен настроить канал, установить IP-адреса и т. Д., У меня есть идея, что я должен делать.
* Передним интерфейсом сервера будет многопоточный, чтобы позволить более одному клиенту одновременно разговаривать с сервером. Синхронизация будет внутренней для сервера.
* Прогнозируемый объем данных, максимум: Текст 1000 * 1кбайт, 100 000 объектов с 4 состояниями. 20 000 обновлений/день. Но это путь в будущем.

мая три самый большой вопрос является
1. Протокол связи. Как мне сопоставить вызовы методов, те, которые у меня есть в интерфейсе, к тому, что я могу передавать по каналу TCP/IP?
2. Мне нужен совет по хорошему шаблону serialize чтение и запись в «базу данных», база данных не обязательно должна быть сервером sql.
3. Могу ли я разрешить серверу отправлять обновления клиенту, не делая его многопоточным приложением с одним потоком, только слушая сокет?

Я с удовольствием обновлю свой вопрос, если потребуется дополнительная информация.
Спасибо заранее.
Gorgen

Answer 1

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

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

Answer 2

SOUNDs, как хороший кандидат fror .Net удаленный доступ.

Это позволит абстрагироваться от смещения байтов низкого уровня и позволить вам писать код comms на языке уровня домена.

Answer 3

1) Пожалуйста, подробно остановитесь на этом вопросе. Я не совсем понимаю, что именно вы хотите объяснить здесь.

2) Я не уверен, что вы подразумеваете под этим (ничего не знаете о шаблонах в смысле программирования), но не было бы разумнее читать и писать асинхронно, чтобы вы только получали доступ к базе данных, когда у вас есть что-то читать/писать

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

Answer 4

Я просто хотел бы добавить некоторые плоть ответ Agent_9191 и записать шаги, которые я сделал для потомков:

Вопрос 1

• Read Getting started tutorial тщательно (не я не сделал, но я жаль, что я сделал)

• Изменен пример моего приступа моего собственного интерфейс

• По умолчанию сгенерированный прокси изменяет интерфейс весьма существенным образом; Все классы коллекции производятся для массива, и все классы, которые вы хотите передать, лишены всех методов из-за механизма доставки. Для доступа к классам доменов как в сервере и клиенте следовать советам this post

• Классы домена, которые будут использоваться должны быть сериализации с [DataContract] и [DataMember] от System.Runtime.Serializion.длл

• Эти WCF samples помогли мне понять, что происходит слишком

Вопрос 2

• Сделано класс, который реализован мой интерфейс снова

• добавлен статический экземпляр в Служба
  private static MyManager myManager = new MyManager();

• просто пересылаются все звонки
  public Project[] GetProjects() { return myManager.GetProjects(); }

Вопрос 3

Двусторонний контракт: How to: Create a Duplex Contract

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