Du kannst STUN/UDP hole punching oder die Draft-Spezifikation von ICE verwenden. Damit solltest du durch die meisten Heimuser-NATs durchkommen. Die anderen Fälle würden Kram wie TURN erfordern.
Selbstverständlich sind die Links und deren weiterführenden Materialien, besonders die Spezifikationen, englisch.
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
Geändert von Psyduck (29.09.2007 um 17:46 Uhr)
Naja, er hat den Hinweis wahrscheinlich deshalb gegeben, weil erstaunlich viele Leute (gerade in Foren) immer deutschsprachige Doku wollen und nicht einzusehen scheinen, dass man frueher oder spaeter Englisch braucht, wenn man sich in Rechner (gerade in Programmierung) tiefer einarbeitet.Gut, dass du mich drauf hingewiesen hast - sonst hätt ich das net herausgefunden
Exakt. Es ist erstaunlich, wie viele Leute auf die Idee kommmen, daß Standardspezifikationen grundsätzlich in der deutschen Sprache vorliegen und es zu jedem Thema deutschsprachige Tutorials und Dokumentation gibt.
Interessant, dass grade dieses "Zitat" meines Posts aufgegriffen wurde. War eigentlich nur ein kleiner Scherz am Rande (deshalb auch der Smilie ^^").
Nuja.. da ich aber eigentlich kein Problem mit englischen Dokus hab (wobei ich natürlich deutsche, wenn vorhanden, bevorzuge) und auch nicht mehr so ganz "Anfänger" in Sachen Programmierung/IT bin, bin ich mir der Tatsache schon bewußt, dass man auch des Englischen mächtig sein sollte (was ich soweit Gott sei Dank einigermaßen bin) und man auch immer wieder auf Dinge stößt, die man halt nicht in der deutschen Sprache vorliegen.
Der Kommentar von mir war also ein wenig scherzhafte "Ironie" (wenn man das überhaupt so nennen kann), die hoffentlich nicht falsch aufgefasst wurde(!?!).
Von mir nicht, aber das hier ist das Internet, wo man keine Annahmen über Bildung, Wissen und geistige Zurechnungsfähigkeit seines Gegenübers machen kann. ;)
Ich würde Englisch der deutschen Sprache immer vorziehen. Im deutschen Raum verlaufen Tutorials zumeist nach dem Klick und Staune Prinzip. Wenn nach Schritt 5 noch nicht absolut Aufregendes passiert ist, dann ist das Tutorial wertlos. Bei englischen Tutorials ist es dann eher wenn du nach 5 Wörtern nicht auf einen Fachbegriff gestoßen bist ist es wertlos. Zugegebenermaßen gibt es Ausnahmen bei den deutschen Communities im Internet (eigentlich, so würde ich spontan sagen, dieses Forum und die Delphi-PRAXiS (www.delphipraxis.net)), aber die englische Seite des Internets ist viel cooler (Niht zu verachten auch die billigen deutschen Nachmach-Seiten , die unbedingt genauso toll werden wollen wie ihre englischen Vorbilder [german-bash.org -> bash.org; facebook.com -> studivz.de/schuelervz.de], im endeffekt aber scheitern).
Ist leider auch oft im RL nicht wirklich immer klar
--Signature.
Berechtigungen
Zitieren