Как структурировать систему чата веб-поддержки / поддержки клиентов

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

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

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

Учитывая, что наш настольный клиент будет создан с использованием WPF в C # .NET, а наш сайт - ASP.NET MVC 2, - как лучше всего установить связь между ними?

Мои первоначальные мысли заключались в том, чтобы веб-сторона сохраняла чат в базе данных SQL и каким-то образом «отправляла эхо-запрос» соответствующему клиенту рабочего стола, сообщая ему обновить журнал чата. Аналогично для настольных компьютеров и Интернета. Но я не уверен, как реализовать это между двумя разными платформами. Если бы это был настольный клиент для настольного клиента, я думаю, это было бы намного проще, но это не так.

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

Любая помощь очень ценится.


person Tom Glenn    schedule 03.12.2010    source источник
comment
ты нашел какое-нибудь решение? Я также ищу реализацию того же типа. Вы можете поделиться своими идеями?   -  person Raj    schedule 23.07.2012


Ответы (1)


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

Если вы все еще хотите действовать самостоятельно, главное препятствие, которое вам придется преодолеть, - это как отправлять сообщения в браузер. «Пинговать» браузер с сервера невозможно с использованием чистых веб-технологий, потому что HTTP построен на модели запрос / ответ «только по запросу». Между клиентом на сервере не поддерживается постоянное соединение. После того, как сервер завершил отправку страницы браузеру, соединение разорвано.

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

Лучшим решением было бы использовать Silverlight, Flash или какую-либо другую технологию толстого клиента, работающую в браузере. Затем вы можете реализовать службу, которая обрабатывает маршрутизацию сообщений между клиентами. Эта статья о CodeProject может быть хорошим началом.

person Dan    schedule 03.12.2010
comment
«Пинговать» браузер с сервера невозможно с использованием чистых веб-технологий - это больше не верно . - person josh3736; 03.12.2010
comment
Silverlight звучит неплохо. - person Tom Glenn; 14.12.2010