shock - Di 23.03.10 17:11
Titel: TUdpSocket Bereitschaft Erkennen

---

Hallo Zusammen!

Gleich vorneweg, ich benutze Delphi 2005 und habe keine Indy Zusätze o.Ä und möchte das nach Möglichkeit vermeiden, da ich sonst das ganze Programm neu aufsetzen muss.

Ich bin leider totaler Anfänger in Delphi und von Netzwerkprotokollen hab ich schon gar keine Ahnung, deshalb wende ich mich an euch :D

Ich Arbeite zur Zeit an einem Roboter, der per UDP Socket mit Delphi kommuniziert und den ich von dort aus steuern kann. Der Ablauf ist, dass Delphi die nächste Wunschposition schickt und der Roboter die aktuelle Position zurücksendet. Durch die Differenz kann dann der Verfahrweg berechnet werden. Soweit ganz grob zum Ablauf.

Das Funktioniert auch alles soweit. Falls jetzt jedoch der Roboter nicht angeschaltet ist und ich starte das Programm, dann friert das Programm natürlich ein da der Blocking Mode an ist (Sagt man das so?) und das Programm auf eine Antwort vom Roboter wartet. Blocking mode möchte ich auch nicht verändern, da sonst das ganze Programm nicht mehr funktioniert (ich habe es nur erweitert, die vorarbeit hat jemand anderes geleistet). Ich weiß mittlerweile auch soviel über UDP, dass man sich über die Verwendung hier streiten kann, da eine Antwort vom Server eigentlich wichtig ist. Aber der Roboter läuft nunmal damit.
Ich habe schon versucht über TUdpSocket.Waitfordata(Zeit) die Bereitschaft abzufragen, aber komischerweise bekomme ich hier immer die antwort "false", selbst wenn das Programm einwandfrei funktioniert.

Es geht also darum, festzustellen ob die UDP Verbindung bereit ist oder nicht.

Vielen Dank im Voraus für die Hilfe.

Grüße M.

BenBE - Di 23.03.10 18:19

---

Bei UDP gibt es keine bestehende Verbindung, weshalb man auch nie "Hier gibt es eine" in dem Sinne abfragen kann.

Daher ist hier die einzig praktische Möglichkeit, entweder auf Non-Blocking zu wechseln, oder das Senden und Empfangen über das Blocking-Socket in einen eigenen Thread auszulagern (was man für Blocking eh tun sollte).

ALF - Di 23.03.10 18:53

---

Glaube das auszulagern in einem eigenen Thread (was im Prinzip richtig ist), würde dem Programm nichts bringen.
Da dieses Prog nichts anderes macht als am Port lauschen (einfrieren), bis er, "Robo" sich meldet, um dann im Programm überhaupt sinnvoll weiter zu arbeiten. Es wird also keine zusätzlichen anderen Sachen nebenbei machen müssen!
Darum hat man das sicherlich auch so vereinfacht geschrieben. Mache nichts bis er da ist!
Koordinaten berechnen wenn er nicht da ist,
Werte Ausdrucken wenn er nicht da ist, würden dem Prog ja nichts bringen, da nur beides zusammen Sinn hat!

Vermute ich mal :wink:
Gruss ALf

shock - Di 23.03.10 22:06

---

Danke schonmal für die Antworten.

Alf hat recht...das Programm darf oder soll nicht weiterlaufen wenn der roboter nicht da ist. Ich würde nur gerne diesen Fall irgendwie abfangen um zu verhindern, dass das ganze Programm einfriert.

Falls ich den mode auf non blocking schalte dann erhält er natürlich keine sinnvollen Daten und spuckt nur Fehlermeldungen aus. Das Problem ist auch dass er Über den Udpsocket.receivebuf drüber geht ohne zu warten bis die Daten auch da sind. So erkläre ich mir zumindest die Fehlermeldungen die kommen wenn der Roboter angeschaltet ist. Gibt es da eine Möglichkeit, dass er an der Stelle wartet bis die Daten auch wirklich da sind?

Grüße M.

elundril - Di 23.03.10 22:15

---

du könntest allgemein das in einen Thread auslagern, das blocken manuell machen und in Wirklichkeit nen Timer für n Time-Out laufen lassen, oder? Nur mal so ne schnelle Idee.

lg elundril

ALF - Di 23.03.10 22:22

---

Das Prog ist ja nicht "eingefroren". Es wartet (lauscht) am Port das was reinkommt! Dafür hat man ja socket genommen!
Das umzuprogen mh... hätte wenig Sinn. Auch wie elundril es schreibt, mhh....?
Das Prog kann ja nichts anderes! Was bringt es also, da eh keine Aktuellen Daten vorliegen!

Ich Frag hallt mal so! :gruebel:

Gruss ALf

elundril - Di 23.03.10 22:25

---

Ja, es lauscht, aber was wenn kein Roboter da ist? Dann lauscht es ewig und 3 Tage. Demnach sollte man vielleicht ein Time-Out reinschmeißen, so wie bei HTTP-Requests. ;) Da ist ja auch der Browser nicht eingefroren sondern lauscht auf eine Antwort. Und nach einer Zeit weiß man dann, ok, das Programm hat gelauscht, aber bekommt keine antwort zurück.

lg elundril

ALF - Di 23.03.10 22:36

---

Ich wittere ein Missverständnis :wink:
Ich sehe das so, solange der Robo nicht an ist, brauche ich das Prog auch nicht starten! War vielleicht auch so gedacht! Sonst müsste ja noch Meldungen mit rein für den Ernstfall "Datencaos", verbindung unterbrochen, Prog muss neu gestartet werden usw..
Und das Prog ist bestimmt für DEN ROBO geschrieben. Der nächste neue bessere ROBO, bekommt meist ein neues Prog für die Abfragen, so kenn ich es, sag ich mal so :?
Ansonsten hast Du elundril ja recht 8)

oops, korrigiere mich. Habe sein Thread noch mal gelesen, ist Homework. Dann sollte man Deine Idee mit reinnehmen!
Anstatt Strg+Alt+Del zu nehmen um das Prog abzuschiessen! :lol:

Bin also voll auf Deiner Seite elundril

Gruss ALf

shock - Mi 24.03.10 00:03

---

Hi zusammen,

werde das morgen mal ausprobieren mit dem Timer. Wenn ich dsa nicht hinbekomme dann werd ich mal nen bisschen Quelltext hier reinwerfen. Aber schonmal Danke für die Antworten.