Vor kurzem haben wir mit einem Kunden diskutiert wie denn Tools wie Skype oder TeamViewer auf Netzwerkebene funktionieren.

Nun, Skype artbeiten mit dem sogenannten „Session Traversal Utilities for NAT“ (STUN), ebenso wie Microsoft Windows Live Messenger; ich gehe davon aus, dass es TeamViewer ähnlich macht, ggf. noch ergänzt durch weitere ähnliche Protokolle/Verfahren.

Neben STUN erwähnt der Wikipedia-Artikel noch das verwandte Protokoll „Traversal Using Relay NAT“ (TURN) und die verwandte Technik „Interactive Connectivity Establishment“ (ICE).

Auch für Peer-to-Peer-Netzwerke (P2P) gibt es entsprechende Techniken wie z.B. „UDP Hole Punching“ oder „TCP Hole Punching“ um via NAT zu funktionieren.

Implementierungen

Alles eine spannende Sache, und inzwischen auch gut dokumentiert.

Ich selbst habe früher während des Studiums und der Diplomarbeit auch viel mit Sockets gearbeitet, kleine Übungs-Chats programmiert oder mal einen HTTP-Server. Natürlich nie über Firewalls und NAT hinweg, das war damals zum Glück nie nötig.

Zurück zum Thema.

Ich habe eine Weile rumgesucht, ob es Implementationen von STUN in .NET gibt. Tatsächlich gibt es ein paar davon, z.B. einen CodeProject-Artikel für einen STUN-Client und einen SIP-Stack-Artikel (VoIP) vom selben Autor.

STUN/TURN/ICE für Windows Communication Foundation (WCF)?

Was ich leider nicht gefunden habe ist eine Implementation von STUN, TURN oder ICE für Microsofts Windows Communication Foundation (WCF).

Ich bin noch recht neu mit WCF, denke aber dass es technisch schon möglich und vor allem sinnvoll ist, zusätzlich zu HTTP und Co. auch noch STUN als zuschaltbares Protokoll zur Verfügung zu haben.

Ggf. gibt’s da ja doch was?

Update 2011-04-23

Für HTTP habe ich was interessantes gefunden: „Comet“ als Überbegriff für verschiedenen Techniken im HTTP-Bereich um vom Server Benachrichtigungen zum Client zu senden. Namentlich z.B. auch „Ajax Push“ oder „HTTP Server Push“ genannt. Interessant! (Gibt’s auch für ASP.NET)