Как правильно управлять большими IStreams?

Question

Я пишу библиотеку классов C # для передачи больших объемов данных с помощью автоматизации COM с помощью IStream. Он использует CreateStreamOnHGlobal вызов API для создания потока и методы в System.Runtime.InteropServices.COMTypes.IStream для работы с ним.

Мой вопрос: при передаче больших объемов данных, как лучше всего контролировать объем памяти? Загрузка 100 МБ + файловых данных в память кажется расточительной, и клиентскому приложению придется подождать, пока этот процесс завершится, прежде чем что-либо загружать.

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

Answer 1

Попробуйте использовать файл, созданный с атрибутами FILE_ATTRIBUTE_TEMPORARY и FILE_FLAG_DELETE_ON_CLOSE. Напишите свои вещи там. Windows попытается сохранить его в кеше диска, если не хватит памяти. Он самоуничтожится, когда вы закроете дескриптор или когда ваша программа завершит работу (или произойдет сбой!). Я узнал об этом здесь .

Answer 2

Можете ли вы взглянуть на эту статью от Microsoft о больших данных и потоковой передаче. В одном из моих проектов мы полностью передаем один и тот же поток клиенту и, поскольку мы никогда не выполняем буферизацию и не поддерживаем его как поток до тех пор, пока клиент его не получит (либо через поток ответов для Интернета), либо поток файлов в Приложение Windows, мы смогли оставить очень мало памяти на сервере.

Попробуйте проверить, удовлетворяют ли ваши требования WCF и TransferMode = Streamed в сочетании с кодировкой MTOM.

Большие данные и потоковая передача => http://msdn.microsoft.com/en-us/library/ms733742.aspx

Answer 3

При отправке больших сообщений с использованием Windows Communication Foundation (WCF) часто желательно ограничить объем памяти, используемый для буферизации этих сообщений. Одним из возможных решений является потоковая передача тела сообщения (при условии, что основная часть данных находится в теле). Однако некоторые протоколы требуют буферизации всего сообщения. Надежный обмен сообщениями и безопасность - вот два таких примера.

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

Доступен образец загрузки http://msdn.microsoft.com/en-us/library/aa717050.aspx

Answer 4

Каждая реализация потока реализуется в буфере. Большую часть времени вы будете иметь 100% контроль над размером буфера. Вы можете настроить размер буфера для настройки производительности и баланса использования памяти. Если вы не открываете сотни потоков одновременно, я предлагаю максимально увеличить размер потока:

var readStream = new System.IO.File.OpenRead (sourceFilePath); var writeStream = new System.Io.File.Create (destinationFile); * +1004 *

byte [] buffer = новые байты [ bufferSize ]; int readLength; в то время как ((readLength = readStream.Read (0,0 BufferSize ))> 0) {
writeStream.Write (буфер, 0, readLength); }

writeStream.Close (); readStream.Close ();

Answer 5

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

Если вы используете .NET 4.0, вы получаете управляемый API для файлов, отображаемых в память.