Socket Programmierung und recv() ist langsam

Hi

Nein wenn du es dir nur richtig anschauen wüdest !

lowbyte

Und klar muss man auch bei send() prüfen ob alles gesendet wurde

Nein, wenn es sich um einen Blocking Socket unter Windows handelt ist das nicht notwendig. Da gibts nur alles oder nichts.

Hi

Ach komm... schau es dir genau an und erzähl nicht so ein Schwachsinn !!

Wen zbsp. 100 bytes empfangen werden sollen, und zbsp. nur 50bytes empfangen werden dan hat rc_3 50 bytes, und das ist dan len - rc_3 = 50bytes und dor schreibt er das nächste mal hin !

lowbyte

Hi

() schrieb:

Zitat:
Und klar muss man auch bei send() prüfen ob alles gesendet wurde

Nein, wenn es sich um einen Blocking Socket unter Windows handelt ist das nicht notwendig. Da gibts nur alles oder nichts.

Das kann ich nicht bestätigen !

hustbaer

Naja ich kann es dafür bestätigen.

Und rc_2, rc_3, das kann ja wohl nur ein Scherz sein.

BTW: Als Puffergrösse die MTU zu verwenden ist doof, die MTU ist viel zu klein für nen anständigen Puffer. Richtig schön grosse Puffer machen, dann geht's auch mit Gigabit noch schön schnell.

Hi

Und wen recv() nicht alle daten hat, dan muss man sowiso prüfen wie viele daten jetz noch mit send() gesendet werden sollen.

lowbyte

Hi

hustbar schrieb:

Naja ich kann es dafür bestätigen.

Und rc_2, rc_3, das kann ja wohl nur ein Scherz sein.

Und was ist daran falsch ?

lowbyte

Hi

Was bringt es bei Blocking call send und recv nur die recv Funktion zu prüfen, ob alles gesendet wurde ? Mann muss ja automatisch auch send prüfen, das man weiss wie viele daten noch aus dem Puffer gesendet werden müssen.

lowbyte

Hi

@hustbar

Dann kannst du ja ein schönens Bsp. posten wie es den nach deiner Meinung funktionieren würde.

Also meine Variante funktioniert einwandfrei. Und richtig.
Das mit der Buffersize ist klar !

lowbyte

Hi

Ich höre ..

lowbyte

Hi

Also nocheinmal:

Wen der Client zum bsp. 100 Bytes senden will dann muss dass bei meinem Bsp. die gegenstelle wissen, und das mache ich indem ich die länge des zu übertragenden
Packet zuerst schicke und die hat constant zbsp. 4 byte. (Bis zu diesem Teil ist es sicher Protokoll abhängig, geht auch anders). Dan schicke ich die 100 bytes mit der send_data funktion wie oben beschrieben. Wenn die gegenstelle (recv()) aber jetz nur 50 Byte empfangen kann (wegen internem zeugs). Dann bekommt die send() Funktion (innerhalb der send_data Funktion) den Wert 50 zurück. Dass heisst jetz das send() nocheimal versucht von der Pufferadresse + 50 Bytes den rest zu senden. und bei recv_data ist das gleich.

Wie man jetz die Packetlen der gegenstelle vermittelt ist Protokoll-abhängig. Und genau da waren wohl unsere Differenzen.

Klar muss man den return value von send nicht prüfen, aber man will doch auch wissen wie viel Daten und von welcher Adresse im Puffer noch gesendet werden müssen.!

lowbyte

hustbaer

Low, hör einfach auf hier rumzuspammen.

p.S.: dein Code ist übrigens wirklich falsch, die Empfangsschleife wird nur das 1. und 2. Stück korrekt ablegen, alle weiteren überschreiben bereits empfangene Daten.

Hi

ja ja ... Besserwisser

lowbyte

Hi

Dann brauchst du woll ne Brille.!

lowbyte

Hi

@hustbaer

Hast rech mit dem rc kake ! War auch nur ein bsp. das ich geschrieben habe. Sollte natürlich so geschriben werden das es nicht daten überschreibt. Sorry

lowbyte

hustbaer

&rbuf[rc_3] != &rbuf[total]

Denk mal drüber nach.

hustbaer

Und das falsche Beispiel war jetzt auf genau welche Art hilfreich?

hustbaer

lowbyte_ schrieb:

Was bringt es bei Blocking call send und recv nur die recv Funktion zu prüfen, ob alles gesendet wurde ? Mann muss ja automatisch auch send prüfen, das man weiss wie viele daten noch aus dem Puffer gesendet werden müssen.

Muss man bei blocking stream sockets nicht, weil send() es dann ganz einfach nicht tut. Also niemals "nicht alles" sendet.
Wozu was prüfen von dem man weiss dass es nicht passieren kann?

Belli

hustbaer schrieb:

p.S.: dein Code ist übrigens wirklich falsch, die Empfangsschleife wird nur das 1. und 2. Stück korrekt ablegen, alle weiteren überschreiben bereits empfangene Daten.

Hast Du etwa gedacht, ich lüge?

hustbaer

@Belli:
Nö. Aber wie man sieht bringt es etwas, wenn es jmd. anderes nochmal wiederholt/bestätigt. Irgendwann wird das auch einem Dickschädel wie Low verdächtig, und er guckt es sich nochmal an.