Dieses Whitepaper liefert einen Überblick über die UDP Support Library, welche ab der Version 8.5 von NI LabWindows/CVI verfügbar ist. Zudem werden typische Anwendungsbeispiele, Vergleiche mit anderen gängigen Kommunikationsprotokollen und Beispielcode vorgestellt.
UDP ist eine reduzierte, nachrichtenorientierte Transportschicht, die Ports verwendet, um paketvermittelte Anwendung-zu-Anwendungskommunikation über ein Netzwerk zu ermöglichen. UDP verpackt Nachrichten – bzw. Pakete – in Form eines Datagramms (siehe Abbildung 2).
Ein Datagramm ist logisch in zwei Teile unterteilt: Header und Nachricht. Jeder Datagramm-Header ist wiederum in vier Abschnitte unterteilt (siehe Abbildung 2). Die Mindestlänge eines einzelnen UDP-Datagramms entspricht der Größe des Datagramm-Headers bzw. 8 Byte. Charakteristisch für UDP sind dieser minimale Overhead und die kleine Paketgröße, was sich im Vergleich zu TCP in höherem Durchsatz niederschlägt. Allerdings erfolgt dieser höhere Datendurchsatz auf Kosten der inhärenten Fehlerkontrolle und der Garantie des Datenempfangs, so dass TCP die bessere Wahl in Anwendungen ist, bei denen ein großer Nachrichtenumfang oder Übertragungszuverlässigkeit wichtig sind.
Unterschiede der Protokolle
Zwar sind TCP, UDP und das NI Publish-Subscribe Protocol (NI-PSP, findet Verwendung in den Netzwerkvariablen von LabWindows/CVI) allesamt plattformübergreifende Kommunikationsprotokolle, doch gibt es entscheidende Unterschiede, die festlegen, wann welches Protokoll in einer Anwendung eingesetzt werden sollte.
TCP ist ein verbindungsbasiertes Protokoll. Durch Herstellen einer Verbindung zwischen einem Server und einem Client sind TCP-Server und -Clients in der Lage, so zu kommunizieren, dass die Daten garantiert ankommen und Nachrichten auch in der richtigen Reihenfolge eingehen. Sollte eine Nachricht nicht oder nicht in der richtigen Reihenfolge ankommen, tauscht der TCP-Client Informationen mit dem Server aus, welcher den weiteren Paketaustausch anhält, bis das entsprechende Paket ankommt oder es bei der Verbindung zu einem Timeout kommt. Um eine Verbindung herzustellen, erfordert TCP einen Mindestaustausch von drei Informationspaketen, bevor als viertes Paket eine Antwort eingeht. Die UDP-Kommunikation andererseits erfordert nur zwei Pakete, um eine Antwort zu erhalten. Da UDP keine Fluss- und Fehlerkontrolle in den Overhead seiner Datagramme integriert hat, muss sich der Entwickler der Anwendung um die Implementierung kümmern, falls eine Fehlerprüfung erforderlich ist.
[+] Enlarge Image Abb. 4: UDP- und TCP-Request/Response-Modelle im Vergleich
Vergleichbare Durchsatzverringerungen bei der TCP-Kommunikation existieren im Fall von Paketen in falscher Reihenfolge. Wenn ein Paket in falscher Reihenfolge eingeht, zwingt TCP die gesamte Datenverarbeitung dazu, zu warten, bis das richtige Paket ankommt, was die Effizienz bei Paketverlusten weiter verringert. UDP, das solche Regulierungen nicht vornimmt, ist ideal in Anwendungen, die große Mengen Daten übertragen können und bei denen Paketverlust keine große Rolle spielt, besonders, wenn ein alternativer Rückgewinnungsmechanismus implementiert werden kann.
Die Wahl des Protokolls sollte, je nach Anwendungsanforderungen, von Fall zu Fall erfolgen. Die TCP-Kommunikation ist an sich zuverlässiger als UDP, da TCP für die Verwaltung der Nachrichtenbestätigung (Handshaking) und Rückübertragung im Falle von verlorenen Paketen oder Paketen in falscher Reihenfolge selbst zuständig ist. Diese Mechanismen bedeuten auch größeren Overhead für TCP. TCP erfordert einen dreimaligen Paketaustausch, um eine Socket-Verbindung zu initialisieren. Des Weiteren sorgt TCP für zusätzliche Latenz, wenn garantiert wird, dass die Nachrichten in richtiger Reihenfolge eintreffen und dazu eine Verarbeitung von in falscher Reihenfolge eingegangenen Daten bis zum Eintreffen der fehlenden Pakete verhindert wird. Durch die Möglichkeit von Broadcast- und Multicast-Nachrichten erhöht UDP den Datendurchsatz noch weiter, da jedes Datenpaket nur einmal verarbeitet werden muss, um Nachrichten an mehrere Empfänger zu schicken.
Zwar scheint die Verringerung der Zuverlässigkeit innerhalb eines Kommunikationsprotokolls ein hoher Preis für den erhöhten Datendurchsatz, doch nicht bei allen Anwendungen ist es erforderlich, dass jedes Datenpaket in der richtigen Reihenfolge an sein Ziel gelangt. In Prüfanwendungen ist UDP sehr gut für die schnelle Übertragung redundanter Daten oder Anwendungen geeignet, welche die Übertragung von Informationen an mehrere Rechner erfordern. Im Allgemeinen sind Netzwerkanwendungen, die eine schnellere Verarbeitungszeit erfordern und nur sehr kleine Dateneinheiten austauschen müssen (wenig Sortierungs- und Anordnungsaufwand), gute Kandidaten für UDP.
Vorteile
Anwendungsfälle
Fünfmal kleinere Paketgrößen als TCP
Viele Datenübertragungen mit akzeptablem Datenverlust
Weniger Datenverkehr
Schnelles Daten-Streaming
Broadcast- und Multicast-Unterstützung
Reduzierung von Netzwerkverbindungen
LabWindows/CVI UDP Support Library
Die LabWindows/CVI UDP Support Library, die mit LabWindows/CVI 8.5 eingeführt wurde, bietet integrierte Funktionen für die Datenübertragung über UDP.
Abb. 5: Funktionen der LabWindows/CVI UDP Support Library
Die LabWindows/CVI UDP Support Library stellt bedienfreundliche Funktionen bereit, um UDP-Write- und -Read-Anwendungen zu erstellen. Eine einzelne Callback-Funktion bietet einen Mechanismus, um zu überprüfen, ob neue Daten empfangen wurden. Die LabWindows/CVI UDP Support Library ruft die Callback-Funktionen von Server und Client-Programm auf, wenn folgendes UDP-Ereignis auftritt:
UDP_DATAREADY
Das Modell zur Erstellung von UDP Writer und Reader sieht folgendermaßen aus:
Das folgende Beispiel zeigt eine Anwendung, die Daten über UDP schreibt. Vor der Ausführung sollten die Kommentarzeichen um den gewünschten Codeabschnitte entfernt werden.
// Create a UDP channel from which to send messages. The port number can be any available
// port since we expect only to write, not receive data.
errChk (CreateUDPChannel(UDP_ANY_LOCAL_PORT, &writerChannel));
DisplayPanel (panelHandle);
RunUserInterface ();
DiscardPanel (panelHandle);
Error:
if (writerChannel)
DisposeUDPChannel(writerChannel);
if (error < 0)
MessagePopup("Error", GetGeneralErrorString(error));
return 0;
}
int CVICALLBACK Send (int panel, int control, int event,
void *callbackData, int eventData1, int eventData2)
{
// Depending on which communication method is desired, the message is addressed to one of:
// (1) a specific IP address or DNS-resolvable host name (Unicast),
// errChk (GetCtrlVal(panel, PANEL_ADDR, destAddr));
// (2) a predetermined multicast address to which multiple readers may be subscribed (Multicast),
// errChk (GetCtrlVal(panel, PANEL_ADDR, destAddr));
// (3) the broadcast address, which propagates to every computer on the subnet (Broadcast).
// strcpy(destAddr, UDP_LAN_BROADCAST_ADDR);
// Write the message to a predetermined port number on which all readers will listening.
errChk (UDPWrite(writerChannel, READER_PORT, destAddr, data, strlen(data) + 1));
}
Error:
if (error < 0)
MessagePopup("Error", GetGeneralErrorString(error));
return 0;
}
int CVICALLBACK PanelCallback (int panel, int event, void *callbackData,
int eventData1, int eventData2)
{
if (event == EVENT_CLOSE)
QuitUserInterface (0);
return 0;
Falls während des Aufrufs einer der Funktionen in der LabWindows/CVI UDP Support Library eine Fehlerbedingung eintritt, enthält der Status-Rückgabewert den Fehlercode. Dieser Code ist ein negativer Wert, der den aufgetretenen Fehlertyp angibt.
Die LabWindows/CVI User Interface Library ist jedoch nicht mit diesen Zielgeräten kompatibel. Daher kann RunUserInterface nicht zur Verarbeitung von Nachrichten und UDP-Ereignissen aufgerufen werden. Stattdessen sollte ProcessSystemEvents genutzt werden, um Callback-Ereignisse für die UDP-Kommunikation zu verarbeiten.
Legal This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).
Print
PDF
