Lnet. Verbindungsabbruch erkennen.
-
- Beiträge: 94
- Registriert: Mi 28. Mär 2007, 22:01
- OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
- CPU-Target: xxBit
- Kontaktdaten:
Lnet. Verbindungsabbruch erkennen.
Hallo
ich schreibe ein Programm, mit dem man über eine TCP-Verbindung ein anderes Programm vernsteuern kann. Mein programm läuft auf nem WinCE-PPC.
Ich hab ihn über Bluethooth in das Lan eingebunden. Klappt auch ganz gut. Ich kann verbinden/trennen/senden/empfangen. Ich würde aber gerne das Zusammenbrechen der Verbindung erfahren. Muss ich dann kontenuierlich etwas empfangen und wenn ich z.b 3 mal hintereinander nix empfangen habe die Verbindung auf Error setzen? Oder liefert mit LNet ein solches Event gleich mit. PS Das OnDissconnect wird bei solch hardwareseitiger trennung nicht ausgelöst.
Gruß Flashbanger
ich schreibe ein Programm, mit dem man über eine TCP-Verbindung ein anderes Programm vernsteuern kann. Mein programm läuft auf nem WinCE-PPC.
Ich hab ihn über Bluethooth in das Lan eingebunden. Klappt auch ganz gut. Ich kann verbinden/trennen/senden/empfangen. Ich würde aber gerne das Zusammenbrechen der Verbindung erfahren. Muss ich dann kontenuierlich etwas empfangen und wenn ich z.b 3 mal hintereinander nix empfangen habe die Verbindung auf Error setzen? Oder liefert mit LNet ein solches Event gleich mit. PS Das OnDissconnect wird bei solch hardwareseitiger trennung nicht ausgelöst.
Gruß Flashbanger
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Ich weiß nicht ob das für Dich relevant ist....
Bei TCP/IP wird ein Verbindungsabbruch nur von dem erkannt, der Daten in den Socket sendet (egal ob Server oder Client). Kommen die nicht an (und/oder werden bestätigt) erhält er eine Verbindungsabbruch - Benachrichtigung. Der, der auf Daten wartet, kann nicht erkennen, ob der andere nichts sendet, oder ob die Verbindung tot ist. Durch eine idle Verbindung werden nicht vom System irgendwelche Lifecheck-Daten geschickt (außer man fordert das explizit, was nicht in allen Systemen realisiert ist). Man muss den Life-Check also selber machen.
-Michael
Bei TCP/IP wird ein Verbindungsabbruch nur von dem erkannt, der Daten in den Socket sendet (egal ob Server oder Client). Kommen die nicht an (und/oder werden bestätigt) erhält er eine Verbindungsabbruch - Benachrichtigung. Der, der auf Daten wartet, kann nicht erkennen, ob der andere nichts sendet, oder ob die Verbindung tot ist. Durch eine idle Verbindung werden nicht vom System irgendwelche Lifecheck-Daten geschickt (außer man fordert das explizit, was nicht in allen Systemen realisiert ist). Man muss den Life-Check also selber machen.
-Michael
-
- Beiträge: 94
- Registriert: Mi 28. Mär 2007, 22:01
- OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
- CPU-Target: xxBit
- Kontaktdaten:
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
pluto hat geschrieben:Was ich mir noch vorstellen könnte: Du sendest einfach eine Anfrage und wenn eine Bestimmte Zeit lang keine Antwort kommt liegt ein Fehler vor.
Wenn man was sendet, überprüft bei TCP/IP das System ob die Daten ankommen und bricht die Verbindung ab, wenn das nicht so ist. Da braucht das Programm auf der anderen Seite nicht zu antworten. Ob der andere dann aber von dem Verbindungsabbruch etwas mitbekommt ist dann durchaus fraglich, weil durch die Leitung nichts kommt, kommt auch die Nachricht über den Verbindungsabbruch nicht an.
-Michael
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Nur eine Frage am Rande:
Läuft die Verbindung über TCP oder UDP. Sprich was sendet der Socket wirklich.
Bei UDP Paketen gibt es keine Kommunikationsüberprüfung, muß man auf Anwendungsebene machen.
Bei TCP sollte nach einigen Resend/Syncversuchen der Socket ein Problem schon feststellen können.
Läuft die Verbindung über TCP oder UDP. Sprich was sendet der Socket wirklich.
Bei UDP Paketen gibt es keine Kommunikationsüberprüfung, muß man auf Anwendungsebene machen.
Bei TCP sollte nach einigen Resend/Syncversuchen der Socket ein Problem schon feststellen können.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
Im Synapse Wiki steht auch was dazu.
http://synapse.ararat.cz/doku.php/publi ... connection
http://synapse.ararat.cz/doku.php/publi ... connection
-
- Beiträge: 94
- Registriert: Mi 28. Mär 2007, 22:01
- OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
- CPU-Target: xxBit
- Kontaktdaten:
Es handelt sich um TCP/IP-Sockets.
Das problem ist Folgendes : Ich hab eine Modelleisenbahn. Die ist an den PC angeschlossen. Das Ansteuern ist kein problem. Aber ich will natürlich was besonderes und will daher mein Hauptprogramm(das auf dem Windows Rechner läuft und mit der hardware komuniziert) durch eine TCP/IP-Verbindung fernsteuern.
Wenn es nun zu einer änderung auf der Anlage kommt(z.b Kurzschluss, dann bekommt das der PC gemeldet). Soweit eine Verbindung zum PPC besteht, wird diese Meldung an den PPC gesendet, der daraufhin z.b mit einem beepen reagiert.
Wenn nun die Verbindung nicht mehr besteht und die beiden partner auch nix davon wissen. Dann kann mein PPC den User nicht durch Beepen aufwecken und eventuell eine fehlermeldung ausgeben.
Was ich aber nicht verstehe: Der PPC bekommt das Disconnecten mit. Das Symbol oben rechts geht auf Nichtverbunden. Nur Wiso werden dann nicht alle Sockets außer Loopback geschlossen?
Ich finde leider kaum material über die Compact-API(ich hab noch mehr auf dem herzen bezüglich CE-API).
Gruß Flashbanger
Das problem ist Folgendes : Ich hab eine Modelleisenbahn. Die ist an den PC angeschlossen. Das Ansteuern ist kein problem. Aber ich will natürlich was besonderes und will daher mein Hauptprogramm(das auf dem Windows Rechner läuft und mit der hardware komuniziert) durch eine TCP/IP-Verbindung fernsteuern.
Wenn es nun zu einer änderung auf der Anlage kommt(z.b Kurzschluss, dann bekommt das der PC gemeldet). Soweit eine Verbindung zum PPC besteht, wird diese Meldung an den PPC gesendet, der daraufhin z.b mit einem beepen reagiert.
Wenn nun die Verbindung nicht mehr besteht und die beiden partner auch nix davon wissen. Dann kann mein PPC den User nicht durch Beepen aufwecken und eventuell eine fehlermeldung ausgeben.
Was ich aber nicht verstehe: Der PPC bekommt das Disconnecten mit. Das Symbol oben rechts geht auf Nichtverbunden. Nur Wiso werden dann nicht alle Sockets außer Loopback geschlossen?
Ich finde leider kaum material über die Compact-API(ich hab noch mehr auf dem herzen bezüglich CE-API).
Gruß Flashbanger
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Ich glaube du wirst um eine mehr oder weniger permanente Überprüfung vom Programm aus nicht umhin kommen.
Die Sokets werden vermutlich deswegen nicht geschlossen, da ein Reconnect erwartet wird, da eine schlechte Verbindung an der Tagesordnung ist.
Bei meinem Handy wird zB. eine Bluetooth-Verbindung von manchen Geräten erst nach 10min Fehlen als gestört empfunden.
Ich gehe davon aus, das dein PPC beim Symbol nicht den Soket auswertet sondern direkt auf den Status des Sende/Empfangs) Gerätes auswertet, also den Status des Kommunikationslayers 1 (physikalische Verbindung) auswertet. Dort wirst du, ohne API-Zugriffe nichts auswerten können.
Die Sokets werden vermutlich deswegen nicht geschlossen, da ein Reconnect erwartet wird, da eine schlechte Verbindung an der Tagesordnung ist.
Bei meinem Handy wird zB. eine Bluetooth-Verbindung von manchen Geräten erst nach 10min Fehlen als gestört empfunden.
Ich gehe davon aus, das dein PPC beim Symbol nicht den Soket auswertet sondern direkt auf den Status des Sende/Empfangs) Gerätes auswertet, also den Status des Kommunikationslayers 1 (physikalische Verbindung) auswertet. Dort wirst du, ohne API-Zugriffe nichts auswerten können.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).