Jump to content

RTSP Client Round-Robin Problem


Recommended Posts

Es passiert recht häufig, und ist recht lästig, allerdings nicht wirklich ein direkter Fehler, sondern nur eine fehlende Prüfung.

 

Szenario:

* Irgendwo im LAN tummelt sich ein RTSP Server (kann auch der RS vom DVBViewer sein, ist völlig egal)

* Da das LAN etwas größer ist, gibt es mehrere Segmente uder der RTSP Server ist "multihomed", damit er von allen Segmenten aus direkt angesprochen werden kann

* Bei den Klienten wird jeweils unter "Hardware" ein RTSP Gerät konfiguriert, durch Plug&Play wird der DNS Name obigen Servers angezeigt

 

(Problem: Der Server wird mehrfach aufgelistet, pro IP Adresse taucht er jeweils einmal in der Liste auf. Hier sollte schon mal ein intelligenter Filter dafür sorgen, dass nur Einträge aus dem lokalen Subnetz des Klienten angezeigt bleiben)

 

* Den "richtigen" Server angeklickt und die Konfiguration abgespeichert.

 

Danach kann man erstmal eine geraume Zeit lang fröhlich TV gucken.

 

Erst, wenn man den Klienten neu startet, tritt die Lottofee hervor. Beim Starten des Klienten wird eine DNS Abfrage zur Ermittlung der IP Adresse des konfigurierten Servers gemacht.

Nun tritt aber das DNS Round-Robin auf, die Liste der zurückgelieferten Adressen wird jeweils neu ausgewürfelt. Der DVBViewer schnappt sich EINE davon! (wahrscheinlich die erste der Liste, weil diese Abfrage die historisch erste und simpelste ist).

Das kann gut gehen, sprich, er nimmt die "richtige", die aus dem lokalen Segment.

Das kann aber auch ekelig in die Hose gehen. Er erwischt eine der anderen Adressen und je nachdem, ob entsprechende Routen konfiguriert sind, oder nicht, kommt ein Bild, oder der Schirm bleibt dunkel.

 

Der Anwender sieht davon nur das Ergebnis (oder eben auch NIX), er kann nicht erkennen, ob nun direkt, über Umweg, oder gar nicht kommuniziert wird.

 

Der arme Admin weis auch nicht so wirklich, wie ihm geschieht, wenn die Anwender sich anfangen zu beschweren. Wenn man dann in die Konfiguration geht, und nochmal von Hand die "richtige" Adresse auswählt, dann gehts ja erstmal wieder für einige Zeit...

 

Es wäre also sehr hilfreich, wenn da an der Stelle der Ermittlung IP Adresse noch eine kleine Schleife eingebaut würde und nur "eigene" Adressen durchgelassen würden...

 

Link to comment

Hallo MaM,

 

Das von dir beschriebene Verhalten ist exakt so, wie sich Round Robin per DNS-Definition verhalten soll: Einem Namen sind mehrere IPs zugewiesen, der DNS-Server schickt diese im Regelfall in einer zufälligen Reihenfolge an den Client. Ziel ist die Erreichung einer gewissen Lastverteilung und Ausfallssicherheit durch simple DNS-Einträge (Beispiel: www.orf.at ist auf mehrere IP-Adressen aufgeteilt, der Client wählt sich zufällig einen aus). Es gibt auch DNS Server, die IPs aus lokalen Metzen priorisieren können, zB http://msdn.microsoft.com/de-de/library/cc787373(v=ws.10).aspx.

 

DNS Round Robin ist nicht dazu gedacht, Dienste in verschiedenen Netzen zur Verfügung zu stellen. Dafür gibt es Protokolle wie DNS Anycast oder DNS SRV-Requests. Soweit ich weiß, müssten nahezu alle Clients ohne Anpassung mit Anycast umgehen können (was am DNS-Server um im Netzwerk zu tun ist, weiß ich nicht), für SRV-Records mit Site-Zuordnung ist auf jeden Fall der Client anzupassen.

 

LG,

 

GruberMa

Link to comment

Ich denke Du solltest Dich wirklich mal mit diversen Dingen wie z.B. dem Tweaker für den RS (und den DVBViewer[n]) und den Einstellungen in den Konfigtools etwas .

In meinen Netzwerken kann ich die von Dir beschrieben Dinge nicht nachvollziehen (und will es auch nicht mehr :closedeyes:)!

Ich denke, Du solltest einfach meine Nachrichten nicht mehr lesen und Deine Inkompetenz bei komplizierten Netzwerkdingen nicht weiter zur Schau stellen. Tu es doch einfach nicht und erspare uns beiden eine Menge Stress.

Das Forum bietet Dir glaube ich sogar eine einfache technische Möglichkeit, Meldungen nicht zu sehen zu bekommen. Nutze sie!

Link to comment

 

>Das von dir beschriebene Verhalten ist exakt so, wie sich Round Robin per DNS-Definition verhalten soll: Einem Namen sind mehrere IPs zugewiesen...
Ja, ich sagte ja, mit dem Server ist alles ok. Round Robin tut genau das, wofür es gedacht ist.
Das Problem tritt beim Klienten ( in diesem Falle dem DVBViewer) auf.
Er fragt nach der Adresse des Hostnamens, bekommt die Liste in zufälliger Reihenfolge und benutzt dann blind irgendeine der Adressen (wahrscheinlich die oberste).
Bei TCP würde man einen Connect() machen und einen Fehler zurückbekommen, da keine Route existiert.
Üblicherweise sind Clients wie Telnet o.ä so programmiert, dass sie "connect()" in einer Schleife machen, mit jeweils der nächsten Adresse in der Liste. Sobald eine Verbindung erfolgreich ist, gehts weiter im Text. Sind alle Adressen durch und es hat immer noch nicht geklappt, erfolgt Abbruch mit Fehlermeldung.
Leider basiert RTSP auf UDP, da gibts keinen connect(), sondern nur sendto().
Aber auch dort kann man den Rückgabewert auf (WSA)ENETUNREACH oder (WSA)EHOSTUNREACH überprüfen und dann versuchsweise auf die nächste Adresse umschalten.
Und mir scheint, genau diese Prüfung fehlt im Code.
Nun weis ich natürlich nicht, auf welche Abstraktionsebene der Viewer programmiert wurde. In "höheren" Schichten wie .NET oder anderen Frameworks kann es sein, dass diese Fehler gar nicht durchgereicht werden, sondern irgendwo "geschluckt" werden.
Edited by MaM
Link to comment

>Meine "Inkompetenz bei komplizierten Netzwerkdingen" besagt, dass dieser Tweak Dein Problem zu 99.9% in den Griff bekommen sollte, :shutup:

Ok, zähl mich zu den 0,1% Rest. Der Knopf hilft wenig, er macht die Sache eigentlich sogar noch schlimmer.

Und ebenfalls nein, ich bin kein Admin einer Firma. Das hier sind einfach ein paar per Kabel verbundene WLANs und die Leute wollen weiter Fußball gucken, wenn sie schnell zum Bierklauen in den Garten des Nachbarn schlüpfen. Da kommts dann schon mal zu "Roaming" und man ist auf die automatische Suche angewiesen. Nur sollte es dann auch immer die "richtige" Adresse finden, damits für den Anwender keinen Stress gibt.

Link to comment
halte jetzt endgültig meine Klappe und gut ist

Ja, bitte bitte! All das, was Du da "unbedingt wissen musst", ist für das angesprochene Problem völlig uninteressant, konzentrier Dich einfach auf das Statement "wenn der DVBViewer mehrere Adressen zur Auswahl hat, entscheidet er sich oft für die falsche". Nur das ist wichtig.

Link to comment

Das ist ein Fall für Dr. Griga ... keine Ahnung ob sich das so ohne weiteres ändern lässt.

Gut, sag er mir welche Programmiersprache / API / Framework verwendet wird, und ich sag ihm, wonach er automatisch im Code suchen soll.

 

Ich gehe mal davon aus, dass die entsprechende Funktion ein paarmal im Code verstreut benutzt wird, es lohnt sich deshalb, eine eigene Funktion zu erstellen und das Problem damit zentral zu beseitigen (oder bei Klassen eben eine geschickte Überladung o.ä)...

Link to comment

Das Problem dürfte eher sein, dass die ganze Anwendung blockiert ist bis man durch die IP Liste durch ist.

 

Ggf. Noch mit Wartezeit für WOL?

Edited by nuts
Link to comment
Ich denke, Du solltest (...) Deine Inkompetenz bei komplizierten Netzwerkdingen nicht weiter zur Schau stellen.

 

Wenn das auf MaxB zutrifft, dann auf mich erst recht. Aufgrund mangelnder Erfahrung mit komplexen Netzwerken und fehlenden Netzwerktechnik-Kenntnissen allgemein habe ich schon im Ansatz nicht verstanden, worum es hier geht und wo genau das Problem liegt.

 

Beim Starten des Klienten wird eine DNS Abfrage zur Ermittlung der IP Adresse des konfigurierten Servers gemacht.

 

DNS-Abfrage??? Nicht dass ich wüsste. Die IP wird doch in den SAT>IP-Einstellungen des DVBViewers durch die Wahl eines Servers aus einer via UPnP oder so ermittelten Liste manuell konfiguriert und steht danach in der hardware.xml. Es gibt nur einen optionalen Mechanismus, der bei einem Fehlschlag des Versuchs, die Kontroll-Kanal-Verbindung herzustellen, sich die Serverliste erneut besorgt und dort nachschaut, ob die UUID des zuvor konfigurierten Servers einer anderen IP zugeordnet ist. Aber darauf hatte bereits MaxB vergeblich hingewiesen. Und jetzt gehe ich lieber in Deckung, bevor mich der Experten-Zorn trifft :fear:

Link to comment
DNS-Abfrage??? Nicht das ich wüsste. Die IP wird doch in den SAT>IP-Einstellungen des DVBViewers durch die Wahl eines Servers aus einer via UPnP oder so ermittelten Liste manuell konfiguriert und steht danach in der hardware.xml. Es gibt nur einen optionalen Mechanismus, der bei einem Fehlschlag des Versuchs, die Kontroll-Kanal-Verbindung herzustellen, sich die Serverliste erneut besorgt und dort nachschaut, ob die UUID des zuvor konfigurierten Servers einer anderen IP zugeordnet ist. Aber darauf hatte bereits MaxB vergeblich hingewiesen. Und jetzt gehe ich lieber in Deckung, bevor mich der Experten-Zorn trifft :fear:

Gut, das ist dann die richtige Stelle.

Dann wird eben kein Round Robin benutzt, sondern er bastelt sich die Liste selber zusammen.

Also lese man dann meine Fehlerbeschreibung "Bei der Auswahl der Serveradresse aus der UPnP Liste wird die FALSCHE Adresse gewählt".

Die fest eingestellte IP in der Konfiguration hilft nicht wirklich weiter. Wenn der Klient sich "bewegt", stimmt sie eben nicht mehr und muß angepasst werden. Deshalb braucht man den UPnP Kram, aber eben richtig.

 

MaxB wollte mich unbedingt auf irgendwelche Konfigurationen / LAN Strukturen festnageln, das ist falsch. Hier gehts um interne Programmabläufe, die können nicht "getweaked" werden, sondern erfordern Änderungen im Code.

 

@nuts: Die Blockade ist zwar ekelig nervig, aber sie wird ja überlebt. Schlimmer empfinde ich, dass das Ergebnis der Warterei dann falsch ist, und man hinterher doch noch wieder alles von Hand einstellen muß. (insofern ist der Tweak schon hilfreich, die doofe 1min Pause entfällt und man kann sofort die richtige Adresse von Hand eingeben).

 

Anwender sind naturgemäß etwas unbedarft, ich kann ihnen schlecht beibringen: "Wenn Du im WLAN von XXX rumläufts musst Du die Serveradresse 192.168.[Hausnummer].13 einstellen um TV gucken zu können". Das scheitert schon meistens daran, dass sie die Hausnummer gar nicht so genau kennen...

Link to comment
Bei der Auswahl der Serveradresse aus der UPnP Liste wird die FALSCHE Adresse gewählt

 

Warum? Die UUID einer Server-Instanz sollte doch eindeutig sein, oder? Der RS hat jedenfalls auf verschiedenen PCs eine verschiedene UUID, das habe ich überprüft. Eingeführt wurde die UUID-basierte Suche im DVBViewer 5.3.0.

Link to comment

 

Warum? Die UUID einer Server-Instanz sollte doch eindeutig sein, oder? Der RS hat jedenfalls auf verschiedenen PCs eine verschiedene UUID, das habe ich überprüft. Eingeführt wurde die UUID-basierte Suche im DVBViewer 5.3.0.

Die UUID ist pro Server eindeutig, aber wenn der GLEICHE RS Server mehrere Adressen hat, taucht er auch mehrfach in der Liste auf. Und dann wird leider der falsche (Ich vermute aus meinen Tests, es ist immer der erste Eintrag der Liste mit übereinstimmendenden UUIDs) genommen.

 

Es wird eben nur auf UUID Gleichheit getestet, nicht, ob die gelieferte Adresse dann auch überhaupt erreichbar ist.

Link to comment

Soweit ich das verstanden habe sollen alle gefundenen Server durchprobiert werden.

Das würde die ekelig lange Pause (bis zu 1min hier) erklären, wenn man den RTSP-Client-Einstell-Dialog aufruft. Irgendwann tauchen dann auch die gefundenen Server (ich hab hier nur einen, aber der taucht pro IP Adresse jeweils in der Liste auf) angezeigt. Dann klickt man einen davon an, und oben ins Adressfeld wird die IP Adresse übernommen. Aber, egal, welchen ich anklicke, oben kommt immer die falsche (und dieselbe!) Adresse rein...

 

Ich mach mal wieder ein paar Screenshots glaube ich...

 

post-130498-0-69652000-1404894218_thumb.jpg

 

(komischerweise taucht heute morgen der RS nur EINMAL in der Liste auf... UPnP... glaubt mir, sonst ist er dreimal drin...)

Erklärung:

Bild Links: gepeicherte Konfiguration, der Klient ist ebenfalls im Netz "0"

Bild Mitte: nach Klick auf den aufgelisteten Server, wird die falsche Adresse "17" eingetragen

Bild Rechts: Screenshot des RS Status mit den drei konfigurierten Adressen.

 

 

Edited by MaM
Link to comment

Soweit ich das verstanden habe sollen alle gefundenen Server durchprobiert werden.

 

Das würde die ekelig lange Pause (bis zu 1min hier) erklären, wenn man den RTSP-Client-Einstell-Dialog aufruft.

 

nuts meinte wohl, du willst, dass alle Listeneinträge probiert werden.

 

Nein, im Einstellungsdialog wird nichts durchprobiert. Es werden nur die Listeneinträge empfangen, zusammengestellt und angezeigt. Und die Server-Such-Automatik bei fehlgeschlagener Kontroll-Kanal-Verbindung probiert auch nichts aus. Sie nimmt den ersten Server aus der Liste bzw. dessen IP mit passender UUID.

 

Bild Mitte: nach Klick auf den aufgelisteten Server, wird die falsche Adresse "17" eingetragen

 

Inwiefern falsch? Irgendwo muss die doch herkommen.

Link to comment

Inwiefern falsch? Irgendwo muss die doch herkommen.

Ja klar, von der UPnP Ankündigung.

 

Der RS sendet sie (korrekterweise) auf alle konfigurierten IP Adressen aus.

 

Die Netze sind natürlich über Router/Gateways miteinander verbunden. Also kommt das "Echo" des 17er Netzes auch bei 0 und 1 vorbei. Deshalb habe ich normalerweise 3 Einträge.

 

Du (bzw. das Programm) nimmt jetzt aber immer kritiklos die erste Antwort, das ist dann mehr oder minder Zufall, welcher gerade als erster wieder eintrifft.

 

Je nach Konfiguration der Router geht es dann sogar noch "irgendwie", 17 z.B ist ne Fritzbox, der kann man die statischen Routen beibringen, also werden die Pakete weitergeleitet. bei 1 ist so ein doofer ALICE Dsl Router, der kann das nicht, die Pakete würden dann im Nirwana enden.

Aber selbst wenn es bei 17 "irgendwie geht", der Paketverlauf ist dann sehr suboptimal. Der Anwender merkt zwar nichts, aber die Pakete flutschen doch erstmal im LAN hin und her, bis er ein Bild zu sehen bekommt.

Bei der richtigen Adresse (hier: "0") würde alles im lokalen Kabel bleiben und direkt zugestellt.

(Dieses Beispiel ist natürlich nur hier gültig, bei anderen LANs würden andere Effekte auftauchen, allerdings bleibt das Grundproblem der fehlerhaften Zuordnung, auch wenn man es manchmal nicht zu spüren bekommt)

Link to comment

Das geht nicht Max.

 

Was mir nun nicht klar ist wie sich der Client verhalten soll.

Ich dachte du meinst der Client sollte einfach alle durchprobieren, aber im letzten Post wird eine kritische Auseinandersetzung angesprochen. Nach welchen Kriterien?

Link to comment

Wenn sich die absolute "Inkompetenz bei komplizierten Netzwerkdingen" mochmal zu dem Thema äußern darf, versuche doch bitte mal die nicht zu verwendenden IP Adressen im RS hier zu unterdücken

attachicon.gifMaM_RS-IP-blocken.png

In Verbindung mit meiner Empfehlung für den Client sollte das funktionieren

NEIN! halt Dich nun endlich mal raus, Du willst es offensichtlich nicht verstehen... (und wenn Du etwas nachgedacht hättest, dann hättest Du erkannt, das MAM den Eintrag schon längst gefunden und bemüht hat, sonst würde da z.B. 127.0.0.1 auftauchen)

 

Natürlich SOLL der RS auf allen Netzen (und es sind im Endausbau noch so 30 mehr) antworten! Aber eben nur auf jedem LAN EINMAL und mit der RICHTIGEN Adresse.

Link to comment

Ich dachte du meinst der Client sollte einfach alle durchprobieren, aber im letzten Post wird eine kritische Auseinandersetzung angesprochen. Nach welchen Kriterien?

Na ja, die simpelste und üblichste Methode wäre:

 

* ermittlere eigene IP Adressen aus dem OS

* vergleiche Listeneintrag mit eigener Liste (der Klient kann ja auch mehrere haben) anhand der konfigurierten Netzmaske

* suche weiter, bis Übereinstimmung erzielt wurde

* wurde gar keine Übereinstimmung gefunden, nimm den ersten Eintrag und hoffe aufs Standardgateway, das es vielleicht richten wird.

Link to comment

Das ist mir ehrlich gesagt zu hoch. Welche wo konfigurierte Netzmaske??? Was soll der Vergleich mit den eigenen IP-Adressen bringen? Dann kriegt man doch nur den Server, der auf dem selben PC wie der Client läuft? Ist das gewollt? Und wenn man einen Remote Server will, was dann?

 

Also in meinem Netzwerk gibt es vom RS immer die 127.0.0.1 und noch eine andere IP. Bei einem Client auf dem selben PC tauchen beide auf (und funktionieren beide). Auf anderen PCs sehen die Clients nur die andere IP. Dafür habe ich nichts speziell konfiguriert. Mehr kenne und weiß ich nicht, und mehr kann ich auch nicht testen.

Link to comment

Das ist mir ehrlich gesagt zu hoch. Welche wo konfigurierte Netzmaske??? Was soll der Vergleich mit den eigenen IP-Adressen bringen? Dann kriegt man doch nur den Server, der auf dem selben PC wie der Client läuft? Ist das gewollt? Und wenn man einen Remote Server will, was dann?

 

also... :

 

* Die Netzmaske ist bei den TCP-4 Einstellungen, kannste mit "ipconfig /all" angucken und mit entsprechenden API Aufrufen ermitteln

z.B. (ignoriert mal alle V6 Einträge,hier ist die Hauptnetztätigkeit auf V6, nur noch Altdienste, die kein V6 unterstützen laufen noch auf V4)

Ethernet-Adapter Werries:

 

Verbindungsspezifisches DNS-Suffix: werries.de

Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller

Physikalische Adresse . . . . . . : 60-A4-4C-60-D8-6C

DHCP aktiviert. . . . . . . . . . : Ja

Autokonfiguration aktiviert . . . : Ja

IPv6-Adresse. . . . . . . . . . . : 2a02:908:fb30:b340:62a4:4cff:fe60:d86c(Be

vorzugt)

IPv6-Adresse. . . . . . . . . . . : fdfd::62a4:4cff:fe60:d86c(Bevorzugt)

Verbindungslokale IPv6-Adresse . : fe80::62a4:4cff:fe60:d86c%11(Bevorzugt)

IPv4-Adresse . . . . . . . . . . : 192.168.0.28(Bevorzugt)

Subnetzmaske . . . . . . . . . . : 255.255.255.0

Lease erhalten. . . . . . . . . . : Mittwoch, 9. Juli 2014 08:20:36

Lease läuft ab. . . . . . . . . . : Donnerstag, 17. Juli 2014 08:20:35

Standardgateway . . . . . . . . . : fe80::2665:11ff:fe1d:4f6%11

192.168.0.253

DHCP-Server . . . . . . . . . . . : 192.168.0.2

DHCPv6-IAID . . . . . . . . . . . : 241214540

DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-2F-3D-99-60-A4-4C-60-D8-6C

 

Wozu is die gut?

* Sie begrenzt die Gültigkeit eines Paketes und wird zusammen mit der IP Adresse verwendet. Alle Maschinen die nach der einfachen boolschen Berechnung "IPAdr AND NetzMaske" denselben vorderen Anteil haben, befinden sich "im selben Netz" und es wird unterstellt, dass diese Maschinen direkt und uneingeschränkt miteinander kommunizieren können.

(Beispiel 1: 192.168.0.28 AND 255.255.255.0 = 192.168.0.0, 192.168.0.13 AND 255.255.255.0 = 192.168.0.0 -> beide Maschinen befinden sich im selben Netz ("lokales Netz")

Beispiel 2: 192.168.0.28 AND 255.255.255.0 = 192.168.0.0, 192.168.1.13 AND 255.255.255.0 = 192.168.1.0 -> die Maschinen sind NICHT im selben Netz) (rechne besser in Hexadezimal bzw. Binär, dann wird das anschaulicher und auch simpler)

 

Wird erkannt, dass die Maschinen nicht im selben Netz sind, so werden die Pakete automatisch umgeleitet und an das konfigurierte Standardgateway versandt (in der Hoffnung, das der Router es schon richten wird...)

 

Wenn der Klient also eine Liste der Serveradresse erhält, ob über UPnP oder DNS ist egal, MUSS er alle Adressen durch obige Rechnung jagen und beim Auffinden eines lokalen Netzes DIESE Adresse verwenden.

 

Es ist gewollt, dass man damit die Serveradresse auffindet, die dem jeweiligen Klienten "am nächsten" ist. Dadurch werden Verzögerungen im LAN und sogar eine Überlastung des Standardgateways vermieden.

 

----------------

>Also in meinem Netzwerk gibt es vom RS immer die 127.0.0.1 und noch eine andere IP. Bei einem Client auf dem selben PC tauchen beide auf (und >funktionieren beide). Auf anderen PCs sehen die Clients nur die andere IP. Dafür habe ich nichts speziell konfiguriert. Mehr kenne und weiß ich >nicht, und mehr kann ich auch nicht testen.

 

Die 127.0.01 sollte laut Empfehlung in diesem Forum abgeschaltet werden :D

Sie ist ja ebenfalls "falsch", denn ein Klient im LAN kann darunter den Server nicht ansprechen. Das funktioniert nur, wenn Klient und Server auf derselben Maschine sind.

 

Du kannst es recht einfach testen, indem Du Deinem Server ein paar Adressen von Hand hinzufügst, das schadet ihm nicht, aber Du wirst dann den Stress mit den Klienten bekommen, den ich hier beschreiben (höchstwahrscheinlich!, denn, da das ganze eine Art Lotterie ist, KANN es auch mal klappen). Je mehr Adressen, desto höher die Fehlerwahrscheinlichkeit.

Link to comment

Also ganz ehrlich, dass hätte man auch in einem Satz schreiben können.

 

Stehen mehrere RS IPs zur Verfügung soll der Client eine wählen die sich im selben Netz befindet......

aber wenn man es möglichst kompliziert ausdrücken will, dann sollte man es so beschreiben wie du ;-)

Edited by VinoRosso
Link to comment

Also ganz ehrlich das hätte man auch in einem Satz schreiben können.

 

Stehen mehrere RS IPs zur Verfügung soll der Client eine wählen die sich im selben Netz befindet......

aber wenn man es möglichst kompliziert ausdrücken will, dann sollte man es so beschreiben wie du ;-)

Na ja, anfangs wußte ich ja noch nicht, wie die Adressen ermittelt werden und ging fälschlicherweise von einer DNS Abfrage aus.

Bei UPnP (man nennt es nicht ganz zu Unrecht "Plug & Pray") ist das alles viel komplizierter.

Offensichtlich mangelt es hier einigen an Basiswissen (was jetzt NICHT böse gemeint sein soll, ich hab auch keine Ahnung von TV und Videokram) bezüglich Netzwerken und deren Programmierung, da muss ich ja erstmal rausfinden, was man wem "zumuten" kann.

 

Aber Deine "in einem Satz" Zusammenfassung ist gut, danke :D

Link to comment
Offensichtlich mangelt es hier einigen an Basiswissen

 

So ist es. Ich bin ja durch Lars' Abschied an die Netzwerkerei gekommen wie die Jungfrau zum Kinde. Vorher waren die Aufgaben so verteilt, dass ich mich kaum darum kümmern brauchte.

 

Die Netzmaske ist bei den TCP-4 Einstellungen, kannste mit "ipconfig /all" angucken und mit entsprechenden API Aufrufen ermitteln

 

Mit welchen Aufrufen? I.a. habe ich hier mit dem WinSock2 API zu tun bzw. Delphi-Bibliotheken, die den Kram etwas zugänglicher machen.

 

Ich denke, die Sache mit der Subnetzmaske habe ich jetzt ungefähr verstanden: Zwei Adressen, die nach Anwendung der Maske gleich sind, befinden sich im selben Netzwerk. Ich suche in der UPnP-Server-Liste den Server, dessen UUID mit der konfigurierten UUID und dessen maskierte IP mit einer maskierten IP des Client PCs übereinstimmt - soweit richtig? Nur wenn das nichts ergibt, nehme ich einen Server mit gleicher UUID und beliebiger IP.

 

BTW: Gerade habe ich entdeckt, dass der RS auf dem PC, auf dem ich das hier schreibe, neuerdings drei IP Adressen hat (eine davon 127.0.0.1). Große Frage: Wo kommt plötzlich die dritte her? Wenn ich wie beschrieben die Subnetzmaske anwende, sehe ich, dass es sich um ein anderes Netzwerk handelt. Vermehren die sich manchmal von selbst?

Link to comment

>So ist es. Ich bin ja durch Lars' Abschied an die Netzwerkerei gekommen wie die Jungfrau zum Kinde. Vorher waren die >Aufgaben so verteilt, dass ich mich kaum darum kümmern brauchte.

Ja, ich kenn die Geschichte, echt sorry. Und mir ist auch klar, dass man auf diese Art ins kalte Wasser geworfen wird. Deshalb versuche ich ja schon, die mir aufgefallenen Probleme so gut wie möglich einzukreisen. Da ich bislang aber nicht wußte, wie und womit das Programm aufgebaut wurde, konnte ich nur wild rumraten.

 

 

>Mit welchen Aufrufen? I.a. habe ich hier mit dem WinSock2 API zu tun bzw. Delphi-Bibliotheken, die den Kram etwas >zugänglicher machen.

Aha, endlich bin ich schlauer. Wsock32 ist kein Problem für mich, Delphi kenne ich leider überhaupt nicht. Aber das sollte nicht daran hindern, die richtigen Funktionen zusammenzusuchen...

 

 

>Ich denke, die Sache mit der Subnetzmaske habe ich jetzt ungefähr verstanden: Zwei Adressen, die nach Anwendung >der Maske gleich sind, befinden sich im selben Netzwerk. Ich suche in der UPnP-Server-Liste den Server, dessen UUID >mit der konfigurierten UUID und dessen maskierte IP mit einer maskierten IP des Client PCs übereinstimmt - soweit >richtig? Nur wenn das nichts ergibt, nehme ich einen Server mit gleicher UUID und beliebiger IP.

Yep! Genau das ist der "normale" Ablauf.

Es tut mir leid, aus historischen Gründen wurde diese Aufgabe dem Klienten zugeschanzt. "Dammals" (Anfang der 80er) gab es eine heftige Diskussion, ob dieses Feature nicht in die Standard-C Bibliothek gehörte und fest (und unsichtbar) in Calls wie "gethostbyname()" oder (moderner) "getaddrinfo()" hineingehörte, aber das wurde abgelehnt, weil man Round-Robin-DNS als zukunftsträchtiger erachtete. War eine totale Fehlplanung, ist aber niemand vorzuwerfen, damals war man froh, wenn man überhaupt einen Netzwerkanschluß hatte, alles, mit "multihomed" war nur ein Gedankenspiel.

 

Ehrlich gesagt, ich würde mich nicht wirklich auf die UPnP Einträge vollständig verlassen, sondern die Bewertung etwas anders formulieren (Hintergrund: wie man sieht, kommen sie manchmal durch, manchmal nicht, manchmal doppelt... sie sind nicht wirklich verlässlich).

 

Bist Du Dir sicher, dass in den Ankündigungen wirklich nur die Adressen eingetragen sind? Wenn ich mir so den RSTP Rfc durchlese, stosse ich eigentlich überall nur auf URLs mit DNS Hostnamen?

 

>BTW: Gerade habe ich entdeckt, dass der RS auf dem PC, auf dem ich das hier schreibe, neuerdings drei IP Adressen >hat (eine davon 127.0.0.1). Große Frage: Wo kommt plötzlich die dritte her? Wenn ich wie beschrieben die >Subnetzmaske anwende, sehe ich, dass es sich um ein anderes Netzwerk handelt. Vermehren die sich manchmal von >selbst?

Nein, lol, irgendwo ist da schon einen Grenze. Aber was Du gerade siehst, ist eben dieses unzuverlässige Verhalten von UPnP. Da kann man u.U. wahnsinnig werden. Welche Adresse taucht denn noch auf? "normale" Rechner haben nur 127.0.0.1 und eine LAN Adresse (üblicherweise aus dem "privaten" Bereich 192.168, oder 10. oder 172.16-31).

Sollte Dir eine "IPAPI" Adresse (169.254...) entgegenblicken, dann hat Deine Kiste ein arges Problem mit Deinem Router (bzw. dem DHCP Server darin) zu reden.

 

Ich nehm mir heute abend mal nen LAN Sniffer und protokolliere das UPnP Handshake. Dann werde ich wohl einkreisen können, wo man am Besten (und einfachsten) Abhilfe schaffen kann.

Im Moment bin ich nicht in der Lage zu entscheiden, ob der Klient den falschen Eintrag wählt, oder der Server die falsche Adresse annonciert.

Link to comment

 

BTW: Gerade habe ich entdeckt, dass der RS auf dem PC, auf dem ich das hier schreibe, neuerdings drei IP Adressen >hat (eine davon 127.0.0.1). Große Frage: Wo kommt plötzlich die dritte her? Wenn ich wie beschrieben die >Subnetzmaske anwende, sehe ich, dass es sich um ein anderes Netzwerk handelt. Vermehren die sich manchmal von selbst?

Nein, lol, irgendwo ist da schon einen Grenze. Aber was Du gerade siehst, ist eben dieses unzuverlässige Verhalten von UPnP.

 

Ich dachte nur, weil der PC über WLAN angebunden ist, vielleicht eine Netzwerk-Verdopplung durch Funkzellteilung, was bekanntermaßen bei der Brechung elektromagnetischer Wellen an Badewannen und Wasserbetten passieren kann (auch "Doppler-Effekt" genannt). Immerhin sehe ich im Netzwerk- und Freigabecenter neben der WLAN-Verbindung ein "nichtidentifiziertes öffentliches Netzwerk". :blink:

 

Sollte Dir eine "IPAPI" Adresse (169.254...) entgegenblicken,

 

Genau so eine ist das. Eigentlich kommt sie mir als Testobjekt für das IP-Ausschlussverfahren gelegen, aber ist schon komisch, dass sie gerade jetzt auftaucht. Wie konntest du das wissen?

Link to comment

 

>Genau so eine ist das. Eigentlich kommt sie mir als Testobjekt für das IP-Ausschlussverfahren gelegen, aber ist schon komisch, dass sie gerade jetzt >auftaucht. Wie konntest du das wissen?

Das ist das normale Rückfallverhalten von Windows wenn in einem neuen Netzwerk kein Server gefunden wird.

Damit irgendeine Kommunikation zustande kommt, wird ein RIESENNETZ mit einer zufällig ausgewürfelten Adresse aus dem Bereich 169.255 gewählt und noch getestet, ob sie derzeit niemand anderes verwendet.

Du kannst den Rückfall auch konfigurieren unter Netzwerk->Eigenschaften->Adaptereinstellungen ändern->Eigenschaften->Internetprotokoll Version 4->Eigenschaften und dann den Reiter "alternative Konfiguration". Aber macht niemand auf der Welt :-)

Link to comment

Ok, armer Griga, nun wirds leider seehr kompliziert....

 

Vorsicht! HexDump ahead :-)

 

post-130498-0-66370900-1404916398_thumb.jpg

 

Was wir hier sehen ist ein LAN Trace vom Klienten aus, gefiltert wurden nur die UPnP Pakete. Die rot markierten Pakete stammen vom DVBViewer Recording Service, Im letzten Paket wurden die relevanten Daten hervorgehoben.

 

Zusammenfassend kann ich dazu leider nicht viel Gutes verkünden. Erst einmal erfolgt die Ankündigung pro Adresse dreimal hintereinander (ich vermute mal ganz böse, dass da jemand die Schleifenvariable vermatscht hat, pro IP Adresse wird jedes Paket genauso oft wiederholt), und dann wird jeweils derselbe UUID announciert, nur immer mit anderer IP Adresse.

Ich vermute mal, das letzte Paket gewinnt und überschreibt alle anderen.

Somit wird bei mir im Moment immer die 17 angezeigt, bei anderem Timing käme was anderes raus.

 

Ach so: die Pakete gehen an eine Multicastadresse 239.255.255.250. Das ist ok so, die ist für die Ankündigung von Multimediageräten vorgesehen. Allerdings bedeutet es auch automatisch, dass die Adresse ÜBERALL sichtbar ist, auch in LANs, wo sie eigentlich nicht hingehört. Aber das ist ein Feature, da kann man nix dran machen.

 

 

Nun kenne ich mich mit dem UPnP Kram nicht so gut aus, ist es möglich, dass ein UUID verschiedene Konfigurationen hat, oder sollte für jede IP Adresse ein eigener UUID generiert werden?

Ich hab hier noch einen Mezzmo DNLA Server laufen, der tut dasselbe, wie der RS, nur für abgelegte Filme.

Der taucht auf jeden Fall DREIMAL in der Netzwerkumgebung auf (RS=GAR NICHT), jeweils mit anderem UUID.

 

Vielleicht ist das schon die eigentliche Ursache des Problems?

 

Es gibt auch noch eine andere Möglichkeit indem man das Paket einfach nur einmal schickt, und bei der URL darin nicht die IP Adresse angibt, sondern den Hostnamen. Dann treten wieder die normalen Abläufe mit DNS Abfrage, Durchprobieren und automatischem Rückfall in Kraft. Allerdings müsste dann auch der von MaxB so geliebte Eintrag "diese IP Adresse nicht verwenden" entfallen, denn es müssen dann alle Adressen, die im DNS stehen auch erreichbar sein um böse "Hänger" zu vermeiden.

Edited by MaM
Link to comment
Du kannst den Rückfall auch konfigurieren

 

Habe ich gemacht :) Dabei hat sich herausgestellt: Das "Riesen-Netzwerk" wird durch meine TechniSat SkyStar S2 aufgespannt, die wegen potentiellem Internet via Satellit als Netzwerkkarte firmiert. Irgendwer/was hat in ihren Eigenschaften die Häkchen bei "Diese Verbindung verwendet folgende Elemente -> TCP IPv4/6" gesetzt. Häkchen entfernt, Spuk vorbei.

 

Erst einmal erfolgt die Ankündigung pro Adresse dreimal hintereinander (...) und dann wird jeweils derselbe UUID announciert, nur immer mit anderer IP Adresse.

 

Vielleicht schaust du mal selbst

 

http://www.satip.info/resources

 

Abschnitt 3.3: Discovery

 

Each instance of a SAT>IP server is uniquely identified by its Universally Unique Identifier (UUID) string. (...) SAT>IP servers joining a network multicast three different NOTIFY ssdp:alive messages to the SSDP address 239.255.255.250 port 1900.

 

Ich glaube nicht, dass für jede IP eine UUID generiert werden soll. Das würde erhebliche Komplikationen mit sich bringen. Hängt natürlich davon ab, wie man "instance" interpretiert.

Link to comment

Hmm, hab ich gelesen.... hmmm...

 

dreimal ist also ok, aber so kurz hintereinander? das bringt doch eigentlich nichts... Da sollten schon ein paar (m)s Pausen zwischen liegen. Ich vermute, die Wiederholungen werden gefordert, damit Störungen im (W)LAN nicht zu bösen Ausfällen führen. Allerdings muss man dann auch ne gewisse Zeit abwarten, damit die Störung beseitigt sein kann.

 

Aber nicht ok ist auf jeden Fall, dass durch die gleichen UUIDs die ersten Einträge überschrieben werden, das letzte durchkommende Paket wird also gewinnen...

Das kann einfach nicht so im Sinne des Erfinders sein. Tja "Instance" ist hier wirklich der Knackpunkt. Ich such mal im Netz nach weiteren Implementationen, mal sehen, wie die das gemacht haben...

 

DNS Namen zu benutzen ist auch nicht erlaubt, habe ich inzwischen rausbekommen. Da dürfen wirklich nur "dumme" IP Adressen drin sein.

Link to comment

Falls noch nicht allen Klar ist worum es geht hier mal das so wie ich das Verstanden habe:

Zeichnung1.png

Sowohl DVBViewer als auch der RS Nutzen mehrere Netzwerkkarten gleichzeitig und sind mit mehreren Netzen Verbunden.

Der RS ist so Konfiguriert dass er alle Netzwerk Karten Nutzt.

 

Das heißt der schickt über alle Leitungen hier bin ich Nachrichten raus.

Und der Client sucht sich eine aus um sich mit dem Server zu verbinden (naheliegend wäre die zuletzt empfangene Nachricht da es in vielen Konstellationen die aktuellste sein dürfte).

 

In den Einstellungen des RS könnte man die Verwendung von einzelnen IP-Adressen deaktivieren. Das ist aber nicht gewünscht.

Da eventuell in jedem Netz ein Client ist der nur in dem einen Netz ist.

 

Statt dessen (so der Wunsch) soll der Client ermitteln was die Kürzeste Route ist und diese dann verwenden.

 

Wenn der SAT>IP Standard das nicht vorsieht und die Verwendete Delphi-Bibliotheken nichts in der Richtung anbietet würde ich sagen dass das eine Funktion ist die nur dann wirklich relevant wird wenn es mal eine Enterprise Version vom RS geben sollte.

 

In Privaten Netzwerken ist es eher selten das ein Client gibt der mit mehreren Netzen Verbunden sein muss.

Wenn die Verbindung über das WLAN schlecht ist und das Notebook per LAN angeschlossen ist macht man das WLAN halt eine weile aus.

Link to comment

Falls noch nicht allen Klar ist worum es geht hier mal das so wie ich das Verstanden habe:

 

Ok, lösch Deinen Beitrag bitte, Du hast es also offensichtlich NICHT VERSTANDEN!

 

Oder mal es richtig,

* der RS besitzt mehrere Netzwerkverbindungen

* der Klient natürlich IMMER NUR EINE!

 

post-130498-0-47941900-1404969473_thumb.jpg

 

Aber diese eine kann sich ändern! Und dann passiert es.

Selbst wenn sie sich nicht ändert, die RS Ankündigungen löschen sich offensichtlich gegenseitig aus und in den meisten der LANs wird dann DIE FALSCHE KONFIGURATION angeboten.

 

Das hat nix mit Enterprise zu tun, dass passiert schon, wenn Du einen Laptop abwechselnd im LAN (Docking Station) und im WLAN betreibst (sofern diese beiden unterschiedliche Netzadressen konfiguriert haben), kann also heutzutage potentiell fast jede Kiste treffen.

 

Und im Kern geht es auch darum, das "Plug & Play" hier genau das Gegenteil erreicht, wozu es eigentlich gedacht war, nämlich den Anwender stressfrei mit Konfigurationsdaten zu füttern.

Edited by MaM
Link to comment

Also weiter im Text Griga...

 

Ich hab die gesendeten Pakete überprüft, sie sind inhaltlich völlig ok. Die drei Pakete pro Adresse sind auch nicht identisch, sondern enthalten normgerecht verschiedene Nutzdaten. Soweit alles in Ordnung.

 

Nun wissen wir eben nicht, was mit "Instance" gemeint ist, meine derzeitige These ist, dass die letzten Pakete die davor überschreiben. Erscheint mir deshalb logisch, weil UPnP ja dem Anwender die lästige Konfiguration abnehmen soll, und deshalb besonders intensiv auf "Updates" zu reagieren hat.

 

Und wenn mir nacheinander drei verschiedene Telefonnummern zu einer Person genannt werden, dann würde ich das Ganze als Update betrachten und mir nur die letzte merken.

 

Hier kommen wir nicht weiter, das ist ja mehr eine Glaubensfrage.

 

Deshalb vielleicht mal andersherum: Wo/wie liest der DVBViewer Klient die UPnP Infos aus?

 

* Ruft er irgendeine Systemfunktion auf ?

* Hat er eine eigene Empfangsroutine ?

 

Windows selber kennt ja gar keine Geräteklasse "SATIP", deshalb kann es gut sein, dass der Windows UPnP Dienst diese Pakete einfach wegwirft und im DVBViewer eine Art "Sink" programmiert ist.

 

Kannst Du irgendwas davon entdecken?

Link to comment

Ok, lösch Deinen Beitrag bitte, Du hast es also offensichtlich NICHT VERSTANDEN!

Ich werde meinen Beitrag mit Sicherheit nicht Löschen. Da eventuell auch andere das so verstanden hatten. Und dein Befehlston ist hier absolut nicht angebracht. Unterlass das bitte in Zukunft!
Link to comment

Ein Problem dieses Forums ist es eindeutig, dass offensichtliche Fehlinformationen nicht korrigiert oder gelöscht werden. Somit trägst Du toll zur Verwirrung der Leser bei.

 

(was an "bitte" ist ein Befehlston?)

Edited by MaM
Link to comment
die RS Ankündigungen löschen sich offensichtlich gegenseitig aus

 

Ich frage mich, ob die Auslöschung im Client erfolgt. Soweit ich das (ohne Testmöglichkeit) aus dem Code ersehen kann, wird beim Parsen der Server Notification die Location (= URL) der Server-Beschreibung gelesen, z.B.

 

LOCATION: http://127.0.0.1:8089/description.xml

 

und die gesamte Ankündigung nach dem Motto "ham'wer schon" ignoriert, wenn es bereits einen Listeneintrag mit gleicher URL gibt. Andererseits erzeugt der RS hier für jede im Web Interface -> Status angezeigte IP eine entprechende URL, so dass von daher erst mal keine gegenseitge Auslöschung erfolgen kann (sonst würde ich hier im lokalen Client neben 127.0.0.1 keine zweite IP sehen).

 

Die im UI angezeigten IPs werden nicht der URL entnommen, sondern über eine Bibliotheksfunktion GetRemoteSinIP ermittelt - ich vermute, weil der Client eventuell eine andere IP als der Server sieht (?).

 

Kurz gesagt rechnet der Code nicht damit, dass ein Server mehrfach mit gleicher Beschreibungs-URL, aber verschiedenen IPs auftaucht. Könnte dies mitspielen?

 

Dabei ist mir übrigens ein Fehler aufgefallen: Server, die sich mit einer byebye Message abmelden, werden auch aufgrund der Beschreibungs-Location identifiziert und dann aus der Liste entfernt. Mit SAT>IP-konformen Servern kann dies jedoch nicht funktionieren, da in den Spezifikationen ausdrücklich steht:

 

Please note that the ssdp:byebye messages should not include the CACHE-CONTROL, LOCATION, SERVER and DEVICEID.SES.COM headers.

 

<Ergänzung> Der Fehler betrifft nur TransEdit und DVBViewer GE, nicht DVBViewer Pro und RS, die sich bei byebye auf die UUID beziehen </Ergänzung>

 

Die obigen Betrachtungen gelten nur für die Serverwahl im RTSP-Einstellungen-Dialog. Sie beruht auf einem Mechanismus, der währendessen im Hintergrund (in einem separaten Thread) ständig die Server Notifications mitverfolgt. Die Funktion, die bei nicht erreichbarem Server einschreitet, ist wesentlich einfacher bzw. direkter gestrickt, da sie nicht beliebig lange warten kann. Sie sendet eine M-SEARCH Message aus, schaut sich maximal 5 Sekunden lang an, was zurückkommt, und nimmt die IP des ersten Servers, der mit passender UUID auftaucht.

 

Hinsichtlich der Subnetmaske habe ich etwas recherchiert. Eine Funktion, die sie ermittelt, gibt es weder in unserem Code noch in den verwendeten Bibliotheken, und sie ist auch nicht auf einfache Weise über WinSock2 erhältlich. Dafür gibt es ein separates API

 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365917%28v=vs.85%29.aspx

 

Die Implementation in Delphi ist also erst mal keine geringfügige Angelegenheit.

Edited by Griga
Ergänzung
Link to comment

>Ich frage mich, ob die Auslöschung im Client erfolgt. Soweit ich das (ohne Testmöglichkeit) aus dem Code ersehen >kann, wird beim Parsen der Server Notification die Location (= URL) der Server-Beschreibung gelesen, z.B.

>und die gesamte Ankündigung nach dem Motto "ham'wer schon" ignoriert, wenn es bereits einen Listeneintrag mit gleicher URL gibt. A

 

Die spannendere Frage ist, was passiert bei unterschiedlicher URL? Wird der alte Eintrag überschrieben, oder der neue weggeworfen?

Hmm, nein, die Frage ist insofern uninteressant, denn das Ergebnis ist immer dasselbe: es bleibt was Falsches übrig (u.U) und die richtigen Infos gehen verloren.

 

>Die im UI angezeigten IPs werden nicht der URL entnommen, sondern über eine Bibliotheksfunktion GetRemoteSinIP >ermittelt - ich vermute, weil der Client eventuell eine andere IP als der Server sieht (?).

Ich hab gerade mal nachgemessen, die Adresse sollte identisch sein, mit der in der URL. Siehe meinen alten Screenshot mit den Paketen, die Absendeadresse entspricht dem Inhalt des Paketes. Also in diesem Falle ebenfalls der falsche Wert.

 

>Kurz gesagt rechnet der Code nicht damit, dass ein Server mehrfach mit gleicher Beschreibungs-URL, aber >verschiedenen IPs auftaucht. Könnte dies mitspielen?

Ja, das ist die Wurzel allen Übels. Die Frage ist weiterhin, ob er das muss, oder ob mit "Instance" doch eine andere UUID gemeint ist. Damit wäre das Problem sofort vom Tisch, denn dann sind die Einträge unterschiedlich.

 

Ich hab gestern abend noch nach weiteren DNLA Servern gefunden, konnte aber keinen finden, der mit mehreren LANs zurechtkam (deshalb hatte ich auch damals den Mezzmo gekauft, der funktionierte direkt und ohne Vortreten müssen). Ich such mal weiter,

 

>Sie beruht auf einem Mechanismus, der währendessen im Hintergrund (in einem separaten Thread) ständig die Server >Notifications mitverfolgt.

Aaah, gut! Ich hatte dies schon erwartet, da es ja keinen offiziellen "onboard" Support für die Funktion gibt. Das erlaubt zumindest an dieser Stelle eingreifen zu können, wenn es nötig wird.

 

>Die Funktion, die bei nicht erreichbarem Server einschreitet, ist wesentlich einfacher bzw. direkter gestrickt, da sie nicht >beliebig lange warten kann. Sie sendet eine M-SEARCH Message aus, schaut sich maximal 5 Sekunden lang an, was >zurückkommt, und nimmt die IP des ersten Servers, der mit passender UUID auftaucht

Aha, dann haben wir hier das Würfelspiel, wie beim alten Videospiel Joust: "Die höchste Lanze gewinnt!".

Irgendwas ist hier aber auch nicht so richtig, denn die Wartezeit ist manchmal deutlich höher als die dann maximal 3*5s hier (allerdings hab ich nie wirklich mitgestoppt, Warten kommt einem ja eh immer eeeendlos vor, ich kann mich da auch täuschen).

 

>Hinsichtlich der Subnetmaske habe ich etwas recherchiert. Eine Funktion, die sie ermittelt, gibt es weder in unserem >Code noch in den verwendeten Bibliotheken, und sie ist auch nicht auf einfache Weise über WinSock2 erhältlich. Dafür >gibt es ein separates API

Keine Panik, es gibt da recht pflegeleichte Abfragen über WMI, da sollten dann auch Klassen für Delphi verfügbar sein.

Dazu kommen wir dann (viiiiel) später.

Aber vordinglich ist erst mal, dass die Daten überhaupt verfügbar werden, im Moment sieht es ja stark davon aus, dass nur ein Eintrag überlebt, manchmal der Richtige, manchmal der Falsche.

Und eine Schleife über eine Gesamtmenge von EINS macht nicht wirklich Sinn :D

 

Mir erscheint der UUID Ansatz einfacher zu realisieren zu sein, welche Probleme siehst Du dabei ?

Edited by MaM
Link to comment

@Griga: vielleicht wäre es sinnvoll, die "Diskussion" privat per Mail zu führen? Die meisten Leute hier werden mit den Details nichts anfangen können und die Nachrichten tragen dann nur zur Verwirrung bei. Melde Dich bei <Mailadresse gelöscht>.

Edited by Griga
Mailadresse gelöscht
Link to comment

Würde ich mich mal dagegen aussprechen.

 

P.S. Die Email Adresse würde ich schnell wieder löschen um SPAM und sonstige Angriffe auf dein Postfach verhindert.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...