Соединение с WCF -сокетом, не закрытое с помощью WS-Сжатия с привязкой net.tcp

Question

Недавно я работал над приложением WCF, и мне нужны некоторые функциональные возможности для сжатия тела сообщения soap, чтобы уменьшить размер ответа от сервиса.

После некоторых исследований я нашел реализацию, доступную в Интернете по адресу http://weblogs.asp.net/cibrax/archive/2006/03/29/WS_2D00_Compression-for-WCF.aspx '>http://weblogs.asp.net/cibrax/archive/2006/03/29/WS_2D00_Compression-for-WCF.aspx, его авторы создали новый элемент привязки 'CompressionBindingElement', связанный с классами, связанными с его каналами.

Это решение для сжатия отлично работает в моем приложении WCF, и размер ответа был уменьшен почти на 90%, отлично!Сначала я протестировал это через http binding (означает пользовательскую привязку с использованием http transport), и все кажется хорошим.

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

Я выполнил модульный тест, вызвав 10 раз метод, который создал клиент с помощью ChannelFactory, и явно добавил все элементы привязки, включая элемент привязки сжатия.Когда я впервые проверил ответ в TcpTrace, я был удивлен, увидев, что все эти 10 сообщений объединены в один запрос.

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

Проблема возникла только в привязке net tcp с элементом привязки сжатия, если элемент не был добавлен в привязку или в привязке http все кажется нормальным.

Кто-нибудь пробовал это решение и сталкивался с такой же проблемой раньше?Есть ли что-нибудь еще, что я могу сделать, чтобы принудительно закрыть соединение?Мог ли я что-нибудь упустить?

Большое спасибо, Тони

Answer 1

Похоже, у Microsoft теперь есть официальная статья о Compression Encoder:http://msdn.microsoft.com/en-us/library/ms751458 (v=VS.90).aspx

Я протестировал это снова, и, похоже, проблема исчезла.Не так-то просто запустить мой модульный тест после стольких дней :)