Socket Programmierung und recv() ist langsam

Hi

@Belli

Du wirst es wohl wissen ! Schönen Tag

lowbyte

Hi

Belli schrieb:

Dein Code ist Müll!

1. stimmt es nicht, daß man beim send über einen blockierten Socket prüfen muß, ob alles versendet wurde (das trifft nur beim recv zu)

2. guck mal genau hin, wohin Dein recv seine Daten in den Puffer schreibt, wenn er mehr als zwei recv's benötigt, um alle Daten zu empfangen.

Wenn meinst du damit ? Bei meinem kleinen Bsp. läuft das schon richtig !

lowbyte

Hi

Und klar muss man auch bei send() prüfen ob alles gesendet wurde, und wenn nötig nichtgesendete Daten nachsenden.

lowbyte

Belli

Muß man nicht!

Und Dein recv schreibt in den Puffer ab Stelle rc_3. Was aber steht in rc_3? Die Anzahl der beim letzten recv erhaltenen Bytes.

Wenn der recv nun 3 mal in der Schleife ausgeführt werden sollte und beim ersten Mal 100 Byte und beim zweiten Mal 50 Byte bekommt, wohin schreibt dann der 3. recv seine Daten?

Richtig, er überschreibt die bereits erhaltenen Daten im Puffer!

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.