Winsock TCP optimierung bzw machung^^

nep

hustbaer schrieb:

nep schrieb:

Ähm noch was anderes: Es ist doch glaube ich nur so, dass die Bytes, welche durch einen Aufruf mit send verschickt werden in korrekter Reihenfolge ankommen. Es ist aber nicht garantiert, dass die Bytes welche durch mehrere send-Aufrufe verschickt werden, auch genau in der Reihenfolge der Aufrufe ankommen. Oder irre ich mich da jetzt? (Alles natürlich auf TCP Sockets bezogen)

Du irrst dich. Das ist garantiert (bei stream Sockets, also TCP, wie du eben schreibst). Weiss nicht was daran so kompliziert ist -- heisst ja "stream" und nicht "partially ordered stream" oder so

Was du schreibst trifft im Übrigen auf datagram Sockets (UDP) zu, da werden die einzelnen Bytes eines Paketes auch nicht durcheinandergewürfelt -- wäre ja komplett unbrauchbar. Dort gilt dann auch dass die Reihenfolge der einzelnen Pakete nicht garantiert wird, bzw. nichtmal dass die überhaupt ankommen...

Ja das hat Ceos weiter oben schon geschrieben Wie gesagt sollte nur ein Einwurf sein, den ich aber extra nochmal hinterfragt habe, weil ich mir da selbst unsicher war wie das genau aussieht (und zu faul zum Doku lesen war ).
Und nochmal, ich kenn den Unterschied zwischen UDP und TCP... das was du schreibst stimmt ja auch, aber das hat so eigentlich gar nix mit meinem "Einwurf" zu tun. Wenn du UDP Sockets hast, kannst du ja eh nur so viele Daten an send() geben, wie die maximale UDP Packet-Größe beträgt (müssten so ~64 Kb sein). Und das die Bytes in einem Packet nicht durcheinandergewürfelt werden ist ja wohl logisch...

geeky

Fachmann schrieb:

aber wie wird sowas dann mit TCP gemacht?

Du müsstest quasi deine send()-Routine austauschen gegen eine send_really() oder so. Ähnlich hat das ja derjenige in dem oben genannten Thread auch gelöst.
Quasi sicherstellen das send() bzw. recv() wirklich alles sendet.

Sagen wir du willst 10 Bytes verschicken und rufst send() auf. send() meldet es hätte 2 Bytes verschickt. Also weisste das noch die restlichen 8 Byte hinterher müssen. Also send() mit den restlichen 8 Bytes nochmal aufrufen.
Diesmal sagen wir mal hätte send() 7 Bytes verschickt. Fehlt also noch einer. Den kriegste dann mit dem letzten send() weg.
Quasi ne kleine Schleife und nen byte-Pointer einfach weitersetzen bis alles weg ist.

Ähnlich ist es bei recv()

Evtl. interessant ist da auch:
http://msdn2.microsoft.com/en-us/library/ms740565.aspx

Ceos

Sagen wir du willst 10 Bytes verschicken und rufst send() auf. send() meldet es hätte 2 Bytes verschickt. Also weisste das noch die restlichen 8 Byte hinterher müssen. Also send() mit den restlichen 8 Bytes nochmal aufrufen.
Diesmal sagen wir mal hätte send() 7 Bytes verschickt. Fehlt also noch einer. Den kriegste dann mit dem letzten send() weg.
Quasi ne kleine Schleife und nen byte-Pointer einfach weitersetzen bis alles weg ist.

Das ist aber auch am thema vorbei!!!
Send sendet (eigentlich) IMMER ALLES was übergeben wurde.
Nur muss das erfolgreiche senden des Array nicht heissen das auch alle bytes in einem schwung gesendet wurden. Der Socket arbeitet in einem ganz anderen kontext als dein programm, du schiebst praktisch nur die bytes in die queue.
Wenn du grad 40 von 100 bytes in den puffer geschreiben hast, kann es passieren das der socket anfängt zu schreiben.
die send methode wird dadurch nicht unterbrochen, sie blockiert nur (im nanosekundenbereich denk ich).
nun sind 40 bytes gesendet, die sendfunktion setzt fort und kopiert die restlichen 60 byte.
Die Send funktion meldet 100 geschreibene bytes und dennoch kommen am client 2 "pakete" 1 40bytes das andere 60bytes

falls dem so nicht ist bitte ich um verzeihung, ich habde das von unserem Java-Dozenten, der mir ehrlich gesagt ein wenig zu viel wissen will

geeky

send() sendet unter Windows in den allermeisten Fällen alles.
(Intern wird das ganze in einen Puffer geschrieben, in Pakete verpackt und gesendet)
...aber der Rückgabewert ist nicht umsonst da - "allermeiste Fälle" sind nicht "alle Fälle"

...statt "ähnlich ist es bei recv()" hätte ich noch besser "vor allem ist es bei recv()" geschrieben. Bei recv() taucht quasi das umgekehrte Problem deutlich häufiger auf.
Wer mit einem recv() meint den gesamten Buffer sofort voll zu haben, wird spätestens bei ner größeren Anzahl von Bytes (z.B. wenn die maximale Paketlänge überschritten wird) und ner relativ lahmen Leitung schnell merken dass recv() gerne nur das zurückliefert was es bereits an Paketen bekommen und in richtiger Reihenfolge wieder in Bytes verpacken konnte...

(btw: Ich hab hier das Gefühl das hier schonmal "Paket" mit den Bytes aus send() gleichgesetzt wird - Was für Pakete daraus entstehen kann man nicht direkt ableiten)

geeky

Ceos schrieb:

falls dem so nicht ist bitte ich um verzeihung, ich habde das von unserem Java-Dozenten, der mir ehrlich gesagt ein wenig zu viel wissen will

So wie ich die Doku da lese (http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#getOutputStream()) scheint man da ja einfach mit Streams zu arbeiten und hat das Glück mit ner komplizierten send()-Methode gar nicht in Kontakt treten zu müssen

Hmm, so langsam glaube ich wir meinen dasselbe und reden bloß aneinander vorbei...

wikipedia schrieb:

Sockets bilden eine standardisierte Schnittstelle (API) zwischen der Netzwerkprotokollimplementierung des Betriebssystems und der eigentlichen Applikationssoftware. [..] Stream Sockets verwenden meist TCP, was aufgrund der Eigenschaften von TCP zu einer hohen Verlässlichkeit führt. Andere Transportprotokolle als TCP sind denkbar, aber wenig verbreitet. Datagram Sockets arbeiten üblicherweise über UDP, also verbindungslos. Dies impliziert schnellen Datenaustausch, jedoch geringe Verlässlichkeit. Auch hier sind natürlich alternative Protokolle möglich.

Ich denke wir lehnen uns hier zu sehr an TCP/UDP an und reden daher aneinander vorbei. Dabei liegen Sockets ja im Prinzip in einer noch abstrakteren Ebene als TCP/UDP...

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...