Unicast - Broadcast
On trouve au moins trois grandes catégories :
- les adresses Unicast : à destination d’un seul hôte
- les adresses Broadcast (IPv4) : à destination de tous les hôtes du réseau
- les adresses Multicast (IPv4 et IPv6) : à destination de certains hôtes du réseau.
Localhost
Source : Wikipedia
Localhost (l’hôte local ) est le nom habituel qui désigne une interface logique de l’ordinateur local.
En informatique, on travaille souvent en mode client-serveur : une ou plusieurs machines envoient des requêtes à un serveur central qui envoie les réponses appropriées.
Pour un programme informatique impliquant des échanges sur un réseau, il n’est pas nécessaire de disposer de plusieurs machines physiques ni même virtuelles :
la même machine physique peut parfaitement héberger le serveur et un ou plusieurs clients, exactement dans les mêmes conditions : en communiquant par des ports.
Le ou les clients hébergés sur une machine utilisent le protocole IP pour communiquer.
Il importe peu de savoir où se trouvent physiquement les programmes.
Le nom localhost est associé à une adresse IP (toutes les adresses comprises entre 127.0.0.1 et 127.255.255.255 dont la plus utilisée est 127.0.0.1).
Après cette courte théorie, passons à la pratique :
Avec comme base de travail : le trafic en mode FT8
Ici on ne détaille pas les configurations mais on parle uniquement de principes …
Unicast :
Dans tout cet article j’utilise le terme JTDX, mais il faut comprendre JTDX ou WSJT les 2 logiciels fonctionnent de la même manière
Lorsque l’on utilise que JTDX (ou WSJT) et que l’on veut envoyer nos QSOs vers son logiciel de Log
Nous sommes en UNICAST c’est à dire que nous sommes sur un même ordinateur (LocalHost) et que JTDX ne dialogue qu’avec 1 seul hôte qui est votre logiciel de Log.
JTDX envoie donc le QSO sur l’adresse IP 127.0.0.1 port 2237 (par défaut mais on peut choisir un autre port)
et le logiciel de Log est en écoute sur cette même adresse IP et ce même port.
Donc lorsque JTDX ajoute 1 QSO le logiciel de Log reçoit une trame envoyée par JTDX qui contient toutes les informations nécessaires pour que le logiciel de Log puisse ajouter ce QSO dans son Log.
JTDX
Logger 32
ATTENTION :
Logger 32 utilise les ports UDP et TCP qu’en réception et n’envoie rien via ces ports.
Ce qui veut dire que L32 peut recevoir et traiter une trame qu’il reçoit sur un port UDP (ou TCP) mais il ne peut en aucun cas envoyer quoi que ce soit via ces ports.
Ce qui signifie que si vous cliquez sur une station dans le BandMap de L32 rien n’est envoyé vers JTDX.
Donc pour faire un QSO il faut cliquer sur les calls que vous souhaitez dans JTDX et non dans L32.
Intégrons maintenant dans notre chaîne logicielle un autre logiciel : par exemple JTAlert
Cette fois-ci , JTDX envoie toujours sa trame sur son même port mais c’est JTalert qui intercepte cette trame et ceci automatiquement.
Ceci est réalisé parce que JTAlert lit par défaut les réglages de JTDX et utilise automatiquement le même port que celui que vous avez validé dans JTDX.
Donc votre logiciel de Log ne peut plus utiliser ce port, il faudra donc lui dire d’être à l’écoute sur un autre port.
Il faut donc que JTAlert envoie également la trame vers le logiciel de Log.
Mais chaque logiciel ne peut dialoguer qu’avec celui qui est « avant » ou « après » lui.
C’est à dire que dans cet exemple JTAlert peut dialoguer dans les 2 sens avec JTDX mais JTDX ne peut pas dialoguer directement avec le logiciel de Log.
Par contre JTAlert peut renvoyer (on dit Forwarder) la trame reçue de JTDX vers le logiciel de Log.
On est toujours en mode UNICAST c’est à dire on est bien sur le même ordinateur (Localhost) et chaque logiciel ne peut dialoguer que via un seul port avec le logiciel « à côté » de lui.
JTDX avec JTAlert et votre logiciel de Log
Broadcast :
Broadcast introduction :
Et arrive un autre logiciel : GridTracker
Nous détaillerons dans un autre article ce logiciel, mais pour résumer Gridtracker fait la même chose que JTAlert mais apporte en plus quelques très bonnes fonctionnalités comme par exemple :
– Affichage d’une carte mondiale avec le trafic en temps réel sur la bande sélectionnée
– Affichage toujours sur une carte mondiale des Calls qui vous sont nécessaires dans cette bande et dans ce mode
– On peut lui demander par exemple de n’afficher que les Calls dont vous avez besoin pour compléter tel ou tel diplôme
– Affichage dans un tableau des États US ainsi que l’azimut et également le niveau de réception
– Bien sûr il est possible de trier tout ça comme on veut
– etc …
Gridtracker
Et donc beaucoup d’OMs ont voulu utiliser ce nouveau logiciel mais tout en gardant ce qu’ils utilisaient avant
C’est à dire qu’ils voulaient garder l’ensemble JTDX – JTAlert – Log et intégrer Gridtracker entre JTAlert et leur logiciel de Log pour obtenir :
JTDX – JTAlert – Gridtracker – Log
Tout cela fonctionne très bien SAUF que si l’on clique sur un DX vu par Gridtracker ça ne commande pas JTDX.
Effectivement si on reste en UNICAST comme nous l’avons vu précédemment, seul le premier logiciel est capable de commander JTDX donc seul JTAlert peut commander JTDX.
Ce fait a été très longuement discuté sur les forums Américains et énormément d’utilisateurs ont demandé aux auteurs de JTDX et de Gridtracker de modifier leurs logiciels afin qu’ils acceptent aussi bien le UNICAST que le BROADCAST
N’importe quel logiciel peut commander JTDX
( à condition bien sûr que votre logiciel de Log accepte le Broadcast ce qui malheureusement n’est pas le cas de L32).
Le broadcast est donc utile si vous utilisez au moins 3 logiciels et que vous voulez que chaque logiciel (ou que n’importe quel logiciel) puisse commander directement JTDX
JTDX - JTAlert - Gridtracker et L32 en mode Broadcast
On peut donc utiliser cet ensemble de logiciels, mais à l’usage on s’aperçoit vite que Gridtracker peut remplacer JTAlert sans aucun problème et donc on peut se retrouver tout simplement avec JTDX – Gridtracker – Log32
Mais là on se retrouve en mode Unicast si on utilise L32.
C’est Gridtracker qui forwarde la trame qu’il a reçu de JTDX (comme le faisait JTAlert).
Pour ceux qui veulent utiliser cet ensemble de logiciel, vous pouvez en rester là.
Mais alors quelle utilité du Broadcast
si on utilise JTDX - Gridtracker et L32 ?
Nous avons vu que :
– Le broadcast permet à des logiciels de dialoguer entre eux à conditions qu’ils soient dans le même réseau
– JTDX sait utiliser le mode Broadcast
– Gridtracker sait utiliser le mode Broadcast
– Logger32 ne travaille qu’en mode Unicast
– Logger32 accepte de recevoir la trame contenant le QSO réalisé soit via un port UDP ou soit via un port TCP
Nous allons exploiter d’autres particularités :
– JTDX est capable de forwarder en local la trame contenant le QSO qui vient d’être réalisé via un port TCP (ou UDP)
– Gridtracker est capable de forwarder la trame contenant le QSO qui vient d’être réalisé via un port UDP
Problème avec le second port UDP de JTDX :
Utilisation de 2 ordinateurs :
La première fonctionnalité que l’on va exploiter est le fait que le Broadcast permet d’utiliser des logiciels
qui sont dans un même réseau mais donc pas forcément sur le même PC.
Cette approche est vraiment importante :
Si vous utilisez un seul ordinateur vous n’avez pas le choix, mais si vous avez la chance d’avoir au moins 2 ordinateurs alors il suffit que les 2 ordinateurs soient dans le même réseau.
Cela va permettre « d’alléger » le premier ordinateur et donc on va utiliser par exemple Gridtracker (qui est le plus gourmand en utilisation mémoire) sur le second ordinateur.
Si comme moi vous utilisez un petit ordinateur portable, cela va permettre de « soulager » ce PC Portable en terme d’utilisation mémoire et d’utilisation de CPU.
Comme JTDX et Gridtracker seront ; certes pas sur le même ordinateur mais sur le même réseau ; ils pourront communiquer entre eux sans aucun problème.
Même mieux les 2 ordinateurs peuvent être totalement différents :
– Ici j’utilise à la fois un Macintosh et un PC
– Gridtracker fonctionnant parfaitement sur Macintosh
J’utilise donc Gridtracker sur Macintosh qui communique sans aucun problème avec JTDX qui lui est lançé sur un PC portable.
Ce qui signifie que si je clique sur un call dans Gridtracker, ce call est bien envoyé à JTDX et JTDX lance donc automatiquement le cycle de QSO.
La seconde fonctionnalité que nous allons utiliser est que JTDX permet d’envoyer la trame contenant le QSO en local via un port TCP.
C’est donc via ce port que L32 va recevoir cette trame et va donc pouvoir ajouter ce QSO au log.
Le PC local est donc « déchargé » de cette application (Gridtracker) ce qui libère de la mémoire et du CPU.
C’est cet environnement que j’utilise et qui fonctionne très bien.
Conclusion :
C’est beaucoup plus difficile à expliquer par écrit mais j’espère que cela vous aura permis de mieux comprendre l’utilisation de Unicast et Broadcast dans un environnement Radio-Amateur.
N’hésitez pas à me laisser un commentaire, à me contacter via les réseaux sociaux ou en direct via le formulaire de contact
Mais surtout n’hésitez pas à me corriger si vous voyez une erreur ou mieux n’hésitez pas à me détailler votre environnement sans doute avec d’autres logiciels de Log.
Octobre 2020
Ça me semble très intéressant…