UDP portfigyelő C nyelven

C nyelven az UDP-portfigyelő egy olyan program, amely UDP-socketet hoz létre, egy helyi porthoz köti, majd figyeli és feldolgozza a beérkező datagramokat. Az UDP kapcsolat nélküli protokoll, ezért nincs TCP-s kézfogás, amely előre igazolná, hogy a másik végpont elérhető.

A működő figyelő legfontosabb lépései a socket létrehozása, a címstruktúra kitöltése, a porthoz kötés, a datagram fogadása, valamint a hibák és időkorlátok kezelése. A port önmagában nem bizonyítja, hogy egy szolgáltatás egészséges: a célalkalmazásnak ténylegesen válaszolnia kell a megfelelő UDP-adatra.

Miért használunk UDP-t?

Az UDP és a TCP egyaránt szállítási rétegbeli protokoll, vagyis az OSI hétszintű modelljében a hálózati és az alkalmazási réteg között helyezkedik el. Gyakran úgy fogalmaznak, hogy az UDP gyorsabb, a TCP viszont megbízhatóbb.

A TCP automatikus TCP-kézfogást használ a küldő és a fogadó közötti kapcsolat létrehozására. Ez biztosítja, hogy az adatátvitel előtt a forrás és a cél megfelelően össze legyen kapcsolva.

Az UDP ezzel szemben közvetlenül továbbítja az adatot a fogadónak kapcsolat létrehozása nélkül. Ez kiküszöböli a kapcsolatfelépítéshez szükséges időt, ezért az UDP gyorsabb lehet a TCP-nél.

A kapcsolatfelépítés hiánya ugyanakkor azt is jelenti, hogy az UDP kevésbé megbízható a TCP-nél. Az átvitel során adatok veszhetnek el vagy duplikálódhatnak.

Az UDP-datagram felépítése

Az UDP-fejléc nyolc bájtból áll, és négy, egyenként két bájtos mezőre oszlik. Ezek a forrásportot, a célportot, a hosszt és az ellenőrző összeget tartalmazzák.

• Forrásport: a küldő eszköz portjának azonosítására szolgál.
• Célport: annak a portnak az adatait tartalmazza, amelyre az adatot továbbítani kell.
• Hossz: az UDP teljes hosszát adja meg, beleértve a fejlécet és az adatmezőt.
• Ellenőrző összeg: lehetővé teszi a célkészülék számára az UDP integritásának ellenőrzését.

A fejléc két bájtos mezőkből áll, és a fejléc mérete nem változtatható meg, míg az UDP teljes hossza a továbbított adatok méretétől függ. Az UDP-csomagokat IP-csomagok foglalják magukba, a célállomással való kommunikáció pedig az IP-n keresztül történik.

Az ellenőrző összeg használata az UDP-ben nem kötelező, mert a protokoll nem biztosít teljes körű hibakezelést, sorrendhelyreállítást vagy újraküldést.

UDP-portfigyelő feladata C nyelven

Egy UDP-portfigyelő egy meghatározott helyi porton várja a datagramokat. A program általában nem „kapcsolatot fogad”, mint egy TCP-szerver, hanem egy socketen keresztül önálló UDP-adatokat vesz át.

A figyelő a következő feladatokat végezheti:

• UDP-socket létrehozása;
• IPv4- vagy IPv6-cím beállítása;
• a socket hozzárendelése egy helyi porthoz;
• beérkező datagramok fogadása;
• a küldő címének és portjának kiolvasása;
• az üzenet tartalmának ellenőrzése;
• válasz küldése a feladónak;
• időkorlát és hibák kezelése;
• csomagvesztés vagy válaszhiány naplózása.

Egyszerű UDP-portfigyelő Linuxon

Az alábbi program egy IPv4-es UDP-portfigyelőt valósít meg C nyelven. A program a 5000-es helyi UDP-porthoz kötődik, datagramot fogad, kiírja a küldő címét és portját, majd visszaküldi a fogadott adatot.

A program POSIX socket API-t használ, ezért Linux és más POSIX-kompatibilis rendszereken fordítható.

#include <arpa/inet.h>#include <errno.h>#include <netinet/in.h>#include <stdio.h>#include <stdlib.h>#include <string.h>#include <sys/socket.h>#include <unistd.h>#define LISTEN_PORT 5000#define BUFFER_SIZE 4096int main(void){ int sockfd; char buffer[BUFFER_SIZE]; struct sockaddr_in server_addr; struct sockaddr_in client_addr; socklen_t client_len = sizeof(client_addr); sockfd = socket(AF_INET, SOCK_DGRAM, 0); if (sockfd == -1) { perror("socket"); return EXIT_FAILURE; } memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = htonl(INADDR_ANY); server_addr.sin_port = htons(LISTEN_PORT); if (bind(sockfd, (struct sockaddr *)&server_addr, sizeof(server_addr)) == -1) { perror("bind"); close(sockfd); return EXIT_FAILURE; } printf("UDP-figyelo a %d-es porton fut.\n", LISTEN_PORT); for (;;) { ssize_t received; received = recvfrom(sockfd, buffer, sizeof(buffer) - 1, 0, (struct sockaddr *)&client_addr, &client_len); if (received == -1) { if (errno == EINTR) { continue; } perror("recvfrom"); break; } buffer[received] = '\0'; char client_ip[INET_ADDRSTRLEN]; if (inet_ntop(AF_INET, &client_addr.sin_addr, client_ip, sizeof(client_ip)) == NULL) { strncpy(client_ip, "ismeretlen", sizeof(client_ip)); client_ip[sizeof(client_ip) - 1] = '\0'; } printf("Datagram érkezett innen: %s:%u\n", client_ip, ntohs(client_addr.sin_port)); printf("Adat: %s\n", buffer); if (sendto(sockfd, buffer, (size_t)received, 0, (struct sockaddr *)&client_addr, client_len) == -1) { perror("sendto"); break; } } close(sockfd); return EXIT_FAILURE;}

A socket létrehozása

A socket() rendszerhívás hozza létre azt a kommunikációs végpontot, amelyen keresztül a program UDP-datagramokat fogadhat és küldhet.

Az AF_INET az IPv4-címzést jelöli, a SOCK_DGRAM pedig azt, hogy datagramalapú, vagyis UDP-kommunikációt használunk.

sockfd = socket(AF_INET, SOCK_DGRAM, 0);

Hiba esetén a socket() -1 értéket ad vissza. A perror() segítségével kiírható az operációs rendszer által megadott hibaüzenet.

A címstruktúra kitöltése

A sockaddr_in struktúra IPv4-es socketcím tárolására szolgál.

memset(&server_addr, 0, sizeof(server_addr));server_addr.sin_family = AF_INET;server_addr.sin_addr.s_addr = htonl(INADDR_ANY);server_addr.sin_port = htons(LISTEN_PORT);

Az INADDR_ANY azt jelenti, hogy a program az összes helyi hálózati interfészen figyeli a megadott portot. A htons() és a htonl() a gazdagép bájtsorrendjét hálózati bájtsorrendre alakítja.

A porthoz kötés

A bind() hozzárendeli a sockethez a helyi IP-címet és portszámot.

if (bind(sockfd, (struct sockaddr *)&server_addr, sizeof(server_addr)) == -1) { perror("bind");}

Ha a portot már egy másik folyamat használja, vagy a programnak nincs megfelelő jogosultsága, a kötés meghiúsulhat. Egyes rendszereken bizonyos alacsony portszámok használatához emelt jogosultság szükséges.

Datagram fogadása

A recvfrom() egy UDP-datagram fogadására szolgál. A függvény az adat mellett a küldő címét és portját is visszaadja.

received = recvfrom(sockfd, buffer, sizeof(buffer) - 1, 0, (struct sockaddr *)&client_addr, &client_len);

A recvfrom() alapértelmezés szerint blokkoló módon működik: a program addig vár, amíg adat nem érkezik, vagy hiba nem történik.

A puffer méretéből egy bájtot le kell vonni, ha szöveges adatként szeretnénk lezárni a tartalmat, mert a recvfrom() nem tesz automatikusan nullkaraktert a fogadott adatok végére.

A küldő azonosítása

A küldő IP-címe bináris formában érkezik a sockaddr_in struktúrában. Az inet_ntop() ember által olvasható IPv4-formátumra alakítja.

inet_ntop(AF_INET, &client_addr.sin_addr, client_ip, sizeof(client_ip));

A küldő portja hálózati bájtsorrendben található, ezért kiírás előtt a ntohs() függvénnyel kell átalakítani.

Válasz küldése

A sendto() kapcsolat létrehozása nélkül küldi el az adatot a megadott célcímre.

sendto(sockfd, buffer, (size_t)received, 0, (struct sockaddr *)&client_addr, client_len);

Az UDP nem garantálja, hogy a datagram eljut a címzetthez, hogy egyszer és csak egyszer érkezik meg, vagy hogy az eredeti sorrendben érkezik meg.

A program fordítása és futtatása

A forrásfájl például udp_listener.c néven menthető el. GCC használatával a program az alábbi paranccsal fordítható:

gcc -Wall -Wextra -O2 udp_listener.c -o udp_listener

A futtatás a következő paranccsal történik:

./udp_listener

A program indítás után a megadott UDP-porton várakozik. Ha a port foglalt, a bind hibát jelez.

UDP-kliens a figyelő teszteléséhez

A portfigyelő ellenőrzéséhez olyan kliensre van szükség, amely UDP-datagramot küld a célgépre és a célportra.

#include <arpa/inet.h>#include <netinet/in.h>#include <stdio.h>#include <stdlib.h>#include <string.h>#include <sys/socket.h>#include <unistd.h>#define SERVER_PORT 5000int main(void){ int sockfd; const char message[] = "udp teszt"; char buffer[1024]; struct sockaddr_in server_addr; socklen_t server_len = sizeof(server_addr); sockfd = socket(AF_INET, SOCK_DGRAM, 0); if (sockfd == -1) { perror("socket"); return EXIT_FAILURE; } memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(SERVER_PORT); if (inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr) != 1) { fprintf(stderr, "Érvénytelen IPv4-cím.\n"); close(sockfd); return EXIT_FAILURE; } if (sendto(sockfd, message, strlen(message), 0, (struct sockaddr *)&server_addr, sizeof(server_addr)) == -1) { perror("sendto"); close(sockfd); return EXIT_FAILURE; } ssize_t received = recvfrom(sockfd, buffer, sizeof(buffer) - 1, 0, (struct sockaddr *)&server_addr, &server_len); if (received == -1) { perror("recvfrom"); close(sockfd); return EXIT_FAILURE; } buffer[received] = '\0'; printf("Válasz: %s\n", buffer); close(sockfd); return EXIT_SUCCESS;}

A kliens a 127.0.0.1 címen futó figyelőnek küld adatot. A figyelőnek előbb el kell indulnia, különben a kliens a válasz fogadásakor várakozni fog.

Időkorlát beállítása

UDP esetén a válasz elmaradása nem feltétlenül eredményez azonnali hibát. Ha a kliens blokkoló recvfrom() hívást használ, válasz nélkül korlátlan ideig várhat.

Socket-időkorlát állítható be a setsockopt() függvénnyel.

struct timeval timeout;timeout.tv_sec = 3;timeout.tv_usec = 0;if (setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout)) == -1) { perror("setsockopt");}

Ha három másodpercen belül nem érkezik adat, a fogadási művelet hibával térhet vissza. A konkrét hibakód platformonként eltérő lehet, ezért a programnak célszerű az errno értékét is ellenőriznie.

Nem blokkoló UDP-figyelő

Valós idejű alkalmazásokban vagy több feladatot végző programokban előnyös lehet a nem blokkoló socket. Ilyenkor a figyelő nem áll meg hosszú időre egyetlen fogadási műveletben.

#include <fcntl.h>int flags = fcntl(sockfd, F_GETFL, 0);if (flags == -1) { perror("fcntl");}if (fcntl(sockfd, F_SETFL, flags | O_NONBLOCK) == -1) { perror("fcntl");}

Nem blokkoló módban a recvfrom() akkor is visszatérhet hibával, ha éppen nincs elérhető adat. Az ilyen esetet nem feltétlenül valódi hibaként kell kezelni.

Várakozás select() használatával

A select() lehetővé teszi, hogy a program meghatározott ideig várjon arra, hogy a socket olvashatóvá váljon.

#include <sys/select.h>fd_set readfds;struct timeval timeout;FD_ZERO(&readfds);FD_SET(sockfd, &readfds);timeout.tv_sec = 5;timeout.tv_usec = 0;int result = select(sockfd + 1, &readfds, NULL, NULL, &timeout);if (result == -1) { perror("select");} else if (result == 0) { printf("Időtúllépés: nem érkezett UDP-adat.\n");} else if (FD_ISSET(sockfd, &readfds)) { printf("A socket olvasható.\n");}

Az időkorlát azért fontos, mert UDP esetén nincs kapcsolati állapot, amelyből a program automatikusan megállapíthatná, hogy a szolgáltatás elérhetetlen.

Szolgáltatásfigyelés UDP-n

Az UDP-port figyelése több lehet, mint annak ellenőrzése, hogy a porthoz érkezik-e adat. A figyelő egyedi próbaüzenetet küldhet, majd ellenőrizheti a választ.

A szolgáltatás állapotának vizsgálatához a program ellenőrizheti:

• érkezett-e válasz a megadott időkorláton belül;
• megfelelő méretű-e a válasz;
• tartalmazza-e az elvárt adatot;
• helyes-e a válasz formátuma;
• megfelel-e a válasz az elküldött kérésnek;
• ismételt próbálkozások során milyen arányban érkeznek meg a datagramok;
• mennyi idő telt el a kérés és a válasz között.

A válasz puszta jelenléte nem garantálja a szolgáltatás helyes működését. A kulcsszó- vagy tartalomellenőrzés azt igazolhatja, hogy a szolgáltatás a várt adatot adta vissza, nem csupán valamilyen választ küldött.

Egyszerű válaszellenőrzés

if (received > 0 && memmem(buffer, (size_t)received, "OK", 2) != NULL) { printf("A szolgáltatás válasza megfelelő.\n");} else { printf("A válasz nem felel meg az elvárásnak.\n");}

A memmem() nem minden C-környezetben része a szabványos könyvtárnak, ezért hordozható programban saját bájtkereső függvény vagy megfelelő protokollparser használata szükséges.

UDP-port és szolgáltatás különbsége

Az UDP kapcsolat nélküli, ezért egy UDP-port „nyitottsága” nem értelmezhető pontosan ugyanúgy, mint egy TCP-porté. TCP-nél a kapcsolat megnyitása közvetlenül jelezheti, hogy egy folyamat figyel a porton.

UDP-nél a rendszer nem feltétlenül küld választ egy tetszőleges, üres vagy ismeretlen tartalmú datagramra. A válasz hiánya ezért jelentheti azt, hogy a port szűrt, a szolgáltatás nem támogatja az adott kérést, a csomag elveszett, vagy a szolgáltatás nem válaszol.

Az UDP-port tesztelését ezért a szolgáltatás protokolljához illeszkedő payload-dal kell elvégezni. Egy DNS-szolgáltató, egy NTP-szerver, egy SIP-végpont, egy RADIUS-szolgáltatás vagy egy játékszerver eltérő kérésformátumot várhat.

Gyakori UDP-szolgáltatások

Az UDP-t rendszerint időérzékeny műveleteknél használják, mert alacsony késleltetésű kommunikációt tesz lehetővé. Ide tartozhat a videokonferencia, a videostreaming, az online játék, a DNS-lekérdezés és az IP-alapú hanghívás.

A 123-as UDP-portot az NTP használja dátum- és időbeállításokra, valamint hálózati időkiszolgálóval végzett szinkronizálásra. Az 53-as port DNS-hez használható TCP-n és UDP-n egyaránt.

A QUIC a 443-as UDP-portot is használhatja. A 1900-as UDP-porthoz az SSDP, az 5353-as porthoz pedig a Multicast DNS társul.

UDP-figyelő és tűzfal

Ha a figyelő helyesen fut, de külső gépről nem érhető el, a tűzfal vagy a hálózati címfordítás akadályozhatja a kommunikációt. A helyi gép tűzfalán engedélyezni kell a szükséges bejövő UDP-forgalmat.

A Windows tűzfalban a portok és programok számára kivételek konfigurálhatók. A szükséges kivételeket mindig az alkalmazás és a használt felügyeleti funkciók határozzák meg.

Linuxon például az iptables vagy más tűzfalrendszer szabályai határozzák meg, hogy az adott UDP-port forgalma engedélyezett-e. A tűzfal megnyitása önmagában nem indít el szolgáltatást: a háttérben ténylegesen futnia kell a C-programnak és a megfelelő porthoz kell kötődnie.

Ha a program router mögött fut, a külső UDP-forgalomhoz porttovábbításra is szükség lehet. A porttovábbításnál a router külső portját a belső gép megfelelő IP-címére és UDP-portjára kell irányítani.

Hálózati hibák elkülönítése

Az UDP-figyelő hibakeresésekor célszerű először ugyanazon a gépen tesztelni a programot, majd helyi hálózatról, végül külső hálózatról próbálkozni. Így elkülöníthető a programhiba, a helyi tűzfal, a hálózati útvonal és a router konfigurációja.

1. Indítsd el a C-programot a célgépen.
2. Ellenőrizd, hogy a bind() sikeresen végrehajtódott-e.
3. Küldj tesztdatagramot a 127.0.0.1 címre.
4. Ismételd meg a tesztet a helyi hálózati IP-címmel.
5. Ellenőrizd a gép tűzfalának bejövő UDP-szabályait.
6. Vizsgáld meg a router porttovábbítását, ha külső hálózatból tesztelsz.
7. Rögzítsd a forgalmat Wiresharkkal vagy tcpdump-pal.

A Wireshark lehetővé teszi az UDP-forgalom valós idejű rögzítését és elemzését. A tcpdump szintén használható a csomagok megfigyelésére, például egy adott UDP-port forgalmának szűrésére.

Forgalom ellenőrzése tcpdump-pal

sudo tcpdump -n -i any udp port 5000

Ha a küldő csomagja látható, de válasz nem jelenik meg, a hiba a C-programban, a szolgáltatás logikájában vagy a válasz küldésében lehet. Ha a csomag egyáltalán nem látható, a probléma a küldő oldalon, az útvonalon vagy egy tűzfalon lehet.

IPv6-os UDP-portfigyelő

IPv6 használatakor az IPv4-es AF_INET helyett az AF_INET6 címcsaládot kell megadni, és IPv6-os címstruktúrát kell használni.

#include <arpa/inet.h>#include <netinet/in.h>#include <sys/socket.h>int sockfd = socket(AF_INET6, SOCK_DGRAM, 0);struct sockaddr_in6 addr;memset(&addr, 0, sizeof(addr));addr.sin6_family = AF_INET6;addr.sin6_addr = in6addr_any;addr.sin6_port = htons(5000);bind(sockfd, (struct sockaddr *)&addr, sizeof(addr));

IPv4 és IPv6 támogatásához a programnak külön socketeket is kezelnie kell, vagy olyan címfeloldási megoldást kell alkalmaznia, amely mindkét címcsaládot támogatja.

Robusztusabb címkezelés getaddrinfo() használatával

A getaddrinfo() használata rugalmasabb, mint a közvetlen IPv4-specifikus címkezelés, mert több címcsalád és címformátum támogatását teszi lehetővé.

#include <netdb.h>struct addrinfo hints;struct addrinfo *result;memset(&hints, 0, sizeof(hints));hints.ai_family = AF_UNSPEC;hints.ai_socktype = SOCK_DGRAM;hints.ai_flags = AI_PASSIVE;int error = getaddrinfo(NULL, "5000", &hints, &result);if (error != 0) { fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(error));}

A visszaadott címlistán végig lehet haladni, és minden címhez meg lehet próbálni socketet létrehozni és kötést végrehajtani.

UDP előnyei és korlátai

Az UDP kevés működési többletet generál, ezért időérzékeny alkalmazásokhoz alkalmas. Olyan egyszerű kérés-válasz kommunikációban is használható, ahol a hibaarány nem okoz jelentős problémát.

• alacsony késleltetésű adatátvitel;
• nincs kapcsolatfelépítési kézfogás;
• kisebb protokolltöbblet;
• egyszerű kérés-válasz kommunikáció;
• multicast- és többcélú továbbítás támogatása;
• streaming és valós idejű kommunikáció támogatása.

Az UDP egyik legnagyobb korlátja a megbízhatatlanság. Nincs beépített sorrendvezérlés, újraküldés vagy teljes körű adatfolyam-szabályozás.

• adatvesztés történhet;
• datagramok duplikálódhatnak;
• a csomagok sorrendje felcserélődhet;
• torlódásvezérlés hiányában a küldő túlterhelheti a hálózatot;
• az UDP-forgalom DDoS-támadások eszköze lehet;
• fájlátvitelhez és levelezéshez önmagában nem megfelelő.

Megbízhatóság hozzáadása az alkalmazási rétegben

Ha egy UDP-alapú alkalmazásnak mégis szüksége van megbízhatóságra, azt az alkalmazási protokollban kell megvalósítani. A program sorszámot, nyugtát, időkorlátot, újraküldést és esetleg hibajavító mechanizmust vezethet be.

Egy egyszerű alkalmazási szintű üzenet például tartalmazhat üzenetazonosítót, sorszámot, adatméretet és ellenőrző összeget. A fogadó a hibás vagy már feldolgozott üzeneteket elutasíthatja.

A szükséges megbízhatósági funkciók megvalósítása azonban növeli a program összetettségét. Ha az alkalmazásnak megbízható, rendezett és torlódásvezérelt adatátvitelre van szüksége, a TCP használata megfelelőbb lehet.

Gyakori programozási hibák

Nullkarakter hozzáadása bináris adathoz

A fogadott UDP-adat nem feltétlenül szöveg. Ha a program nullkaraktert ír a pufferbe, azt csak akkor szabad megtenni, ha van elegendő hely, és az adatot szövegként kívánjuk kezelni.

Hálózati bájtsorrend figyelmen kívül hagyása

A portszámokat htons() segítségével kell hálózati bájtsorrendre alakítani, kiolvasáskor pedig ntohs() használata szükséges.

A válasz hiányának félreértelmezése

UDP esetén a válasz hiánya nem bizonyítja egyértelműen, hogy a port zárva van. A csomag elveszhet, a tűzfal eldobhatja, vagy a szolgáltatás csak megfelelő formátumú kérésre válaszolhat.

Puffer túlcsordítása

A fogadási puffer méretét mindig korlátozni kell. A program nem írhat több adatot a pufferbe, mint amennyi ténylegesen rendelkezésre áll.

Hibák figyelmen kívül hagyása

A socket(), bind(), recvfrom(), sendto(), setsockopt() és címátalakító függvények visszatérési értékét ellenőrizni kell.

Biztonsági szempontok

Egy internet felé nyitott UDP-port folyamatosan kaphat ismeretlen vagy rosszindulatú datagramokat. A programnak nem szabad megbíznia a feladó által küldött adatokban.

• ellenőrizd a datagram hosszát;
• ne használd közvetlenül parancsként a beérkező szöveget;
• korlátozd az erőforrás-felhasználást;
• naplózd a hibákat és a gyanús forgalmat;
• használj szükség esetén forráscím- vagy hitelesítési ellenőrzést;
• csak a szükséges interfészeken és portokon figyelj;
• tartsd naprakészen a tűzfalszabályokat.

A korlátlan naplózás szintén problémát okozhat, mert nagy mennyiségű UDP-forgalom megtöltheti a lemezt vagy túlterhelheti a programot. A naplózást célszerű méret, idő és eseménytípus alapján korlátozni.

Összetettebb UDP-monitorozás

Az UDP-monitorozás akkor ad használható eredményt, ha nem csak a port elérhetőségét, hanem a válasz minőségét is méri. A figyelő rögzítheti a válaszidőt, a sikertelen próbálkozásokat és a csomagvesztési arányt.

Az UDP-kapcsolat nélküli működése miatt bizonyos mértékű csomagvesztés előfordulhat. A monitorozásban ezért beállítható egy elfogadható veszteségi küszöb, amely felett a szolgáltatás hibásnak tekintendő.

A földrajzilag eltérő helyekről végzett ellenőrzések megmutathatják, ha egy szolgáltatás csak egy adott hálózati útvonalról vagy régióból nem érhető el.

UDP-figyelő gyakorlati alkalmazásai

UDP-portfigyelővel vizsgálható DNS-szerver, NTP-szolgáltatás, SNMP-végpont, SIP- vagy RTP-infrastruktúra, RADIUS-hitelesítési szerver, játékszerver, VPN-végpont, STUN/TURN-szerver és más UDP-alapú szolgáltatás.

Otthoni laborban a figyelő használható játékszerver, WireGuard-végpont, helyi DNS-feloldó, médiafelfedezési szolgáltatás vagy hangkommunikációs port ellenőrzésére.

Vállalati környezetben a DNS-lekérdezések, a VoIP-forgalom, a RADIUS-hitelesítés, az NTP-időszinkronizálás és az SNMP-alapú hálózati felügyelet ellenőrzése lehet fontos.

Az UDP-portfigyelő C nyelven tehát nem egyszerűen egy port megnyitását jelenti, hanem socketkezelést, datagramfeldolgozást, időkorlátokat, válaszellenőrzést, hibakezelést és a hálózati környezet vizsgálatát is magában foglalja.

tags: #listener #udp #in #port #c