Ci sono una serie di importanti informazioni mancanti:
- Perché è rilevante OpenMPI?
- Perché è eterogeneo rilevante?
- Qual è il lavoro che il server sta orchestrando?
- Si parla di un thread per connessione è un problema.
Se stai utilizzando Boost :: Asio e stai riscontrando il problema di un thread per client, probabilmente stai facendo qualcosa di sbagliato. Assicurati di fare le cose in modo asincrono e non bloccandole qualsiasi filo troppo lungo. Questa è probabilmente la cosa più facile da fare al momento.
OpenMPI non è quello che ti serve. MPI è stato progettato originariamente per architetture di memoria distribuita. È possibile utilizzarlo su Internet, ma probabilmente non è la scelta migliore. Il fatto che parli di eterogeneo e MPI mi fa pensare che hai fatto un corso di CS in HPC. Questo non è rilevante in questo caso.
Quando si decide su un protocollo e un'architettura, il tipo di lavoro che i client stanno facendo è importante, il modo in cui si condivide lo stato tra i client e il server e la durata di ciascun messaggio per l'elaborazione.
Se stai ottimizzando il throughput, un overhead per messaggio è meno importante, quindi i formati di serializzazione dettagliati come XML e JSON sono ok. È anche possibile eliminare le connessioni tra i processi di elaborazione dei messaggi, ovvero il server non deve mantenere un thread.
Se stai cercando di mantenere le cose a bassa latenza, allora l'overhead del messaggio è importante, quindi stai mantenendo una connessione e usando i formati di serializzazione terse.
Un Message Broker è uno schema architettonico che potresti prendere in considerazione. È responsabile della distribuzione dei messaggi tra le tue applicazioni.
È meglio usare protocolli internet-friendly, come HTTP. Non ti devi preoccupare dei proxy o del NAT traversal. Internet può essere considerato un enorme sistema distribuito con milioni di client eterogenei. REST è uno stile architettonico ispirato a quello che potrebbe essere appropriato.
Suppongo che:
- il server produce elementi di lavoro per i client e aggrega le risposte.
- i tuoi clienti ricevono un messaggio, alcuni funzionano e restituiscono una risposta.
La mia scelta di tecnologia predefinita, sarebbe un server web per implementarlo. Avrebbe due URL. Uno in cui i clienti possono ottenere un nuovo lavoro, l'altro per i clienti alle risposte POST.
All'inizio, il client dovrebbe eseguire periodicamente il polling per il nuovo lavoro (è possibile utilizzare le richieste HTTP WS o Long Poll). Quando il server restituisce un oggetto di lavoro, un cliente dovrebbe consumarlo. Ogni elemento di lavoro deve essere contrassegnato con un ID univoco, in modo da garantire che non vi siano duplicati e correlare le risposte con il lavoro iniziale.
Quando il client ha completato l'attività, deve POST la risposta e riavviare il processo di polling per il nuovo lavoro.
I server Web non funzionano bene per le lunghe richieste, quindi vorresti consegnarlo a qualcos'altro, magari tramite un DB, IPC o una coda di messaggi.
Il server quindi non deve preoccuparsi delle funzionalità di ciascun client (quindi rende irrilevante l'eterogeneo). I clienti consumeranno solo alla velocità che possono.