Winsock TCP optimierung bzw machung^^
-
LinkeT schrieb:
zum thema warum kommen einige bytes (schätze mal gar pakete) nicht an ... TCP garantiert eine "fehlerfreie verbindung" (ist eigentlich quatsch) sie garantiert nur das kein fehler unbemerkt passiert, sowie das ein paket übermittelt wird(falls doch nicht ist da ein fehler) ... die reinfolge sollte eigentlich stimmen je grösser die strecke ist desto höher ist die wahrscheinlichkeit das pakete NICHT in der richtigen reihnfolge ankommen, was u.a. probleme mit VoIP verursacht ... es ist aber für datei transfer kein Problem.
Verdammt noch mal, WAS denn nun???
Bitte bitte bitte eine Komplett- Zusammenfassung von jemandem der WIRKLICH Ahnung hat...
-
BlicksNichtMehr schrieb:
LinkeT schrieb:
zum thema warum kommen einige bytes (schätze mal gar pakete) nicht an ... TCP garantiert eine "fehlerfreie verbindung" (ist eigentlich quatsch) sie garantiert nur das kein fehler unbemerkt passiert, sowie das ein paket übermittelt wird(falls doch nicht ist da ein fehler) ... die reinfolge sollte eigentlich stimmen je grösser die strecke ist desto höher ist die wahrscheinlichkeit das pakete NICHT in der richtigen reihnfolge ankommen, was u.a. probleme mit VoIP verursacht ... es ist aber für datei transfer kein Problem.
Verdammt noch mal, WAS denn nun???
Bitte bitte bitte eine Komplett- Zusammenfassung von jemandem der WIRKLICH Ahnung hat... das is natürlich bs. tcp garantiert das alles.
-
TCP-Pakete haben im Header eine Sequenznummer, einzelne TCP-Pakete können tatsächlich völlig unsortiert über die Leitungen rennen - ist aber völlig egal da der Zielrechner den Datenstrom dank der Sequenznummer wieder korrekt zusammenbaut.
Generell kannst du dir bei TCP/IP sicher sein das deine Daten bei recv() in derselben Reihenfolge ankommen wie sie verschickt wurden - Tun sie das nicht hast du garantiert einen Programmierfehler in deiner Anwendung.
Außerdem kommen die Daten garantiert fehlerfrei oder gar nicht an (was du aber an nem SOCKET_ERROR bemerken wirst)Bei VoIP wird eigentlich eher auf UDP gesetzt (sogar für SIP).
Bei UDP verschickt man einzelne Pakete:
- Die entweder ankommen oder nicht
- Die möglicherweise defekt sind (Bei UDP ist die Prüfsumme optional)
- Die in x-beliebiger Reihenfolge ankommen könnenTCP(=SOCK_STREAM) kann man sich wie nen Telefonat vorstellen: Der Herr "Client" ruft Herrn "Server" an und dann schwafeln die beiden munter los - Hat einer von beiden was nicht verstanden fragt der einfach nochmal nach*
UDP(=SOCK_DGRAM) ist eher wie Briefversand: Der Herr "Client" schmeißt ne Handvoll Briefe (=Pakete) in den Postkasten und der Postbote bringt die in den Briefkasten von Herrn "Server"
Zwei Briefe könnten dem Postboten da unbemerkt in den Schnee/Gulli gefallen sein oder ne Briefmarke wurde vergessen oder so - Die kommen dann halt nicht an.
Und der Postboste schmeißt die Briefe in irgendeiner Reihenfolge in den Briefkasten.* Das passiert für uns als Winsock-Nutzer unbemerkt - Wir sehen die Daten immer in korrekter Reihenfolge und müssen uns um sowas nicht kümmern!
-
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.
-
Bei UDP wird nichts aufgeteilt, die Größe ist beschränkt:
msdn2: send schrieb:
For message-oriented sockets (address family of AF_INET or AF_INET6, type of SOCK_DGRAM, and protocol of IPPROTO_UDP, for example), care must be taken not to exceed the maximum packet size of the underlying provider. The maximum message packet size for a provider can be obtained by calling getsockopt with the optname parameter set to SO_MAX_MSG_SIZE to retrieve the value of socket option. If the data is too long to pass atomically through the underlying protocol, the error WSAEMSGSIZE is returned, and no data is transmitted.
Bei TCP: keine Ahnung wie Windows die Pakete da bildet
-
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.
