| Autor |
Beitrag |
rstaeker
 
Beiträge: 94
WIN 2000
D6 Prof
|
Verfasst: Fr 14.10.05 20:32
Hi Leute,
einige Freunde und ich schreiben nun schon seit längerem an der kompletten Neuentwicklung unserer Kassensoftware für Diskotheken.
Die alte Version ist zwar im Einsatz, aber funktionsmäßig stark veraltet.
Jetzt sollen auch einige Funktionsbeschränkungen mit reinkommen. Userechte, etc. ist schon drin.
Uns fehlt nur noch eines (auf der Wunschliste).
Hat jemand eine Idee, wie man bewirken kann, daß ein Programm im Netzwerk nur X-Mal gestartet werden kann.
Also quasi eine Art von Arbeitsplatz Lizenzierung.
Ich habe im Internet nur Lösungen mit Hardware-Dongels gefunden. Geht das nicht auch ohne das, oder vielleicht mit einer Art von Software-Dongel (vermutlich dann Server / Client).
Bin für Vorschläge dankbar
MfG
Rene
|
|
alias5000
Beiträge: 2145
WinXP Prof SP2, Ubuntu 9.04
C/C++(Code::Blocks, VS.NET),A51(Keil),Object Pascal(D2005PE, Turbo Delphi Explorer) C# (VS 2008 Express)
|
Verfasst: Fr 14.10.05 20:43
eigentlich ganz einfach. Man meldet jedem Client beim Start, dass er online ist. Die antworten und sagen, du kannst starten, oder "du bis einer zu viel"
Das ganze in "Code"
  Quelltext
1:
2:
3:
| -Programmstart
-z.B. mit Indy: TUDPCLient.Broadcast('Hello'); auf einem definierten Port natürlich!
-warten bis antwort kommt, dann entscheiden, ob Programm startet oder geschlossen wird |
Verstanden? _________________ Programmers never die, they just GOSUB without RETURN
|
|
rstaeker 
Beiträge: 94
WIN 2000
D6 Prof
|
Verfasst: Fr 14.10.05 20:53
Danke,
scheinbar war die Client / Server Idee doch richtig.
Werde jetzt mal versuchen, das mit Indy hinzubekommen. Hab noch nie damit gearbeitet.
Melde mich sonst nochmal im Forum
Rene
|
|
alias5000
Beiträge: 2145
WinXP Prof SP2, Ubuntu 9.04
C/C++(Code::Blocks, VS.NET),A51(Keil),Object Pascal(D2005PE, Turbo Delphi Explorer) C# (VS 2008 Express)
|
Verfasst: Fr 14.10.05 21:01
naja eigentlich geht das auch ohne richtigen Client/Server. Jedes PRogramm hat eine Server und CLient-Komponente des UDP-Protokolls. Wenn ein Client per Broadcast was verschickt, empfangen alle UDPClients auf dem Port die Nachricht. Das geht über das Ereignis OnRead. Eigentlich ganz einfach
_________________ Programmers never die, they just GOSUB without RETURN
|
|
MSCH
Beiträge: 1448
Erhaltene Danke: 3
W7 64
XE2, SQL, DevExpress, DevArt, Oracle, SQLServer
|
Verfasst: Sa 15.10.05 10:58
 alias5000 hat folgendes geschrieben: | | naja eigentlich geht das auch ohne richtigen Client/Server. Jedes PRogramm hat eine Server und CLient-Komponente des UDP-Protokolls. Wenn ein Client per Broadcast was verschickt, empfangen alle UDPClients auf dem Port die Nachricht. Das geht über das Ereignis OnRead. Eigentlich ganz einfach |
bis zum nächsten Router/Switch/Gateway, der per se broadcasts filtert.
grez
msch _________________ ist das politisch, wenn ich linksdrehenden Joghurt haben möchte?
|
|
alzaimar
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Sa 15.10.05 11:05
UDP bietet auch kein QoS, also ist nicht garantiert, das alle Abmeldungen auch alle Clients erreichen. Wenn ich nur eine maximal Anzahl an Clients erlauben will, benötige ich ka zwangsweise einen Zähler: +1 für jeden Start, -1 für jedes Ende eines Clients. Dieser Zähler wird ohne Server von allen Clients gepflegt. Wenn nun ein 'Tschüss, ich geh jetzt' nicht durchkommt, dann verhaspeln sich die Clients. Gut, wie oft das vorkommt, kann ich nicht beurteilen, aber so elegant das UDP auch ist, so unsicher ist es auch.
Bleibt also nur die C/S Lösung über Sockets. Dazu musst Du den Clients mitteilen, wo die zentrale Überwachungsinstans ist. Gleichzeitig musst Du sicherstellen, das diese Überwachungsinstanz wirklich nur 1x gestartet wird, denn sonst verbinden sich X clients mit Server#1 und weitere mit Server#2 usw.
Es gibt bei sourceforge eine Komponentensammlung von Turbopower, die alle diese Aspekte abdeckt. Das Teil ist richtig gut und, soweit ich das weiss, auch ausgereift.
FYI: sourceforge.net/projects/tponguard_________________ Na denn, dann. Bis dann, denn.
|
|
rstaeker
Beiträge: 94
WIN 2000
D6 Prof
|
Verfasst: So 16.10.05 21:58
| MSCH hat folgendes geschrieben: | bis zum nächsten Router/Switch/Gateway, der per se broadcasts filtert.
grez
msch |
Das ist mir klar, aber wir reden von autonomen Netzwerken mit 5 bis 15 Rechnern. Da gibt es sicher keine PortBlocks. Ist ja eine Spezialentwicklung, kein Internetdownload, -Vertrieb, etc., daher kann man das bei der Einrichtung von Switchen ja bedenken.
| alzaimar hat folgendes geschrieben: | | UDP bietet auch kein QoS, also ist nicht garantiert, das alle Abmeldungen auch alle Clients erreichen. Wenn ich nur eine maximal Anzahl an Clients erlauben will, benötige ich ka zwangsweise einen Zähler: +1 für jeden Start, -1 für jedes Ende eines Clients. Dieser Zähler wird ohne Server von allen Clients gepflegt. Wenn nun ein 'Tschüss, ich geh jetzt' nicht durchkommt, dann verhaspeln sich die Clients. ... |
Werden aber trotzdem auf Client/Server gehen. Mal schauen, ob TCP oder UDP.
Das Zentrale Programm (Einlaß und Abrechnung) muss eh immer laufen. Da müsste man den Server direkt integrieren können.
Client / Server ist wesentlich sicher als Client / Client, wie alzaimar sehr richtig festgestellt hat.
Danke für die Meinungen
Rene
|
|
|
