Передача больших полезных нагрузок данных (Сериализованные объекты) с помощью wsHttp в WCF с безопасностью сообщения

У меня есть случай, где я должен перевести большие суммы графиков сериализованного объекта (через NetDataContractSerializer) использующий WCF, использующий wsHttp. Я использую безопасность сообщения и хотел бы продолжить делать так. Используя эту установку я хотел бы передать график сериализованного объекта, который может иногда приближаться приблизительно к приблизительно 300 МБ, но когда я пытаюсь сделать так, я начал видеть исключение системы типов. InsufficientMemoryException появляются.

После небольшого исследования кажется, что по умолчанию в WCF, что результат к служебному вызову содержится в рамках единственного сообщения по умолчанию, которое содержит сериализированные данные и эти данные, буферизуется по умолчанию на сервере, пока целое сообщение полностью не записано. Таким образом исключение памяти вызывается тем, что сервер исчерпывает ресурсы памяти, которые позволяется выделить, потому что тот буфер полон. Две основных рекомендации, с которыми я столкнулся, состоят в том, чтобы использовать потоковую передачу или разделение на блоки для решения этой проблемы однако, мне не ясно, что это включает и возможно ли любое решение с моей текущей установкой (wsHttp/NetDataContractSerializer/Message безопасность). До сих пор я понимаю, что для использования безопасности сообщения потоковой передачи не работало бы, потому что шифрование сообщения и дешифрование должны работать над полным набором данных и не частичного сообщения. Разделение на блоки однако кажется, что могло бы быть возможно однако, что мне не ясно, как это было бы сделано с другими ограничениями, которые я перечислил. Если кто-либо мог бы предложить некоторое руководство на том, какие решения доступны и как пойти о реализации его, я был бы очень признателен за его.

Я должен добавить, что в моем случае действительно не волнуюсь по поводу совместимости с другими клиентами, поскольку мы владеем и управляем каждой стороной коммуникации и используем общий интерфейсный шаблон для данных, переданных любой стороне. Таким образом, я открыт для любой идеи, что соответствия в ограничениях использования wsHttp с безопасностью сообщения для передачи графов объектов, сериализированных с помощью NetDataContractSerializer и я предпочитаю решение, где я не должен изменять свои существующие сервисы и окружающую инфраструктуру решительно.

Связанные ресурсы:

• Большой канал
• Как к: позвольте передать потоком
• Большие вложения по WCF
• Пользовательское сообщение кодер
• Другое определение InsufficientMemoryException
• Недуплекс Большой Канал необходим
• Потоковая передача большого содержания с WCF и задержанным выполнением

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

Обновление (2010-06-29):

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

Базовое соединение было закрыто: соединение было неожиданно закрыто.

В конечном счете после выполнения этого и выполнения еще некоторого входа я нашел базовое исключение InsufficientMemoryException, которое вызывало проблему с указанным сообщением.

Не удалось выделить буфер управляемой памяти 268 435 456 байтов. Объем доступной памяти может быть низким.

Который порожденный из следующего метода.

Система. ServiceModel. Диагностика. Утилита. AllocateByteArray (размер Int32)

Таким образом в otherwords отказ прибыл из выделения массива. При записи тех же данных, сериализированных к диску, это поднимает приблизительно 146 МБ и если я сократил его наполовину затем, я прекращаю получать ошибку однако, я не вырыл намного больше в определенный порог, который повреждает мой буфер и ли это характерный для моей системы или нет.

Обновление (2010-12-06):

Я предполагаю эту точку, я ищу некоторый clarifcation для следующего. Мое понимание - то, что по умолчанию с WCF wsHttp с безопасностью сообщения, что целое сообщение (обычно полный набор данных я возвращаюсь) должно быть буферизовано на сервере, прежде чем ответ передадут обратно клиенту и таким образом порождению моих проблем.

Возможные решения:

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

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