RMI & threading ou autre moyen de comm ?

Bonjour à tous,

Je développe une application serveur-client avec un exécutable tournant en continue (sorte de daemon) sur le serveur et un client distant permettant d'exécuter des fonctionnalités disponibles sur le serveur.

J'ai pensé au RMI pour la communication. L'optique du dev' est de permettre l'utilisation d'une multitude de clients pour le serveur. Est-ce que le RMI permet de tenir la charge en supposant qu'il puisse y avoir 10 000 clients (par exemple) exécutant des méthodes sur le serveur ? (peu importe le traitement du serveur... écrire dans un fichier par exemple).

Le multi-threading peut-il être éventuellement utilisé ?

Je signale que je débute en RMI, j'étais plus remoting .NET !!!

;)

Bon alors... apparement d'après mes recherches il semblerait que le JRE gère automatiquement un pool de thread à chaque utilisation d'un objet remote (comme en .NET donc) mais je ne sais pas trop si avec un grand nombre de connexions le RMI tient la charge. Est-ce qu'il y a des restrictions matérielles ? (comme par exemple : CPU important (pour le multi-threading), bande passante large, RAM...).

Autre question, est-ce que le RMI est asynchrone ?

Une réponse serait la bienvenue !!! (le RMI n'a pas l'air d'être un sujet passionnant :? )

Le RMI sérialize les réponse aux client, et vis-versa désérialize les question. Le principe du RMI, c'est un protocol qui permet de partager un objet entre le client et le serveur. Le problème,c'est que tout paramètre d'appel à une méthode ou résultat d'appel est sérializé sur la ligne TCP/IP et réceptionné pour être désérializer à l'autre bout. Si t'as 10.000 client en simultané, tu va souffrir! Ca veux dire déjà 10.000 objet (minimum) en partage sur la ligne (les objets RMI de contact). Probablement plus, a moins que tu ne partage qu'une simple facade :)

Je te conseillerais d'utiliser d'autres chose qui tiennent mieux la charge et qui ne nécessitent pas un canal ouvert en permanence. Plutot un truc qui fait "ouverture du canal, question, réponse, fermeture", tu évite comme çà le goulot réseau et la maintenance trop forte. Enfin tout dépend de ton application, mais si tu veux du massif en RMI. Tu dois faire extrèmement gaffe à ce que t'envoie comme réponse (j'ai travaillé pour une boite qui envoyait à un même client, trois à 4 fois par minutes une liste complète de code postaux avec villes, çà saturait pour un seul client une ligne à 10Mbits). Donc quant tu fait tes objet RMI, fait gaffe à ton interface, qu'elle soit légère dans ses réponses/paramètres :)

Je vais probablement laisser tomber la piste du RMI alors...

Est-ce que les Web Services permettraient de résoudre ce problème ?

up ?

Essaie déjà de faire un hello world en RMI et de lancer 10000 clients si ça marche tu pourras envisager de l'utiliser.
Sinon les web services tu peux oublier, vu le volume de données que ça génère (tout est en XML donc c'est assez verbeux), ça coutera trop "cher" au niveau performances.

Si tu veux gérer une multitute de clients tu devrais regarder du coté des java.nio
ils sont là pour ça.