![]() |
INDY-UDPClient:#10040 "Die Botschaft ist zu lang"
Servus
ich bin z.Z. dabei , ein Proggi zu schreiben , welches mir von Battlefield1942-Servern (das Game ist eigentlich variabel , könnte auch UT2k3 nehen usw.) die Infos anzeigen soll. Ich hab ne richtig informative Seite gefunden und da steht: ".. man muss ein UDP-Paket zu dem Server auf dem Queryport (BF1942 = 23000 ; UT = 7777) mit dem Inhalt '/Basic/' (oder andere) schicken und sofort schickt einem der Server die Gewünschten Infos.." die Leute auf dieser Seite haben es alle mit den FastNet-Kompos , die ja unter D7 nichtmehr dabei sind , gemacht .. auf einer anderen Seite stand , wie man es mit den INDYs machen kann .. da mir ja nichts anderes übriggreblieben ist , hab ich also den IdUDPClient genommen (was sonst ;)) Problem: wenn ich die wenigen Zeichen (/basic/) schicken will , meint er: SocketFehler #10040 Die Botschaft ist zu lang was aber irgendwie nicht sein kann , da es ja NUR 7 Zeichen sind .. Einstellungen: Host: jenachdem was man in Edit1 eingibt Port: 23000 Buffer:8192 TimeOut:500 durch den TimeOut werden mit einem Try..Except-Block die zurückkommenden Daten gelesen (klingt komisch , soll aber funzen) DANKE für Hilfe CU |
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
Moin Hanswurst,
die ausführliche Fehlermeldung sagt noch etwas mehr aus, als die Kurzform: Zitat:
Bei den meisten Fehlercodes kannst Du Dir einen ausführlichen Klartext anzeigen lassen, z.B. so:
Delphi-Quellcode:
ShowMessage(SysErrorMessage(10040));
|
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
danke Christian
also sprich: was der Server schickt , ist zu kurz ??? wie kann man machen , dass komplett alles , was der server schickt , also wie es bei meinem Prog sein soll (yyystatus) , aufgelistet wird ?? die "y" sind nicht die "normalen" sondern die in ASCII mit ":" überm y CU |
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
Nein, es scheint nicht in den Puffer zu passen, den du zum Empfang bereitstellst. Nur eine Vermutung, bitte nicht hauen, falls ich falsch liege.
|
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
*Christian hau*
ne schmarn aber warum passt eine kleine nachricht nicht in den Speicher und wird dann nicht angezeigt ?!?!?!? da ja ein Buffer für größere Datenmengen gedacht ist (?) und bei den anderen Leuten , die sowas machen , funzt es einfach problemlos .. CU |
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
mir fiel grad so ein ..
, dass die Biffergröße ja automatisch erzeugt wird (wenn ich mich nicht irre)..
Code:
außerdem fiel mir noch ein , dass der Server bei jeder anfrage einige "0"-Chars schickt
UDPClient.ReceiveBuffer (sReceived, SizeOf(sReceived));
was kann ich wegen den 0ern machen , da die ja nicht mit Edits, Memos usw mitspielen ?? CU |
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
Moin Hanswurst,
die Message die Du verschicken willst ist sieben Zeichen lang. Na schön, der Fehler wird aber auch gemeldet, wenn der Buffer für die Anwort vom Server zu klein ist. Mach Dich doch mal schlau, wie gross die Datenmenge ist, die vom Server kommt. PS: Warum willst Du mich hauen :shock: Soll ich mal unsere Wachkatzen auf Dich hetzen :twisted: :mrgreen: |
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
Moin Hanswurst,
Zitat:
Wenn Du die genaue Struktur kennst, kannst Du auch einen Recordtypen mit der Struktur anlegen, und eine entsprechend typisierte Variable für den Empfang der Daten verwenden. |
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
klingt sehr interessant für nen noob :spin: (bezieht sich auf mich)
aber kann man da nicht einfach sagen , dass der die 0er einfach "umbennennt" zB in ein Leerzeichen , da mich die 0er nicht interessieren ?? Danke CU |
Re: INDY-UDPClient:#10040 "Die Botschaft ist zu lang&am
Moin Hanswurst,
klar. Schau Dir mal die Funktion StringReplace an. Mit der lässt sich das ganz einfach machen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:59 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz