Jump to content

RTSP Client Round-Robin Problem


Recommended Posts

vielleicht wäre es sinnvoll, die "Diskussion" privat per Mail zu führen?

 

Abgelehnt. Ich möchte auch anderen ermöglichen, an der Diskussion teilzunehmen, sich über den Stand der Dinge zu informieren und etwas beizutragen, auch wenn dir letzteres nicht passt bzw. du darauf ziemlich rüde reagierst.

 

Weiterhin möchte ich dich bitten, die Zitier-Funktion des Forums (Quote-Tags) zu verwenden. Die Verwendung von > macht deine Posts unübersichtlich und schlecht lesbar.

 

 

>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.

 

Sicher? Kann ich mal einen vollständigen Dump des RS UPnP Outputs sehen, so wie er beim Client ankommt? Also wie hier, aber bitte alle Neune :)

 

Es hat ja keinen Zweck, mit Subnetzmasken anzufangen, wenn die zu filternden Einträge überhaupt nicht erfasst werden, warum auch immer.

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.

Lol, das ist ja einer der Hauptgründe, diese Forum nicht wirklich zu lieben. ICH KANN NACHTRÄGLICH NICHTS an meinen Nachrichten ändern. Ich würde liebend gerne sich als falscher Weg herausgestellte Vermutungen löschen, oder zumindest durchstreichen,

Das macht die Sache für potentielle Leser nicht wirklich einfacher, da sie sich auch durch die Irrungen zu kämpfen haben.

 

Lol2, die Mailadresse gibts seit 1986, sei versichert, ich habe alle Spamwellen der letzten 30 Jahre mitgemacht und überlebt (irgendwie :D )

Aber danke für die Besorgnis :fear:

Link to comment

 

Abgelehnt. Ich möchte auch anderen ermöglichen, an der Diskussion teilzunehmen, sich über den Stand der Dinge zu informieren und etwas beizutragen, auch wenn dir letzteres nicht passt bzw. du darauf ziemlich rüde reagierst.

 

Ich reagiere "rüde" darauf, weil immer wieder alte Dinge hervorgekramt werden, die schon lange abgehakt sind. Im Prinzip müsste man den Thread löschen und einen neuen aufmachen zum Thema "UPnP Probleme".

 

Weiterhin möchte ich dich bitten, die Zitier-Funktion des Forums (Quote-Tags) zu verwenden. Die Verwendung von > macht deine Posts unübersichtlich und schlecht lesbar.

 

Ja, gerne, ich finde das hier aber viel unübersichtlicher, nicht?

 

Sicher? Kann ich mal einen vollständigen Dump des RS UPnP Outputs sehen, so wie er beim Client ankommt? Also wie hier, aber bitte alle Neune :)

 

Willst Du alle Paketinhalte sehen? der Dump war vom Client aus aufgenommen, nicht vom Server die 9 Stück sind als so vom Client empfangen worden.

 

Es hat ja keinen Zweck, mit Subnetzmasken anzufangen, wenn die zu filternden Einträge überhaupt nicht erfasst werden, warum auch immer.

Na ja, ankommen sie auf jeden Fall schon, meine Frage "Wer empfängt die Pakete?" bzw. "wie werden sie ausgelesen?" bezog sich auch auf den Klienten. Der Server macht erstmal alles "richtig", er sendet brav pro Adresse jeweils drei Pakete aus, mit dem Inhalt, wie die Spec es erfordert. Und der Klient empfängt auch jeweils drei davon (aus den Absendeadressen im Screenshot sieht man, dass sie nicht alle in "richtiger" Reihenfolge eintreffen, aber das sollte auch nicht wirklich stören, ist halt UDP).

Link to comment

Also im Anhang dann ein kompletter Dump der 9 Pakete, so, wie sie vom Client empfangen werden.

 

Damit Du die Daten lesen kannst, musst Du noch den (umsonstigen) LAN Analyser runterladen (ganz runterscrollen, unten die "Portable Version").

Braucht keine Installation, einfach Exe starten (32 oder 64 Bit), dann "load capture" und dann kannst Du Dich fröhlich durchklicken.

Achtung! es werden die Rohpakete angezeigt. Wenn Du nur sehen willst, was der Klient zu lesen bekommt, dann oben links im Treeview Ethernet Header öffnen, und im Baum ganz unten "Data" anklicken. Dann werden im Paketfenster die entsprechenden Bytes invertiert dargestellt. Und das SSDP ja auf HTML basiert, kann man das recht einfach lesen.

 

(Achtung! Datei umbenennen von *.txt in *.cap !!! Das Forum lässt mich nix anderes hochladen :-( )

 

VCRssdpDump.txt

Link to comment

Ich hab mal spaßeshalber zum Vergleich den Mezzmo durchgemessen, Protokoll ist angehängt. Bei dem gehts beim Start aber deutlich plauschiger zu, der testet auch, ob der DeviceID eventuell schon belegt ist (beim RS finde ich solche Tests nicht, der ID wird doch wohl nicht fest auf "1" konfiguriert sein, siehe Spec §3.3.3)

 

Also hier erfolgen die Ankündigungen eindeutig mit unterschiedlichen UUiDs pro LAN Adresse.

 

(wieder umbenennen in .CAP)

 

HexalotteSSDPDump.txt

Link to comment
Willst Du alle Paketinhalte sehen? der Dump war vom Client aus aufgenommen, nicht vom Server die 9 Stück sind als so vom Client empfangen worden.

 

Header (insbesondere Location) plus zugeordnete IPs. Bevor ich etwas unternehme, hätte ich gerne verifiziert, dass Pakete mit unterschiedlicher UDP IP Source (ich nehme an, die wird im Code mit GetRemoteSinIP ermittelt), aber gleicher Description-URL beim Client eintreffen. Das ist nämlich der einzige für mich sichtbare Grund, aus dem Serverlisten-Einträge im Client verloren gehen können.

 

"load capture"

 

Unter dem Link gibt's keinen LAN Analyzer, sondern einen Network Scanner, und der will xml haben, nicht cap.

 

Aber soweit ich in der Textdatei sehen kann, gibt es kein Problem mit gleicher Location bei verschiedener IP. Jede URL kommt dreimal vor und entspricht den in deinem Screenshot angezeigten IPs (.0.13, .1.13, .17.13).

 

P.S. Meine ursprünglich Annahme ist falsch, dass der von mir in TransEdit verwendete Code weitgehend mit dem im DVBViewer Pro identisch ist. Lars hat mir offenbar damals eine vereinfachte Version zur Verfügung gestellt. Im DVBViewer Pro gibt es noch etwas. Nämlich eine Schleife, die beim Eintreffen eines (potentiellen) neuen Eintrags die bereits vorhandene Liste abklappert und dabei eine mit GetLocalSinIP ermittelte lokale IP (was immer das sein mag...) einbezieht. In Pseudo-Code:

 

for i := Liste.Count-1 downto 0 do

if (Liste.LocalIP = NewServer.LocalIP) and

(Liste.UUID = NewServer.UUID) and

(Liste.RemoteIP <> NewServer.RemoteIP) then

Liste.Delete(i);

Liste.Add(NewServer);

 

Auf deutsch: Bevor ein neuer Eintrag hinzugefügt wird, lösche alle Einträge mit gleicher LocalIP, gleicher UUID und abweichender RemoteIP. Der Sinn erschließt sich mir nicht wirklich. ;)

 

Falls das für das Verschwinden von Einträgen verantwortlich ist. dürfte es bei TransEdit 4.0.7 (siehe Mitgliederbereich, Beta Sektion, ReadMe lesen, unter Settings -> Hardware ein RTSP Network Device hinzufügen...) nicht passieren, weil die Schleife dort fehlt.

Link to comment

Auf deutsch: Bevor ein neuer Eintrag hinzugefügt wird, lösche alle Einträge mit gleicher LocalIP, gleicher UUID und abweichender RemoteIP. Der Sinn erschließt sich mir nicht wirklich. ;)
Wieso? ist doch recht logisch: Wenn sich die RemoteIP geändert hat, dann alten Eintrag weg und neuen hin. Nennt sich gemeinhin: UPDATE :D Der Server könnte sich theoretisch ja auch "wegbewegt" haben und nun in einem anderen Netz sein. Ist zwar zugegebenermassen sehr unwahrscheinlich, aber nicht unmöglich. Und die Schleife sorgt dafür, dass das Programm auf der sicheren Seite bleibt. Guter, defensiver, Programmierstil.
Ist genau das Problem, was wir suchen. Es kommen die 3*3 (behandeln wir ab jetzt das Tripel der Pakete als eine Einheit, da die Spec sie so fordert, wenn ich also von "3" rede, meine ich die drei verschiedenen Absendeadressen) hier an und werden einzeln einsortiert. Sobald ein Paket von anderer Adresse eintrifft, werden die anderen weggeschmissen.
(Du kannst ruhig in "richtigem" Code reden, ich hab zwar nie was mit Delphi gemacht, aber vor Urzeiten mal nen Pascal Compiler für den C64 programmiert, die Syntax kenne ich also noch :innocent: )
Die Schleife zeigt auch eindeutig, dass die Einträge überleben würden, wenn die UUID unterschiedlich ist.
Du hast mir immer noch nicht verraten, warum Du solche Angst hast, sie zu ändern?
Link to comment
Ist genau das Problem, was wir suchen.

 

Verifiziere bitte mit TransEdit 4.0.7, dass dort alle erwarteten Einträge erscheinen.

 

Die Schleife zeigt auch eindeutig, dass die Einträge überleben würden, wenn die UUID unterschiedlich ist. Du hast mir immer noch nicht verraten, warum Du solche Angst hast, sie zu ändern?

 

Du meinst eine unterschiedliche Server-UUID bei unterschiedlicher IP? Werde ich nicht ohne zwingenden Grund machen, und auch nicht ohne Rückversicherung, dass es standardkonform ist (bzw. die existierende Vorgehensweise nicht standardkonform ist). Lars hat die SAT>IP-Schiene in Kooperation mit SES Astra entwickelt und war auch an Referenz-Implementationen beteiligt. Da ändere ich nicht einfach etwas ab, nur damit es in irgendeinem Netzwerk besser passt. Da könnte ja jeder kommen :)

 

Bei der Server-Erkennung im Client gibt es etwas mehr Spielraum, aber jede Änderung muss solide begründet und ihre Wirksamkeit verifiziert sein.

 

Ich mach erst mal Pause. War 'ne Menge Stoff heute...

Link to comment

Hach, Du bist aber ein Ungläubiger Jakob :D

 

Sieh selbst, was Dein Transedit so meint:

post-130498-0-50612000-1404989770_thumb.jpg

 

Der Clientfix wird nicht ausreichen, ich hab hier noch einen anderen Client (Telestar B1), der zeigt dasselbe Phänomen, je nachdem, an welches Kabel man ihn anschliesst. (bzw, er meldet meistens "Server nicht gefunden").

Und an dem Teil kann man nix rumoperieren.

 

Aber eins nach dem Anderen...

Link to comment

So, etwas Rumstöbern bringt ein wenig mehr Klarheit, aber leider immer noch keine vollständige Aufklärung.

 

Ich hab mir mal den zugrundeliegenden RFC vorgenommen, leider gibts den nur als Draft, und leider auch schon seit 15 Jahren "outdated and obsolete", aber an irgendwas muß man sich ja halten.

 

(Nachzulesen hier : http://tools.ietf.org/html/draft-cai-ssdp-v1-03 )

 

Darin werden zumindest schon mal ein paar ungelöste Fragen des Universums erklärt, leider fehlt auch hier die vollständige Definition von "Instance".

 

Aber, zumindest beweist folgender Abschnitt, dass das derzeitige Verhalten des RS nicht so ganz korrekt ist:

 

 

2.3.2.2. Why are USNs URIs and why are they required to be unique across the entire URI namespace for all time?

In general making a name universally unique turns out to usually be
a very good idea. Mechanisms such as UUIDs allow universally unique
names to be cheaply created in a decentralized manner. In this case
making USNs globally unique is very useful because services may be
constantly moved around
, if they are to be successfully tracked they
need an identifier that isn't going to change
and isn't going to get
confused with any other service.

URIs were chosen because they have become the de facto managed
namespace for use on the Internet. Anytime someone wants to name
something it is easy to just use a URI.

Das lese ich so, dass es gewollt ist, unter dem festen UUID den entsprechenden Dienst als solchen immer wiederfinden zu können, egal, in welches Netz er abgewandert ist.

Im Umkehrschluß belegt mir das dann aber auch, dass es drei Instanzen mit getrennten UUIDs geben muß, jede von denen kann einzeln abwandeln.

Oder, es darf nur eine einzige Instanz geben, dann darf der RS aber auch nur ein Paket aussenden (was ja nun nicht wirklich klappen würde).

Auf jeden Fall heißt es, dass ein UUID genau eine definierte Location hat.

Die Schleife im Viewer ist also korrekt, im Transedit nicht.

 

(Der etwas längliche Text sei auch den "Enterprise"-Zweiflern wärmstens empfohlen, da wird dann auch nebenbei erklärt. WARUM das extra mit mehreren Netzen und Routern funktionieren soll und wie das Ganze abläuft)

 

Die von Dir verwendete Spec ist nur ein Ausschnitt des kompletten Drafts, sie legt die für SATIP eingeführten Erweiterungen fest, obiger Text definiert das komplette UPnP Protokoll (na ja, ist ja nur ein Draft, also "definiert" stimmt nicht. Aber offensichtlich sind alle derzeitigen Implementationen daran orientiert).

Edited by MaM
Link to comment

Gäähn... noch ein kleiner Nebenschauplatz zu dem Thema:

 

Wenn Du Dir die LAN Captures mal etwas genauer anguckst, öffne mal oben links im Tree "IPv4 header" und suche den Eintrag "Time to live".

Du wirst bei den vom RS gesendeten Paketen den Wert 128 finden, laut Spec gehört da 2 hinein.

Da hat wohl jemand vergessen, beim Anlegen des Sockets den Wert zu setzen...

 

(Erklärung: das Feld legt die maximale Laufweite eines Paketes fest, also wieviele Router es weiterleiten sollen, bevor es entsorgt wird. Die Norm will mit "2" erreichen, dass es in einem baumförmig strukturiertem LAN genau EINEN Ast tief funktioniert.)

 

Leider kenne ich ja Delphi nicht, aber bei .NET wäre das ganz einfach eine Zeile:

static void ConfigureTTLSocket(Socket tcpSocket)
{
// Set the Time To Live (TTL) to 2 router hops.
tcpSocket.Ttl = 2;
}

 

Ist jetzt nicht so wahnsinnig eilig, sollte aber irgendwann mal korrigiert werden.

Muss für ALLE UPnP Sockets gesetzt werden!

Mezzmo hält sich auch nicht so strikt an die Norm, die setzen "4" ein, wahrscheinlich damit es noch über eine WLAN Bridge funktioniert. 2 ist m.E nach etwas knapp, aber 128 ist natürlich völlig übertrieben. Für den Heimeinsatz sind 3 oder 4 sinnvoll.

Edited by MaM
Link to comment

Wenn Du Dir die LAN Captures mal etwas genauer anguckst, öffne mal oben links im Tree "IPv4 header" und suche den Eintrag "Time to live".

Du wirst bei den vom RS gesendeten Paketen den Wert 128 finden, laut Spec gehört da 2 hinein.

 

Da sehe ich "Time to live: 1 hops (seconds)".

Link to comment

 

Da sehe ich "Time to live: 1 hops (seconds)".

Yep, sorry, hatte die falschen Samples genommen (die vom Datentransfer über rtsp) (gäähn 5 Uhr morgens im Halbschlaf...)

 

Steht 1 drin, ist aber auch falsch :D

 

Also Minimum wäre 2. aber das diese "WLAN-Extender" inzwischen weite Verbreitung gefunden haben, würde ich 3 oder 4 nehmen.

 

Das Programm wird wahrscheinlich dann korrekterweise die 2 nehmen, wird ja einer abgezogen, wegen der Multicastweiterleitung.

Edited by MaM
Link to comment

Wie so oft im Leben, hatten wir beide recht. Teilweise ist da 1 drin, teilweise 128. Nimm diese Samples, die ich gerade gemacht habe. Die Pakete zum Multicast Socket haben alle 1, die letzten unten, sind unicast direkt an den potentiellen Client, da ist dann 128 drin.

 

Das stört aber nicht weiter, da Unicast und lokale Adresse.

 

Schlimmer ist die 1, die wird Dir böse Supportanfragen a la "ich kann über mein WLAN den RS nicht finden, bei Rechnern im LAN wird er gefunden" bringen.

 

(oh, irgendjemand hat mein Attachmentlimit angehoben, danke!)

 

xxx.txt

Link to comment
Die Pakete zum Multicast Socket haben alle 1,

 

 

Hmm, in der Datei UPNPAnnounce.pas des RS, Prozedur InitSocket sehe folgenden Code (Auszug):

 

Socket := TWSocket.Create;

Socket.Proto := 'udp';

Socket.Addr := IP; //IP passed as parameter

Socket.LocalAddr := IP;

Socket.Port := '1900';

Socket.MultiCastIpTTL := 5; //<========

Socket.MultiCast := true;

Socket.MultiCastAddrStr := '239.255.255.250';

Socket.ReuseAddr := true;

 

Ich finde auch keine Stelle, die (für Multicast) eine andere TTL setzt. Der gute Wille ist bzw. war jedenfalls da :)

 

Beim Aufruf von Create initialisiert die verwendete Bibliothek MultiCastIpTTL mit IP_DEFAULT_MULTICAST_TTL = 1. In der Bibliothek gibt es nur eine Stelle in einer Prozedur Connect, die die TTL dem WinSock2 API übergibt, sofern sie verschieden 1 ist. Aber die Stelle wird laut Debugger im RS nie ausgeführt. Connect wird offenbar für den Multicast überhaupt nicht aufgerufen (hätte mich bei UDP auch irgendwie gewundert). Also läuft die Sache wohl mit dem Socket TTL Default = 1. Das ganze passt hinten und vorne nicht ;)

 

Sobald ich dafür Zeit finde, ich werde dem weiter nachgehen...

Link to comment

Keinen Stress damit, das ist nur ein Nebenschauplatz.

 

Aber zur Info:

A list of TTL thresholds and their associated scope follows:

 

TTL Scope ----------------------------------------------------------------------
0 Restricted to the same host. Won't be output by any interface.
1 Restricted to the same subnet. Won't be forwarded by a router.
<32 Restricted to the same site, organization or department.
<64 Restricted to the same region.
<128 Restricted to the same continent.
<255 Unrestricted in scope. Global.

 

Die "1" bedeutet also "nur in diesem LAN Segment" und ist bestimmt nicht das, was er beabsichtigt hat. "Site" usw. ist viel besser geeignet.

(lol, ich muß den Altkram auch immer wieder nachlesen, heute nimmt man FF05::C und fertig ist die Laube (UPnP Multicast Adresse für V6 auf Site Level)

Edited by MaM
Link to comment

 

Socket.Port := '1900';

Socket.ReuseAddr := true;

Obige beiden Angaben würde ich als "gefährlich" einstufen, die solltest Du im Auge behalten und wenn möglich entfernen:

1) es ist völlig unüblich und unnötig, den Absendeport (ich unterstelle mal, das ".Port" das Quellport festlegt) zu definieren. Irgendwo beim Senden, da wird die Zieladresse und Zielport festgelegt. Jeder normale Mensch schreibt da "0" rein und lässt dem Betriebssystem die freie Auswahl eines freien Ports. Beim Trace hab ich schon gesehen, dass es von 1900 nach 1900 ging, hatte mich stutzig gemacht.

 

2) wenn bei 1) 0 drin ist, kann es nie zu einer Doppelbenutzung kommen, deshalb ist diese Einstellung unnötig.

 

Die Kombination der beiden birgt die Gefahr in sich, dass auf der gleichen Maschine noch ein anderes Programm sich auf UDP/1900 verlustigen möchte. Dann kommts zum Kampf um den Socket und bei ReuseAddr=true kann ich das Verhalten nicht vorhersehen, die Daten könnten gedoppelt werden, den Bach runtergehen oder es kann eine böse Exception geben. Im unwahrscheinlichsten Falle kann es auch klappen :-)

 

Hmm, oder war das der Empfangsocket ? dann wäre es richtig, selbst das Reuseaddress.

 

Der Teil muß zweimal vorhanden sein, einmal zum Senden, einmal zum Empfangen...

Beim Empfang kommt wohl kurz dahinter ein "bind()" und die Empfangsschleife, wohl in einem separaten Thread.

Edited by MaM
Link to comment

Beim Aufruf von Create initialisiert die verwendete Bibliothek MultiCastIpTTL mit IP_DEFAULT_MULTICAST_TTL = 1. In der Bibliothek gibt es nur eine Stelle in einer Prozedur Connect, die die TTL dem WinSock2 API übergibt, sofern sie verschieden 1 ist. Aber die Stelle wird laut Debugger im RS nie ausgeführt. Connect wird offenbar für den Multicast überhaupt nicht aufgerufen (hätte mich bei UDP auch irgendwie gewundert). Also läuft die Sache wohl mit dem Socket TTL Default = 1. Das ganze passt hinten und vorne nicht ;)

Nach allem was ich sehe (nach dem ich das Komische Tool heruntergeladen habe um die .cap Datein in eine Wireshark Taugliche Forma zu konvertieren) ist TTL bei allen Multicast Paketen 1 ist

(auch bei mir). Das entspricht also dem was du im Code gefunden hat.

 

Das heißt das ist ziemlich sicher der falsche Platz zum suchen.

 

Die einzigen Pakete mit einer längeren ttl (128) sind UDP Pakete mit der Ankündigung source port 1900 dest port 64486 mit dem HTTP Statuscod 200 (Standard response for successful HTTP requests) sonst aber den Inhalt der Multicast Pakete.

 

Interessant wäre jetzt ob und wenn ja zu welcher anfrage die eine Antwort sind.

 

PS: Ab 100 Beiträgen gibt es automatisch den Status Senior Members mit ein paar mehr rechten und etwas mehr platz. Da hat also niemand was extra umgestellt.

 

 

Ich bekomme bei mir grade nur die Multicast Pakete.

Link to comment

Also "connect()" kann es bei UDP nicht geben, die Pakete werden überweise einfach mit socket.sendto() unter Angabe der Zieladresse (hier eben die Multicastadresse) gesendet.

Eigentlich muß es zwei getrennte Sockets geben, einen zum Empfang (das scheint mir der zu sein, den Du gefunden hast) und einen zum Senden (bei dem eben NICHT alle Felder angeben werden, wenn TTL defaultmässig auf 1 ist, dann wird das wohl gar nicht definiert sein. die "5" hier hat keine Funktion wenn es der Empfangssocket ist).

Ich tendiere dazu, dass Du die falsche Stelle gefunden hast, sorry.

 

 

@Tjod: Vergiß nicht Murphy's Law #53: "wer misst, misst Mist!". Die Traces enthalten immer nur die Pakete, die beim Messclient auch ankommen. Also nur die Multicasts, die an alle "Members" gerichtet sind. Wenn Du alle Pakete des Ports 1900 sehen willst, mußt Du den RS messen und das bitte über ein Shadowport vom Switch (oder eben auf dem RS selber). Meine Traces waren vom Client, da kommt also nix an, was an andere Clients gesendet wurde (Machte die Anzahl der zu sichtenden Pakete aber deutlich handlicher :-) )

Link to comment
Eigentlich muß es zwei getrennte Sockets geben, einen zum Empfang (das scheint mir der zu sein, den Du gefunden hast) und einen zum Senden

 

Für jede lokale IP - außer für die in der Blacklist - erzeugt der RS in einer Schleife ein UDP Multicast Socket-Objekt, indem er InitSocket aufruft (und dort für jeden Socket eine Methode namens Listen). Ergebnis: Eine Liste von Multicast UDP Listening Sockets. Danach wird ein Timer aktiviert, der periodisch irgendwelche Strings über genau diese Sockets mit SendTo abschickt. Kurz gesagt werden sie für Empfang und Senden verwendet. Siehe dazu auch hier.

 

Lars hatte offenbar nicht auf der Rechnung, dass bei der verwendeten Bibliothek die Eigenschaft MultiCastIpTTL dann und nur dann wirksam wird, wenn man die Methode Connect aufruft, was aber nicht passiert (es wird Listen aufgerufen). Ich habe jetzt für Abhilfe gesorgt, indem ich in InitSocket direkt mit dem WinSock2 API spreche:

 

OptVal := 5;

SetSockOpt(HSocket, IPPROTO_IP, IP_MULTICAST_TTL, @OptVal, SizeOf(OptVal));

 

Ist jetzt im Licht dieser Erkenntnisse noch etwas fragwürdig?

Zwischenablage01.png

Link to comment
OptVal := 5;

SetSockOpt(HSocket, IPPROTO_IP, IP_MULTICAST_TTL, @OptVal, SizeOf(OptVal));

 

Ist jetzt im Licht dieser Erkenntnisse noch etwas fragwürdig?

 

 

Nö, klingt gut, Thema durch. Falls Du mal irgendwann an Arbeitsmangel leidest und Dir langweilig ist, kannste diese Stelle ja nochmal vorkramen und einen der ach so beliebten Tweaks einbauen, damit der Admin bei Bedarf dran rumschrauben könnte. Aber mit "5" fällt mir nun auch keine handelsübliche Topologie mehr ein, wo die Pakete nicht mehr bis zum Client kommen.

Einzige kleine Warnung: IP_MULTICAST_TTL ist nicht wirklich portabel. Aber darauf wirds Dir wohl auch nicht ankommen.

 

Gut, Thema durch, zurück zum Hauptproblem...

Jetzt werden die Ankündigungen auch abgesetzt Clients erreichen, nun fehlt noch, dass dort auch nur das Richtige ankommt.

 

Ich möchte nochmals darauf hinweisen, dass ein Filter (nach Netzmaske) im Client zwar eine notwendige Bedingung ist, aber keine ausreichende. Da viele "andere" Klienten nicht änderbar sind, muss der RS dafür sorgen, dass zumindest die Pakete nicht überschrieben werden. Und ich glaub, damit sollte man anfangen, wir werden dann sehen, wie der aktuelle DVBViewer reagiert (er wird dann dasselbe machen, wie Transedit, nämlich drei verschiedene Einträge zeigen).

 

Deshalb sag ich immer noch UUID, aber zusätzlich muß nochwas passieren:

Dem User hilft es nichts, in der Liste dreimal "DVBViewer Server(Name)" zu sehen, er klickt dann selbst bei Kenntnis der Topologie, weil er nicht erkennen kann, WELCHE IP hinter dem Eintrag lauert, auf den falschen Eintrag.

 

Also würde ich vorschlagen, auch diesen Text pro Instanz irgendwie zu modifizieren, vielleicht statt Name die IP Adresse rein, oder irgendwas anderes virtuoses. Das ist zwar nur Kosmetik, aber erspart dann auch schonmal viele Rückfragen.

 

Bei den "Dummclients" (wie z.B. diesem Telestar Dingen) hat der User ja gar keine Auswahl, die werden erstmal weiter gegen die Wand fahren. Hoffen wir, dass dort ein Fallback programmiert ist, nach dem Motto: Na, wenn der eine Server nicht antwortet, dann probier ich eben nach Timeout den nächsten der Liste aus (kann ich im Moment nicht testen, weil dort garantiert auch der Eintrag überschrieben wird, er also nur einen Server kennt und deshalb niemals weiterprobiert).

Edited by MaM
Link to comment

..der thread hatte ja anfangs einen hohen popcorngehalt. Jetzt wo es ernster ist, verfolge ich es nicht mehr so genau ;) Nur eine bemerkung:

 

Aber mit "5" fällt mir nun auch keine handelsübliche Topologie mehr ein, wo die Pakete nicht mehr bis zum Client kommen.

Der hop-counter ist nicht nur vom diameter des netwerks abhängig, sondern soll auch schleifen verhindern. Bei einem zu hohen wert können die datagramme ein paar extrarunden machen, bevor sie vernichtet werden ;)

Link to comment
..der thread hatte ja anfangs einen hohen popcorngehalt. Jetzt wo es ernster ist, verfolge ich es nicht mehr so genau ;)

 

Sorry, beim nächsten Thread werde ich bestimmt wieder mit meiner rüden Art für Deine Samstagabendunterhaltung sorgen, versprochen. Aber hier gehts eigentlich darum, was getan zu bekommen an der Basis.

 

 

 

Der hop-counter ist nicht nur vom diameter des netwerks abhängig, sondern soll auch schleifen verhindern. Bei einem zu hohen wert können die datagramme ein paar extrarunden machen, bevor sie vernichtet werden ;)

 

 

 

Ich könnte nun wieder mal einen meiner lästerlichen Kommentare... aber nein, bleiben wir sachlich. Sei versichert, wir sind eingedenk dieser wertvollen Information und haben deshalb einen möglichst geringen Wert angesetzt. Aber die aktuelle "1" ist definitiv zu wenig und der default von "128" viel zu hoch, durch Fingerabzählen (WLAN Bridge) kam ich auf 3 und Griga hat noch ein WLAN vom Nachbarn draufgehauen und kam so auf 5.

Selbst wenn ich direkt im RouterLAN 5 hops "nach draussen" sende (also totale Fehlkonfiguration, bewußt in Kauf genommen) lande ich dabei gerade mal beim Eingangsrouter vom DECIX. Der kann das ab :-)))

Mit 5 wird also auf keinen Fall die Welt verseucht.

 

 

Routenverfolgung zu www.heise.de [2a02:2e0:3fe:1001:7777:772e:2:85] über maximal

30 Abschnitte:

 

1 <1 ms <1 ms <1 ms 2a02:908:fb30:b340:2665:11ff:fe1d:4f6

2 8 ms 9 ms 16 ms 2a02:908:fb00:3::1

3 8 ms 9 ms 9 ms 2a02:908:0:10f::1

4 12 ms 11 ms 12 ms 2a02:908::9:1

5 18 ms 15 ms 15 ms gi1-15.c1.d.de.plusline.net [2001:7f8:8::3012:0:

1]

6 18 ms 18 ms 15 ms 2a02:2e0:12:13::102

7 17 ms 15 ms 15 ms 2a02:2e0:3fe:0:c::1

8 15 ms 20 ms 15 ms www.heise.de [2a02:2e0:3fe:1001:7777:772e:2:85]

(und ich geh mal davon aus, die meisten anderen Provider haben noch mehr interne Hops zwischen Kunde und Internet)

PS: bei mir würd es eh nicht in die Welt entweichen, wie man sieht, ich hab nur noch V6 zum Internet. V4 Pakete bleiben immer lokal.

Edited by MaM
Link to comment
zurück zum Hauptproblem...

 

Ich habe mich mal etwas in die UPnP-Spezifikationen eingelesen, und hier der aktuelle Erkenntnisstand:

 

Der USN Header mit der UUID identifiziert eindeutig eine Geräteinstanz. Bei SAT>IP ist das der Server und speziell beim RS die Server-Installation - wenn man ihn neu / woanders installiert, hat er eine andere UUID.

 

Die UUID bleibt gleich, egal über welches Netzwerk, welches Interface oder welchen Stack (IPv4/IPv6) die Instanz ihre Dienste anbietet, außer wenn die Geräteeigenschaften signifikant von der jeweiligen Schiene abhängen. Z.B. kann ein Gerät über IPv6 andere Dienste als über IPv4 anbieten.

 

A device supporting both IPv4 and IPv6 simultaneously SHALL be advertised using the same USN on both IPv4 and IPv6 only if the device description document and presentation resources are identical when accessed from both protocols.

 

Der Client bzw. Control Point erfährt durch den LOCATION Header, wie der Server erreichbar ist. Wenn er Ankündigungen mit gleicher USN, aber verschiedener LOCATION erhält, gibt es jedoch ein Problem: Er kann nicht wissen, ob ein und der gleiche Server auf verschiedene Arten erreichbar ist, oder ob es sich um ein Update handelt, d.h. der Server auf eine andere Adresse abgewandert ist.

 

Mit den Mitteln USN und LOCATION lässt sich dies nicht feststellen. Der DVBViewer Pro versucht es trotzdem auf unzureichende Weise. Er nimmt an, dass es sich um ein Update handelt, wenn über das selbe lokale Interface eine Ankündigung mit bereits erfasster USN, aber anderer LOCATION eintrifft. Das ist so jedoch nicht korrekt und geht in MaM's Netzwerk prompt schief. Es kommt zur gegenseitigen Auslöschung von Einträgen.

 

Um Updates sauber erkennen zu können, müssen sowohl Server als auch Client ein weiteres Header-Element namens NLS (Network Location Signature) unterstützen, das sich nur bei Updates ändert. Es wird in den ursprünglichen UPnP-Spezifikationen 1.0 nicht erwähnt und ist offenbar erst nachträglich anlässlich IPv6 spezifiziert worden, gilt aber auch für IPv4. Am besten (kürzesten) sind die Zusammenhänge in UPnP Device Architecture v1.0 Annex A - IPv6 beschrieben, siehe insbesondere Abschnitt A.2.3 und A.2.4 - letzterer geht explizit auf die Verhältnisse in MAM's Netzwerk ein:

 

(...) when a control point supporting multiple networks, addresses, or interfaces receives announcements from a device which also supports multiple networks,address, or interfaces - the USNs will still match, but the location URL may be different (each may contain a different literal numeric IP address). In this case, if the device follows the guidelines above, the NLS header values will match across all networks, address, and interfaces, allowing the control point to properly determine that the device is accessible through multiple LOCATIONs rather than having changed LOCATION.

 

Die Anwendung einer Subnetmaske, um unter mehreren möglichen die "beste" Verbindung herauszufinden, bleibt von diesen Betrachtungen unberührt. Das ist eine Sache für sich.

 

Um das alles sauber zu regeln, sind einige architektonische Arbeiten sowohl im RS als auch in unsere Clients (DVBViewer Pro/ GE, TransEdit, RS als Client) erforderlich. Sicherlich keine kurzfristige und keine einfache Angelegenheit, und Tjod's Idee, die Implementation in einer Enterprise-Version zu verschieben, hat deshalb eine gewisse Verführungskraft :)

 

Nichtsdestotrotz werde ich über die Sache weiter nachdenken... kurzfristig möglich und angebracht erscheint mir, den missglückten IP-Update-Identifizierung-Mechanismus in der Pro erst mal rauszunehmen, so dass sich das Programm in der Hinsicht wie TransEdit verhält. Und von der Basis ausgehend weiterzusehen.

Link to comment

Na gut, so kommen wir nicht weiter. Die Dokumentation ist einfach zu schwammig.

 

Ich hab aber noch ne andere Idee, wo wir gucken und eingreifen können:

 

* Die Klienten verlassen sich ja nicht nur auf die zyklischen Ankündigungen, sondern plärren doch beim Neustart sicherlich so eine M-SEARCH Nachricht raus? (Schliesslich will ja wohl keiner warten, bis innerhalb der 1800s der Server sich mal wieder gemeldet hat, das soll ja eigentlich nur einmal passieren und der Klient sich danach die USN merken und beim nächsten Booten versuchen den Server wiederzufinden).

 

* Der Server antwortet darauf mit einem UNICAST direkt an den Klienten !

 

Wenn wir zumindest schon mal hinbekommen (ich sach nur.... Netzmaske...) dass der Server wenigstens hier mit der richtigen Location antwortet, wäre schonmal viel gewonnen.

 

Das ersten Einschalten eines Klienten könnte dann in die Hose gehen, der User wird ungeduldig und bootet den Klienten neu, der fragt nun nach der richtigen USN und diesmal erhält er dann wenigstens auch die richtigen Daten.

 

Kann man dem Anwender ggf. zumuten, ist vielleicht sogar sein natütliches Verhalten. Und nachdem es einmal geklappt hat, grummelt er auch nicht so lange und laut vor sich hin.

Link to comment

Um weiteren möglichen Streit zu vermeiden, ich glaub, ich hab den Verursacher des Übels entdeckt: MICROSOFT :D

 

Hier aus den "final" Specs von 2008, 1.0 Chapter 1, Discovery:

 

For devices and control points that have multiple network interfaces, UPnP advertisements and searches should be sent on all network interfaces enabled for UPnP networking. Each advertisement or search must specify an address in the LOCATION header that is reachable on that interface

Liest sich erstmal harmlos und richtig, ist aber total falsch!

Begründung: Die haben glatt vergessen, dass die Advertisements über einen Multicast Kanal gehen! Da KANN MAN DIE PAKETE JA GAR NICHT TRENNEN!

Die Mischerei (und damit das Kuddelmuddel) passiert also automatisch...

 

Also, der RS ist zwar "laut Spec", aber funktionieren kann es so nicht.

 

Dieselbe Spec sagt auch:

 

To limit network congestion, the time-to-live (TTL) of each IP packet for each multicast message should default to 4 and should be configurable.

Mit 5 liegen wir also gut, und die Idee mit dem Tweak ist auch nicht so abwegig.

 

So, und bevor Du noch am Schlucken bist, der Tag ist noch nicht zuende...

 

Ein paar Wochen später hat man wohl gemerkt, dass da irgendwas nicht so ganz toll ist, und nachgearbeitet!

Da gibts doch glatt ne Spec 1.1 MIT GLEICHEM DATUM!

Und noch dümmererweise werden BEIDE immer noch parallel weiterverbreitet! Wenn Du gaaanz viel Zeit hast geh auf diese Seite http://upnp.org/sdcps-and-certification/standards/device-architecture-documents/ und klick auf "Download.zip", da sind dann ALLE Docs und viele Samples mit drin und Du kannst Dir das Beste raussuchen...

Von 1.1 sind die Seiten 14 und 15 interessant, sie beschäftigen sich nur mit Multihomed Devices und was mit ihnen passieren soll.

 

Für uns am meisten interessant ist vielleicht dieser Satz:

 

When a multi-homed device becomes available to the network on a new UPnP-enabled interface (in addition to any existing UPnP-enabled interfaces), it MUST increase its BOOTID.UPNP.ORG field value (see section 1.2 “Advertisement”), and multicast a number of update messages on the existing UPnP-enabled interfaces to announce the new BOOTID.UPNP.ORG field value.

Also nicht die UUiD ändern, sondern das BOOTID Feld hochzählen! (hmm, mussich mir mal angucken, gibts das Feld überhaupt?)

 

Ach ja, 1.1 hat auch eine andere Meinung zur TTL:

To limit network congestion, the time-to-live (TTL) of each IP packet for each multicast message SHOULD default to 2 and SHOULD be configurable

Mir scheint, die wissen da nicht wirklich, was sie tun...

 

Und dann gibts natürlich auch noch diesen Annex für V6, da ist dann wieder alles anders...

Edited by MaM
Link to comment

Ich denke, die Update-Problematik ist erst mal nicht so bedeutend. Mit den im DVBViewer / in TransEdit implementierten SAT>IP relevanten UPnP-Mechanismen wird ja kein SAT>IP-Server-Monitoring betrieben, sondern nur eine relativ kurzzeitig angezeigte und eher selten verwendete Auswahlliste in einem Einstellungsdialog bestückt. Dass sich gerade in dem Zeitraum eine Server IP ändert, ist ziemlich unwahrscheinlich, oder?

 

Wichtiger erscheint mir, die folgende Empfehlung aus den UPnP-Spezifikationen zu realisieren:

 

A UPnP device which advertises on multiple networks, multiple addresses, or multiple interfaces SHOULD be displayed only once in the control point user interface in order to reduce user confusion.

 

Um dafür einen Rahmen abzustecken: Wäre folgende Vorgehensweise angebracht?

 

(1) Wenn eine Ankündigung mit einer Loopback-IP = 127.xxx.xxx.xxx eintrifft, führt dies zum Löschen aller Einträge mit gleicher UUID und anderer IP. Solche Einträge werden nicht mehr aufgenommen, wenn bereits ein Eintrag mit gleicher UUID und einer IP = 127.xxx.xxx.xxx existiert. D.h. ein RS auf dem selben PC wie der Client erscheint nur noch unter 127.0.0.1.

 

(2) Wenn eine Ankündigung über ein Interface eintrifft, dessen IP laut Subnetzmaske zum selben Netzwerk wie die Server IP gehört, führt dies zum Löschen aller Einträge mit gleicher UUID und einer Server IP, die nicht zu diesem Netzwerk gehört. Solche Einträge werden nicht mehr aufgenommen, wenn bereits ein Eintrag mit gleicher UUID und einer zum selben Netzwerk gehörenden IP existiert.

 

Anzumerken sind noch folgende Punkte:

 

- Server, deren LOCATION nicht erreichbar ist, können nicht in der Liste erscheinen, weil der Download der Description.xml mit HTTP GET scheitert. Allerdings hält dies den gesamten Erkennungsprozess je nach Timeout mehr oder weniger lange auf ;)

 

- Zu berücksichtigen ist, dass ein Server mit gegebener UUID eventuell nur in einem anderen als dem Netzwerk des Clients präsent ist. Deshalb kann die Erkennung nicht lange auf eine bessere (kürzere) Verbindung warten. Die Folge ist, dass in der Server-Auswahlliste zu Beginn unerwünschte Einträge auftauchen können.

Link to comment

Sehr unbefriedigend :fear:

 

Du willst also alle Leute, die irgendwelche fertigen Clients gekauft haben, im Regen stehen lassen? Das wird den jeweiligen Firmen nicht wirklich gefallen. Und deren Anwendern schon gar nicht.

 

Fixe lieber den RS, damit sind viele Fliegen mehr mit der Klatsche erschlagen.

 

PS: den "Get" Befehl würde ich nun wirklich nicht als Maß aller Dinge ansehen. Wer weiß, welche Funktionen der Programmierer von Client-X dafür verwendet hat? Unter Umständen werden da noch Proxy Server eingeschleift, die dann Deine Erwartungen arg enttäuschen und die Seite trotz fehlender Direktconnectivität ausliefern.

 

Link to comment

Zusammenfassung:

 

* Das Problem ist wohl darin begründet, dass der RS seine Ankündigung (und seine Unicast Antworten! Ich habs nachgemessen) immer mit demselben UUiD, aber mit unterschiedlichen LOCATIONs (IP Adresse) macht. Dadurch werden die verschiedenen Ankündigungen bei den Klienten nicht als "alternatives Ziel", sondern als "Update" interpretiert, es bleibt immer nur das zuletzt eintreffende Paket übrig. Und da wird eben für viele Klienten die falsche Location drinstehen.

Leider ist dieses Verhalten in den sich teilweise widersprechenden Specs ausdrücklich erwünscht, zumindest die Version mit der höchsten Versionsnummer hat das Problem nun zumindest erkannt und schlägt eine Alternative vor (die allerdings inkompatibel zu vorhandenen Klienten ist, also auch nicht wirklich in Betracht kommt).

 

Griga möchte nun dauernd und gerne an dem einen, ihm verständlicherweise nahestehenden, Klienten rumbasteln und dort für Abhilfe sorgen, ich denke da viel mehr an die ganzen Leute, die das Zeug schon gekauft haben und nun mit mystischen Problemen konfrontiert werden, ohne eine Chance auf Update, weil man eigentlich dazu nochmals die Spec überarbeiten müsste (und, nebenbei, die Firma SES gar keinen Einfluß nehmen kann, weil sie noch nichtmals Mitglied ist in dem entsprechedem Arbeitskreis).

Deshalb sehe ich als einzige sinnvolle Möglichkeit, den Serverteil des RS zu modifizieren, und habe einen Ansatz dafür gefunden:

 

Das Handshake basiert auf zwei unterschiedlichen Abläufen:

1) die zyklischen Ankündigungen des Servers auf den Multicast Kanal (auf dem wir bislang rumgeritten sind, und nun nicht weiterkommen)

und

2) Unicast Antworten des Servers auf sogenannte M-SEARCH ("Hallo, ich bin wieder im Lande, Server mit UUiD X, wenn Du an bist, bitte bei mir melden!") Anfragen eines Klienten, der nach einem Reboot seinen alten Server versucht wiederzufinden.

 

Der Vorteil von 2 ist, der Server kennt die Absenderadresse des Klienten und kann ihm nun in der Antwort die richtige, zugehörige, Location zusenden. Meine Messungen haben leider ergeben, dass im Moment die Antworten auch mehr oder minder zufällig aus der Liste der verfügbaren IP Adressen erfolgt, hier könnte man also durch eine relativ einfache Ergänzung (suche anhand der Netzmasken die richtige lokale Adresse raus) dafür sorgen, dass der Klient korrekt bedient wird.

 

Damit würde bei keinem Klienten, egal von welchem Hersteller, eine Änderung notwendig werden. Der Handshake läuft zwar immer noch nicht so glatt, wie das Protokoll mal gehofft hatte, aber zumindest ist ein Rückfallkonzept da, das ab dem zweiten Start eines Klienten greift.

 

Beim ersten Start (also nach "zurück auf Werkseinstellungen") überwacht der Klient die zyklischen Ankündigungen die unter 1) beschrieben sind. Daraus erwählt er einen Server und speichert dessen UUiD im NVRAM ab. Ab dem nächsten Boot, bzw, bei Nichterreichbarkeit des ermittelten Servers, fällt er auf 2) zurück und versucht, den gespeicherten UUiD mittels M-SEARCH wiederzufinden.

 

Mit der vorgeschlagenen Änderung kommt dann wenigstens der richtige Teil an und der Klient ist lebensfähig.

Edited by MaM
Link to comment
Sehr unbefriedigend :fear: Du willst also alle Leute, die irgendwelche fertigen Clients gekauft haben, im Regen stehen lassen

 

Was soll das den jetzt??? Will er sich duellieren? Ich mache das, was man sinnvollerweise bei komplexen Problemen tut: In Teilprobleme zerlegen, Prioritäten setzen, die Teilprobleme lösen, Teil-Lösungen austesten. Divide et impera :)

 

Heute habe ich erst mal eine Funktion gebaut, die mir die Subnetzmasken aller verfügbaren Adapter / Interfaces liefert, also eine programmtechnische Voraussetzung für die Realisierung deiner Vorschläge geschaffen. Dann habe ich die weitere Vorgehensweise hier zur Diskussion gestellt, für den Fall, dass ich dabei einer Fehleinschätzung unterliege.

 

Dabei geht es erst mal nur um die Serverliste im RTSP Einstellungs-Dialog von vier Anwendungen (DVBViewer Pro, DVBViewer GE, TransEdit, RS Optionen). Damit fängt man IMO am besten an, weil man dort die Ergebnisse sieht, was Tests erleichtert. Ich werde es zuerst in TransEdit implementieren, weil ich von dem Programm schnell & unkompliziert Testversionen hochladen kann, so dass z.B. du probieren kannst, ob es in deiner Ungebung funktioniert. Beim DVBViewer Pro und RS müsste es dagegen immer über Christian laufen, und das zieht sich...

 

Griga möchte nun dauernd und gerne an dem einen, ihm verständlicherweise nahestehenden, Klienten rumbasteln und dort für Abhilfe sorgen,

 

Wat'n Blödsinn.

 

2) Unicast Antworten des Servers auf sogenannte M-SEARCH ("Hallo, ich bin wieder im Lande, Server mit UUiD X, wenn Du an bist, bitte bei mir melden!") Anfragen eines Klienten, der nach einem Reboot seinen alten Server versucht wiederzufinden.

 

Natürlich arbeiten die Clients mit M-SEARCH-Anfragen, und der RS antwortet darauf. Haben dir das deine schlauen Tools noch nicht erzählt? Oder warum sehe ich *sofort* eine Liste *aller* laufenden RS-Instanzen in meinem Netzwerk, wenn ich in TransEdit oder sonstwo die Einstellungen eines RTSP-Gerätes öffne? Wo ist jetzt das Problem?

Link to comment

 

Was soll das den jetzt??? Will er sich duellieren?

Quatsch, ich will Lösungen, und dabei möglichst universelle und mit dem geringsten Aufwand.

 

 

Heute habe ich erst mal eine Funktion gebaut, die mir die Subnetzmasken aller verfügbaren Adapter / Interfaces liefert

Sehr schön, die werdet Ihr dann ein paarmal brauchen.

 

Testversionen hochladen kann, so dass z.B. du probieren kannst, ob es in deiner Ungebung funktioniert

Na ja, ich hab schon ausprobiert, was passiert. Deshalb ja meine Vorschläge. Nicht nur Code ist modifizierbar, mit geeigneten Geräten kann man auch vorbeifliegenden LAN Pakete umdupsen, wie man sie haben möchte :-)

 

 

Dabei geht es erst mal nur um die Serverliste im RTSP Einstellungs-Dialog von vier Anwendungen (DVBViewer Pro, DVBViewer GE, TransEdit, RS Optionen). Damit fängt man IMO am besten an

Wenn Du meinen Vorschlag mal näher betrachten würdest, könntest Du erkennen, dass damit die Änderung der vier Anwendungen unnötig wird. Heile die Quelle und der Fluß wird folgen...

 

 

Beim DVBViewer Pro und RS müsste es dagegen immer über Christian laufen, und das zieht sich

Sorry, ich kenne eure Arbeitsteilung nicht, also muss ich mich mit meinem Anliegen an Christian wenden ?

Zeit ist kein Problem, gut Fix will Weile haben.

Ich habe keinen akuten Stress damit, ich kann hier so umstrukturieren, dass der Fehler nicht auffällt (da jetzt gleich Fußball ist habe ich mal alle Smartphones und Tablets per DHCP ins "0" Netz geholt und dem RS nur noch die 0 gelassen. Da klappts dann auch mit dem Streaming...)

Ich wollte euch hauptsächlich erstmal für das Problem sensibilisieren und rechne damit, dass immer mehr Leute sich mit etwas diffusen Fehlerbildern bei euch melden, von denen sich einige sicherlich auf ursächlich auf diesen Kram rückführen lassen werden. So braucht man wenigstens nicht immer neu von vorne anfangen zu suchen.

Nehmt euch alle Zeit der Welt, aber macht es sauber und richtig und hilfreich für alle.

 

Natürlich arbeiten die Clients mit M-SEARCH-Anfragen, und der RS antwortet darauf. Haben dir das deine schlauen Tools noch nicht erzählt? Oder warum sehe ich *sofort* eine Liste *aller* laufenden RS-Instanzen in meinem Netzwerk, wenn ich in TransEdit oder sonstwo die Einstellungen eines RTSP-Gerätes öffne? Wo ist jetzt das Problem?

Das Problem hierbei ist dasselbe, wie bei dem Multicast: DIE ANTWORT IST FALSCH!

Auch hier wird (bislang) nicht überprüft, WELCHER Klient denn da anfragt und es wird ihm irgendeine Location aus den verfügbaren gesendet (bei mit immer die "Hauptadresse" des Servers, also wahrscheinlich immer die erste der Liste).

Also ist genau dasselbe Spielchen, wie bei den Klienten, nur diesmal beim Senden des Servers.

Und ich gehe mal davon aus, dass wenn man ihm hier an dieser Stelle "Marnieren beibringt", sich der Kram bei den Klienten automatisch mit erledigt.

 

Link to comment
Auch hier wird (bislang) nicht überprüft, WELCHER Klient denn da anfragt und es wird ihm irgendeine Location aus den verfügbaren gesendet (bei mit immer die "Hauptadresse" des Servers, also wahrscheinlich immer die erste der Liste).

 

Für diese Annahme lieferst du keinen Beleg, und es gibt auch im Code keine Anhaltspunkte dafür. Der RS beantwortet Multicast M-SEARCH Messages über die Interfaces/Adapter, von denen sie eingetroffen sind, mit deren jeweiliger IP als LOCATION. In einer Netzwerkarchitektur, in der die Multicast M-SEARCH Message eines bestimmten Clients den Server über verschiedene Schnittstellen / Adapter erreicht, wird sie natürlich mehrfach mit verschiedenen LOCATION-Angaben beantwortet.

 

Schaut man sich die Vorgaben für die Server-Antwort in den UPnP-Spezifikationen (und den entsprechenden Programmablauf im RS) an, die u.a. eine zufällige Streuung der Antwortzeit in einem gegebenen Intervall 0...MX vorsehen, wird schnell klar, dass sich die Sache serverseitig schlecht regeln lässt. Wenn eine Multicast M-SEARCH Message eintrifft, bei der Absender-IP und Schnittstellen-IP verschiedenen Netzwerken angehören, kann und darf der Server nicht warten, ob die Message vielleicht später über eine andere besser geeignete (= zum Netzwerk des Clients gehörende) Schnittstelle eintrifft.

 

Und selbst wenn der Server dies irgendwie regeln würde: Es löst das Problem nicht vollständig, solange Clients zusätzlich auf Multicast NOTIFY ssdp:alive Messages des Servers lauschen. In diesem Fall ist eine clientseitige Filterung / Zuordnung von IPs mit Hilfe der Subnetzmaske unumgänglich, um die "beste" LOCATION zu finden.

 

Insgesamt also eine unzureichend durchdachte Idee. Auch wenn sie sich noch als realisierbar herausstellen sollte, scheitert weiteres daran, dass du dich weigerst, auf die von mir angedachte kurzfristig realisier- und überprüfbare (Test-)Implementation der Filterung mittels Subnetzmasken einzugehen und dass du sie angesichts deiner eigenen grandiosen Idee auf (man kann fast sagen: gewohnt) unfreundliche Weise ablehnst. Ohne Tests in deinem Netzwerk ist hier das Ende vom Gelände. Es gibt genug andere Baustellen, an denen ich zu tun habe.

 

Nichtsdestotrotz hat diese Diskussion ein paar interessante Aspekte und Einblicke mit sich gebracht, und die Resultate werden beizeiten Eingang in DVBViewer & RS finden. Wann und auf welche Weise bleibt erst mal offen...

Link to comment

Also ich weigere mich natürlich nicht, irgendwelche Änderungen hier auszuprobieren, da hast Du mich falsch verstanden,

 

Bei den Samples, die ich Dir hochgeladen habe, sind doch auch ein paar M-Searches dabei, und da schau doch nochmal bitte GENAU hin. (oder, zur Sicherheit, NIMM DIESE HIERxxx.txt)

 

Überspring mal den Kram am Anfang und schau ab Paket 18

Hin (und nicht REIN!) !

Das sind die NOTIFY Meldungen des Server auf die Anfrage des Clients.

Wie Du siehst, sind das keine Multicasts, sondern gehen direkt an 192.168.0.28. #18 ist ja noch richtig, aber #19 & #20 sind völlig unnötig, denn der Server weiß doch schon, dass dieses Paket für das "0" Netz gefordert wurde.

Es mag ja irgendwo in den mystischen Specs mal wieder genau so gefordert sein, aber es ist falsch und kontraproduktiv.

 

19 & 20 sorgen erst dafür, das der Klient verwirrt wird, unterdrückt man das Senden, ist alles ok und der Klient glücklich.

 

Genau DAS meine ich. Beim Server alle so lassen, aber vor dem Absenden der Pakete per Netzmaske überprüfen, ob DIESE Paket das Richtige für ihn ist, alle anderen sang und klanglos vergessen (return true).

 

 

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...