IRC-bot zu langsam!?



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



  • Nicht nur das, es kann auch sein, dass du mehrere Zeilen auf einmal bekommst.



  • k also muss ich bis \n\r zwischenspeichern und denn rest dann schon fuer den naechsten anfang nehmen! richtig?
    aber es ist sicher das das \n\r mitgeschickt wird?



  • XzenTorXz schrieb:

    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.



  • k ich glaub das bekomm ich hin

    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?



  • Es ist immer \r\n. Wenn du das beim Senden andersrum machst und es funktioniert, hast du vielleicht nen ziemlich gnädigen Server erwischt (obwohl ich das persönlich ziemlich scheiße finde, das verwässert die Protokollspezifikation und ist nicht notwendig)



  • XzenTorXz schrieb:

    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



  • ich hab eine schleife die die recv funktion immer wieder aufruft, bis der wert 0 oder SOCKE_ERROR zurueckkommt. Hmm ich hab das jetzt umgeschrieben kann es aber leider nicht testen, weil mein Programmier Pc nicht im i-net ist ;/.
    Auf jeden fall ein BIG THX für eure Hilfe!!!



  • auf das \r\n wuerd ich mich nicht so verlassen. Manche server (zb im euirc.net) schicken nur ein normales \n



  • also ich wollte noch mal sagen das jetz das mit dem \r\n geht. Naja jetzt ist C aber wirklich zu langsam ^^. Waerend der 200 leute eintraegt und whoist, wird er gekickt wegen pingtimeout, weil der nie den pong einliest. Hab im moment noch keinen plan wie ich das behebe, aber das schaff ich schon noch.



  • Da ist nicht C zu langsam, sondern die Interaktion übers Netz. Während dieser WHOIS-Geschichte kann C bzw. deine CPU ja nicht viel mehr tun, als auf Antwort zu warten, und eigentlich warten alle Sprachen gleich schnell 😉 Du musst dich natürlich parallel auch ums PingPong kümmern.



  • wie soll man das den parallel machen? Geht eigendlich Multitasking in einer Dosanwendung?
    Von meinem bissherigen wissen hab ich nur die moeglichkeit die anfragen aufzuteilen. Das ich vllt bei jedem pong nur ein channel einlese.



  • Kein Multitasking. Mich wundert ehrlich gesagt, wieso du so ein Problem damit hast, das sollte sich eigentlich von selbst ergeben, wie das funktioniert. Wie ist denn deine Hauptschleife aufgebaut?

    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.



  • Sry ich meinte Konsolen anwendung. Ich weiss das es erst seit windows 95 moeglich ist ;).



  • Hast du bedacht, dass der IRC-Server deinen Bot drosselt, wenn dieser zu viel/zu schnell sendet? Deiner Beschreibung nach offenbar nicht...

    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.



  • nein ich hab mein Bot noch nicht gedrosselt. Aber er sendet ja die 200 whois anweisungen nicht auf einmal. Er laed die zuerst in Datenbank und dann sendet er whois zu dem einzeilen user. Naja auch wenn ich das Whois komplett rausnehme ist er immernoch zu langsam alles einzutragen. Ich dachte eigendlich immer das das viel schneller gehen muesste. Er prueft erst ob es den namen gibt wenn ja updatet er ihn wenn nicht erstellt er ihn, naja und dafuer braucht er so eine halbe sekunde.
    Wenn der in den Channel joint bekommt man ja eine namensliste die liest er ein und trennt die ganzen namen in eine array dann traegt er die ganzen namen in SQL Datenbank ein. Kann natuerlich auch sein das SQL datenbank zu langsam ist (die ist auch online).
    Aja opropo drosseln. Ich wollte den sowieso drosseln damit der nicht wegen Flodden gekickt wird. Wieviel beitraege pro sekunde waerenden gut? bzw. wieviel zeit solte zwischen jedem senden gelassen werden?
    So und ich werd mich jetzt erstmal ueber multitasking schlau machen.



  • XzenTorXz schrieb:

    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.



  • cd9000 schrieb:

    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?



  • K ich hab jetzt ueber multithreads informiert. Ich hab jetzt ein paar extrathreads die das mit dem mysql uebernehmen. Das problem ist aber das der irgendwie mit den sql abfragen durcheinander kommt und dann verliert er immer die connection von dem sql server verliert !?
    Aja und kann ich irgendwie ueberpruefen ob der eine thread noch arbeitet, ohne auf ihn zu warten?

    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?


Anmelden zum Antworten