Frage zur Aufgabe 2, Sister

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

Frage zur Aufgabe 2, Sister
Hallo,
zur Aufgabe 2: Angenommen, die Datei konnte im [m]request-http.c[/m]-Modul erfolgreich geöffnet werden und wird nun übertragen. Passiert während der Übertragung ein Fehler, wird das mithilfe von z. B. [m]ferror[/m] festgestellt. Wie soll man dann agieren? Soll der Server dann einen Internal-Server-Error senden oder genügt es, [m]perror[/m] aufzurufen? Im ersteren Fall könnte man diesen Fehler ja nur senden, wenn man die ganze Nachricht zwischenpuffert, oder täusche ich mich da (eine ganze Datei zwischenzupuffern kann doch durchaus ineffizient werden)?

Und generell: Ist es erlaubt, wenn man den aktuellen Prozess mit [m]exit(EXIT_FAILURE)[/m] einfach sterben lässt oder soll man aus der Methode [m]handleRequest[/m] mit [m]return[/m] zurückkehren?

Außerdem: Muss man mit [m]stat[/m] oder auch [m]access[/m] überprüfen, ob der aktuelle Prozess Lesepermissons auf die entsprechenden Dateien hat oder genügt es, dies mit [m]fopen[/m] zu überprüfen?

PS: Sister soll ja solange offen sein, bis es z. B. durch Strg + C unterbrochen wird. Muss man hierfür einen speziellen Signalhandler schreiben, der z. B. den Serversocket schließt, oder kann man das ignorieren?

LG Gabriel


Das sicher nicht, da du schon eine „Ok“-Nachricht geschickt hast – alles was nach dem Header kommt ist ja der Inhalt des Bodys. Da würde auch kein Buffern helfen, da der Fehler nach absenden der Header, während der Übertragung der eigentlichen Daten passiert.

Meine Meinung: arbeite mit Prozessen in [m]connection-fork[/m], arbeite mit HTTP in [m]request-http[/m]. Fall du, rein hypothetisch, deine Codebase mal erweitern/verändern willst, oder was umbauen würdest, ist es sauberer die beiden Konzepte voneinander getrennt zu halten.

Allgemein: Gebe einen HTTP-Fehler zurück, der zum jeweiligen Fehlercode passt.


stat-then-fopen würde übrigens auch Race Conditions erlauben. Ich glaube, ich habe damals fdopen-then-fdstat genutzt.

1 „Gefällt mir“

Noch eine Sache: Ich habe mal meinen Code über [m]valgrind[/m] gejagt und habe ein sehr merkwürdiges Verhalten mit der [m]i4httools.o[/m]. Immer wenn ich z. B. [m]httpForbidden[/m] oder auch [m]httpBadRequest[/m] aufrufe, gibt mir [m]valgrind[/m] folgenden Fehler aus:

[localhost] 403, forbidden: /
==2805== 
==2805== HEAP SUMMARY:
==2805==     in use at exit: 5,255 bytes in 13 blocks
==2805==   total heap usage: 160 allocs, 147 frees, 51,096 bytes allocated
==2805== 
==2805== LEAK SUMMARY:
==2805==    definitely lost: 0 bytes in 0 blocks
==2805==    indirectly lost: 0 bytes in 0 blocks
==2805==      possibly lost: 0 bytes in 0 blocks
==2805==    still reachable: 5,255 bytes in 13 blocks
==2805==         suppressed: 0 bytes in 0 blocks
==2805== Rerun with --leak-check=full to see details of leaked memory
==2805== 
==2805== For lists of detected and suppressed errors, rerun with: -s
==2805== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Tausche ich nur diese eine Zeile durch z. B.: [m]httpOK[/m], sagt [m]valgrind[/m], dass alle Blöcke gefreed wurden. Interessanterweise zeigt die Referenzdatei nicht dieses Verhalten. Baut man allerdings das gesamte Projekt nur durch die vorgegebenen [m].o[/m]-Dateien und kompiliert diese, tritt exakt derselbe Fehler auf. Bin ich da blind oder ist das tatsächlich ein Fehler in der Aufgabe?

LG Gabriel


Ist bei der sister ok, aber wird bei der mother ein Problem. Also besser gleich richtig machen. Beim return aufpassen, dass alle Resourcen freigegeben werden!

Wie schon gesagt wurde, ist das eine Race-Condition. Einfach aufmachen, dann merkst du schon wenn es nicht geht.

Nein, brauchst du nicht. Strg-C terminiert das Programm und dabei werden auch alle Sockets geschlossen.


Was sagt [m]–leak-check=full[/m]?


Wir haben das im CIP vor einer Woche getestet, und bemerkt das was unterschiedliches passiert, je nachdem auf welcher Maschine man es ausprobiert. Ich habe darauf getippt, dass es mit einer neueren version von glibc zusammenhängt, da laut valgrind der Speicher in [m]getnameinfo[/m] (bin mir unsicher) alloziert wurde.