Discussion :

[r1-1024]

Bonjour à tous,

Je dois créer un serveur utilisant une bibliothèque native (jni).
Ce serveur aurait qq sessions utilisateurs 100 grand maximum qui utiliseraient chacune cette bibliothèque native.

Il me faut impérativement séparer chaque session utilisateur dans un process java afin d'éviter qu'un core dump de la lib jni ne provoque un core dump global du serveur.

Le serveur frontal doit donc pouvoir:
-lancer une nouvelle jvm fille qui charge la lib jni (le serveur frontal ne la chargerait jamais)
-lui déléguer qq services de calculs lourds le temps de la session (qui peut durer plusieurs jours)
-éteindre la jvm fille

Toutes les jvm filles sont locales.

Je me demandait quelle api utiliser.
Pour l'instant je suis parti sur du rmi, mais j'aimerai éviter d'ouvrir un port pour chaque jvm fille (ce qui contraint l'admin à autoriser une plage de port ouverts).

J'aurai aimé pourvoir piper les flux rmi dans le stdin/stdout des jvm filles.

Si qq'1 a une idée ?

Merci

[tchize_]

vous avez plusieurs possibilité

1) la socket réseau (ce que vosu faites). Ca ne devrais pas impliquer de travail de l'admin, vous pouvez dans votre maitre ouvrir un socket aléatoire et laisser la fille s'y connecter. Normalement toutes les applis peuvent ouvrir des sockets aléatoire, plus particulièrement si elles sont liées uniquement à 127.0.0.1

2) stdin/stdout. Vous utilisez getOutputStream/getInputStream/getErrorStream sur l'objet Process de la nouvelle jvm créée, dans la jvm fille vous utilisez System.in/err/out

3) Les pipes nommés sous linux. vous créez un out plusieurs pipes nommés via mkfifo. Un process lit ce pipe nommé, un autre y écrit. Similaire à lier via des sockets TCP, sans besoin de la couche réseau

4) Toujours sous linux, les sockets de domaine (appelées aussi IPC sockets). Vous aurez besoin d'une librairie native comme junixsocket. Avantage sur les tubes nommés: bi directionnelles et supporte les datagrammes. Avec junisocket, comme ça se présente comme des sockets standard java, vous pourriez mettre directement votre RMI actuel dessus.

5) éventuellement, la zone mémoire partagée, nécessite une librairie native a priori, j'ignore si c'est réellement faisable en java.

[r1-1024]

1) la socket réseau (ce que vosu faites). Ca ne devrais pas impliquer de travail de l'admin, vous pouvez dans votre maitre ouvrir un socket aléatoire et laisser la fille s'y connecter. Normalement toutes les applis peuvent ouvrir des sockets aléatoire, plus particulièrement si elles sont liées uniquement à 127.0.0.1

Ouvrir un port serveur sur la jvm fille implique il me semble une ouverture de port de la part de l'admin (même en 127.0.0.1).

Utiliser un port du serveur frontal est une très bonne idée :
-1.1 un port de communication extérieur vers les clients.
-1.2 un port de communication sur lequel les jvm filles se connectent.

le pb en 1.2 est que la sérialisation d'un call back pour appeller une méthode de la jvm fille (un service) alors qu'elle n'est pas en mode serveur mais en mode client implique nécessairement l'ouverture d'un port serveur côté jvm fille (Il faut regarder le code source jvm pour s'en apercevoir: l'appel à une méthode en rmi n'est possible que ds le sens client => serveur, donc un call back en rmi ne peut se faire que si les deux jvm ont des ports ouverts en mode serveur).

Donc de nouveau une autorisation de l'admin pour l'ouverture de port.

2) stdin/stdout. Vous utilisez getOutputStream/getInputStream/getErrorStream sur l'objet Process de la nouvelle jvm créée, dans la jvm fille vous utilisez System.in/err/out

C'est ce que je pensais utiliser mais le protocole rmi ds stdin/sdtout risque de facilement être perturbé par des loggers par ex (c bof)
Et quelle api utiliser ?

3&4) : trop spécifique au système même si mkfifo est la solution la plus propre (au passage merci pour junixsocket )

5) Il me semble impossible en java.

D'autres idées / réponses ?

[tchize_]

si vous restez sur du réseau (point 1), faites tourner ce réseau sur 127.0.0.1 uniquement et vous ne devriez avoir aucun soucis de droit. Il est extrèmement rare (et bizarre) qu'un admin aie configuré un serveur pour interdire d'ouvrir un port sur 127.0.0.1. D'autant plus que, le port étant local et accessible uniquement localement, seule une application locale peut s'y conencter, le firewall n'est en rien impliqué dans l'histoire, puisque rien n'atteind la carte réseau. Bref, on est typiquement dans la même zone de droit qu'une socket de domaine unix. Quand à savoir si comment configurer RMI pour qu'il fasse des bind sur 127.0.0.1 (loopback) et non pas sur 0.0.0.0 (all interfaces), ça dépasse mes compétence. Si ce n'est pas possible, il faudra s'orienter vers une autre solution ou utiliser le réseau sans le RMI.


Au point 2. Il n'y a pas d'api a utiliser. vous allez devoir vous assurer que les fille n'écrivent pas de logs sur stdout (configuration ad-hoc des loggers). Ensuite vous établissez, comme on le fait quand on attaque directement la couche réseau, votre propre protocole binaire qui utilise ces deux stream pour communiquer. Ne rêvez pas, RMI ne fonctionnera pas dessus.