delete[] Frage

Page 2 of 3 1 2 3
03/26/2012 15:27 kleinernascher4#16
also WSAGetLastError(); gibt immer 0 zurück.
und wieso soll recv 0 zurückgeben? recv gibt die anzahl der empfangenen bytes zurück.
bei null würde er also GAR NIX empfangen. bei mir empfängt er immer hin etwas (wenn auch nicht alles :))
03/26/2012 15:45 jacky919#17
Dann liegt es vielleicht daran, dass, wie MrSm!th schon sagte, nichtz alles auf einmal kommt.
03/26/2012 15:49 kleinernascher4#18
nu, und wie stelle ich dann sicher dass ich alles empfange?
03/26/2012 15:56 jacky919#19
Am besten übermittelst du zuerst die Größe der Datei. Dann kannst du mit der empfangenen Größe einen Puffer allozieren. Nun fängst du an zu empfangen.
Code:
char* buf = new char[size];
int received = 0;
while(recieved < size)
{ 
received += recv(s, buf+received, size - received, 0);
}
delete[] buf;
03/26/2012 18:38 kleinernascher4#20
ok, thx jetzt gehts!
03/26/2012 18:39 MrSm!th#21
Quote:
Originally Posted by kleinernascher4 View Post
also WSAGetLastError(); gibt immer 0 zurück.
und wieso soll recv 0 zurückgeben? recv gibt die anzahl der empfangenen bytes zurück.
bei null würde er also GAR NIX empfangen. bei mir empfängt er immer hin etwas (wenn auch nicht alles :))
genau, und wenn es 0 zurückgibt, wurde nichts mehr empfangen

Quote:
Originally Posted by kleinernascher4 View Post
nu, und wie stelle ich dann sicher dass ich alles empfange?
genau so. du rufst recv so lange auf, bis es 0 zurückgibt, dann hast du nichts empfangen und der sendevorgang ist vorbei.
03/26/2012 18:52 jacky919#22
Oder du empfängst solange, bis die dir übermittelte Dateigröße erreicht wurde (siehe mein Beispiel).
03/26/2012 19:25 xNopex#23
Quote:
Oder du empfängst solange, bis die dir übermittelte Dateigröße erreicht wurde (siehe mein Beispiel).
Setzt voraus, dass man weiß wie groß die Datei ist, was meistens leider nicht der Fall ist.
03/26/2012 19:28 jacky919#24
Quote:
Originally Posted by xNopex View Post
Setzt voraus, dass man weiß wie groß die Datei ist, was meistens leider nicht der Fall ist.
Stimmt natürlich, aber wenn man sie nicht wissen sollte, hat man ohnehin Probleme mit der Puffergröße.
03/26/2012 19:31 xNopex#25
Nicht unbedingt. recv() empfängt afaik nie mehr als die angegebene Anzahl Bytes (s. dritter Parameter). Man kann sich dann einen einfachen dynamischen Puffer basteln. Muss halt bisschen Kopieraufwand betrieben werden ;O
03/26/2012 19:34 jacky919#26
Nicht empfangene Bytes können also später noch empfangen werden?
(Bin nicht so bewandert im Umgang mit TCP ;))
03/26/2012 19:38 xNopex#27
Jaja das geht. Man muss Recv halt solange aufrufen, bis es 0 returned, wie bereits schon erwähnt wurde.
03/27/2012 01:01 MrSm!th#28
Ja, siehe:
Quote:
Originally Posted by MrSm!th View Post
genau, und wenn es 0 zurückgibt, wurde nichts mehr empfangen



genau so. du rufst recv so lange auf, bis es 0 zurückgibt, dann hast du nichts empfangen und der sendevorgang ist vorbei.
Genau daher rührt das ja. recv gibt solange etwas zurück, solange noch Daten im Netzwerkstream liegen.

Anders wäre Netzwerkkommunikation gar nicht möglich. Dateigrößen zu übermitteln wäre ja nicht das Problem, nur generell erstmal zu wissen, wie groß ein Packet wäre.
So ziemlich jedes Spiel hat verschiedene Packetstrukturen für verschiedene Zwecke, die auch unterschiedlich groß sind.
Der 3. Parameter spezifiziert nur die maximale Größe, aber wie viel davon tatsächlich genutzt wird, kannst du zum Zeitpunkt des Empfangens ja noch gar nicht wissen; erst, wenn du es empfangen hast und es parst, erfährst du anhand der eigenen Spezifikationen und Festlegungen, wie groß nun der Inhalt dieses Packettyps sein kann.
Da muss man genau so vorgehen: Man läuft in einer Schleife durch recv, bis nichts mehr empfangen wird.

recv ist ein blocking Call; wenn die Daten gerade noch auf dem Weg sind bzw. der Stream leer ist, bleibst du hängen, bis weitere Daten ankommen. Nur, wenn das Senden wirklich beendet ist, also mit keinen Daten mehr zu rechnen ist, der send Call beendet ist, dann wird 0 zurückgegeben.
Also wirst du recv nie mit 0 verlassen, außer der Sendevorgang ist beendet oder die Verbindung wurde unterbrochen.

Dementsprechend kannst du natürlich auch keine Daten "verlieren", wenn du gerade an einer anderen Stelle der Schleife bist, während Daten ankommen. Die warten dann im Stream auf die Abfrage per recv.
03/27/2012 11:58 Nightblizard#29
Quote:
Originally Posted by xNopex View Post
Jaja das geht. Man muss Recv halt solange aufrufen, bis es 0 returned, wie bereits schon erwähnt wurde.
Nein, recv gibt die Anzahl der empfangenen Bytes zurück. Gibt es es 0 zurück, dann hat der Client die Verbindung unterbrochen.


Siehe: [Only registered and activated users can see links. Click Here To Register...]
03/27/2012 12:08 xNopex#30
Ja da hast du zweifelsfrei Recht. Hab da scheinbar iwas durcheinander geworfen. Also man muss recv nicht aufrufen, bis es 0 returned, aber man kann es sicherlich tun. Zusammengehörige Daten muss man dann natürlich anders erkennen. Ich vermute das wird dann über das verwendete Protokoll erledigt.. Bin aber jetzt auch etwas verunsichert.
Page 2 of 3 1 2 3