Autor Beitrag
Martin1966
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 1068

Win 2000, Win XP
Delphi 7, Delphi 2005
BeitragVerfasst: Do 21.08.08 14:04 
Hallo! :wink2:

Ich entwickle für unsere Firma eine Client/Server Anwendung. Ich teste gerade ein wenig rum und habe bereits mit den Indy Komponenten (TIdTcpServer, TIdTcpClient) eine Server- und Client-Anwendung geschrieben. Im Moment läuft es wie folgt:
  • Server Anwendung wird auf dem Server gestartet (klar, wo auch sonst :mrgreen:)
  • Wenn ein Mitarbeiter jetzt seinen Rechner startet wird automatisch auch die Client Anwendung ausgeführt. Diese Anwendung verbindet mit der Server Anwendung. Der Client schickt noch ein paar Daten zum Server (Username, Computername)
  • Die Verbindung bleibt die ganze Zeit über bestehen
  • Die Server Anwendung beobachtet eine bestimmte Hardware auf dem Server und schickt bei Bedarf eine Nachricht an einem bestimmte Client
  • Der Cient wiederum empfängt diese Nachricht und gibt eine Meldung aus.
Soviel zu dem Ablauf. Meine Frage ist nun ob es sinnvoll ist, die Verbindung zwischen Client und Server den ganzen lieben langen Tag bestehen zu lassen? Wir haben hier in der Firma etwas über 100 Mitarbeiter. Da mir leider Erfahrungswerte mit TCP etc fehlen weiß ich nicht ob es sinnvoll ist das der Server über 100 Clientverbindungen 8 Stunden lang am Tag hält obwohl nur nur ab und zu einige Client eine Nachricht vom Server erhalten.

Möglich wäre ja auch folgendes: Der Client meldet sich einmal am Server an und sagt: "Hallo Server, hier bin ich". Der Server merkt sich das der User XYZ sich gerade angemeldet hat und baut anschl. die Verbindung ab. Wenn jetzt der Server dem Client eine Nachricht schicken muss dann baut er erstmal wieder die Verbindung zum Client auf und schickt erst dann die Nachricht.


Wie gesagt, mir fehlen einfach Erfahrungwerte und vielleicht kann mir jemand von Euch da ein paar Sätze zu sagen welches Vorgehen besser ist. Wenn Ihr noch irgendwelche Informationen benötigt so sagt bescheid. ;-)


Lg und danke!
Martin

_________________
Ein Nutzer der Ecke ;-)
j.klugmann
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Do 21.08.08 14:11 
Moin!
Ich bin zwar kein Fachmann in dem Bereich,aber es ist
egal wenn du die Verbindung bestehen lässt.
Was sollte das denn für auswirkungen haben?
Martin1966 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 1068

Win 2000, Win XP
Delphi 7, Delphi 2005
BeitragVerfasst: Do 21.08.08 14:19 
user profile iconj.klugmann hat folgendes geschrieben:
Was sollte das denn für auswirkungen haben?

Das kann ich eben nicht genau sagen weil ich keine wirklichen Erfahrungen auf diesem Gebiet habe. ;-)

Eine Auswirkung wäre zum Beispiel das für jede Connection ein Thread beim Server erstellt wird. Keine Ahnung ob das jetzt negativ ist.

Lg, Martin

_________________
Ein Nutzer der Ecke ;-)
iKilledKenny
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 394
Erhaltene Danke: 8

Win XP
D5 Prof, C# Express 2005
BeitragVerfasst: Do 21.08.08 14:43 
Bei uns in der Firma sind wir komplett auf HTTP Verbindungen umgestiegen, weil die eben nicht gehalten werden müssen, sondern bei Bedarf aufgebaut werden. Das hat vor allem Vorteile, wenns ums Speichern von Daten geht, da auch bei einem Verbindungsfehler einfach versucht wird, diese erneut aufzubauen. Vorher haben wir DCOM benutzt, was dann zu einem toten Client führte, wenn es einen Netzwerkfehler gab.

In deinem konkreten Fall würde das, wie du ja auch schon geschrieben hast, eine Anmeldung des Clients am Server bedeuten. Der Server speichert IP und Port des Clients und "ruft" diesen dann über z.B. HTTP, wenn es neue Werte zu übertragen gibt. Der Client bräuchte dann einen "Server-Baustein", um die Calls des Servers zu empfangen.

Bei uns nutzen wir diese Technik, um den angemeldeten Clients z.B. die Sperrung/Entsperrung von Daten anzuzeigen.

In dem von mir geschilderten Fall würde damit auch der Traffic minimiert, da der Server die Clients nur benachrichtigt, wenn auch was zum Benachrichtigen da ist. Permanente Anfragen an den Server sind dadurch nicht nötig.

In deinem Fall (Messwerte) ist das jedoch kein Argument, da ja wahrscheinlich eh alle n Sekunden Werte übertragen werden sollen. Da bietet sich dann UDP an.
j.klugmann
Ehemaliges Mitglied
Erhaltene Danke: 1



BeitragVerfasst: Do 21.08.08 14:47 
Könnte bei zu vielen Connections zu einem Stillstand des Servers kommen.
Versuche es lieber mit der konstanten Verbindung.In der Schule ,in der Computer AG, hab ich mal den
Server lahmgelegt.(Habe leider erst in 2 Jahren Info) :D
Mein Client denkt sich eine Zahl aus zwischen -2000000 und 2000000 und schickt sie an den Server.
Für jede Zahl 1 Connect.Und das bei 250000 Zahlen. :mrgreen:
Protokolliert Windoof nicht alle Verbindungen?Dann müsste Windoof für jedes Connect
ein neues Protokoll schreiben.Das könnte Rechenzeit beanspruchen.
Allerdings bei 100 Mitarbeitern wird es wohl nicht so extrem viele Connections geben. :idea:
Wenn man allerdings die Anwendung so effektiv wie möglich machen möchte,sollte man
dies nicht machen. :wink:
mfg,
j.klugmann
BenBE
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 8721
Erhaltene Danke: 191

Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
BeitragVerfasst: Do 21.08.08 17:16 
Wenn es allein um Statusmeldungen geht, könntest Du auch für eine "Ankündigung" UDP verwenden, woraufhin der Client sich per TCP meldet (sofern die Info nicht bereits ins UDP-Paket passt). An- und Abmeldung des Clients jeweils mit TCP, Regelmäßiges Keep-Alive des Clients mit UDP.

_________________
Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.