Datenkonsistenz von AG_RECV

[oid]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen ,

Folgende Situation:
Ich empfange auf einem Lean-CP ab und zu ein einzelnes UDP-Paket fester Länge (einige Bytes) mittels AG_RECV. AG_RECV schreibt die empfangenen Daten dann über den Eingangsparameter "RECV" in einen Datenbaustein.

Frage:
Stellt die Funktion AG_RECV sicher, dass die Daten im Zieldatenbaustein zu jeder Zeit konsistent sind? Oder wird der DB Byte für Byte aufgefüllt und der Zyklus läuft währenddessen weiter? Das hätte zur Folge, dass sich während eines recieve-Vorgangs alte und neue Daten um DB befinden.

Dann hätte ich noch eine Frage zum UD-Protokoll an sich:
Dass das UDP-Paket möglicherweise nicht ankommt ist mir klar, und stellt in meiner Anwendung auch kein Problem dar.
Aber gibt es bei UDP eine Checksumme, die die gesendeten Daten auf Fehler überprüft? Sollte ein fehlerhaftes Paket dann einfach verworfen werden, wäre mir das recht. Ich hab lieber gar kein Paket als ein fehlerhaftes.

Grüße
oid

 

[IBFS]

Im Prinzip kannst du eine UDP-Verbindung wie eine Serielle Kommunikation (CP340) verstehen .
Die Bausteinaufrufe sind fast gleich. Es ist fast so wie das serielle Protokoll mit Zeichenverzugszeit -so nutze ich es.
D.h. ist der Datenstrom eingefahren, bekomme ich die Datenstromlänge mitgeteilt.
Jetzt überprüfe ich die (z.B.) ersten drei Zeichen und die Länge.
Passt das ins Raster ist es gut und ich gebe eine Datenquittung an
den Datensender zurück. Damit hat man auch ohne TCP ein Datenhandshake geschaffen.

Gruß

IBFS

 

[oid]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schonmal danke für die Antwort, aber ein handshake brauch ich eigentlich gar nicht .

Ich möchte einfach nur sicher gehen, dass zu jeder Zeit in meinem Ziel-DB (der DB in den mir AG_RECV das empfangene Paket schreibt) alle Daten vom gleichen UDP-Paket sind.
Und nicht - sollte der recieve-Vorgang noch nicht abgeschlossen sein - Teile vom Vorgänger-Paket und Teile vom aktuellen Paket.
Klar könnte ich mit Hilfe des NDR-Flags am AG_RECV noch einen Puffer basteln, um dann wirklich konsistente Daten zu haben. Aber das kann ich mir ja sparen, wenn sich da der AG_RECV eh schon drum kümmert.

Oder anders formuliert: Läuft das CPU-Programm weiter während der Ziel-DB von AG_RECV gefüllt wird? Und könnte das Programm somit im DB auf inkonsistente Daten stoßen?

Gruß
oid

 

[Sarek]

AG_RECV schreibt erst in Deinen DB wenn alle Daten empfangen worden sind.
Vorher werden die Daten im CP zwischengespeichert.
Deshalb musst Du auch die Länge angeben am ANY-Pointers des AG_RECV.

Bei UDP ist die Länge aber auf 240 Bytes begrenzt.

 

[oid]

okay merci, 240 byte reichen mir

 

[IBFS]

Zuviel Werbung?
-> Hier kostenlos registrieren

AG_RECV schreibt erst in Deinen DB wenn alle Daten empfangen worden sind.
Vorher werden die Daten im CP zwischengespeichert.
Deshalb musst Du auch die Länge angeben am ANY-Pointers des AG_RECV.

Bei UDP ist die Länge aber auf 240 Bytes begrenzt.

Die Angabe des ANY-Pointers ist aber die BufferGesamtlänge.
Diesen Buffer mache ich immer um einiges größer als die erwartete Länge.
Die real empfangene Länge - nach dem "abreisen" des Datenstromes
wird am Bausteinausgange für EINEN Zyklus lang angetragen.
Die Länge zu überprüfen ist schon wichtig, weil Pakete auch
verstümmelt sein können und damit kürzer sind.

 

[Sarek]

Ist das nur bei UDP so?

Bei TCP kanns ja nicht so sein, da man die Daten nur kriegt wenn der
Puffer auch voll ist. Deshalb auch das Problem beim Empfang von TCP-Telegrammen unbekannter Länge.

Bei UDP ist der Empfang mit der max. Länge 240Bytes ja sowieso auf ein Paket begrenzt.

Die Angabe des ANY-Pointers ist aber die BufferGesamtlänge.
Diesen Buffer mache ich immer um einiges größer als die erwartete Länge.
Die real empfangene Länge - nach dem "abreisen" des Datenstromes
wird am Bausteinausgange für EINEN Zyklus lang angetragen.
Die Länge zu überprüfen ist schon wichtig, weil Pakete auch
verstümmelt sein können und damit kürzer sind.

 

[IBFS]

@Sarek

Die Eingangsfrage handelte NUR von UDP. Deshalb bin ich nicht auf TCP eingegangen sondern habe nur das Verhalten von UDP erklärt.

Den Buffer einfach maximal zu machen hat den Hintergund, dass man
bei Protokolländerung einen DB-Bereich hat den man einfach nicht mehr
ändern (vergrößern) muß weil er auf Maximalgröße ist.

Gruß

 

[oid]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hätte da nochmal eine Frage:

Was passiert, wenn ein zweites UDP-Paket am CP angekommen ist, bevor das erste Paket mit AG_RECV ausgelesen wurde? Liest AG_RECV pro Aufruf dann immer nur das älteste Paket aus (FIFO-Prinzip)?
Wie groß ist der Zwischenspeicher vom CP? Und was passiert, wenn der Zwischenspeicher voll ist?

Grüße