Можно ли передать HTTP-соединение из IIS / ASP.NET в другое приложение или службу? - PullRequest
4 голосов
/ 21 декабря 2010

Я изучаю создание приложения ASP.NET MVC, которое предоставляет (кроме обычных HTML-страниц) службы JSON и XML REST, а также веб-сокеты .

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

У меня естьесли это невозможно, , который в основном включает использование ASP.NET для проверки заголовков обновления подключения к веб-сокетам и ответ HTTP/1.1 302 Found, который указывает на другой хост, на котором настроена моя служба веб-сокетовнапрямую слушать конечную точку (и) соответствующего пользователя.

Ответы [ 4 ]

1 голос
/ 31 декабря 2010

Если я полностью понимаю вашу цель, я считаю, что вы можете использовать модуль IIS7 / 7.5 Application Request Routing для этого.

Вот краткий справочник: http://learn.iis.net/page.aspx/489/using-the-application-request-routing-module/

1 голос
/ 31 декабря 2010

Вместо 302 ответов вы можете использовать ISAPI_rewrite для направления на соответствующую конечную точку (и манипулировать заголовком HTTP, чтобы получить его там)

http://www.isapirewrite.com/docs/

В противном случае IIS не может изначально выдавать HTTP-соединение. Текущий метод MSFT должен использовать 302 или что-то еще, что перехватывает необработанный сокет и выполняет манипулирование заголовком перед отправкой в ​​IIS (или любое другое приложение)

0 голосов
/ 29 декабря 2010

Способ сделать это - использовать уникальный идентификатор сеанса, связанный с сеансом Http. Из описания кажется, что вы можете захотеть охватить это одним экземпляром HttpApplication, но в этом нет необходимости (вы также можете сохранить сеанс во многих экземплярах приложения). В любом случае этот идентификатор сеанса необходимо каким-либо образом присоединить к каждому запросу Http (либо с файлом cookie, строкой запроса, статической переменной с экземпляром HttpApplication, данными формы). Затем вы сохраняете идентифицирующую информацию о сеансе Http где-нибудь с идентификатором.

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

Использование этого SessionID где-то в запросе Http позволяет вам восстановить любую информацию, которая вам нужна для вызова и взаимодействия с соответствующими службами. Экземпляры сервисов также могут нуждаться в определении области для сеанса.

По сути, я предлагаю, чтобы вы НЕ непосредственно передавали соединение Http внешнему процессу, а вместо этого передавали необходимые данные внешнему процессу и позволяли создать механизм для отправки данных обратного вызова. Я думаю, что изучение шаблона посредника может помочь вам понять, что я имею в виду. http://en.wikipedia.org/wiki/Mediator_pattern. Надеюсь, это поможет.

0 голосов
/ 25 декабря 2010

Мне кажется, что лучше задать вопрос Microsoft, чем задавать нам.Web Sockets - это новая технология, и вместо того, чтобы искать взлом, вы можете спросить Microsoft, как они планируют ее поддерживать.IIS это их программное обеспечение.Поиграйте на http://iis.net (может быть, в http://forums.iis.net) и посмотрите, что вы узнали.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...