Самый простой для двусторонней связи через Интернет с использованием C #

Question

Самый простой для двусторонней связи через Интернет с использованием C #

2

Что я использую для двусторонней связи через Интернет без необходимости открывать порты на стороне клиента?

Пользователи не согласятся открывать порты и выполнять переадресацию портов на стороне клиента, хотя все возможно на стороне сервера.

Но мне нужно выполнить двухстороннюю связь.

Как мне добиться этого?

Не имеет значения, будет ли его WCF или удаленный доступ или веб-службы... Мне просто нужен быстрый и быстрый способ получить концепцию для разработки и распространения приложения.

Конечно, это будет через Интернет.

Пожалуйста, помогите.. Благодаря

Изменить: Обратите внимание, что мне нужно подключить несколько клиентов и поддерживать сеанс для каждого клиента.

Josh 23 авг. 2009, в 13:09

Источник

0

Ну, я имею в виду, вы можете просто использовать веб-сайт. Люди могут иметь учетные записи, а затем, вы знаете, сообщения друг другу :)
Noon Silk 23 авг. 2009, в 10:24
0

Нет, у меня уже есть Windows-клиент, который связывается с веб-сайтом ... но теперь мне нужен веб-сайт, чтобы инициировать некоторую работу над клиентом .... это проект распределенной архитектуры для совместного использования процессов на разных машинах
Josh 23 авг. 2009, в 10:33

Теги:

c#

networking

communication

3 ответа

2

Это зависит от того, что вы хотите сделать. Дуплексный WCF может работать, но через NAT и Proxies он становится несколько "iffy", потому что он зависит от того, что клиент открывает конечную точку WCF и поддерживает соединение.

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

blowdart 23 авг. 2009, в 09:22

0

Ваш гид работает через NAT? NAT - моя проблема ... Я не могу ожидать, что обычные пользователи ПК настроят переадресацию портов.
Josh 23 авг. 2009, в 10:35
0

помогите пожалуйста ... любой способ выйти из NAT? Teamviewer.com и logmein.com сделали это ... почему мы не можем, имея столько технологий внутри .Net? Там нет из коробки пути?
Josh 23 авг. 2009, в 10:38
0

Брандмауэры да, NAT нет. Вы можете посмотреть на Тередо и туннелирование, но это может быть излишним. TeamViewer и Loginme оставляют открытым TCP-соединение, которое туннелирует через NAT - это не WCF, не веб-сервисы и не удаленное взаимодействие (что плохо работает с брандмауэрами).
blowdart 23 авг. 2009, в 10:44
0

Похоже, что нет простых путей .. :(
Josh 23 авг. 2009, в 10:56

Показать ещё 2 комментария

1

Подключить через TCP (raw сокеты или более высокую реализацию) к центральному серверу.
На вашем сервере должно быть приложение, которое прослушивает конкретный, известный TCP-порт.
Каждый клиент подключается к вашему серверу, используя конкретный порт и "входит в систему".
Запишите протокол приложения выше TCP (проверка подлинности, управление сеансом и т.д.), И там у вас есть , поскольку TCP-соединение, однажды установленное, работает для обоих направлений.

Ron Klein 23 авг. 2009, в 07:24

0

HTTP (с использованием TCP) работает таким же образом. Нет оснований для такого низкоуровневого подхода.
Mark Seemann 23 авг. 2009, в 10:25
0

Я думаю, что HTTP должен иметь свое время ожидания, и я не уверен, что этот предел в порядке OP.
Ron Klein 23 авг. 2009, в 10:26
1

Кроме того, модель HTTP представляет собой один ответ на запрос. Я не могу сказать, хочет ли ОП "выполнить двустороннюю связь" просто одним ответом на один запрос.
Ron Klein 23 авг. 2009, в 10:34

Показать ещё 1 комментарий

Ещё вопросы

Ну, я имею в виду, вы можете просто использовать веб-сайт. Люди могут иметь учетные записи, а затем, вы знаете, сообщения друг другу :)
Нет, у меня уже есть Windows-клиент, который связывается с веб-сайтом ... но теперь мне нужен веб-сайт, чтобы инициировать некоторую работу над клиентом .... это проект распределенной архитектуры для совместного использования процессов на разных машинах
Ваш гид работает через NAT? NAT - моя проблема ... Я не могу ожидать, что обычные пользователи ПК настроят переадресацию портов.
помогите пожалуйста ... любой способ выйти из NAT? Teamviewer.com и logmein.com сделали это ... почему мы не можем, имея столько технологий внутри .Net? Там нет из коробки пути?
Брандмауэры да, NAT нет. Вы можете посмотреть на Тередо и туннелирование, но это может быть излишним. TeamViewer и Loginme оставляют открытым TCP-соединение, которое туннелирует через NAT - это не WCF, не веб-сервисы и не удаленное взаимодействие (что плохо работает с брандмауэрами).
HTTP (с использованием TCP) работает таким же образом. Нет оснований для такого низкоуровневого подхода.
Я думаю, что HTTP должен иметь свое время ожидания, и я не уверен, что этот предел в порядке OP.
Кроме того, модель HTTP представляет собой один ответ на запрос. Я не могу сказать, хочет ли ОП "выполнить двустороннюю связь" просто одним ответом на один запрос.

Mark Seemann · Accepted Answer · 2009-08-23T09-16-00.000Z

3

Лучший ответ

WCF поддерживает дуплексные привязки HTTP.

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

Mark Seemann 23 авг. 2009, в 09:16

0

но я думаю, что порт должен быть открыт на стороне клиента, и требуется переадресация порта ... правильно?
Josh 23 авг. 2009, в 10:31
0

Если клиентский компьютер может получить доступ к веб-сайту, он также может получить ответ от веб-службы. Вопрос заключается просто в том, сколько времени потребуется, прежде чем ответ придет к клиенту :) Вот чем пользуется WCF: клиент терпеливо ожидает HTTP-ответа от службы и сохраняет соединение открытым до бесконечности. Поскольку соединение открыто, служба может передавать ответы клиенту в любое время, когда ему это нравится. (Azure) Internet Service Bus также работает таким образом.
Mark Seemann 23 авг. 2009, в 10:38
0

Есть ли пример для этого? Я использовал WCF как веб-сервис, добавив ссылку ... но как мне сделать так, чтобы WCF вызывал функцию на клиенте всякий раз, когда это необходимо?
Josh 23 авг. 2009, в 10:40
0

msdn.microsoft.com/en-us/library/...
Mark Seemann 23 авг. 2009, в 13:07
0

В этой привязке не указан файл конфигурации
Josh 24 авг. 2009, в 17:29
0

@Josh: я не уверен, что понимаю, был ли твой последний комментарий вопросом или нет. Конфиг-файлы полностью ортогональны к вопросу о дуплексных соединениях.
Mark Seemann 24 авг. 2009, в 17:57
0

да, но я не вижу указанной привязки. В этой статье вы не видите дуплексной связи, проходящей через один и тот же порт. Я хочу открыть только один порт для входящих соединений на одной стороне.
Josh 25 авг. 2009, в 10:45
0

Дуплексная связь не зависит от привязки. Вы можете использовать его с несколькими различными привязками. AFAIR, он работает с wsHttpBinding (среди других привязок).
Mark Seemann 25 авг. 2009, в 11:15
0

Но смогу ли я получить эту архитектуру .... имея порт, открытый для входящих соединений только с одной стороны?
Josh 26 авг. 2009, в 08:29
0

@ Джош: это идея :)
Mark Seemann 26 авг. 2009, в 08:58
0

Спасибо, Марк ... но мне все еще трудно усвоить этот факт, так как я не смог найти ни одного примера дуплексного кода, который бы оставлял порт открытым только на стороне сервера. В большинстве случаев каждый пример указывает открытый порт на клиенте для обратного вызова.
Josh 27 авг. 2009, в 02:04
0

@Josh: я не уверен, что понимаю, что вы имеете в виду, оставляя порт открытым на стороне сервера - на сервере всегда должен быть открыт порт (80?) - это та же проблема с обычным веб-сервером.
Mark Seemann 27 авг. 2009, в 05:15

Показать ещё 10 комментариев