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.
sister
Zu initRequestHandler des Anfrage-Moduls ist beschrieben:
[code=c]
/**
- @brief Initializes the request-handling module.
- @note This function must be invoked after cmdlineInit().
- @return 0 on success, -1 if the command-line arguments are invalid. If a
-
non-recoverable error occurs during initialization (e.g. a failed -
memory allocation), the function does not return, but instead prints -
a meaningful error message and terminates the process.
*/
int initRequestHandler(void);[/code]
Aber was für Kommandozeilenargumente liest die Funktion eigentlich?
Verstehe ich richtig, dass die HTTP-Anfrage (z.B. [m]GET /doc/index.html HTTP/1.0[/m]) vom Socket in [m]handleRequest(FILE *rx, FILE *tx)[/m] gelesen werden soll?
Die Funktion ueberprueft die Kommandozeilenargumente, d.h. wurde z.B. ein Pfad uebergeben? Ist die Anzahl der Argumente korrekt?etc…
Wie du sehen kannst, arbeitet diese Funktion mit [m]FILE*[/m]. Ein Socket ist nicht weiteres als eine Zahl.
Damit die Funktion [m]handleRequest()[/m] mit den Sockets arbeiten koennen, muessen die Sockets vorher erst „als [m]FILE*[/m]“ geeoffnet werden.
Ach klar, das kann man ja mit dem cmdline-Modul machen. Ich hatte schon vor die Kommandozeilenargumente zu überprüfen, habe mich jedoch daran gestoßen, woher die Funktion argv[] bekommt. Jetzt ist’s klar.
cmdline
ist ndash ein „- -“ ? oder das wunderbare unicode zeichen fuer einen langen strich :)?
sorry kann nicht lesen -
Both keys and flags must begin with one or two dashes followed by one alpha-numeric character and an arbitrary number of additional characters (excluding ‚\0‘ and ‚=‘).
Gnah, das ist ein bekannter Bug in der Doxygen-Version, die bei Debian Wheezy mitgeliefert ist. Im aktuellen Doxygen-Release 1.8.5 wurde es behoben. Ich bessere die Doku mal eben per Hand aus. 
Muss man den Wert eines eingegebenen Port überprüfen und wenn ja, in welchem Zahlenbereich soll er liegen? 0 <= Port <= 65535 ?
Ja, das sollte man machen. 0 < port <= 0xffff
Hi,
ich bräuchte auch mal einen Tipp. sister.c läuft bei mir soweit, dass es mit den gegebenen Modulen anständig zusammenarbeitet und die c+±Doku ausliefert.
Jetzt gehts an [m]handleConnection()[/m] bzw. den Aufruf von [m]handleRequest()[/m]. Zum Testen hab ich erstmal versucht das im selben Prozess durchzuführen, um andere Fehlerursachen auszuschließen.
Also [m]clientSock[/m] und [m]listenSock[/m] schreibend bzw. lesend geöffnet und an [m]handleReqest[/m] übergeben. Der Request scheint durchzukommen (sagt zumindest mein Browser), nur wenns ans antworten geht kommt die Meldung [m]fgets: Transport endpoint is not connected[/m]. Das heißt ja, dass tx in der Luft hängt, oder (obwohl zum Schreiben geöffnet)? Oder ist die Verbindung vom Browser geschlossen worden, bevor geantwortet werden konnte?
EDIT:
Gnah - Gummientendebuggen. 
Nen socket sollte man auch irgendwann mal verbunden haben, bevor man ihn öffnet… -.-
Aber ports <=1024 sind doch well-known ports und benötigen unter Unix root-Zugriff.
Sollte man nicht eher auf 1024< ports <65636 prüfen?
Hindert dich ja keiner dran (ok, im CIP wohl doch, aber Allgemein nicht) die sister als root auf Port 80 auszuführen.
Hmpf, zu früh gefreut. “Transport endpoint is not connected.” bleibt, egal wie ichs anstell. 
Edit: Wer lesen kann. Jetzt gehts Danke fürs mitlesen ^^
Exakt. Die sister soll ja ein ganz normaler (mehr oder weniger) HTTP-Server werden. Und HTTP nutzt nun mal Port 80.
Mir ist nicht ganz klar an welcher Stelle ich überprüfe, ob der Port im gültigen Bereich liegt. Ich denke in der sister.c. Allerdings lese ich [m]wwwpath[/m] in der [m]initRequestHandler()[/m] aus, dann hab ich den Port und den wwwpath in dem jeweiligen Modul in dem er gebraucht wird.
Auf der anderen Seite frage ich mich, wie ich in der [m]initRequestHandler()[/m] einen Fehler produziere, der “non-recoverable” ist, solange ich kein malloc oder so verwende.
Ich denke mal, das ist dir überlassen, wo du den Port überprüfst. Ich prüfe es auch in der sister.c, denn dort ist die einzige Stelle, wo ich den Port tatsächlich verwende.
Nicht ganz. Das Kind interagiert nur mit dem clientSock.
Ja, hab ich dann auch gelesen, nachdem ich die Beschreibung zum 10. mal durch hatte m(
Wofür wird der listenSock dann überhaupt übergeben, wenn man den eigentlich garnicht dort braucht? Denn wenn man den im child zu macht schlägt das nächste accept fehl, weil der socket ja geschlossen ist, oder?
Überleg mal, was fork() genau macht und was das Kind folglich mit [m]listenSock [/m]machen sollte…
fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process...Du solltest es da prüfen wo es verwendet hier. Schließlich können die anderen Module ausgetauscht werden.
[m]valgrind --track-fds=yes …[/m] ist (da) auch sehr praktisch.