IRC-bot zu langsam!?
-
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.
Kann das programm das nicht zwischenspeichern und dann nach und nach abarbeiten?
-
Kann das programm das nicht zwischenspeichern und dann nach und nach abarbeiten?
ja, das geht.
wie das geht erfährste im winapi forum :p
-
XzenTorXz schrieb:
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.
-
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 ;).