Discussion :

[ootsun]

Bonjour,

j'ai du mal à visualiser l'architecture que prendra mon projet. Je fais de la VOIP.

J'ai un serveur VOIP qui peut recevoir et initier des appels, un front qui permet à un utilisateur de lancer un appel et une servlet pour répondre au front et demander au serveur VOIP d'initier un appel. Jusque là tout fonctionne



Maintenant j'aimerais pouvoir notifier le front lorsque l'utilisateur est appelé par l'un de ses clients. Pour l'instant, j'ai écrit un programme qui se connecte à mon serveur VOIP et qui, dès que mon utilisateur reçoit un appel, affiche dans la console la fiche du client (je compare le numéro de l'appelant avec les numéros de mes clients présents en DB).

La prochaine étape sera d'envoyer la fiche client au frontend. Je pense utiliser des sockets pour pouvoir notifier mon frontend. Mais comment faire pour que mon back à la fois écoute le front (si l'utilisateur veut passer un appel) et le serveur VOIP (si un appel survient et qu'il faut prévenir le front) ?



Devrais-je faire du multi-threading ou bien faire deux applications en back (une qui écoute le front et l'autre le serveur VOIP) et les faire communiquer entre elles également via des sockets ou y a-t-il une meilleure solution ?

Merci d'avance,

OoTsun.

[dinobogan]

Il faut forcément quelque chose d'automatique ?
L'utilisateur ne pourrait-il pas cliquer sur un bouton "fiche client" lorsqu'il est en ligne ?

[ootsun]

Oui, il faut que ça soit automatique. Si l'utilisateur est droitier, il tiendra son téléphone dans la main droite et devra donc faire une manipulation pas très "user-friendly" pour prendre sa souris et clique sur "voir fiche client". D'autant qu'il peut ainsi laisser le téléphone sonner 15 sec pour vite lire les infos importantes comme le nom, les dernières commandes, etc

[dinobogan]

Une autre possibilité : le front fait un check toutes les secondes pour savoir s'il doit se mettre à jour.
Combien as-tu de clients au maximum ?

[yildiz-online]

Pour les notifications client en "temps réel", il y a plusieurs possibilités:

-polling, long polling
-websocket
-server-sent events

[ootsun]

Merci pour vos propositions, en cherchant par moi-même je pense avoir trouvé la bonne architecture et j'ai commencé à l'implémenter. J'utilise des sockets et du multi-threading.

Pour la partie "Notifier l'utilisateur lorsqu'il reçoit un appel", j'ai :
-Une classe contenant deux Hashtable. Le premier est <Numéro d'un utilisateur, Son socket> et le deuxième est <Numéro d'un utilisateur, Numéro du client en train de l'appeler>.
-Un main lançant deux Thread (dont le constructeur demande un objet de la première classe, cet objet sera donc partagé!).

1. Ecoute le serveur VOIP. Dès qu'un appel entrant est détecté, place une nouvelle entrée dans la 2ème table.
2. Joue le rôle de serveur. Lance lui aussi deux threads.
   
   1. Le premier écoute les connexions entrantes via la classe ServerSocket. Lorsqu'un utilisateur (frontend) essaye de se connecter, accept() et écoute une fois. En effet, l'utilisateur enverra son numéro de téléphone après s'être connecté. Le thread rajoute ensuite dans la première table cette nouvelle entrée (le numéro du nouvel utilisateur et le socket associé).
   2. Le second, lui, ne fait que regarder si la deuxième table contient quelque chose. Si elle n'est pas vide, ça signifie qu'un (ou plusieurs) appel vient d'arriver. Il faut notifier le client! Il utilise donc la première table pour envoyer un message au client puis remove() l'entrée.

Je crois que ça n'est pas très optimisé ("Le second, lui, ne fait que regarder si la deuxième table contient quelque chose.[...]" --> boucle infinie qui utilise des ressources CPU pour rien la plupart du temps). J'améliorai le projet lorsque ça fonctionnera