Not logged in. · Lost password · Register

gabriel2029
Member since Nov 2018
49 posts
Subject: Frage zur Aufgabe 2, Sister
Hallo,
zur Aufgabe 2: Angenommen, die Datei konnte im request-http.c-Modul erfolgreich geöffnet werden und wird nun übertragen. Passiert während der Übertragung ein Fehler, wird das mithilfe von z. B. ferror festgestellt. Wie soll man dann agieren? Soll der Server dann einen Internal-Server-Error senden oder genügt es, perror 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 exit(EXIT_FAILURE) einfach sterben lässt oder soll man aus der Methode handleRequest mit return zurückkehren?

Außerdem: Muss man mit stat oder auch access überprüfen, ob der aktuelle Prozess Lesepermissons auf die entsprechenden Dateien hat oder genügt es, dies mit fopen 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
This post was edited 2 times, last on 2019-11-26, 02:01 by gabriel2029.
zge
(〜 ̄▽ ̄)〜
Avatar
Member since Nov 2017
142 posts
Soll der Server dann einen Internal-Server-Error senden

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.

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

Meine Meinung: arbeite mit Prozessen in connection-fork, arbeite mit HTTP in request-http. 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.

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

Allgemein: Gebe einen HTTP-Fehler zurück, der zum jeweiligen Fehlercode passt.
;;
Marcel[Inf]
#faui2k15, GTI-Tutor a. D.
Member since Nov 2015
538 posts
In reply to post #1
+1 siccegge
Quote by gabriel2029:
Außerdem: Muss man mit stat oder auch access überprüfen, ob der aktuelle Prozess Lesepermissons auf die entsprechenden Dateien hat oder genügt es, dies mit fopen zu überprüfen?

stat-then-fopen würde übrigens auch Race Conditions erlauben. Ich glaube, ich habe damals fdopen-then-fdstat genutzt.
gabriel2029
Member since Nov 2018
49 posts
Noch eine Sache: Ich habe mal meinen Code über valgrind gejagt und habe ein sehr merkwürdiges Verhalten mit der i4httools.o. Immer wenn ich z. B. httpForbidden oder auch httpBadRequest aufrufe, gibt mir valgrind 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.: httpOK, sagt valgrind, dass alle Blöcke gefreed wurden. Interessanterweise zeigt die Referenzdatei nicht dieses Verhalten. Baut man allerdings das gesamte Projekt nur durch die vorgegebenen .o-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
rudis
SPler
(Administrator)
Member since Apr 2010
649 posts
In reply to post #1
Quote by gabriel2029 on 2019-11-25, 23:23:
Und generell: Ist es erlaubt, wenn man den aktuellen Prozess mit exit(EXIT_FAILURE) einfach sterben lässt oder soll man aus der Methode handleRequest mit return zurückkehren?

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!

Quote by gabriel2029 on 2019-11-25, 23:23:
Außerdem: Muss man mit stat oder auch access überprüfen, ob der aktuelle Prozess Lesepermissons auf die entsprechenden Dateien hat oder genügt es, dies mit fopen zu überprüfen?

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

Quote by gabriel2029 on 2019-11-25, 23:23:
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?

Nein, brauchst du nicht. Strg-C terminiert das Programm und dabei werden auch alle Sockets geschlossen.
rudis
SPler
(Administrator)
Member since Apr 2010
649 posts
In reply to post #4
Quote by gabriel2029 on 2019-11-26, 19:50:
ausche ich nur diese eine Zeile durch z. B.: httpOK, sagt valgrind, dass alle Blöcke gefreed wurden. Interessanterweise zeigt die Referenzdatei nicht dieses Verhalten. Baut man allerdings das gesamte Projekt nur durch die vorgegebenen .o-Dateien und kompiliert diese, tritt exakt derselbe Fehler auf. Bin ich da blind oder ist das tatsächlich ein Fehler in der Aufgabe?

Was sagt --leak-check=full?
zge
(〜 ̄▽ ̄)〜
Avatar
Member since Nov 2017
142 posts
Quote by rudis:
Was sagt --leak-check=full?

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 getnameinfo (bin mir unsicher) alloziert wurde.
;;
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
Datenschutz | Kontakt
Powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2011 by Yves Goergen