Winsock TCP optimierung bzw machung^^
-
BlicksNichtMerh schrieb:
Danke sehr für die Beschreibung.
Gerne würde ich noch wissen, wie das nun beim Senden und Empfangen mit der Aufteilung der Bytes der Pakete aussieht, sowohl im UDP als auch im TCP.Von UDP hab ich keine Ahnung. Für TCP gilt:
Wenn man blocking - Sockets benutzt, kehrt send erst zurück, wenn er alles auf den Weg gebracht hat oder ein Fehler aufgetreten ist.
Bei nonblocking - Sockets muß man prüfen, wieviel gesendet wurde und ggf. send wiederholt aufrufen.recv kehrt zurück, sobald Daten empfangen wurden oder ein Fehler aufgetreten ist; wenn man eine bestimmte Menge erwartet, muß man prüfen, ob schon alle empfangen wurden - das gilt auch für blocking - Sockets, für nonblocking natürlich sowieso.
D.h. insbesondere: Wenn ein blocking Socket 1000Byte sendet, und der empfangende blocking Socket per recv Daten bekommt, dann ist NICHT gewährleistet, daß er die 1000 gesendeten Byte in einem Rutsch bekommt. Deshalb braucht man, wenn man eine bestimmte Anzahl Byte erwartet, IMMER eine Schleife.
-
send sendet auch nicht alles, das stimmt nicht. du musst send und recv solange aufrufen bis das gewünschte ergebnis erreicht ist. lass dich nicht lumpen weil irgendwelche kiddies "die erfahrung" gemacht haben, daß es anders ginge. halte dich an die dokumentation.
-
Auszug aus der Doku:
"... If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in a nonblocking I/O mode. On nonblocking stream-oriented sockets, the number of bytes written can be between 1 and the requested length, ..."
-
Networkopa schrieb:
send sendet auch nicht alles, das stimmt nicht. du musst send und recv solange aufrufen bis das gewünschte ergebnis erreicht ist. lass dich nicht lumpen weil irgendwelche kiddies "die erfahrung" gemacht haben, daß es anders ginge. halte dich an die dokumentation.
haha selfowned!
-
Networkopa schrieb:
send sendet auch nicht alles, das stimmt nicht. du musst send und recv solange aufrufen bis das gewünschte ergebnis erreicht ist. lass dich nicht lumpen weil irgendwelche kiddies "die erfahrung" gemacht haben, daß es anders ginge. halte dich an die dokumentation.
Doch, send sendet schon alles (bei blocking sockets). Die Beschreibung in der MSDN ist für meinen Geschmack etwas unklar, aber alle Implementierungen machen es wohl so, dass send einfach blockiert, bis alles gesendet werden konnte.
Ich hatte es auch immer anders verstanden (so wie du), aber nachdem ich in einigen anderen Socket Dokus nachgelesen habe, und nochmal genau in der MSDN drübergelesen habe, musste ich meine ursprüngliche Auslegung revidieren
-
hustbaer schrieb:
Die Beschreibung in der MSDN ist für meinen Geschmack etwas unklar
Da stimme ich Dir zu.
-
aber wo steht dies hustbaer? ich kann dies nicht herauslesen!
-
Das kannst Du aus dem von mir etwas weiter oben zitierten Auszug herauslesen.
-
ja, wo? seh ich nich und von wo ist der?
-
Das Zitierte ist aus der MSDN Doku zu send, Remarks, 3. Absatz.
Dort steht...
*If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in a nonblocking I/O mode. On nonblocking stream-oriented sockets, the number of bytes written can be between 1 and the requested length, depending on buffer availability on both client and server machines. The select or WSAEventSelect function can be used to determine when it is possible to send more data.
*Damit meinen die eben dass send in dem Fall blockt bis wirklich alles übertragen wurde. Steht aber leider nicht explizit da, und da es bei recv eben anders ist... kann man das schonmal falsch auslegen.
Weiter oben bei "Return Value" steht noch
If no error occurs, this function returns the total number of bytes sent, which can be less than the number indicated by len for nonblocking sockets.
Das impliziert, dass das "can be less..." nicht für blocking sockets gilt. Was wiederum bedeutet, dass send, wenn kein Fehler passiert, immer alles überträgt.
Auch hier wäre mir sympathischer wenn es explizit dastehen würde. Immerhin ist das Verhalten von send() und recv() die #1 Quelle für Verwirrung/Fehler/Stress, wenn Leute das erste mal was mit Sockets machen.
