• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Tim Cooke
  • Devaka Cooray
  • Ron McLeod
  • Jeanne Boyarsky
  • Liutauras Vilda
  • paul wheaton
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
  • Tim Holloway
  • Martijn Verburg
  • Frits Walraven
  • Himai Minh

jabber compatibility with various im standards

Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
here is a question for the authors:
what features of the architecture of jabber allow users to connect through through the different instant messenging standards (AOL, ICQ, MSN, Yahoo, Lotus Sametime. IRC.....) and communicate compatibly across all of them.
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jabber is designed to move as much IM related work as possible to the server. this makes client development easier and allows you to handle a lot of these issues on the server. The protocol remains efficient enough that even with all this server-side work, Jabber servers on standard x86 boxes can basically saturate their network connections long before they max out their CPUs. (Basic IM is primarily a network bound domain no matter how much work you push to the server).
Jabber itself uses a distributed client-server architecture (see the topic on IM in Java). This archicture is the same as is used in email. Messages go from a client to their server. From that server to the recipient's server, and from the recipient's server to the recipient's client. It is expected that direct server to server communication occurs however there is nothing in the protocols to stop servers from relaying messages through special Jabber router servers (something that larger IM providers will probably have to use).
The design allows you to break up the messaging space into smaller domains, each controlled by a central authority. However there is no overall authority for the Jabber network as a whole. The design makes gatewaying into other systems simple.
Most Jabber servers (including the open source reference server jabberd) includes "transports" that bridge from Jabber into other IM systems. A typical jabber identifier may look like:
Which means send a message to "iain" at the Jabber domain "shigeoka.com". Most transports use a simple naming convention to rewrite IDs intended for foreign systems:
for example may indicate to the server that you want to send a message to screen name "iain" in the "AIM" transport located at "shigeoka.com". Jabber clients don't see any difference between a native and non-native IM message or user (although smart clients can query the server for gateway information, and may indicate foreign IM users with special icons).
If the protocols for the foreign IM system are well document and open, Jabber can and does provide excellent interoperability. IRC for example is very well supported.
Interop problems emerge when trying to access proprietary networks. Some tolerate reverse engineering (like yahoo) and others actively fight Jabber transports (like AIM).
For a while, I was seeing new Jabber transports coming out almost daily to adjust to AOL changes to AIM specifically targetted at blocking Jabber servers. Things have settled down now with AOL mostly doing server blacklisting on anyone bridging too many users into AIM, and most Jabber developers recognizing AOLs desire not to be accessed.
    Bookmark Topic Watch Topic
  • New Topic