Hilfe beim Client/Server...

Badestrand

Hi

Hab ehrlich gesagt keine Lust, deinen kompletten Code durchzusehen (bin aber drübergeflogen). Und ein Tip: Poste nicht zuviel Code (das da ist definitiv zu viel! Das treibt nämlich potenziellen Helfern die Lust am helfen aus!
<- Nicht böse gemeint

Zu deinem Problem:
Wenn man die Ausgabe richtig deutet, wird in deinem Fall bei der Eingabe von "test" folgende Zeile

while((rc=select(0,&fdSetRead,NULL,NULL,&timeout))>0)

abgearbeitet und select gibt irgendwas kleiner gleich 0 zurück. Logisch, oder? Immerhin geht er gar nicht erst in die Schleife rein. Also finde am besten erstmal raus, warum select <= 0 zurückgibt. Gib für diesen Fall z.B. mal "rc" aus.

kernel64

Hab folgendes ergänzt:

//vor der schleife
cout << "vor While..." << endl;
cout << "rc:" << rc << endl;

while((rc=select(0,&fdSetRead,NULL,NULL,&timeout))>0) 
{
cout << "in while..." << endl;
				cout << "rc:" << rc << endl;

//...

}
cout << "nach While()" << endl;
			cout << "rc:" << rc << endl;

Folgendes wird ausgegeben wenn ich ein Befehl eingebe:

Eingabe: test //Befehl
vor While...
rc:4
nach While()
rc:0

Eingabe: //hier nichts eingegeben und dann Enter gedrückt
vor While...
rc:0
in while...
rc:1
empfange...
...//Hier kommt die Ausgabe von test
nach While()
rc:0

Badestrand

Das ist doch schonmal was! Aber könntest ja auch mal selber versuchen, deine Ausgaben zu interpretieren :p

Naja, also:
Bei dieser Ausgabe: "cout << "rc:" << rc << endl;" ist rc ja der Rückgabewert von send(...). Nachschauen-> send gibt die Anzahl von Bytes zurück, die gesendet wurden. Also wurden erfolgreich die 4 Bytes ("test") gesendet! Das funktioniert also!
Der Eintritt in die While-Schleife scheitert und select hat 0 zurückgegeben. Bedeutet, dass nix angekommen ist, in dieser kurzen Zeit.

Bei der nächsten Eingabe (bei dir "" <-Nix) ruft er wieder select auf und siehe da Es wartet ein Paket.
Daraus könnte man schlussfolgern, dass das erste select so schnell aufgerufen wurde (direkt nach dem senden), dass das Paket in der kurzen Zeit noch gar nicht angekommen ist!
Ist das nicht eine Erkenntnis ? Lass dem Paket also ein bisschen Zeit, dann müsste es funktionieren, scheint ja sonst alles korrekt zu sein.

Mit freundlichen Grüßen,
Badestrand

kernel64

Das was du meinst hab ich auch die ganze Zeit gedacht, dass beim Client die Daten viel zu früh erwartet werden. Hab den Client mal mit dem debugger gestartet also mit F10 und gabs keine Probleme, da hier alles Schritt für Schritt abgearbeitet wird, deshalb sind alle Daten angekommen.

Lass dem Paket also ein bisschen Zeit, dann müsste es funktionieren, scheint ja sonst alles korrekt zu sein.

Also ich werde ein Sleep(1000) einbauen, mal sehn wie es dann läuft.
Danke nochmals für die Erkenntnis.

[Edit] Es funktioniert danke habe für Sleep(500) eingesetzt müsste ausreichen.
Wie sieht es mit dem Buffer aus, der dritte parameter bei recv() send()?

recv(s,buf,1024,0);

Soll da 1024 oder 1023 stehn?

Badestrand

Bin froh, dass es doch noch geklappt hat!

kernel64 schrieb:

Wie sieht es mit dem Buffer aus, der dritte parameter bei recv() send()?
recv(s,buf,1024,0);
Soll da 1024 oder 1023 stehn?

Da dein Buffer 1024 Byte groß ist, stimmt das schon mit der 1024. Da du allerdings das letzte Zeichen auf '\0' setzt, mach lieber 1023. Wenn du nämlich 1024 Bytes an Daten empfängst (Rückgabewert rc=1024), dann schreibst du mit "Buf[rc]='\0';" in das 1025-ste Byte. Das wär zuviel.

Mfg,
badestrand

kernel64

Vielen vielen Dank, endlich klappts
Hatte immer ein fehler wenn ich den client beendet habe:

'buf' Stack corrupted

Wahrscheinlich wegen denn 1024

kernel64

Noch ne kleine Frage nebenbei, wie soll ich folgendes senden:

string pc;
		pc += "host:";
		pc += ComputerName();
		pc += "\n";

Habe es so gemacht:

send(s, pc.c_str(), pc.length(), 0);

Wie würdest du das machen?

CodeFinder

kernel64 schrieb:

Habe es so gemacht:
send(s, pc.c_str(), pc.length(), 0);
Wie würdest du das machen?

Kannste doch so machen, allerdings kannste zur Verkettung auch das machen:

string pc(string("host:") + string(ComputerName()) + string("\n"));

kernel64

Aber wie sieht das Empfangen auf der Gegenseite aus, also welche größe soll bei recv() dann verwendet werden? Die göße von pc ist ja dynamisch!

Badestrand

Du kannst ja einfach auch einen Puffer von 1024 Bytes nehmen. Wenn recv(...) dann einen Wert von 1024 zurückgibt, besteht eine gute Chance, dass noch mehr Bytes warten. Es werden dann ja schließlich nicht mehr als 1024 in deinen Puffer geschrieben!
Also dann Puffer vergrößern Dynamischer Puffer mit new[] und delete[] oder malloc, realloc(!) und free anlegen.

- Puffer anlegen mit 1024 Bytes Größe
- recv mit 1024 aufrufen
- Wenn recv 1024 zurückgibt, dann Puffer vergrößern und immer wieder recv mit wieder 1024 und richtiger Pufferposition aufrufen, bis recv<1024
- Dann letztes Byte auf '\0' setzen und ausgeben