Problem mit recv und endlos schleife
-
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.
-
Wenn ich's nicht wüsste, würde ich recv wohl kaum wiederholt aufrufen.
-
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 ?
-
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.
-
Framing Protokoll FramesAlso 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 ?
-
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.
-
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().
-
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.
-
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.
-
Was dem Standard meiner Meinung nach sowieso fehlt, sind Container, denen man ihren Speicher klauen kann. Damit wäre sowas überhaupt kein Problem mehr.
-
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
-
Tuxist schrieb:
Keine Container oder anderer Ballast. Bitte nicht hauen
Ja ich mag auch so Sachen wie
rep movsmemmoveMan muss dann aber auch eingermaßen wissen was man tut sonst landet man ruckzuck in Teufels Küche.