4. Problem mit recv und endlos schleife

Problem mit recv und endlos schleife

  • 3

    Tuxist schrieb:

    Das Problem ist das http die Verbindung offen hält und deswegen das Parsen Asyncron von httpd laufen muss.

    Ist doch gar kein Problem. Für jeden Client wird ein eigener Thread erstellt, in dem dieser dann bearbeitet wird. Eine professionellere Lösung hätte vermutlich Worker-Threads verwendet, da hier pro Client ein Thread quasi-geleakt wird. (Die Threads werden erst bei Programmende aufgeräumt.)

    Tuxist schrieb:

    jup dieser Eigangsbuffer muss anhand des http Startheader in aufgeteilt werden, hatte hierbei an memmmove gedacht um die Daten weiter zu verarbeiten was man z.b. in einem Vector oder Array machen kann. Die Kompletten http Daten könnte man dann mit strsep in Kopf und Daten aufteilen und dann einen cgiparser laufen lassen.

    Pfui pfui pfui!
    Du kriegst die Daten vom Socket doch schon zeilenweise als std::string's. Du brauchst also nur noch diese Zeilen zu verarbeiten und dem Client eine Antwort zu senden.

    0
  • E

    DaRe schrieb:

    Ethon schrieb:

    Der Andere: Lies die Dokumentation von recv bevor du "hilfst", ist ja grauenhaft.

    Ich vermute, du sprichst mich damit an.
    Auf welchen Beitrag beziehst du dich?

    Ich meine sdfsdfsdf. 😉

    0
  • T

    314159265358979:

    Die Zeilen müssen aber nicht komplett sein dar recv immer nur 255 zeichen in den Buffer schreibt und ein habler Post Datensatz zum beispiel lässt sich schlecht parsen. Deswegen muss alles zuerst in einen Buffer und dann verarbeitet werden.
    Die Zeilen beinhalten nicht unbedingt einen kompletten Datensatz das kann ich erst im Buffer prüfen. Oder habe ich jetzt recv() falsch verstanden ? Der Rückgabe wert sagt Lediglich über die anzahl der Zeichen im Bitstream was aus ? Und der char* muss eine Festdefinierte länge haben ?

    0
  • 3

    recv liest so viel, wie du ihm sagst.

    0
  • T

    314159265358979 schrieb:

    recv liest so viel, wie du ihm sagst.

    Nö. recv(..) liesst maximal soviel wie du ihm sagst, manchmal durchaus auch weniger.
    Es braucht ein Frameing Protokoll, welches sagt wo eine Meldung (hier ein String) aufhört und wo der nächste anfängt.

    0
  • 3

    theta schrieb:

    Nö. recv(..) liesst maximal soviel wie du ihm sagst, manchmal durchaus auch weniger.

    Das meinte ich ja. Steht doch eh implizit da.

    0
  • T

    314159265358979 schrieb:

    theta schrieb:

    Nö. recv(..) liesst maximal soviel wie du ihm sagst, manchmal durchaus auch weniger.

    Das meinte ich ja. Steht doch eh implizit da.

    Genau. 🕶

    0
  • 3

    Wenn ich's nicht wüsste, würde ich recv wohl kaum wiederholt aufrufen.

    0
  • T

    Nur mal eben zum zusammen fassen folgendes muss beachtet werden

    -recv liest einen bitstream in einer vorgebenden maximalen länge ein die aber durch aus unterschritten werden kann.

    -Die Connection wird nicht vom einem Client nach einer Anfrage nicht geschlossen, das heißt es muss ein thread im Hintgrund laufen und einer die Daten verarbeiten.

    -Der Buffer für die Daten von recv muss dynamisch in der Größe sein

    -Pro Anfrage einen Thread macht am meisten sinn dar man so optimal skalieren kann.

    Also ich komme auf eine dynamische anzahl von threads in denen jeweils 2 threads laufen ?

    0
  • T

    Tuxist schrieb:

    -recv liest einen bitstream in einer vorgebenden maximalen länge ein die aber durch aus unterschritten werden kann.

    Also ein byte-Stream ist es schon... 😉

    Tuxist schrieb:

    -Die Connection wird nicht vom einem Client nach einer Anfrage nicht geschlossen, das heißt es muss ein thread im Hintgrund laufen und einer die Daten verarbeiten.

    Da ist vermutlich ein nicht zuviel - obs einen zweiten Thread braucht ist eine andere Frage.

    Tuxist schrieb:

    -Der Buffer für die Daten von recv muss dynamisch in der Größe sein

    Ja, wenn das Framing Protokoll Frames von unterschiedlicher Länge vorsieht, falls nicht, dann nicht. Also: It depends.

    Tuxist schrieb:

    -Pro Anfrage einen Thread macht am meisten sinn dar man so optimal skalieren kann.

    Eigentlich skaliert das sehr schlecht, geht aber gut für den Anfang und für wenige Verbindungen.

    0
  • T
     

    Framing Protokoll Frames

    Also dieser begriff ist mir nicht geläufig du meinst sicherlich die größe der Frame Packete ? Welche bei http variieren können.

    Eigentlich skaliert das sehr schlecht, geht aber gut für den Anfang und für wenige Verbindungen.

    Stattdessen Threads für die einzelnen Verarbeitungsschritte ?

    0
  • ?

    Wenn du etwas gut skalierendes brauchst, dann kommst du um die API des Betriebssystems nicht durm herum. Für den Anfang könntest du dir aber vielleicht mit Threads + select was zusammenbasteln.

    0
  • C

    sdfsdfsdf schrieb:

    Es gibt diese Stelle sogesehen nicht, da im Standard nicht geschrieben wird, dass der Speicher zusammenhängend sein muss. Ganz anders beim std::vector, wo dies explizit verlangt und somit garantiert ist.

    Das ist nicht (mehr) korrekt. Siehe auch

    n3242 21.4.1 basic_string general requirements 5 schrieb:

    The char-like objects in a basic_string object shall be stored contiguously. That is, for any basic_string
    object s, the identity &*(s.begin() + n) == &*s.begin() + n shall hold for all values of n such that 0
    <= n < s.size().

    0
  • ?

    cooky451 schrieb:

    sdfsdfsdf schrieb:

    Es gibt diese Stelle sogesehen nicht, da im Standard nicht geschrieben wird, dass der Speicher zusammenhängend sein muss. Ganz anders beim std::vector, wo dies explizit verlangt und somit garantiert ist.

    Das ist nicht (mehr) korrekt. Siehe auch

    n3242 21.4.1 basic_string general requirements 5 schrieb:

    The char-like objects in a basic_string object shall be stored contiguously. That is, for any basic_string
    object s, the identity &*(s.begin() + n) == &*s.begin() + n shall hold for all values of n such that 0
    <= n < s.size().

    Es ist richtig, dass dies mit dem neuen Standard garantiert wird. Jedoch ist der neue Standard ja noch nicht in Form konformer Compiler in Erscheinung getreten und das wird wohl auch noch dauern. Letztendlich ist dieser Umstand aber eh nicht wirklich relevant, da zumindest mir kein Compiler bekannt ist der es anders handhabt. 😉

    0
  • C

    Natürlich ist das relevant. Vorher hatten es nur die Compiler implementiert, jetzt garantiert es auch noch der Standard. Wenn das (der Standard) nicht wichtig wäre, hättest du es ja auch gar nicht erst erwähnen müssen. Schließlich macht es schon einen Unterschied, ob man das ganze Zeug aus einem Vektor in den String kopiert oder eben gleich in den String einliest.

    0
  • 3

    Was dem Standard meiner Meinung nach sowieso fehlt, sind Container, denen man ihren Speicher klauen kann. Damit wäre sowas überhaupt kein Problem mehr.

    0
  • T

    Habe gedacht GO wird interessant. Aber als ich die Syntax gesehen war mir zu viele Sachen drinnen die ich nicht mag, Stichwort Packages :-D. Eine stark reduzierte OOP Sprache würde mir gefallen wo nur Templates und klassen drinne sind. Keine Container oder anderer Ballast. Bitte nicht hauen 😃

    0
  • E

    Tuxist schrieb:

    Keine Container oder anderer Ballast. Bitte nicht hauen 😃

    Ja ich mag auch so Sachen wie

    rep movs

    memmove

    Man muss dann aber auch eingermaßen wissen was man tut sonst landet man ruckzuck in Teufels Küche.

    0
Anmelden zum Antworten