решил дома использовать AoE причем в качестве хранилища используется девайс со слабеньким процессором может быть я его проапгрейжу на девайс с чуть менее слабеньким процессором ну да не суть. А суть в том, что текущая реализиция aoetools/vblade и winaoe оставляют желать лучшего в плане перфоманса и надежности (есть некоторые нарекания). Вобщем несколько вечеров проведенных за компом — и я их похоже допилил до пригодного состояния. Допилив, хочется чтоб мои старания не прошли мимо других нуждающихся и тут то возникло два НО:
Послав на мэйллист разработчиков aoetools свои ченжи я получил в ответ что чувак ты слишком сильно все переделал, лучше форкай свой проект
А разработчики winaoe вообще постеснялись представится и непонятно кому слать патчи. Представленная на winaoe.org формочка не работает, а на указанном irc канале — только мертвые с косами. Впрочем, учитывая что дата последнего изменения проекта — март 2008 года — сложно было ожидать иного
Вобщем похоже надо создавать свой проект, собственно вопрос: насколько правомерно использовать название winaoe и продолжать его версионинг под той же GPL если автор оригинального winaoe канул в Лету и спросить его самого об этом невозможно?
Ну и это — если кто хочет попилить его со мной — велкам. Правда я похоже уже все допилил что мне хотелось...

идеи следующие — развить протокол и софт по фичам и перфомансу, в данный момент у протокола есть некоторые недостатки (не считая фатального ) и очевидные пути развития функционала
Недостаток 1 — отсутствие слежение за дубликацией пакетов. В хорошем эзернет железе это проблем не доставляет, в плохом может вызвать повреждение данных в случае прилета дубликата пакета. Плохо то что плохое железо все равно исправное — эзернет по стандарту не гарантирует отсутствие приема дубликатов фреймов. Вобщем этот недостаток я уже выпилил.
Недостаток 2 — отсутствие CRC в пакетах. С другой стороны, ethernet фреймы содержат в себе crc32 на весь пакет, и это прописано в стандарте и на технчиески исправном железе все должно быть хорошо. Вобщем тут пока ничего делать не собираюсь.
Недостаток 3 — каждый запрос==каждый эзернет фрейм. Очевидно, что намного эффективнее мержить мелкие запросы в единый фрейм. TODO вобщем.

Далее очевидная фича, которую софт просто просит — ethernet-based raid массив. офразработчики, будучи делающими бабло на железе, а не софте предлагают использовать со своим протоколом лишь классические рэйды либо же свои хардварные etherdrive'ы. Ну да это и понятно — разработчики получают денюжку за продажу своего железа, они и софтовые решения свои поэтому не развивают. В то же время очевидным видится следующее тупое-как-пробка решение (вообще это можно сказать девиз AoE ) — инициатор (клиент — WinAoE) шлет write-запросы на мультикаст адрес, запросы получает одновременно ряд таргетов, инициатор же в свою очередь дожидается ответа от всех. Не чтение же инициатор шлет запросы лишь одному клиенту, а лучше — всем поочередно — для повышения производительности чтения. Разумеется в случае ошибки ввода вывода на любом таргете — оный исключается инициатором из массива, выдавая юзеру варнинг что надо бы сменить веник.

В результате имея дома гигабитный эзернет (или несколько эзернетов — датаграмность протокола позволяет свободно масштабироваться на произвольное количество/качество каналов) — на дешевых бытовых NAS'ах можно построить опенсурсный масштабируемый домашний SAN с блэкджеком и плюшками. Ну а основной десктоп — будет совершенно бесшумным — основная ось грузится с SSD или вообще diskless boot на каком нить Intel NUC, расположенном, например, в туалете

ЗЫ А еще у WinAoE есть недостаток который пока я не знаю как пофиксить — его драйвер не подписан, но всеми вытекающими проблемами под win64. Поскольку своего личного сертификата у меня нету и делать его для опенсурсного драйвера нет желания — пока не знаю что с этим делать. Его кто готов помочь с подписью драйвера — то ваще велкам

O>ЗЫ А еще у WinAoE есть недостаток который пока я не знаю как пофиксить — его драйвер не подписан, но всеми вытекающими проблемами под win64. Поскольку своего личного сертификата у меня нету и делать его для опенсурсного драйвера нет желания — пока не знаю что с этим делать. Его кто готов помочь с подписью драйвера — то ваще велкам

Может тебе эти парни помогут: http://www.reactos.org/wiki/Driver_Signing
Я так понял, главное, чтобы поделка жила в ReactOS