![]() |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Und der Server sendet garnichts?
Wie regelst du das mit der Kommunikations, steuerst du die Clients via deren IP-Adressen an? Möglicherweise liegt das Problem daran, das sich die IP-Adresse spätestens alle 24 stunden ändert |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Also nochmal ausführlicher:
Verwaltungsprogramm (welches die Inhalte an die Clients sendet) besitzt: UDPClient (zum senden der Inhalte) UDP Server (zum eventuellen Empfang der ClientNamen) Clientrechner besitzt UDPClient (zum Senden des PCNamen) UDP Server (zum Empfang aller Nachrichten und Inhalte) --------------------------------------------------- Verwaltungsprogramm sendet einen String als Stringarray
Delphi-Quellcode:
---------------------------------------------------
SendMessage('UpdateSSP$$' + SSPContent);
Client erhält den String und splittet ihn bei $$ Wenn Strings[0], wie hier im Beispiel = UpdateSSP ist, weiss das Tool, was es zu tun hat. Steht da aber SendPCName, sendet der Client per UdpClient an das VerwaltungsTool seinen Namen. Mehr nicht. Das funzt ja auch alles ganz toll, aber leider scheint die UDPServer-Komponente an den Clients, welche die Daten ja empfängt, gern mal abzuschmieren. Alle Clients verhalten sich immer gleich, weshalb ich sie nicht steuern muss. Sie tun es einfach selbst, wenn denn Daten ankommen, bzw. wenn die UDPServer aktiv ist, was hier das Problem zu sein scheint. Mit der Ip der Clients stelle ich gar nix an, noch nicht. |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Laufen server und client auf dem selben port?
|
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Nein, das ist natürlich abgestimmt. Es funktioniert ja auch in der Masse. Daran kanns also nicht liegen.
|
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Habt ihr vieleicht einen DHCP Server laufen wenn ja is das ein Windows Server oder ein Router.
|
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Hm, interessante Frage, aber wir haben bei uns keinen DHCP-Server laufen. Jeder Rechner hat seine eigene zugewiesene IP.
Ich bin nun an dem Punkt, wo ich nicht mehr weiter weiss, denn ich hatte eben den Fall, das ein Rechner nicht mehr auf eingehende Protokolle reagiert hat. Ich habe dann das Programm beendet und in die Ini geschaut. UDPServer und UDPClient waren zum Zeitpunkt des Programmendes aktiv. Dann wird mir wohl auch ein Timer nix nützen, der den Zustand der beiden Komponenten überprüft und notfalls aktiviert. Noch irgendwelche Ideen oder Vorschläge? |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Sendest du wirklich auf die richtige Broadcast-IP?
Wenn deine SubNetzMask z.B. 255.255.255.0 ist und deine IP-Adresse wäre 10.2.2.120, dann müsstest du auf 10.2.2.255 senden, um alle Rechner in deinem Netzwerksegment zu erreichen. Sind alle Rechner im gleichen Segment oder gibt es da einen Router, der UDP weiterleitet? |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Hast du mal probiert ob es wieder funktioniert wenn du, nachdem er streik via eines buttons den zustand auf inaktiv und anchließend wiedr auf aktiv zu setzen?
|
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Hallo Shmia,
Zitat:
Netzwerksegmenttechnisch haben aber alle Clients eine IP in diesem Bereich: 192.168.2.x. Die Clients haben ein eigenes Netzwerk und nur der "Server" kommt noch in ein anderes Netzwerk. Demnach müsste ich auf 192.168.2.255 senden!? Aber was macht das besserer und/oder sicherer und vor allem stabiler. Ich frage nicht kritisch, nur neugierig, denn ich versteh die Welt nicht mehr, wenn es daran liegen sollte. Ich bin dankbar für jeden Tipp und werde das hier auf jeden Fall ausprobieren. |
Re: UDP-Protokolle laufen nicht mehr ein, wenn ein Rechner a
Zitat:
EDIT: Nach nun 10-stündigem Dauerbetrieb sind von anfangs 9 Clients nur noch 5 "OnAir". Normal ist das nicht, aber gestern waren nach 2 Stunden schon alle Clients weg. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:42 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