Einzelnen Beitrag anzeigen

Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#4

Re: Alternative zur TCP - Daten blind senden???

  Alt 15. Feb 2005, 16:44
Im Grunde mit Threads. Beim Indy Package spaltet der Server für jeden Client einen eigenen Thread ab, ergo kann ein Client nicht mehr die anderen Clients blockieren. Das geht auch im Windows API per Notifycallbacks, habe das aber nie selber bisher benutzt (warum auch wenn man mit Indy in 5 Minuten einen Server programmiert hat). Wichtig ist eben nur das der Clientcode im Server auch wirklich Threadorientiert ist und keine Synchronisationen mit dem Mainthread benötigt. Solche Fehler machen Anfänger gerne die im Server einen Fortschrittsbalken oder ähnliches einbauen wollen. Der Server sollte komplett ohne GUI->ergo Synchronisation auskommen und durchweg Threadbasiert arbeiten, dann gibts solche Probleme wie du sie hast nicht. Zudem dann der Server auch wirklich als echter Dienst laufen kann.

Tja, ob der Router oder die Firewall UDP's durchlässt hängt wohl erstmal nur von deren Konfiguration ab. Dazu muß der Client über dessen IP + Port freigeschaltet sein, das ist primär erstmal alles. Denn es macht technisch gesehen erstmal keinen Unterschied ob man über TCP/IP ein UDP oder HTML oder RPC oder sonstwas Prototoll fährt. Sekundär kann man aber die Router+Firewalls sehr wohl so einstellen das sie nicht nur IP's oder Port sperren sondern ganze Protokollklassen.

Ich persönlich hatte bei meinem Servern nie das Problem mit gemischten Clients (DSL+GPRS) und einem Performanceeinbruch dadurch. Allerdings nutze ich eben Indy -> ergo VCL und schei.e auf 700Kb mehr Codegröße.
Klar das A&O ist immer das Protokoll so zu bauen das man sehr kurze Verbindungszeiten hinbekommt. Fast alle meiner Server arbeiten sozusagen als Statemachines und benötigen keine permanente Verbindung zwischen Clients und Server. Gerade in Bezug auf Clients die über GPRS->Handy laufen ist dies sinnvoll da dort desöfteren die Abrechnung der verbrauchten Einheiten auch zeitgebunden ist. Hat man erstmal ein solches Statemachine-Protokoll implementiert ist es ein einfacher Compilerswitch um auf eine Permante Connection umschalten zu können. Auch dies ist manchmal erforderlich weil es eben auch GPRS Tarife gibt die teuer sind wenn man ständig neue Verdindungen aufbaut.

Aber dies ist ja schon offtopic und hilft dir nicht bei deinem konkreten Problem weiter.

Gruß Hagen
  Mit Zitat antworten Zitat