Hallo Forum,

ich möchte mein bisheriges Programm netzwerkfähig machen.

Das bisherige Programm:
Es fragt über spezielle PCI-Karten angeschlossene angeschlossene Hardware ab, rechnet irgendwas mit den Signalen aus und speichert die Ergebnisse in Zeitintervallen von Sekundenbruchteilen bis Minuten (je nach Anwendungsfall) erst im Speicher und bei Langeweile auch auf Festplatte ab.
Beispiel: Eine PCI-Karte mit 48 I/O-Leitungen kann einen Lichtschrankenrahmen mit 32x32 Lichtschranken abfragen und so irgendwelche Bewegungsabläufe beobachten. Solange ich mit 5 Lichtschrankenrahmen auskomme ist alles super, ein Programm auf einem Rechner.

Nun gibt es das Problem der Erweiterbarkeit und das irgenwann in einem einzelnen PC nicht mehr so viele PCI-Steckplätze vorhanden sind, das alles auf einem Rechner läuft.

Also ist meine Idee, daß mehrere Rechner in einem Netzwerk sich die Aufgabe teilen sollen. Also der erste Rechner die ersten 5 Rahmen, der zweite Rechner die Rahmen 6-10, usw. bis der Kunde kein Geld mehr hat Rahmen von uns zu kaufen.

Schön wäre es, wenn der Ausfall eines Rechners nur den Wegfall dessen Ergebnisse zur Folge hätte, bzw. falls es nur zeitweilige Netzwerkprobleme sind (Kabel kurz mal rausgezogen) daß er später seine Ergebnisse "nachreichen" kann.

Einen speziellen Rechner als Server zu definieren will ich eigentlich nicht, denn ausgerechnet der kann ja ausfallen. Schön wäre es auch, wenn auf jedem Rechner die gleiche Software läuft (eine exe kann alles, welchen Teil an der Gesamtaufgabe sie übernehmen soll, muß konfiguriert werden) und jenachdem, an welchem Rechner der Bediener gerade steht, alle anderen Rechner auf diesen Befehl gehorchen. Das zwei Bediener an zwei verschiedenen Rechner hü und hott sagen, soll per Definition nicht passieren, bzw. der letzte "hat Recht".

Also vielleicht so, daß auf allen Rechnern ein Programm läuft, was zwar 20 Rahmen datenmäßig verwalten kann, aber nur 5 Rahmen abfragt und die Daten der anderen Rahmen von den anderen Rechnern bekommt und die eigenen Daten zu den anderen schickt. Ausgefallene Rechner sollen erkannt werden, den Gesamtablauf aber nicht stören und "wiedergefundene" Rechner sollen nachträglich syncronisiert werden können. Am Ende des Versuches haben dann eben alle Rechner die kompletten Daten (ist dann zwar alles doppelt gemoppelt, aber Sicherheit ist wichtig)

Das Timing sollte auf allen Rechnern im Zehntelsekundenbereich stimmen.

Wie würdet Ihr an sowas herangehen?

Wo sollte man von vornherein drauf achten?

Gibt es z.B. irgendwelche Dinge beim Design und bei der Auswahl bestimmter Technologien zu beachten, um mir nicht später irgendwelche Möglichkeiten zu verbauen?

TCP oder UDP, oder gar IPX/SPX?
Auf jedem Rechner ein Client- + ein Server-Socket?
Wie finden sich die Rechner möglichst automatisch?

Muß ich z.B. meine Pakete mit CRC absichern (z.B. 1./2. WORD = Befehlscode/PaketLänge, letztes WORD = CRC) oder ist das heutzutage nicht mehr nötig?

Oder wie?

Ich will hier (erstmal) keinen Code bekommen, sondern nur in die richtige Richtung geschubst werden. Einn paar gut durchdachte Hnweise von Leuten, die das eine oder andere Problem schon hatten, was ich erst noch bekommen werde, helfen vielleicht schon.
Die Tut's habe ich schon überflogen, werde sie jetzt aber gründlich durcharbeiten. Vielleicht ist aber jemand schon eher mit Ideen hier und ich muß mir nicht alle Tut's durcharbeiten. Ist ja vielleicht auch nicht alles zwingend für meinen Fall.

Danke, Knulli.

www.delphi-library.d...cket+v300_54269.html
in diesem tut gibts eine serverkomponente, die nachrichten an alle schickt und auch von jedem bekommt; das könnte doch jede anwendung bei dir machen, oder?
und, das aktualisieren kannst du auch so machen wie im tut, und die procedur, die dort mit einem button.click funktioniert, mit einem timer koppeln (unelegant, ich weiß )
und: bei sowas würd ich (wegen abstürzen und so) die finger von windows lassen

mfg

Die Probleme, die es in der Welt gibt, sind nicht mit der gleichen Denkweise zu lösen, die sie erzeugt hat.
Albert Einstein

Ich scheitere schon an den banalsten Problemen

Ich habe zwar die Datei sctcomp.pas in meinem VCL-Verzeichnis, aber in der Werkzeugleiste finde ich keinen TServer/TClient.

Müssen die Dinger erst noch irgendwie registriert werden?

Habs selber gefunden...

www.delphi-forum.de/...t=dclsockets70%20bpl

Wäre es nicht fast einfacher, eine "Box" zu entwickeln, die dir deine Daten digitalisiert und dann diese Daten an den PC schickt? Soweit ich deine Aufgabe verstanden habe, brauchst du ja nur lesenden Zugriff, oder?
Es gibt doch hunderte von Bausätzen, die da weiterhelfen können.

Das leidige Schicksal der Softwareentwickler:

Alles, wozu die Hardwareleute nicht in der Lage sind oder keine Lust zu haben, muß die Software 'kitten'.

Soll heißen: Wenn ein Problem irgendwie mit Software gelöst werden kann, landet es auf meinem Tisch.
Oder salopp formuliert: Die zeigen mir einen Vogel, wenn ich damit ankomme.

Abgesehen davon müßte ich den Controller in der Box auch programmieren, womit sich der Kreis wieder geschlossen hat. Dann braucht der Kram auch noch ne Stromversorgung und etwas Elektronikansteuerung, die nicht für jeden Rahmen einzeln aufgebaut werden soll, sondern immer für z.B. 5. Es sind auch nicht nur Rahmen, sondern manchmal auch noch mehr und Steuerungsaufgaben sind auch gelegentlich dabei. Und für jeden Kunden gibt es eine andere Konfiguration. Ich wüßte nicht, wie man Compilerschalter und Konstantendefinitionen in "Hardware gießt".

Letztendlich würde ich nur einen Teil der Software vom PC in einen Controller verlagern, also kanns auch im PC bleiben, da sind die Entwicklungsumgebungen und Bibliotheken (z.B. TServer/TClient) komfortabler.

Ich bin mir nicht sicher, ob es einfacher wird. Ich arbeite in einer Firma, die Regler für Prüfstände herstellt. Von daher kenne ich den Aufwand.
Groß programmieren würde ich die Controller nicht. Einen Netzwerkadapter und dann die Daten regelmäßig rausjagen. Es müssen ja nur kleine Bitpakete sein. Solltet ihr euer Produkt verkaufen, sollte das in den Entwicklungskosten locker drin sein.

Die Entscheidung hätte vor hundert Jahren getroffen werden müssen.

Fakt ist: Softwareentwickler sind in der Befehlskette ganz hinten. Friß oder stirb. Problem MUSS mit Software gelöst werden.

Für zukünftige Systeme kann man da sicherlich drüber nachdenken. Meißtens ist aber alles zeitlich gesehen immer sehr knapp. Also muß man mit der vorhandene Hardware auskommen. Scheint auch eine geprägte Denkweise zu sein: Hardware kann man anfassen = kostet Geld, Software ist bloß ein paar Bits und Bytes hin und herschieben = billig zu haben.

Hat ja bisher auch immer geklappt (hab bisher alle Probleme gelöst), warum nicht auch jetzt.

Also zurück zur Aufgabe!

Bin am überlegen, ob man UDP zum "gegenseitigen finden der Clients" und "untereinander Befehle verteilen" nimmt und TCP "Standleitungen" für die Daten.
Oder alles über UDP mit "Paket verloren Kontrolle" und allen anderen Unannehmlichkeiten.
Oder nur TCP mit manuellem Konfigurationsaufwand bei der Einrichtung der "System-Landschaft" (weniger Programmieraufwand?).

Im TUT steht sinngemäß "TCP paßt für mich auf, daß nichts in der falschen Reihenfolge ankommt oder verloren geht"
Heißt daß, ich kann einen 3MB großen Puffen an die Senderoutine übergeben und auf der anderen Seite kommen die 3MB genauso wieder raus?

Bitte um Korrektur, wenn ich was falsch verstanden habe.

Tja, wenn ich mir so Leute angucke, die bei großen Firmen programmieren... Ich denke, wir wissen, was Software kostet und was da alles drinsteckt.


Die UDP-TCP-Geschichte hast du schon richtig verstanden. Ein Handshake zu implementieren sollte ja kein Problem sein. Müssen die Daten denn in der richtigen Reihenfolge ankommen?

Nur mal so aus unseren Statistiken:

von 50000 gesendeten Paketen und einer maximalen Wartezeit für die Antwort von 20ms, mussten 0,05% neu gesendet werden. Die Reihenfolge war immer richtig. Wir haben vor die Pakete einen Header gesetzt, in dem die Paketnummer abgeglichen wird. Somit sollte das in 99,9% der Fälle sicher sein.

Kleiner Nachtrag:

Zitat:

Solltet ihr euer Produkt verkaufen, sollte das in den Entwicklungskosten locker drin sein.

Sie sind schon verkauft, jetzt muß nur noch entwickelt werden...

Meinst Du mit Handshake:
Ich bin PC1 mit Rahmen 1-5, es gibt noch PC2+PC3 mit Rahmen 6-15, ich schicke meine Daten vom Zeitpunkt XYZ von Rahmen 1-5 zu PC2+PC3 und wenn ich eine Rückmeldung von denen bekommen habe, daß es angekommen ist, kann ich Zeitpunkt XYZ sendemäßig vergessen. Dann muß ich noch warten, bis ich von PC2+PC3 die Daten der Rahmen 6-15 bekommen habe (und natürlich quittieren). Dann kann ich Zeitpunkt XYZ auf Festplatte schreiben und gänzlich vergessen.

Scheint mir ein steiniger Weg zu sein. Viel Jongliererei mir diversen Puffern. Würdest Du das auch so machen? Brauche ich dann noch TCP?

Reihenfolge:
Ich denke, wenn man in die Pakete einen Zeitstempel und/oder ähnliche Informationen mir reinpackt, ist die Reihenfolge egal. Dann kann ja jeder Empfänger dort nachsehen und somit die empfangenen Daten in seinen eigenen Datenbestand richtig einsortieren. Bedingt aber ein gutes Timing zwischen den Rechnern, z.B. ein Zeitraster mit Toleranzfenster, damit bei kleinen Zeitdifferenzen zwischen den Rechnern trotzdem die Pakete dem richtigen Zeitpunkt zugeordnet werden können.

Es ist vom Anwendungsfall abhängig, welches Protokoll du nimmst. Du musst dir halt bewusst sein, dass bei UDP ans Ankommen nicht garantiert ist. Deshalb haben wir ein Handshake eingebaut. Jedes Paket hat eine Paketnummer und eine ID, die besagt, was für ein Paket gerade gesendet wurde. Sind in dem Paket Daten, die unbedingt ankommen müssen, wird es so oft gesendet, bis eine Quittierung vom Zielrechner erfolgt ist. Diese hätte dann die ID für "Handshake" und in den Nutzdaten die Nummer des Befehlpakets.

Messdaten werden bei uns allerdings ohne Handshake gesendet. Die Relevanz, ob sie ankommen oder nicht, ist nicht so hoch.