¿Red de diseño de transmisión UDP?
broadcast packets (3)
Estoy trabajando en un par de aplicaciones de servidor C ++ / .NET en las que mi servidor (que ejecuta c ++ en linux) transmite un mensaje para mostrar que está vivo a toda la red y mi programa .NET escucha los paquetes y los análisis para obtener el tiempo de actividad. del servidor.
Como he leído, para enviar una transmisión UDP regular a la dirección de transmisión, simplemente tengo que enviar un paquete a 192.168.0.255 (en mi caso 192.168.2.255) o 255.255.255.255. ¿Es esto correcto? ¿Puedo usar la misma dirección de puerto? ¿Hay alguna otra necesidad?
Entiendo el hecho de que si mi programa .NET escucha en esa dirección en particular, es posible recibir paquetes de otras aplicaciones que no sean mi programa de servidor C ++. ¿Hay algún método para "firmar" el paquete en el lado del servidor C ++ para que mi programa .NET lea el encabezado del paquete y vea que es (casi) el que estoy buscando?
Independientemente del idioma que esté utilizando, aquí está mi respuesta:
Con respecto a las direcciones IP de difusión, ambas direcciones son direcciones de difusión, pero los enrutadores no reenviarán la dirección de difusión limitada (que es 255.255.255.255). Es mejor utilizar la dirección de difusión dirigida por subred (192.168.2.255).
Para enviar / recibir una dirección de transmisión, debe definir su dirección de transmisión (dirección IP de transmisión y número de puerto). Por ejemplo: 192.168.2.255 y número de puerto 3000. Las aplicaciones cliente (los remitentes) DEBEN habilitar la opción de socket SO_BROADCAST de la siguiente manera:
int enabled = 1;
setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &enabled, sizeof(enabled));
donde sockfd es el descriptor de socket.
La aplicación del servidor escuchará en un número de puerto específico (puerto 3000). Normalmente, el servidor responderá a cada solicitud mediante un mensaje de unidifusión.
No habrá conflicto mientras no haya una aplicación escuchando en el mismo número de puerto. Su servidor no se ejecutará si otra aplicación está escuchando en el mismo puerto a menos que haya habilitado la opción de socket SO_REUSEADDRESS. Sin embargo, si hay un conflicto, su firma depende de su protocolo (formato de mensaje). Por lo tanto, verifique el formato del mensaje y rechácelo si no sigue el formato del mensaje definido por su protocolo de aplicación.
Para las aplicaciones cliente, el paquete recibido es unidifusión (a menos que tenga otro diseño). Entonces, no hay conflicto en este lado.
Si su programa .NET escucha el tráfico de difusión, recibirá todo el tráfico de difusión en la red que se envía en ese puerto, incluido el tráfico no enviado por su servidor. Podría poner un "marcador" en la carga útil de los mensajes de difusión enviados por su servidor. De esta manera, su programa .NET podría distinguir cuáles le interesan.
Más allá de eso, recomendaría el uso de multidifusión en lugar de la difusión. El tráfico de difusión generalmente está restringido a hosts en la misma subred. En términos sencillos, si tiene un enrutador en su red, un host en el lado A del router no verá el tráfico de difusión enviado por un host en el lado B (y viceversa) porque el enrutador lo "bloquea". Los enrutadores casi siempre reenviarán el tráfico de multidifusión si un host se ha unido al grupo de multidifusión.
También tiene que habilitar la opción de socket SO_BROADCAST en C ++ para enviar tráfico de difusión, o obtendrá un error de permiso denegado:
int broadcastPermission = 1;
setsockopt(socketDescriptor, SOL_SOCKET, SO_BROADCAST, (void*)&broadcastPermission, sizeof(broadcastPermission))