Socket Programmierung und recv() ist langsam



  • Low, hör einfach auf hier rumzuspammen.

    p.S.: dein Code ist übrigens wirklich falsch, die Empfangsschleife wird nur das 1. und 2. Stück korrekt ablegen, alle weiteren überschreiben bereits empfangene Daten.



  • Hi

    ja ja ... Besserwisser

    lowbyte



  • Hi

    Dann brauchst du woll ne Brille.!

    lowbyte



  • Hi

    @hustbaer

    Hast rech mit dem rc kake ! War auch nur ein bsp. das ich geschrieben habe. Sollte natürlich so geschriben werden das es nicht daten überschreibt. Sorry

    lowbyte



  • &rbuf[rc_3] != &rbuf[total]

    Denk mal drüber nach.



  • Und das falsche Beispiel war jetzt auf genau welche Art hilfreich?



  • lowbyte_ schrieb:

    Was bringt es bei Blocking call send und recv nur die recv Funktion zu prüfen, ob alles gesendet wurde ? Mann muss ja automatisch auch send prüfen, das man weiss wie viele daten noch aus dem Puffer gesendet werden müssen.

    Muss man bei blocking stream sockets nicht, weil send() es dann ganz einfach nicht tut. Also niemals "nicht alles" sendet.
    Wozu was prüfen von dem man weiss dass es nicht passieren kann?



  • hustbaer schrieb:

    p.S.: dein Code ist übrigens wirklich falsch, die Empfangsschleife wird nur das 1. und 2. Stück korrekt ablegen, alle weiteren überschreiben bereits empfangene Daten.

    Hast Du etwa gedacht, ich lüge? 😉



  • @Belli:
    Nö. Aber wie man sieht bringt es etwas, wenn es jmd. anderes nochmal wiederholt/bestätigt. Irgendwann wird das auch einem Dickschädel wie Low verdächtig, und er guckt es sich nochmal an.



  • Hi

    Und wie ist es dan bei recv() ?
    Einfach so lange einlesen bis 0 ?

    lowbyte



  • Wie ist was bei recv? Steht doch alles in der Doku?

    recv() liest bei blocking Sockets zwischen 1 Byte und der übergebenen Puffergrösse.

    recv != send



  • Hi

    Ja das stimmt.

    lowbyte



  • lowbyte_ schrieb:

    Hi

    Und wie ist es dan bei recv() ?
    Einfach so lange einlesen bis 0 ?

    lowbyte

    recv auf einen blockierenden Socket kehrt dann zurück, wenn Daten gekommen sind, oder aber wenn die Socketverbindung abbricht.
    Wieviel Byte gelesen wurden, gibt recv als Funktionswert zurück. Die Anzahl kann, wie Hustbaer schon schrieb, zwischen 1 und der angeforderten Menge liegen.

    recv erkennt nicht, wann ein Datenstrom fertig eingelesen wurde. Deshalb empfiehlt es sich, ein Protokoll zu vereinbaren.

    Du hast ja schon so etwas geschildert: Man sendet zB erst Mal 4 Byte, in denen steht, wie groß die folgende Datenmenge ist.

    Beim Empfang liest man zuerst mal diese 4 Bytes, wobei man dabei schon eine solche Schleife benötigt, weil man nicht sicher sein kann, daß auch 4 Byte auf einmal ankommen.

    Dann weiß man, wieviel man noch lesen muß und führt solange recv aus, bis die angekündigte Anzahl an Bytes empfangen worden ist.



  • Deshalb empfiehlt es sich, ein Protokoll zu vereinbaren.

    Empfehlen ist da etwas gewagt, es ist ein Muss.



  • Hi

    @Belli

    Danke. So habe ich das auch gelernt doch das send alles oder nichts sendet wusste ich nicht daher meine, (wen auch so fehler) hafte Version.

    lowbyte



  • Gern geschehen.
    Fehlerhaft ist allerdings nicht Deine Senderoutine.
    Es ist zwar überflüssig zu prüfen, ob send alles verschickt hat, weil es das bei blockierenden Sockets nun mal macht, aber es führt nicht zu Fehlern.

    Der Fehler ist/war in der Empfangsschleife.



  • Hi

    Da ich gestern ein bisschen schmaren erzählt habe ( bisschen 😉 ). Möchte ich noch eine korrekte Lösung präsentieren.

    Sende Routine:

    long send_data(int socket ,char *sbuf ,long len )
    
    {
    	long r = 0;
    
    	do
    	{
    		r = send(socket ,&sbuf[0] ,(int)len ,0);
    		if(r == SOCKET_ERROR) {
    			return -1;
    		}											
    	}
    	while(r != len);
    
    	return len;
    }
    

    Empfangs Routine:

    long recv_data(int socket ,char *rbuf ,long len)
    
    {
    	long p = 0;
    	long r = 0;
    	long l = len;
    
    	do
    	{
    		r = recv(socket ,&rbuf[p] ,(int)l ,0);
    		if(r == SOCKET_ERROR) {
    			return -1;
    		}
    		p += r;
    		l -= r;												
    	}
    	while(p != len);
    
    	return len;
    }
    

    lowbyte



  • äh
    wozu die schleife in send_data()?
    nur mal so?



  • hu

    fals send 0 zurück gibt.

    lowbyte



  • hi

    nach der docu bei msdn. erhalte ich entweder die len zurück oder socket__error ua.

    daher sendet die funktion immer alles? ausser bei einem socket_error und derivaten?
    ich dachte die funktion gibt alles oder nichts zurück. und wenn dan 0 zurück kommt müsse man send widerholen.!??

    lowbyte


Anmelden zum Antworten