IRC-bot zu langsam!?
-
Also ich glaube ich uebervorder dem am anfang zu sehr. Er joint in 3 channel und traegt alle mitglieder in eine sql datenbank ein und schickt gleichzeitig whoist er alle und traegt den authnamen mit ein. Ich hab das dann mit dem whois rausgenommen und naja erstmal werden ca 60 aus 200 mitgliedern eingetragen und was dann da drin steht ist auch nicht rigchtig. 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.
Ich schick euch den code wenn ich wieder zu hause bin.
Hmm und was hat das mit WinApi zu tun?
-
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
-
XzenTorXz schrieb:
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.
-
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.