Socket Programmierung und recv() ist langsam

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.

Hi

Und wie ist es dan bei recv() ?
Einfach so lange einlesen bis 0 ?

lowbyte

hustbaer

Wie ist was bei recv? Steht doch alles in der Doku?

recv() liest bei blocking Sockets zwischen 1 Byte und der übergebenen Puffergrösse.

recv != send

Hi

Ja das stimmt.

lowbyte

Belli

lowbyte_ schrieb:

Hi

Und wie ist es dan bei recv() ?
Einfach so lange einlesen bis 0 ?

lowbyte

recv auf einen blockierenden Socket kehrt dann zurück, wenn Daten gekommen sind, oder aber wenn die Socketverbindung abbricht.
Wieviel Byte gelesen wurden, gibt recv als Funktionswert zurück. Die Anzahl kann, wie Hustbaer schon schrieb, zwischen 1 und der angeforderten Menge liegen.

recv erkennt nicht, wann ein Datenstrom fertig eingelesen wurde. Deshalb empfiehlt es sich, ein Protokoll zu vereinbaren.

Du hast ja schon so etwas geschildert: Man sendet zB erst Mal 4 Byte, in denen steht, wie groß die folgende Datenmenge ist.

Beim Empfang liest man zuerst mal diese 4 Bytes, wobei man dabei schon eine solche Schleife benötigt, weil man nicht sicher sein kann, daß auch 4 Byte auf einmal ankommen.

Dann weiß man, wieviel man noch lesen muß und führt solange recv aus, bis die angekündigte Anzahl an Bytes empfangen worden ist.

theta

Deshalb empfiehlt es sich, ein Protokoll zu vereinbaren.

Empfehlen ist da etwas gewagt, es ist ein Muss.

Hi

@Belli

Danke. So habe ich das auch gelernt doch das send alles oder nichts sendet wusste ich nicht daher meine, (wen auch so fehler) hafte Version.

lowbyte