Public Support

Um genau so einen generischen Receiver (UDP) geht es. Hier kommt ein anonymer Stream heraus. Das heißt also, daß wir einen eigenen "Typecast"-Filter bauen müssen.

Danke für die Info!

Hi Patrick,

aber auch genau so einen UDP Filter liefern wir ja schon mit (https://support.digitalwerk.net/adtf/v3/adtf_html/page_demo_non_adtf_application_sender_receiver.html). Und der hat auch die Möglichkeit eine DDL vom Media Description Service zu holen und auf den Stream Type zu setzen.

Gibts einen Grund warum ihr nicht den nehmen könnt, bzw. warum das nicht der von Euch verwendete UDP Filter macht, der ist ja für seine Daten verantwortlich?

Grüße,

Martin

Hi Patrick,

Um genau so einen generischen Receiver (UDP) geht es. Hier kommt ein anonymer Stream heraus. Das heißt also, daß wir einen eigenen "Typecast"-Filter bauen müssen.

Dann solltest du eigentlich diese Streaming Source genauso verwenden können.
Anhand von Properties holt er sich die DDL vom Media Description Service und setzt den Stream Type.
Du wirst es ja genauso bereitstellen oder ?
Dann brauchst du eigentlich nichts mehr casten.

Auf Empfängerseite steht dann alles bereits im Stream, da musst du nichts mehr machen.
Das wäre die Lösung die out of the box geht.

Natürlich kannst du es auch genau anders rum machen, aber das wäre doppelter Code in meinen Augen.

Ah, Martin hatte den gleichen Gedanken, gut dass die zwei Aussagen matchen :-)

Das hört sich gut an. Was bedeutet "Demo" im Namen? Ist das Plugin supportet? Ist die "Demo" nur als Beispiel/Anregung für den Bau eines eigenen Filters gedacht? Wir müssen eine zuverlässige Tool-Kette aufbauen, wo solch eine Filterbezeichnung Fragen aufwerfen wird.

Hi Patrick,

ja der ist komplett supportet und ist zusätzlich noch als Beispiel verfügbar.

@Flo: Ich denke wir müssen das "Demo" endlich aus allen Labels streichen, das führt wie wir schon öfters gesehen haben dazu, dass sie nicht verwendet werden.

Grüße,

Martin

Danke für die Info. So ein Filter wäre auf jeden Fall nützlich, sofern das "Non-ADTF-Sender" im Namen so gemeint ist, daß UDP-Datagramme aus der freien Wildbahn gemeint sind, bspw. Prüfstände im Prüfgelände mit proprietären Protokollen. Meine letzte Info vor langer Zeit war, daß so ein Filter nicht geplant wäre und nur ADTF-to-ADTF-Kommunikation via UDP auf der Agenda stehen würde.

Ansonsten sind meine Fragen beantwortet. Das Ticket kann geschlossen werden.

Hi Patrick,

So ein Filter wäre auf jeden Fall nützlich, sofern das "Non-ADTF-Sender" im Namen so gemeint ist, daß UDP-Datagramme aus der freien Wildbahn gemeint sind, bspw. Prüfstände im Prüfgelände mit proprietären Protokollen.

Genau das ist die Intetion, du brauchst auf der Gegenseite keine IPC Implementierung, was bei ADTF-2-ADTF der Fall wäre.
Diese Seite Non-ADTF Application and IPC Integration Examples fasst das imho eigentlich gut zusammen und welche Möglichkeiten der Kommunikation und Implementierungen es gibt.

Ich habe den Demo-Receiver nun ausprobiert: Es klappt, auch das Festlegen einer DDL für den Stream. Wenn ihr das "Demo" aus dem Namen entfernen würdet, wäre ich voll zufrieden.

Das Ticket kann geschlossen werden.