Netzwerk Client-Server Modell Problem
-
Und das TCP auch nicht so sicher ist sei mal dahingestellt. Die Chance auf Fehler bei TCP ist doch wesentilch geringer als bei einer Datagrammübertragung (per UDP).
Wenn du 5 UDP Pakete schickst (im Abstand von vielleicht 1 Sekunde, also nicht zu schnell) ist die Wahrscheinlichkeit dass wenigstens eines davon ankommt grösser als die Wahrscheinlichkeit dass der Aufbau einer TCP/IP Verbindung hinhaut. So war das zu verstehen.
-
@Jester:
Also ich hab nicht genau erzählt was genau gemacht wird. Einen Benutzer im herkömmlichen Sinne gibts nicht. Weder Client noch Server werden von einem Menschen bedient. Es können Daten vom Host kommen die der Client im ersten Thread verarbeiten muss und anders rum. Und um keinen gegenseitigen Ausschluss zu erzeugen wenn diese Daten vom anderen Thread auslesen, benötige ich z.B. ein Mutex.
Und das Problem hätte ich eben mit einem Thread nicht.Aber ich sehe schon: alles andere als den Client in 2 Threads zu teilen wäre Frickelwerk...
@hustbaer:
Naja, ich glaub dir das jetzt mal gerne, ich hab mich nämlich damit nie beschäftigt wie hoch die Wahrscheinlichkeiten von solchen Dingen sind. Aber danke für den Hinweis. Ich hätte mich jetzt auf die "Sicherheit" von TCP verlassen. Tja, bin halt ein naiver Mensch
-
Tobias W schrieb:
@Jester:
Also ich hab nicht genau erzählt was genau gemacht wird. Einen Benutzer im herkömmlichen Sinne gibts nicht. Weder Client noch Server werden von einem Menschen bedient.Äh ja. Hast Du jemals als Benutzer in diesem Sinne Speicher freigegeben? -- Ne? Genau: Mit Benutzer ist hier natürlich derjenige gemeint, der den restlichen Client-Code programmiert. Und das Netzwerkmodul als Bibliothek verwendet. (Bitte komm mir jetzt nicht mit "ich programmiere das aber alleine")
Und um keinen gegenseitigen Ausschluss zu erzeugen wenn diese Daten vom anderen Thread auslesen, benötige ich z.B. ein Mutex.
Und das Problem hätte ich eben mit einem Thread nicht.Naja, im Prinzip mußt du ja nur nen pointer übertragen. Da nur einer schreibt ist das garnicht sooo kritisch... evtl kann man, wenn's geschickt gemacht ist, da um ne komplette synchronisation mit nem mutex rumkommen.
Abgesehen davon ist das selten das Problem -- wenn es gut gemacht ist.
-
evtl kann man, wenn's geschickt gemacht ist, da um ne komplette synchronisation mit nem mutex rumkommen.
Nur wenn man Lust hat selbst mit Barriers zu arbeiten, oder sich auf plattformspezifische Eigenheiten zu verlassen
Ich würde einfach ne Mutex nehmen, und dann mal gucken ob's ein Problem gibt vonwegen langsam (was ich nicht erwarte).
-
hustbaer schrieb:
Nur wenn man Lust hat selbst mit Barriers zu arbeiten, oder sich auf plattformspezifische Eigenheiten zu verlassen
Dadurch, dass die Kommunikation nur in eine Richtung geht muß man das vermutlich nichtmal... aber wie auch immer. Auch mit Mutex dürfte die performance kein problem sein.
-
Klar, der Client wird als Bibliothek von anderen verwendet. Aber ich möchte mich nicht drauf verlassen das es bei geschickter Pointerübergabe problemlos laufen könnte.
Wenn das mal ausgeliefert wird und nach einigen Monaten lässt diese Stelle ein Modul aufhängen, will ich nicht in der nähe meines Cheffe sein
Mal im ernst, ich denke ich schreib mir einen kleinen Prototypen mit dem ich die Last mal simulieren kann, dann werd ich weiter sehen. Eventuell seh ich das ganze Performancetechnisch zu eng.
-
Tobias W schrieb:
Klar, der Client wird als Bibliothek von anderen verwendet. Aber ich möchte mich nicht drauf verlassen das es bei geschickter Pointerübergabe problemlos laufen könnte.
Ich weiß nicht, von welchen Frickelqualitäten Du bei mir ausgehst, aber wenn ich meine, dass das funktioniert wenn man es geschickt macht, dann meine ich, dass man es auf bibliothekseite geschickt machen muß, nicht dass es eventuell funktioniert, wenn der (bibliotheks-)client geschickt arbeitet.
Ein Lasttest klingt wirklich vernünftig. Ich tippe, dass die Synchronisation kein Problem sein wird. Lass mal was von Dir hören, wenn Du mehr weißt!
-
Lass mal was von Dir hören, wenn Du mehr weißt!
Werd ich machen. Außerdem muss ich mich eindeutig tiefer in das Thema Threads einlesen.
-
Jester schrieb:
hustbaer schrieb:
Nur wenn man Lust hat selbst mit Barriers zu arbeiten, oder sich auf plattformspezifische Eigenheiten zu verlassen
Dadurch, dass die Kommunikation nur in eine Richtung geht muß man das vermutlich nichtmal... aber wie auch immer. Auch mit Mutex dürfte die performance kein problem sein.
Wenn man nur einen Zeiger austauscht müsste man das Schreiben des Zeigers "mit release" sein und das Lesen des Zeigers "mit acquire".
Dafür braucht man je nach Plattform ne CPU memory barrier, und auf jeden Fall ne Compiler Barrier.Da man dabei so enorm viel übersehen und ganz allgemein falsch machen kann würde ich auf jeden Fall erstmal mit einer Mutex anfangen.
-
Tobias W schrieb:
@Unix-Tom:
In wie weit braucht das aufnehmen eines Broadcasts mehr Ressourcen beim Empfänger? Kannst du mir das erklären, oder mir einen Tipp geben wo ich solche Infos finden kann? Danke!Ob er nun wartet das ein UDP und diesen dann auswertet (könnte ja auch ein anderes Programm verursachen) kommt oder ob er versucht eine Verbindung zum Server aufzubauen spielt da keine Rolle. Beides braucht CPU-Leistung.
Er sagte das er es deshalb nicht machen möchte weil er Ressourcen sparen will und kein Threads möchte.
Code braucht er sowieso. Der Client lauscht oder er sendet.
-
So, nur so zur Info:
Ein Lasttest hat ergeben, dass die Performance mit 2 Threads kein Problem sein sollte. Auch Mutexe zur synchronisation bringen die Last nicht annähernd so hoch wie ich befürchtet habe.
Das heißt ich werde, auch wenn die Kommunikation nur in eine Richtung geht, Mutexe verwenden um sicher zu stellen das nichts schief geht.
Nochmal vielen Dank für die vielen hilfreichen Antworten...
