собсвенно есть куча байтов byte[], хотелось бы это дело передать из одного экзэмпляра порограммы в другой (и по сети тоже), еше не хочется строить велосипеды, и еше не хочется чтобы это все сериализовывалось/десериализовывалось по дороге (ну как например в remoutin). была мысля заюзать пайпы, только по сети это как будет выглядеть? нечто многопоточно на сокетах писать желания ни какова.
подскажите как лутьше эту задачку решить.
даных может быть вплодь до 10 гб.

Здравствуйте, pumpurumer, Вы писали:

P>собсвенно есть куча байтов byte[], хотелось бы это дело передать из одного экзэмпляра порограммы в другой (и по сети тоже), еше не хочется строить велосипеды, и еше не хочется чтобы это все сериализовывалось/десериализовывалось по дороге (ну как например в remoutin). была мысля заюзать пайпы, только по сети это как будет выглядеть? нечто многопоточно на сокетах писать желания ни какова.
P>подскажите как лутьше эту задачку решить.
P>даных может быть вплодь до 10 гб.

WCF

Здравствуйте, pumpurumer, Вы писали:

P>собсвенно есть куча байтов byte[], хотелось бы это дело передать из одного экзэмпляра порограммы в другой (и по сети тоже), еше не хочется строить велосипеды, и еше не хочется чтобы это все сериализовывалось/десериализовывалось по дороге (ну как например в remoutin).

Ээээ… А во что (и, главное: зачем!) можно сериализовывать _байты_ в данном случае (для передачи)?

Здравствуйте, _FRED_, Вы писали:

_FR>Ээээ… А во что (и, главное: зачем!) можно сериализовывать _байты_ в данном случае (для передачи)?

ну всмысле при использовании remouting потребуется данный процесс потомучто он так устроен. или если использовать binary formatter оно будет быстро?
по сути нужно файлы гонять по сети внутри локалки, от клиентов на сервер и только. по сути можно и smb(всмысле на сервере пошарить диру) для этой цели использовать, но такая реализация будет кладезем багов и гимароя как для пользователей так и для программистов.


Здравствуйте, anton_t, Вы писали:

_>WCF

этот проект написан на 2.0 framework, и пока нет желания менять платформу по множеству причин к делу не относяшихся.

Здравствуйте, pumpurumer, Вы писали:

P>собсвенно есть куча байтов byte[], хотелось бы это дело передать из одного экзэмпляра порограммы в другой (и по сети тоже), еше не хочется строить велосипеды, и еше не хочется чтобы это все сериализовывалось/десериализовывалось по дороге (ну как например в remoutin). была мысля заюзать пайпы, только по сети это как будет выглядеть?

Пайпы вполне нормально будут выглядеть.

>нечто многопоточно на сокетах писать желания ни какова.

И не надо.

P>подскажите как лутьше эту задачку решить.

Memory mapped файлы. Придется выйти в unsafe код. Самое быстрое решение. ИМХО. Фактически при этом никакой передачи в прямом смысле слова не происходит, то есть данные не копируются. Просто организуется доступ к файлу, содержащему эти данные, из нескольких приложений. При этом каждое приложение будет брать те данные, которые ему в данный момент нужны (в пределе — все). Идеально подходит под твою ситуацию, то есть байтовый массив. Надо просто вместо его создания средствами C# использовать CreateFileMapping/MapViewOfFile. Получишь void*, преобразуешь к byte*, заполнишь этот массив, и все. Другие приложения — тот же саиый вызов CreateFileMapping/MapViewOfFile, только без заполнения. После вызова данные уже у них, остается их только брать.

P>даных может быть вплодь до 10 гб.

Однозначно — MMF.

PD>Memory mapped файлы. Придется выйти в unsafe код.
Отнюдь. Можно и безо всякого unsafe сделать SharedMemoryStream какой. Естественно, память будет копироваться.

Здравствуйте, Аноним, Вы писали:

PD>>Memory mapped файлы. Придется выйти в unsafe код.
А>Отнюдь. Можно и безо всякого unsafe сделать SharedMemoryStream какой.

Можно подробнее, о чем идет речь ? На базе чего ты его делать собираешься ?

>Естественно, память будет копироваться.

А ее там 10 Гб...

Здравствуйте, pumpurumer, Вы писали:

P>даных может быть вплодь до 10 гб.
Может все-таки app-сервер, который будет давать доступ к этим данным?

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, pumpurumer, Вы писали:

P>>даных может быть вплодь до 10 гб.
HL>Может все-таки app-сервер, который будет давать доступ к этим данным?

Этот сервер, что, в свое адресное пространство пустит и даст возможность там покопаться ?

Господа, отдаватйе себе отчет в том, что любое решение, в котором кто-то будет давать доступ, неизбежно связано с копированием этих данных. Не обязательно сериализация, тем более, что она здесь не нужна по характеру данных. Что значит — давать доступ ? Давать можно либо сами данные (а это копирование), либо указатель на данные (а вот это не копирование). И для MMF именно указатель и дают. Физические страницы RAM при этом даются под данные ровно один раз, независимо от числа процессов, которые эти данные используют. А копирование — это умножение на N. Хоть с сервером, хоть без него. Хоть TCP/IP, хоть пайпы, хоть дух святой. А данных там 10Gb...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Этот сервер, что, в свое адресное пространство пустит и даст возможность там покопаться ?
Зачем?

PD>Что значит — давать доступ?
Это уже зависит от конкретной задачи, которую пытается решить топикстартер.
Данные сами по себе не нужны, с ними нужно что-то сделать. Я предлагаю вариант типа "IAppServer.ProcessData". Сервер сам подготовил данные, сам обработал. Никто ничего никуда не передает.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Однозначно — MMF.

хотелось бы это дело передать из одного экзэмпляра порограммы в другой (и по сети тоже),

Научи плиз шарить память между приложениями на разных машинах!

Здравствуйте, HowardLovekraft, Вы писали:

HL>Данные сами по себе не нужны, с ними нужно что-то сделать. Я предлагаю вариант типа "IAppServer.ProcessData". Сервер сам подготовил данные, сам обработал. Никто ничего никуда не передает.

А топикстартер вроде спрашивал имено о передаче. Если можно просто вынести всю обработку этих 10 Гб в отдельный процесс, так чтобы никому больше они не были нужны, тогда да, конечно. Но тогда и вопроса не будет, как он поставлен.

Здравствуйте, Pavel Dvorkin, Вы писали:

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

Было бы проще, если бы автор пояснил, что это за данные, откуда берутся и что с ними нужно сделать.

PD>Можно подробнее, о чем идет речь ? На базе чего ты его делать собираешься ?

Кому, как не специалисту по WinApi, должно быть хорошо известно, что для этого достаточно CreateFileMapping(), MapViewOfFile(), UnmapViewOfFile() и RtlMoveMemory(). Плюс отнаследоваться от Stream. Все это не требует никакого ансейфа. Работы примерно минут на 30. Конечно, для _передачи сообщений_ этого еще недостаточно, еще нужны какие-то механизмы информирования своего корреспондента о поступлении данных В простейшем случае сгодится любой разделяемый объект синхронизации. Вообще, в свое время для своих поделок я сделал некий аналог SQL серверного SuperSocket'а, который работает через сокеты при обмене вне машины, и переключается на использование разделяемой памяти при обмене в пределах одного компа. По производительности эта самопальная штука значительно превосходила виндовые сокеты при локально обмене данными.

>>Естественно, память будет копироваться.
PD>А ее там 10 Гб...

и что?

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А топикстартер вроде спрашивал имено о передаче
HL>Да, но очень смущает размер данных и необходимость передачи по сети, да еще и между экземплярами одного процесса...

HL>Было бы проще, если бы автор пояснил, что это за данные, откуда берутся и что с ними нужно сделать.

"экзэмплярами программ" а не процесса, те есть какой-то абстрактный сервер в вакууме, и есть такойже клиент, который на сервер данные должен передать, точнее он туда должен содержимое файлов передавать, сервера один штука, клиентов н штук, клиент может запушен как на одной машине с сервером так и на другой машине, котороя находится в одной локалке с сервером. данные на клиенте (или на сервере) пока не решено будут архивироватся, и на сервере куда нужно складыватся.
все.

MMF — чето невкурил, как это по сети делать, поясните.

Здравствуйте, pumpurumer, Вы писали:

P>есть какой-то абстрактный сервер в вакууме, и есть такойже клиент, который на сервер данные должен передать, точнее он туда должен содержимое файлов передавать, сервера один штука, клиентов н штук
В общем, как и предполагалось.
Если не хотите уходить со второго фрэймворка, то Remoting вас спасет. Только не выставляйте с сервера наружу stream'ы. Можно даже сжатие траффика добавить.

Здравствуйте, <Аноним>, Вы писали:
А>Кому, как не специалисту по WinApi, должно быть хорошо известно, что для этого достаточно CreateFileMapping(), MapViewOfFile(), UnmapViewOfFile() и RtlMoveMemory(). Плюс отнаследоваться от Stream. Все это не требует никакого ансейфа.
А можно продемонстрировать способ работы с CreateFileMapping(), MapViewOfFile(), UnmapViewOfFile() и RtlMoveMemory() "без ансейфа"?

Здравствуйте, Аноним, Вы писали:

PD>>Можно подробнее, о чем идет речь ? На базе чего ты его делать собираешься ?

А>Кому, как не специалисту по WinApi, должно быть хорошо известно, что для этого достаточно CreateFileMapping(), MapViewOfFile(), UnmapViewOfFile()

А прочитать внимательно можно, что я писал ?

http://rsdn.ru/forum/dotnet/3538292.1.aspx

Автор: Pavel Dvorkin
Дата: 16.09.09

Там ведь именно это и предлагается.

>и RtlMoveMemory().

А это еще зачем ? Откуда и куда эту memory move, и главное, зачем ? Никаких пересылок памяти работа с именованными мэппингами не требует, даже между процессами. Просто открываем вью мэппинга и пишем данные в одном процессе, а читаем в другом.

>Плюс отнаследоваться от Stream. Все это не требует никакого ансейфа.

Что-то я не понимаю. CreateFileMapping(), MapViewOfFile(), отлично, и что же мы получим ? MapViewOfFile() возвращает указатель void*. Его можно преобразовать в byte*. Этот массив неуправляемый. Как ты потом собираешься с ним без unsafe работать — объясни. Я, может, действительно что-то не понимаю.

Это во-первых. А во-вторых, что тут делает Stream ? Во-первых, вью мэппинга — это не поток, а массив с произвольным доступом. Если же ты собираешься его использовать его как поток (то есть последовательно), то бога ради, но тогда, пожалуйста, объясни, где ты намерен исходные (то есть отсылаемые в поток) данные в размере 10 Гб держать, и зачем, если их можно изначально в мэппинге и хранить, и никуда не пересылать. И ограничение адресного пространства в 32-битной системе здесь никому не мешает, хотя при 10 Гб читать мэппинг, конечно, придется по частям.



>>>Естественно, память будет копироваться.
PD>>А ее там 10 Гб...

А>и что?

Ничего. Памяти много, лей — не хочу. Времени на ее пересылку тоже много...

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Однозначно — MMF.
K>

хотелось бы это дело передать из одного экзэмпляра порограммы в другой (и по сети тоже),

Научи плиз шарить память между приложениями на разных машинах!

Хм. Интересно. Никогда не делал. Проблема в том, что давать одинаковое имя мэппингу бессмысленно — машины-то разные. Все же, думаю, вот такое будет работать

Создали шару на одной машине с правами записи для EveryOne (или кому надо) Пусть имя ее MyShare. На "сервере" (то есть машине, где данные создаются)

int _tmain(int argc, _TCHAR* argv[])
{
    HANDLE hFile = CreateFile("\\\\dvorkin-PC\\MyShare\\1.dat",GENERIC_ALL,0,NULL,CREATE_ALWAYS,0, 0);
    HANDLE hMapping = CreateFileMapping(hFile,NULL,PAGE_READWRITE, 0, 1024,"MyCoolMapping");
        // открываем view, заносим данные, закрываем view и мэппинг, информируем процесс на другой машине (последнее вне данного рассмотрения)
    return 0;
}

На другой машине открываем этот же файл, создаем мэппинг тем же способом, читаем данные.

Кстати, если это надо делать несколько раз, то закрывать мэппинг и даже view необязательно. Достаточно вызвать FlushViewOfFile, но при этом надо иметь в виду

When flushing a memory-mapped file over a network, FlushViewOfFile guarantees that the data has been written from the local computer, but not that the data resides on the remote computer. The server can cache the data on the remote side. Therefore, FlushViewOfFile can return before the data has been physically written to disk. However, you can cause FlushViewOfFile to return only when the physical write is complete by specifying the FILE_FLAG_WRITE_THROUGH flag when you open the file with the CreateFile function

Так что если "сервер" имеет шару именно на себе, то FlushViewOfFile досточно, так как запись идет на локальный компьютер. Если же шара физически находится на компьютере клиента, то надо FILE_FLAG_WRITE_THROUGH.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А топикстартер вроде спрашивал имено о передаче
HL>Да, но очень смущает размер данных и необходимость передачи по сети, да еще и между экземплярами одного процесса...

Меня тоже. Передавать по сети 10 Гб — удовольствие ниже среднего. Тут и песочные часы не помогут, надо что-то посерьезнее выводить (например, ориентировочное время до завершения . Но если автору это надо...


HL>Было бы проще, если бы автор пояснил, что это за данные, откуда берутся и что с ними нужно сделать.