Danke erstmal. Vor allem Erstes scheint einigermaßen interessant zu sein (bzw., soweit ich das auf den ersten Blick gesehen habe, eine nähere Spezifikation zu dem, was in dem Skype Artikel steht).Zitat von Jesus_666
TURN scheint ja momentan eher nur eine Empfehlun/ein Entwurf zu sein!?
Werd mich damit befassen, sobald es soweit ist - bis dahin ist aber eh noch eine Menge andere Dinge zu erledigen (z.B. dass die Clients, die NICHT hinter Routern stecken miteinander können ^^").
Ich bin mir immer noch nicht 100% sicher ob ich den Server, (bzw. die Kommunikation Server-Client) wie ichs ganz ganz ursprünglich gedacht hatte, auf einer verbindungslosen Ebene aufzuziehen (alá HTTP) und nur die Clients untereinander eine P2P Verbindung aufbauen zu lassen.
Es stellt sich aber immer mehr raus, dass es wahrscheinlich sinnvoller wäre, eine dauerhafte Verbindung der Clients zum Server bestehen zu lassen, da ja ohne ständigen Informationsfluss vom Server nötig ist. Angefangen von "welcher Client hat welche IP", bis hin zum Übermitteln von Daten zur (zu einem späteren Zeitpunkt dann implementierten) Hilfestellung, damit Clients hinter Routern eine direkte Verbindung zueinander aufbauen können (denn die Artikel zeigen ja, dass dies nicht möglich ist, ohne dass nicht beide zuerst mit dem Server Server kommuniziert haben). Außerdem ist ja auch immer wieder eine "(Re)Authentication" notwendig.
Vielleicht an dieser Stelle ganz kurz zum Hintergrund.. es geht um eine Software die entstehen soll, welche es Mitgliedern Nachrichten, aber auch spezielle Daten untereinander auszutauschen.
Die Mitglieder sind präzise gesagt angehörige einer Community,
Wer mir jetzt sagt, ich soll auf einen IM setzen, dem darf versichert sein, dass das in dem Fall nicht geht, da es ganz spezielle Anforderungen abzudecken gilt und das Schicken von Nachrichten z.B. dann eher nur ein kleines Nebenfeature des eigentlichen Programmes ist.
Wie auch immer: Nachdem sich also immer mehr zeigt, dass eine verbindungslose Server-Client Spezifizierung doch nicht optimal geeignet ist (trotzdem es dabei bleiben soll, dass der eigentliche Datentransfer zwischen den Clients selber stattfinden soll), stellt sich die Frage, ob es die sinnvollste (einzige?) Variante ist, für jeden eingehenden Verbindungsversuch einen eigenen Thread zu starten, der die Verbindung dann akzeptiert und aufrecht erhält - der aber nur aktiv arbeitet, wenn der Client wirklich mit dem Server kommunizieren soll (und dementsprechend sind dann natürlich alle Aufgaben die der Client an den Server stellen kann, möglichst einfach und kurz zu halten). Oder spreng ich dadurch alle Dimensionen?
Es wird im Produktivbetrieb freilich auf einem einigermaßen vernünftigen Server: 4 GB Ram, Dual Core Server Prozessor (wahrscheinlich Opteron). Es wird schätzungsweise mit 100 gleichzeitigen Verbindungen im Höchstfall gerechnet.
Hat vielleich wer Erfahrungswerte/Tips ?
Thx
Gut, dass du mich drauf hingewiesen hast - sonst hätt ich das net herausgefunden
Zitieren