Entwickler-Ecke

Internet / Netzwerk - TCP Client-Server Lösung - Konzept korrekt?


Martin1966 - Do 21.08.08 14:04
Titel: TCP Client-Server Lösung - Konzept korrekt?
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:
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


Delete - 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 - 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


iKilledKenny - 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.


Delete - 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 - 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.