staging.inyokaproject.org

Also eine Race-Condition kann ich mir nicht wirklich vorstellen. Denn das Problem tritt auch immer wieder mal auf, wenn ich ganz gemächlich die Dateien in beiden Fenstern anklicke. Gerade eben hatte ich das Problem nachdem ich erst im Netzwerkfenster vom Server ein Direktorylisting angefordert hatte und nach einiger Bedenkzeit einen Dateinamen im Hauptprogramm angeklickt hatte. Also eigentlich nichts zeitkritisches.

Und ich teste das gerade auf meiner schnellsten Maschine und mit 16GiB RAM. Schneller kann ich grad nicht.

Die Optionen -ff und -tt kannte ich schon aus dem Video. -ff erscheint mir momentan nicht hilfreich. Ich erzeuge in diesem Zusammenhang nicht wirklich neue Prozesse. Allerdings rufe ich mit execvp() mehrfach ffprobe auf. Vorher wird noch versucht, lokale Vorschaudateien zu laden und die Metadaten anzuzeigen. Die Netzwerkverbindung wird erst versucht aufzubauen, wenn das alles abgefrühstückt ist, um diese Daten dann zu vergleichen.

Ich glaube ich hab's (zumindest abgemildert). Im Buch "The Linux Programming Interface" wird empfohlen, dass wenn connect() scheitert, man den Socket schließen und es mit einem neuen erneut probieren kann.

Das habe ich mal eingebaut und schon mit einem Retry-Zähler von 1 ist das Problem bisher noch nicht wieder aufgetaucht. Ich werde das aber noch weiter beobachten.

Generell scheint es wohl so zu sein, das viele der blockierenden Systemaufrufe unterbrochen werden können. Möglicherweise kann man die Auswirkung durch einen eigenen Signalhandler verhindern, wenn man das mit sigaction() das Flag SA_RESTART setzt. Das auszuprobieren erscheint mir momentan aber zu aufwändig, da ich in einer anderen Klasse schon einen Signalhandler für SIGPIPE und SIGCHILD habe.

BTW, könnte es sein, das strace sich da irgendwie eingeklinkt hat und das Problem dadurch nicht mehr auftrat?

Dakuan schrieb:

BTW, könnte es sein, das strace sich da irgendwie eingeklinkt hat und das Problem dadurch nicht mehr auftrat?

Ich würde eher vermuten, dass es am durch strace geänderten Timing liegt. Oder Du hast da ein wirklich unzuverlässiges Netzwerk, wo ab und zu mal was rausfällt.

Eine Sache fällt mir noch ein: wie lang ist denn die Empfangsqueue im Server? Wenn die nicht lang genug ist, kann schon mal ein Connect schief gehen.

Ich glaube nicht, dass bei Verbindungen von localhost zu localhost etwas raus fällt, so ohne externes Kabel. Mit 2 PCs habe ich natürlich auch schon getestet. Ist nur umständlicher, weil ich da auch immer ein Programm kopieren muss.

Der Server startet für jede Anfrage einen neuen Prozess und die haben alle einen festen Puffer von 2048 Bytes. Und was da noch mit ioctl() gemacht wird, habe ich mir noch nicht genauer angesehen. Der Server hat die Verbindung ja angenommen und wartet auf mehr.

Aber vielleicht sollte ich doch auf einem einfacheren Server Beispiel aufbauen, da ich ja nur eine Punkt zu Punkt Verbindung brauche. Andererseits hatten die einfachen Beispiele nichts für HTTP an Bord.

Dakuan schrieb:

Der Server startet für jede Anfrage einen neuen Prozess und die haben alle einen festen Puffer von 2048 Bytes. Und was da noch mit ioctl() gemacht wird, habe ich mir noch nicht genauer angesehen. Der Server hat die Verbindung ja angenommen und wartet auf mehr.

Wie gesagt, es ist wichtig, wie Du die offenen Dateideskriptoren beim Forken behandelst.

Aber vielleicht sollte ich doch auf einem einfacheren Server Beispiel aufbauen, da ich ja nur eine Punkt zu Punkt Verbindung brauche. Andererseits hatten die einfachen Beispiele nichts für HTTP an Bord.

Ich weiß nicht, was Dein Server macht, aber die Behandlung von HTTP würde ich anderen (z.B. NginX als Server, curl als Client) überlassen. Selber machen ist vielleicht interessant, wird Dir aber enorm viel Zeit wegnehmen von dem, was Du eigentlich machen willst.

Ich weiß nicht, was Dein Server macht, aber die Behandlung von HTTP würde ich anderen (z.B. NginX als Server, curl als Client) überlassen.

Das wäre jetzt wirklich mit Kanonen nach Spatzen geschossen. Ich hatte schon mal Apache, Lighttpd und bozohttpd im Einsatz. Die würden mir hier aber nur erhebliche Probleme bereiten. Ich benötige einen Server, der zugriff auf die Thumbnail Verzeichnisse des Users hat, weil er genau diese ausliefern soll, falls sie zum freigegebenen Verzeichnis gehören.

Der Server soll nur Dateien aus dem Verzeichnis ausliefern, in dem er vom jeweiligen User gestartet wurde und auf Wunsch auch die zugehörigen Vorschaudateien. Die Namen der Vorschaudateien müssen aus dem absoluten Pfad berechnet werden. Zugriff hätten da nur der User und Root. Das kriege ich mit einem normalen Server und PHP wohl nicht hin. Und ein wechsel des Verzeichnisses ist nicht vorgesehen. Das kann nur der freigebende User machen.

Im Endeffekt läuft das darauf hinaus, dass der Server nur HTTP-Get Anfragen beantworten soll, die außer dem Dateinamen eine begrenzte Anzahl von Parametern enthält (download, status, thumbs, list), davon nicht alle mit Wert. Alles andere ist "not found" oder "forbidden". Und der Server Code ist aktuell 23kB Groß.