Socket Programmierung und recv() ist langsam

Belli

Müll!

Hi

Ich schrieb:
Im internen Lan bringe ich Geschwindikeiten von 8-10 MB pro sec + Overhaed.

Im 100mbit Netz, versteht sich von selbst !

lowbyte

Hi

Belli die Funktionen waren nur Bsp. die man Sicher noch verändern muss. Return codes etc...

lowbyte

disaster123

@Belli
völlig richtig:
nach einer Änderung in
char *buffer = char[1024*256];

geht es super. Es liegt also wirklich daran, dass er sonst immer nur 4byte ließt.

Belli

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.

Belli

disaster123 schrieb:

@Belli
völlig richtig:
nach einer Änderung in
char *buffer = char[1024*256];

geht es super. Es liegt also wirklich daran, dass er sonst immer nur 4byte ließt.

Na bitte, kleine Ursache, große Wirkung

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