Instant Messaging: Difference between revisions
Line 109: | Line 109: | ||
</table> |
</table> |
||
<table align="right" border="0" cellpadding="0"><tr><td> |
|||
Ein weiteres Problem ist, dass die meisten Instant Messenger nicht plattformunabhängig sind und somit nicht für alle Systeme vorhanden sind. Dies ist in der folgenden Tabelle aufgeführt: |
Ein weiteres Problem ist, dass die meisten Instant Messenger nicht plattformunabhängig sind und somit nicht für alle Systeme vorhanden sind. Dies ist in der folgenden Tabelle aufgeführt: |
||
</td></tr></table> |
|||
== Betriebssysteme: == |
== Betriebssysteme: == |
Revision as of 13:58, 13 January 2006
Instant Messaging ist eine internet basierte Protokoll-Anwendung, die es Benutzern ermöglicht, in Echtzeit miteinander zu kommunizieren
Was bedeutet Kommunikation bzw. Konversation?
Eine Konversation ist eine schnelle Übertragung von Informationen zwischen zwei oder mehr Parteien, die durch drei einfache Merkmale charakterisiert wird:
1.Sie passiert spontan 2.Sie dauert eine kurze Zeit an 3.Sie ereignet sich zwischen Peers
Was sind Peers?
Peers sind sowohl Personen (P) als auch Anwendungen (A), die ihre Informationen wie eine Konversation austauschen. Somit kann eine Konversation zwischen:
1. P-P: Email, chat und message boards 2. A-A: Webdienste und IP routing 3. P-A: intelligente Agentensysteme oder bots (zukünftige Möglichkeiten)
stattfinden.
Client/Server-Struktur des „Instant Messaging“
Die bekanntesten Instant Massaging-Anbieter, wie z.B. AIM (AOL), MSN (Microsoft), Yahoo! und ICQ, basieren alle auf einer Zentralen-Server-Struktur.
Bei einem zentralisierten Netzwerk, muss sich jeder Benutzer des Netzwerks mit dem zentralen Server verbinden. Dieser Server vermittelt zwischen allen Kommunikationen. Dementsprechend werden Kommunikations- und Userdaten auf diesem Server gespeichert.
Die Anmeldung vom Client an den Server erfolgt meistens durch das HTTP-Protokoll. Die Kommunikation zwischen zwei Clients kann ebenso per HTTP-Protokoll oder über andere Protokolle und Ports erreicht werden.
Diese Kommunikation zwischen zwei oder mehreren Clients ist unproblematisch, sofern sich die Clients im selben Netzwerk befinden, z.B. beide Clients sind mit dem AIM-Netzwerk verbunden. Problematisch wird es jedoch, falls Clients unterschiedlicher Netzwerke miteinander kommunizieren möchten, da die Server, der jeweiligen Netzwerke, nicht miteinander kompatibel sind.
Diese Inkompatibilität liegt an den unterschiedlichen Protokollen und deren Implementierungen. Um diesen Vorgang zu verstehen, werden wir zuerst ein paar Protokolle betrachten:
1.Internet Relay Chat (IRC) Protocol (RFC 1459)
Das IRC-Protokoll ist ein etabliertes, rein textbasiertes Chat-System, das jedoch durch weitere Kommandos über eine „Direct Client-to-Client-Verbindung“ (DCC) den Austausch von Daten und sonstigen Informationen erlaubt. IRC ermöglicht sowohl Gespräche zwischen 2 Teilnehmern (Privatchat) als auch Gesprächsrunden mit einer beliebigen Anzahl von Teilnehmern (Channels, Gesprächskanäle). Zur Vermittlung der Gespräche wird ein Netzwerk aus miteinander verbundenen Servern eingesetzt. Somit wird die Belastung auf viele Rechner verteilt und man kann eine beliebig große „Chatlandschaft“ ermöglichen. Die Kommunikation (ursprünglich: TCP/IP) zwischen Client/Server und Server/Server wird über Nachrichten (messages) in Befehlsform abgewickelt. Die maximale Länge einer Nachricht beträgt 510 Zeichen. Zudem besteht eine Nachricht aus dem Absender (prefix), dem Befehl (command) und zusätzlichen Befehlsparametern, wie z.B. Fehlerkorrektur. Anschließend kann der Server eine Antwort-Nachricht (reply) senden. Wobei sich die Reply-Nachricht gegenüber der obigen Erklärung für eine Nachricht(message) nur darin unterscheidet, dass anstelle des Befehls (command) ein Reply-Code (3-stellige Zahl mit fester definierter Bedeutung) generiert wird. Zudem ist der zwingende Bestandteil einer Nachricht nur die Angabe eines Befehls. Außerdem schicken die Clients Nachrichten ohne Absender, da diese vom Server ergänzt werden und somit Spoofing (Falschangaben) verhindert wird. Server routen oft die Nachrichten bloß durch und benötigen deshalb nur Ziel und Quelle einer Nachricht.
Vorteile:
1. Verglichen mit anderen Chat-Systemen sehr leistungsfähig und robust 2. Trotz enormer Ausmaße bewegt sich die Verzögerung bei der Vermittlung im Bereich von Sekunden und liegt deutlich darunter
Nachteil:
Durch unabhängige Weiterentwicklungen, im Bereich der Kommunikation zwischen Servern innerhalb eines IRC-Netzwerkes werden teilweise auch verkürzte Abwandlungen des Protokolls eingesetzt. Daraus folgt, dass keine einheitlichen Standards über die Erweiterungen existieren. Dies wiederum impliziert Inkompatibilität.
2.OSCAR-Protokoll (ICQ und AOL)
OSCAR steht für Open System for Communication in Realtime. Das Protokoll ist unveröffentlich (propietär) und beruht bisher auf Reverse Engineering. Das original ICQ-Protokoll gebrauchte eine Direktverbindung zwischen den Clients. OSCAR hingegen setzt auf Verbindungen über den Server ICQ kann auch in das IRC-Netzwerk gelangen, indem ICQ sich mit dem hauseigenen IrcQnet.icq.com-Server verbindet. Das OSCAR-Protokoll baut auf TCP auf und besteht selbst aus zwei Protokollschichten, nämlich das Flap- und SNAC-Paket. Das Flap besteht aus dem Flap-Header, Channel, Sequenznummer und der Größe der angehängten Daten. Der Channel ist ähnlich wie die Ports für TCP und UDP, steht allerdings für einen bestimmten Vorgang: z.B. SNAC-Paket, Neue Verbindung, Flap-Fehler und Keep-Alive. SNAC-Pakette sind in sogenannten Service Families organisiert. Jede Familie hat eine ID-Nummer und jeder darin enthaltene SNAC-Typ eine weitere "Unter-ID" (Subtype). Nach dem Login teilt der Server mit, welche SNAC Families er unterstützt, nur diese kann/soll der Client nutzen.
3. SIP-Protokoll (Beführworter: Microsoft)
SIP steht für Session Initiation Protocol und wird im RFC 3261 beschrieben. Dabei wurden auf folgende Dinge geachtet: leichte Implementierbarkeit, Skalierbarkeit, Erweiterbarkeit und Flexibilität. Das SIP-Protokoll kann beliebige Sessions mit einem oder mehreren Teilnehmern verwalten. Sessions können beliebige Multimediaströme, Konferenzen, Computerspiele usw. sein.
Zuletzt möchte ich noch die Entwicklung auf Client-Seite kurz erwähnen. Die Auswahl der Clients ist ziemlich groß und zudem auch kostenlos. Es gibt sowohl Singel- als auch Multi-Clients, wobei der Unterschied darin besteht, dass Singel-Clients sich nur mit einem Netzwerk verbinden können. Wohingegen Multi-Clients sich mit mehreren unterschiedlichen Netzwerken verbinden können, sofern der Client die Netzwerke unterstützt:
Generelle Informationen:
IM / GI | Entwickler | Erstes Release | Typ | Toolkit | Aktuelle stabile Version | Kosten |
AOL IM | AOL | Mai 1997 | Single Protocol | W32 | 5.1 (Win), 4.3(Mac) | kostenlos |
Yahoo!Messenger | Yahoo! | Jun.1999 | Single Protocol | W32 | 7.0 (Win, 2.5.3 (Mac)Cocoas,1.0.4-1 (Unix),4 FreeBSD, GTK | kostenlos |
ICQ | Miarbilis | Nov.1996 | Single Protocol | W32 | 5.06 | kostenlos |
MSN Messenger | Microsoft | Jul.1999 | Single Protocol | W32 | 7.5 | kostenlos |
Google Talk | Google,Inc. | 24.08.2005 | Single Protocol | W32 | 1.0.0.72 | kostenlos |
Trillian | Cerulean Studios | Jul.2000 | Multi Protocol | W32 | 3.1 | kostenlos |
Gaim | Mark Spencer | Nov.1998 | Multi Protocol | GTK | 1.5.0 | Lizenz kostenfrei |
iChat | Apple Computer | Aug.2002 | Multi Protocol | Cocoa | 3 | kostenlos |
Miranda IM | Miranda IM Project | 2000 | Multi Protocol | W32 | 0.4.0.1 | kostenlos |
Netzwerk-Unterstützung:
IM/Netzwerke | AIM | ICQ | MSN Messneger | Yahoo!Messenger | IRC | Jabber | Bonjour NovellGroupWise | |
AOL IM | Ja | Ja | Nein | Nein | Nein | Nein | Nein | Nein |
Yahoo!Messenger | Nein | Nein | Nein | Ja | Nein | Nein | Nein | Nein |
ICQ | Ja | Ja | Nein | Nein | Nein | Nein | Nein | Nein |
MSN Messenger | Nein | Nein | Ja | Nein | Nein | Nein | Nein | Nein |
Google Talk | Nein | Nein | Nein | Nein | Nein | Ja | Nein | Nein |
Trillian | Ja | Ja | Ja | Ja | Nein | Nein | Nein | Nein |
Gaim | Ja | Ja | Nein | Nein | Nein | Ja | Ja | Ja |
iChat | Ja | Ja | Nein | Nein | Nein | Ja | Ja | Ja |
Miranda IM | Ja | Ja | Ja | Ja | Ja | Ja | Ja | Ja |
Ein weiteres Problem ist, dass die meisten Instant Messenger nicht plattformunabhängig sind und somit nicht für alle Systeme vorhanden sind. Dies ist in der folgenden Tabelle aufgeführt: |
Betriebssysteme:
IM/Betruebssysteme Windows Mac OS X Unix, Linux, BSD AOL IM Ja Ja Ja Yahoo!Messenger Ja Ja Ja ICQ Ja Ja Ja MSN Messenger Ja Ja Nein Google Talk Ja(nux 2000/XP/2003) Nein(geplant) Nein Trillian Ja Nein Nein Gaim Ja Ja Ja iChat Nein Ja Nein Miranda IM Ja Nein Nein
Zusammenfassung
Es gibt keinen Instant Messenger, der: 1. zu allen Netzwerken eine Verbindung aufbaut 2. plattformunabhängig ist 3. alle wichtigen Funktionen implementiert hat Mit allen wichtigen Funktionen sind, z.B. Verschlüsselung, Dateitransfer, Audio Chat, Multi- Person Audio Chat, Video Chat, Multi-Person Video Chat, SMS, usw. gemeint.
Dies liegt aber an den Protokollen und deren unterschiedlichen Implementierung. Daraus folgt Inkompatibilität zwischen den Server und Clients.
Quellen:
• Andy Oram (2001). Peer-to-Peer: Harnessing the Power of Disruptive Technologies. O’Reily • Paper: Chapter 1 Introduction to Instant Messaging • Running-gag.de. OSCAR (Protokoll). Quelle: http://www.running-gag.de/wiki/OSCAR_%28Protokoll%29 • Ihse.net. The ICQ Protocol Site. Quelle: http://www.ihse.net/icq/ • Running-gag.de. Session Initiation Protocol. Quelle:
http://www.running-gag.de/wiki/Session_Initiation_Protocol
• Wikipedia. Internet Relay Chat. Quelle: http://de.wikipedia.org/wiki/Internet_Relay_Chat • Wikipedia. Instant Messaging. Quelle: http://de.wikipedia.org/wiki/Instant_Messaging • Syndicon.de. Instant Messaging Glossar. Quelle:
http://www.syndicon.de/im_hilfe/im_glossar/index.html.de.html