Winsock TCP optimierung bzw machung^^

LinkeT

das von 1000 byte nur ein byte gesendet wird steht bestimmt nirgends (soll ich gucken)

wenn dann steht da:
es kann sein das ein paket (gröse 1000) gesendet wird und 2 pakete (a 500 byte) ankommen ... das hat für meine begriffe die relvanz das man beim empfangen der pakete nach schauen muss [wenn man es nicht wie ein stream behandelt] ...

wie gesagt TCP ist die gesicherte variante von udp (jedes paket was nicht korrekt empfangen würde wird noch mal gesendet:

Sender ............. empfänger
--------------DATEN-------->
<---------CRC32-------------
------------OK------------->

für nur EIN paket !!!!!!!!!!!! zum glück aber nicht von endpunkt zu endpunkt sondern von jeder übertragungsstrecke[ die auf TCP basiert, Bsp Lan mit mehren Subnets die per router komunizieren]

sollte da ein NOT OK (falsche CRC32) gesendet, wird das paket noch mal gesendet (bis zu 3 mal, und dann is der socket als "tod" gekennzeichnet (zumindest bei Winsock unter VB6 ... wie und ob man das in C++ feststellen kann kA wird schon nen fehler wo kommen notfalls mal das lan kabel ziehen dann weiss ma was passiert und kann dafür ne fehlerbehandlung schreiben)

@fachman ... ich bin zwar in c++ noch am testen [so wie du] aber das wichtigste über TCP/UDP hab ich in meiner lehre gelernt ... also denn darfste mir abnehmen
die methode war für mich alleine ´nur deswegen zum scheitern verurteilt weil da ja null fehlerbehandlung vorkommt (und netzwerk ist ja nun mal so ne sache)

PS TCP/UDP sind standardiesierte netzwerk protokolle jede firma nutzt das - weils keine andere oder gar bessere methode gibt UDP = schnell(unzuverlassig) TCP = zuverlässig(langsam), rattet mal warum man mit http langsamer downloaded als mit ftp [bei ftp ist das aber über andere "wege" gesichert ;)]

geeky

LinkeT schrieb:

das von 1000 byte nur ein byte gesendet wird steht bestimmt nirgends (soll ich gucken)

Außer in der MSDN:

MSDN schrieb:

If no error occurs, send returns the total number of bytes sent, which can be less than the number requested to be sent in the len parameter.

http://msdn2.microsoft.com/en-us/library/ms740149.aspx
(Natürlich muss man beachten das sich die Socket-Komponenten in VisualBasic und im .NET-Framework diese Einschränkung vermutlich selber umgehen...)

hustbaer

Ok. Ganz einfach: es ist (wie auch schon mehrfach aus der MSDN zitiert wurde) eben NICHT garantiert dass send() immer alles sendet. Fertig, ende der Diskussion. Ob es meistens so ist, oder sogar immer bis auf die Tage wo der Osterhase Schneewittchen im Wald getroffen hat und gleichzeitig Omis Kuckuksuhr kaputtging, ist vollkommen egal. Nicht garantiert heisst "wer sich trotzdem drauf verlässt ist des selberen schuld". Blubb.

LinkeT

bin mal gespannt wann ich drauf stosse

wenns so sein sollte ok aberwie gesagt fehlerbehandlung mit reinbringen und ok

Fachmann

es ist (wie auch schon mehrfach aus der MSDN zitiert wurde) eben NICHT garantiert dass send() immer alles sendet.

ich glaub das ist so selten der fall, dass TCP sogar von banküberweissungen von millionen dollars machen und auch vista ihre gesamte ergatterte daten ans FBI/CIS usw schicken
das risiko geh ich ein weil es ist bestimmt selten dass was nicht ankommt. warscheinlich so selten wie dass daten vom prozessor nicht zur grfikkarte kommen

also fackt ist wenn ich in der schleife alle daten über send schicke werden in nen internen puffer geschrieben und früher oder später abgeschcikt ( verloren geht nix). nachdem alles im puffer is (un teile schon geschickt wurden) close ich den socket. dann wird close_socket warscheinlich auch hinten an den send-stack geschickt sodass auch keine daten verloren gehn. das problem steckt also warschinlich bei recv(). aber wie? er empfängt solang bis close_socket ankommt (oder so) un nach close_socket kommen auch keine daten mehr? wo liegt dann das prob? oder bricht socketclose einfach die verbindung ab un löscht den puffer??

#edit
wenn ich meine beiträge mal lese merk ich wie schwer es ist den text zu verstehen...sry

#edit
achja hab bei google "send really sock" eingegeben und es kam:
"do really rich people wash their socks?" :D^^

geeky

Auf die Gefahr hin das dein Source noch wie auf Seite 1 aussieht, zitiere ich nochmal die msdn

MSDN schrieb:

For connection-oriented sockets (type SOCK_STREAM for example), calling recv will return as much data as is currently available — up to the size of the buffer specified.

Quelle: http://msdn2.microsoft.com/en-us/library/ms740121.aspx

D.h. wenn du recv(socket,&buf,1000,0); aufrufst, sind nachher in buf bis zu 1000 Bytes drin, aber möglicherweise auch weniger. Der Rest käme dann bei folgenden recv()-Aufrufen rein.
Bei recv() ist das Risiko das nicht alle 1000 Bytes gleich da sind um einen exorbitant großen Faktor größer als das Risiko das send() nicht sofort alles sendet

Nachtrag - Schnell gefrickelt und ungetestet:

int recv_complete(SOCKET mySocket, char* myBuffer, int recv_bytes)
{
    int BytesRead=0;
    char* buff_ptr;
    int BytesLeft=0;

    buff_ptr = myBuffer;
    BytesLeft = recv_bytes;

    while(BytesLeft > 0)
    {
        BytesRead = recv(mySocket, buff_ptr, BytesLeft, 0);
	if (BytesRead==0)
	{
	     // Socket wurde geschlossen!
	     return (recv_bytes-BytesLeft);
	}
	else if (BytesRead==SOCKET_ERROR)
	{
	     // Fehler aufgetreten!
	     return SOCKET_ERROR;
	}
	else
	{
	     // Daten empfangen!
	     buff_ptr+=BytesRead;
	     BytesLeft-=BytesRead;
	}        
    }

    return recv_bytes;
}

Ceos

ACHTUNG das ist meine meinung, das ist kein erfahrungswert oder getestet geschweige denn irgendwie von mir schrifftlich belegbar

also das send WENIGER zurückgibt als du angegeben hast wird ausschliesslich dann eintreten, wenn du den hardwareseitigen puffer der netzwerkkarte überlastest.
ich glaube kaum das beim senden von 4 byte wirklich nur 1 byte übertragen wird, aber wenn du jetzt [utopie] 1GB [/utopie] in form eines array in das send pushst dann wird er nur so viel senden können wie gepuffert werden kann, den rest wird er einfach ignorieren.

die zitate sind zwar schön und gut, aber kann jemand auch mal zeigen wo steht WANN GENAU der wert kleiner wird als das was eingegeben wurde. Weil sonst wird das hier noch n echt buntes verschwörungstheorieraten ...

falls keiner was passendes findet ...
ich tipp mal, da sitzt ein kleines männchen mit axt und immer wenn ein datenstrom durchflutscht versucht er ihn zu treffen ^_

geeky

Mit setsockopt() kann man zumindest den "per-socket" Receive und Send Buffer verändern. Allerdings steht bei beiden sowas:

This is unrelated to SO_MAX_MSG_SIZE and does not necessarily correspond to the size of a TCP send/receive window..

http://msdn2.microsoft.com/en-us/library/ms740476.aspx

Welchen Wert der TCP (also nicht Winsock) send/receive Buffer hat: k.A. Für Windows XP war mal auf irgendner Seite irgendwas um die 16K erwähnt und das man dessen Wert wohl auch irgendwo verändern kann.

Aber egal, diese kleine Einschränkung das nicht unbedingt der gesamte Buffer mit einem Schlag weg ist bzw. empfangen ist lässt sich ja nun eigentlich mit geringstem Aufwand beseitigen...

hustbaer

@Ceos:
Ja, blubb. Blubberliblubbdidubb.
Wir richten uns nach der Doku und sind deswegen doof, und du bist schlauer oder wie?

Ceos

@hustbaer
klar bin ich das (das war ironisch gemeint)

nur hab ich mich nicht mit der halbherzigen doku zufrieden gegeben und mal nachgedacht und selber probiert ...
und heraus kam egal wie schnell ich versucht habe zu senden, nur wenn das array hinreichend groß ist habe ich bei send weniger im return als ich reingeschickt habe ... ausserdem war mein kommentar weniger ein angriff sondern eher ne bitte nicht immerwieder dasselbe zu wiederholen und dann es nach eurem willen auszulegen

PS google iss ja manchmal echt wertlos

EDIT hab vergessen zu erwähnen das ich NICHT mit setsockopt rumgespielt hab, womöglich hat die option SO_NODELAY einfluss auf das sendeverhalten

Ich glaube das "which can be less than the number requested to be sent in the len parameter" bei send steht da wegen non-blocking sockets.

Im Blocking-Mode würde das doch auch absolut keinen Sinn machen das die Funktion früher abbricht.

In der Doku zu WSASend stehts nämlich so: "Given the same buffer situation and a blocking socket, WSASend will block until all of the application buffer contents have been consumed."

send sendet ALLES, sofern es sich um einen Socket im blocking-mode handelt. Bei einem Socket im non-blocking - mode muß geprüft werden, wieviel gesendet worden ist und ggf. weiter gesendet werden.

Allerdings ist das beim recv nicht so. D.h. wenn ich 1000Byte via send verschicke, ist NICHT gewährleistet, daß ich die mit EINEM recv auch alle bekomme. Beim recv ist IMMER zu prüfen, ob die erwartete Datenmenge gelesen werden konnte, und ggf. weiter zu empfangen.

geeky

mf schrieb:

In der Doku zu WSASend stehts nämlich so: "Given the same buffer situation and a blocking socket, WSASend will block until all of the application buffer contents have been consumed."

Was für WSASend() gilt, gilt aber nicht zwangsweise für send() - Was dein Zitat natürlich nicht falsch macht

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.

geeky

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önnen

TCP(=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.

geeky

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.