Kann das programm das nicht zwischenspeichern und dann nach und nach abarbeiten?

ja, das geht.
wie das geht erfährste im winapi forum :p

Ich hab einen IRC Bot geschrieben. Aber irgendwie kommt der mit dem ganzen abfragen nicht hinterher und dann bekommt er also recv wert keine vollstaendigen daten mehr.

Das kann nicht sein. Im IRC ist so wenig Action, da kommt jeder Bot hinterher. Was mich stutzig macht ist deine Behauptung, recv verliere Daten. TCP ist ein verläßliches Protokoll, es verliert unter keinen Umständen Daten. Es kann im Einzelfall dauern, bis die korrekten Daten eintreffen, es kann auch sein, dass das Socket-Subsystem die Verbindung nicht mehr aufrechterhalten kann. Also entweder du bekommst irgendwann sämtliche Daten, die geschickt wurden, oder die Verbindung bricht zusammen. Wenn du Daten verlierst, machst du irgendwas bei der Verarbeitung falsch.

Dann hab ich mir das alles mal angeckut und ich hab als receive manchmal nur bruchstuecke. z.b. wird ein befehl abgebrochen und dann kommt ein naechsten recv mit dem rest.

Das absolut normal fuer TCP. Es kommen nunmal nicht alle Paket in einem an,
sondern sie werden fragmentiert, wenn es sein muss.

Wie sieht denn deine recv-Zeile aus?

mfg
v R

Dann hab ich mir das alles mal angeckut und ich hab als receive manchmal nur bruchstuecke. z.b. wird ein befehl abgebrochen und dann kommt ein naechsten recv mit dem rest.

Also verlierst du doch keine Daten.

Dass du nur Bruchstücke empfängst ist normal, TCP ist ein Bytestrom, du kannst im Allgemeinen nicht davon ausgehen, dass du die gleichen Portionen empfängst wie ausgesandt wurden.

k also muss ich bis \n\r zwischenspeichern und denn rest dann schon fuer den naechsten anfang nehmen! richtig?

Jep.

aber es ist sicher das das \n\r mitgeschickt wird?

Andersrum, \r\n. Der RFC sieht das jedenfalls so vor.

Andersrum, \r\n. Der RFC sieht das jedenfalls so vor.

Ich hab beim senden das aber \n\r gemacht sollte ich das aendern oder ist das nur beim empfangen so?

ach so also muss ich das alles zwischenspeichern bis \n\r kommt?
recv sieht normal aus mit 0 flag am ende.

Wie rufst du recv auf? Manchmal muss man recv mehrmals aufrufen, um den
Kompletten Inhalt zu bekommen.

Und das Pakete nicht zwingend im Ganzen ankommen, gehoert eigentlich zu den
TCP/IP-Grundlagen ;).

mfg
v R

BTW bezweifle ich, dass du eine DOS-Anwendung hast. Unter DOS ist es ein ziemlicher Akt, TCP/IP zum Laufen zu kriegen.

Geht eigendlich Multitasking in einer Dosanwendung?

Natürlich nicht.
Oder meinst du "Konsolen-Anwendung" statt Dos-Anwendung? Dann lautet die Antwort auf deine Frage: Ja.

Es ist nämlich so, dass ein Client nur eine bestimmte Anzahl Anweisungen pro Sekunde (der genaue Algorithmus steht im RFC, hängt aber auch vom Server ab) absetzen darf. Wenn du nun 100 WHOIS-Anfragen auf einmal schickst, ist dein Bot effektiv lahmgelegt, bis alle diese Anfragen vom Server abgearbeitet wurden.
Weil diese Anfragen aber zu schnell hintereinander kamen, lässt sich der Server mit der Bearbeitung viel Zeit und dein Bot ist ziemlich lange lahmgelegt.

Wieviel beitraege pro sekunde waerenden gut? bzw. wieviel zeit solte zwischen jedem senden gelassen werden?

Wie gesagt, der genaue Algorithmus steht im RFC bzw. sollte sich leicht finden lassen.

Ich meine, im RFC steht, dass ein "einfacher" Client nur eine Zeile pro zwei Sekunden schicken soll. Das ist der einfachste Drosselalgorithmus.

Ich meine, im RFC steht, dass ein "einfacher" Client nur eine Zeile pro zwei Sekunden schicken soll. Das ist der einfachste Drosselalgorithmus.

eine antwort in 2 sekunden? das ist ein bisschen arg langsam finde ich. Wo finde ich eigendlich die RFC?

EDIT: K ich hab das eigendlich problem gefunden und zwar das er die zeile falsch uebergibt ist irgendwie eine andere.
also:

WORD WINAPI namelist(LPVOID data){	
        char line[MAXBUFFER], temp[MAXBUFFER], temp2[MAXBUFFER];
	char sline[64][92];
	strcpy(line, (char *)data);
	...
}

void auswerten(char line[MAXBUFFER]){
	...
	if(strgleich(substr(aktion, 0, 3), "353")){
		hThread[threadid] = CreateThread(NULL,0,namelist,(LPVOID)line,0,&dwThreadID[threadid]); //die zeile wird an den thread uebergeben
		...
	}
}

Theoretich muesste er die line variable uebergeben und zwar nur die wo eine Namesliste kommt.

Wenn man aber die ausgabe anguckt. wird der thread viel speater gestartet. und ich glaube das er auch die line von viel spaeter nimmt. Hat jemand eine ahnung wie man das beheben kann?