Перенести данные в Silverlight с сокетами через прокси?

В настоящее время мне нужно создать приложение в браузере silverlight 4, которое может получать push-сообщения с сервера. Я полагаю, что использование сокетов - лучший способ, который также позволит соединению между сервером и клиентом для передачи данных и обновления страницы. Но меня беспокоят брандмауэры и / или прокси-серверы. Возможно ли использование технологии push или даже сокетов за прокси-сервером, который может блокировать все, чего нет на порту 80? Или возможно подключение сокетов к порту 80, что было бы идеально, потому что он обходил бы прокси и брандмауэр. Я знаю, что для Silverlight доступен определенный диапазон портов, поэтому я имею в виду обходной путь.

Кстати ... Будет ли отправка массового блока данных из silverlight быстрее через сокеты, ASP.NET AJAX или подключение к веб-службе ASMX?

Благодаря тонну!


firewall proxy sockets silverlight
person Matt    schedule 04.06.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Вы не можете подключиться к TCP-сокету с портом 80 в Silverlight. Как вы заявили, существует ограниченный диапазон портов (4502-4534), к которым вы можете подключиться, и все.

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

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

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

Рассматривали ли вы использование WCF PollingDuplex Channel? Это позволяет вам создавать "толчок" от серверного механизма, при этом придерживаясь HTTP. Кроме того, большая часть сантехники сделана за вас.

person AnthonyWJones    schedule 04.06.2010
comment
Спасибо, я посмотрю на WCF PollingDuplex. Прежде чем я это сделаю, эта статья: dotnetaddict.dotnetdevelopersjournal.com/sl_polling_duplex.htm говорит, что это не масштабируемый. Этим будет пользоваться большое количество людей, поэтому лишние накладные расходы не вариант. Если это правда, есть ли лучший вариант на основе HTTP? Спасибо. - person Matt; 04.06.2010
comment
@Matt: Определите большое количество людей? - person AnthonyWJones; 04.06.2010
comment
@Matt: тогда следующий вопрос: сколько задержек можно терпеть между созданием сообщения и его доставкой клиенту? Также как часто один клиент будет получать сообщения? - person AnthonyWJones; 04.06.2010
comment
Ну, частота будет сильно варьироваться, но может быть не меньше одного раза в секунду. И секунда или две были бы приемлемым временем ожидания - вот почему я смотрю на push. Я смотрел на WCF и дуплекс с опросом, и, насколько я понимаю, использование дуплекса с опросом такое же, как и простой WCF, за исключением того, что канал остается открытым, поэтому для частых запросов (опроса) нет накладных расходов. Это правильно? - person Matt; 05.06.2010

arrow_upward
1
arrow_downward

Вот отличная статья о дуплексном режиме опроса WCF (длинный опрос HTTP или стиль COMET) в надежде, что это поможет. Это немного устарело по содержанию, с которого вы начнете.

http://tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html

person Michael D. Irizarry    schedule 04.06.2010