Взлом Mono для поддержки асинхронного ввода-вывода для файлов с отображенной памятью
Я ищу небольшой совет по "взлому" Mono (и на самом деле.NET тоже).
Контекст: В рамках библиотеки Isis2 (Isis2.codeplex.com) я хочу поддерживать очень быструю репликацию файлов с отображением в память "нулевого копирования" на компьютерах с правильным видом оборудования (Infiband NIC) и минимальное копирование для большего количества стандартный Ethernet с UDP. Итак, настройка такова: у нас есть набор процессов {A,B....}, все связаны с Isis2, и у некоторого члена, возможно, A, есть большой файл с отображением в памяти, назовите его F и попросите Isis2 удовлетворить повторить F на B, D, G и X. Библиотека сделает это очень эффективно и очень быстро, даже при интенсивном использовании многими параллельными инициаторами. Идея состоит в том, чтобы предложить это HPC и облачным разработчикам, работающим с приложениями больших данных.
Теперь Isis2 написан на C# в.NET и кросс-компилируется в Linux через Mono. Как.NET, так и Mono являются управляемыми, поэтому ни один из них не хочет позволять мне выполнять сетевой ввод-вывод с нулевым копированием - нормальная модель будет "копировать ваши данные в управляемый объект byte[], а затем использовать SendTo или SendAsync для отправки. receive, тот же расклад: Receive или ReceiveAsync в объект byte[], затем копирование в целевое местоположение в файле." Это будет медленнее, чем то, что может выдержать аппаратное обеспечение.
Оказывается, в.NET я могу взломать обычные средства защиты памяти. Я создал свою собственную обёртку для сопоставленных файлов (на самом деле основанную на публикации, опубликованной много лет назад исследователем из Колумбии). Я вытягиваю библиотеку Win32Kernel.dll, а затем использую методы Win32 для сопоставления моего файла, инициирования вызовов сокета Send и Receive и т. Д. После небольшого взлома я могу имитировать асинхронный ввод-вывод.NET таким образом, и в итоге получаю с чем-то довольно чистым и полностью написанным на C#, и ничего.NET даже не распознает как небезопасный код. Я отношусь к своему отображенному файлу как к большому неуправляемому байтовому массиву, избегая всего этого ненужного копирования. Очевидно, я защищу все это от моих пользователей Isis2; они не будут знать.
Теперь мы подошли к сути моего вопроса: в Linux я, очевидно, не могу загрузить dll ядра Win32, поскольку его не существует. Поэтому мне нужно реализовать некоторые базовые функциональные возможности с помощью основных вызовов Linux O/S: вызов fmap() отобразит мой файл. Linux также имеет свою собственную форму асинхронного ввода / вывода: для Infiniband я буду использовать библиотеку Verbs от Mellanox, а для UDP я буду работать с необработанными IP-отправками и сигналами ("прерываниями") по завершении. Ужасно, но я могу заставить это работать, я думаю. Опять же, я постараюсь обернуть все это так, чтобы он выглядел как стандартный асинхронный асинхронный ввод / вывод Windows для чистоты кода в самом Isis2, и я скрою весь неуправляемый, небезопасный беспорядок от конечных пользователей.
Поскольку я буду отправлять гигабайт или около того по частям, одна из ключевых целей состоит в том, чтобы данные, отправленные по порядку, в идеале были бы получены в том порядке, в котором я публикую свой асинхронный прием. Очевидно, мне нужно беспокоиться о ненадежном обмене данными (из-за чего вещи в конечном итоге отбрасываются, и мне тогда придется копировать). Но если ничего не пропущено, я хочу, чтобы n-й кусок, который я посылаю, попал в область n-го приема...
Итак, вот мой вопрос: кто-нибудь уже сделал это? У кого-нибудь есть какие-либо советы о том, как Mono реализует асинхронные вызовы ввода-вывода, которые так интенсивно использует.NET? Предположительно, я должен сделать то же самое. И есть ли у кого-нибудь совет, как сделать это с минимальной болью?
Еще один вопрос: Win32 ограничен 2 ГБ сопоставленных файлов. Облачные системы часто запускают Win64. Любые предложения о том, как максимизировать совместимость, позволяя в полной мере использовать Win64 для тех, кто работает это? (Своего рода проблема отражения O / S...)