Na verdade, funcionaria apenas em poucos casos (certamente não em jogos!), mesmo que fosse possível.
O primeiro passo é exportar um protocolo de dispositivo bruto, já que o Windows emprega acesso direto para operações de troca mais rápidas. Atualmente isso não pode ser feito, pois não há protocolo de dispositivo bruto para o Windows (existe no Linux e em alguns Unices, e talvez o iSCSI possa fazer isso).
Em seguida, você precisa importar o dispositivo na máquina do cliente como um dispositivo físico. Isso também pode ser feito, mas por razões de segurança a maioria das implementações tratam dispositivos de rede como dispositivos removíveis . Pode-se conseguir fazer isso aprimorando a tecnologia ReadyBoost.
Mas o problema agora é que um dispositivo de rede é ordens de magnitude mais lento que um dispositivo de disco físico (que é de magnitude mais lenta que a memória), então você não poderia trocar muito nele sem a moagem do sistema a um impasse.
Você poderia usá-lo somente se os requisitos de RAM velozes fossem baixos e os requisitos de armazenamento em massa fossem enormes e tolerantes a velocidades muito lentas. E só valeria a pena se você tivesse isso em vários computadores. O que significa que você construiu um cluster de computação ... e isso significa que você tem um problema de computação distribuída (que tem seu próprio conjunto de ferramentas e geralmente é abordada descarregando processos inteiros com toda a sua memória para outros nós).
No uso comum, se um swapfile maior disco não o ajudar, porque é muito lento e o thrashing mata suas performances, como poderia uma unidade de rede ainda mais lenta resolver qualquer coisa ?
Cenários
This would allow users to build RAM clusters using all of their home or office computers, that will boost the performance of a single computer for some development/gaming/video tasks, etc.
Para o processamento de vídeo existe a possibilidade de descarregar tarefas em paralelo aos computadores clientes, cada um deles operando em um bloco de quadros de vídeo ou canais diferentes. Existe pesquisa ativa sobre isso. O truque é que todos os clientes têm acesso rápido ao armazenamento em massa (que também pode ser distribuído: há também sistemas de arquivos distribuídos em rede nos quais os arquivos podem residir em mais de um servidor físico), cada um trabalhando em tarefas ligadas à CPU. >
Para o desenvolvimento , existem ferramentas como dmake que permitem particionar uma compilação de projeto (e análise estática, teste e documento ...) para hosts diferentes. Isso também pode ser feito automaticamente com sistemas de produção contínua e construção automatizada , e os resultados são possivelmente muito melhores do que fazer tudo sob demanda de um único host de comando.