Tuesday 26 June 2007

ejabberd's mod_muc with XEP33 support

I have improved mod_muc (ejabberd implementation of XEP-0045: Multi-User Chat) to use XEP-0033: Extended Stanza Addressing in certain situations. This is still preliminary code, and includes some ugly code. But it seems to work.

Of course I followed the Guidelines for Server Active Multicasting on XEP33.

As previously mentioned on Multi User Chat and Extended Stanza Addressing, improving room presence broadcasts to use XEP-33 will be a little difficult. So, for now I concentrated on the easiest and potentially more beneficial improvements: message broadcasts.

Publicado por badlop en 18:58 0 comentarios

Etiquetas: ,

Multi User Chat and Extended Stanza Addressing

A Multi-User Chat service sends a lot of similar messages to a lot of JIDs, so it would seem this service can bastly benefit if using Extended Stanza Addressing.

We can group the possible targets in:

  • Sending message broadcasts (section 7.9 of XEP-45)
  • Sending system advisories: change on subject, change on room configuration, system messages (sections 8.1, 10.9)
  • Sending presence broadcasts: join, leave, nick change, granting/removing privileges... (sections 7.1.3, 7.2, 7.3, 7.4, 8.2, 8.3, 8.4, 8.5, 9.1, 9.2, 9.3...)
Upgrading a MUC service to send message broadcasts and system message broadcasts using a multicast service (XEP-33) is easy, since the exact same message stanza is sent to all the room occupants.

However, presence broadcasts are slightly different depending on the room configuration and the destination role and affiliation: on some cases the presence stanza includes additional attributes (jid). So, upgrading a MUC service to send presence broadcasts using a multicast service is slightly more complicated.

Publicado por badlop en 18:12 0 comentarios

Etiquetas: ,

Monday 25 June 2007

Guidelines for Server Active Multicasting on XEP33

Jabber servers and components sometimes send the same stanza to several destinations. Using XEP33 on such situations they could save traffic. I'll now provide some guidelines to implement that feature.

Guidelines

1. If there's a local multicast service, the sender SHOULD send a single stanza with an 'addresses' element as described on XEP33. If no local multicast is available, obviously it MUST send multiple stanzas as usual.

2. Each desired destination address must be included as an 'address' element, as a child of the 'addresses' element, as described on XEP33.

3. All the 'address' elements MUST include the attribute 'jid'. It is not allowed to use the attribute 'uri'.

4. All the 'address' elements MUST include the attribute 'type' with value 'bcc'. It is not allowed to put any other value on this attribute.

5. All the 'address' elements SHOULD NOT include any other attribute, since they will never be presented to the destination entity.


Example

On this example I'll show how a MUC service that follows the proposed guidelines sends a message to all the occupants of a room.

Scenario

On this example, I suppose those JIDs, which are described on
XEP45 sec. 4.3:

  • the Jabber server: shakespeare.lit
  • the multicast service: multicast.shakespeare.lit
  • the MUC service: macbeth.shakespeare.lit
  • the room: darkcave@macbeth.shakespeare.lit
  • the room occupants:
    • crone1@shakespeare.lit/desktop
    • wiccarocks@shakespeare.lit/laptop
    • hag66@shakespeare.lit/pda
Without XEP33

The section 7.9 Sending a Message to All Occupants on XEP45 shows a room occupant that sends a message to the room. Then, the MUC service sends this message to all the room occupants.

The example 60 shows the three stanzas sent by the MUC service to the room occupants:
<message
  from='darkcave@macbeth.shakespeare.lit/thirdwitch'
  to='crone1@shakespeare.lit/desktop'
  type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>

<message
  from='darkcave@macbeth.shakespeare.lit/thirdwitch'
  to='wiccarocks@shakespeare.lit/laptop'
  type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>

<message
  from='darkcave@macbeth.shakespeare.lit/thirdwitch'
  to='hag66@shakespeare.lit/pda'
  type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>


With XEP33

If the MUC service supports XEP33, instead of sending three similar stanzas it sends only one to the multicast service:

<message
  from='darkcave@macbeth.shakespeare.lit/thirdwitch'
  to='multicast.shakespeare.lit'
  type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<addresses xmlns='http://jabber.org/protocol/address'>
   <address type='bcc' jid='crone1@shakespeare.lit/desktop'/>
   <address type='bcc' jid='wiccarocks@shakespeare.lit/laptop'/>
   <address type='bcc' jid='hag66@shakespeare.lit/pda'/>
</addresses>
</message>

Publicado por badlop en 19:38 0 comentarios

Etiquetas: ,

Sunday 24 June 2007

XEP33 and Server Active Multicasting

XEP-0033: Extended Stanza Addressing specifies how Jabber entities can define multiple destination addresses on a XMPP stanza.

This is interesting when a user wants the destinations to know that he sent the same message to all the other destinations (Carbon Copy), or to send a copy to a supervising user (Blind Carbon Copy). The current version of XEP33 explains this basic usage, including an example.

XEP33 can also be used by Jabber servers, MUC services... to reduce bandwidth consumption. This possibility is hinted on the introduction of XEP33, but is not further described on the content of the document. I call this usage Server Active Multicasting, since the server (or a server component) is actively determined to use multicasting, and instead of sending individual stanzas to each destination, tries to send stanzas to groups of users.

There are many opportunities on the server side to use XEP33 to reduce traffic, for example:

  • On the Jabber/XMPP server: to send presence changes
  • MUC service: to send chatroom messages, subject changes, presence changes, join, leaves, nick changes...
  • Pubsub/PEP service
  • Subscription/group list service
  • RSS transport
As part of my GSoC project, my next steps are to define some guidelines to implement
Server Active Multicasting. And of course implement this on ejabberd.

Publicado por badlop en 18:27 0 comentarios

Etiquetas: ,

Tuesday 19 June 2007

mod_multicast: completed XEP33 support

During the past week I fixed several small problems on the source code of mod_multicast:

  • Periodically remove from the cache those items that are really old.
  • If the packet has wrong xmlns, no 'addresses' or no 'address', it now rejects to process the packet and reports an error to the sender.
  • Fixed reception of IQ Query packets. This topic deserves a blog post, even a documentation section.
  • Added support for XEP-0092: Software Version. Currently it shows the SVN revision.
  • I verified that mod_multicast does not interfere with Privacy Lists. I initially thought that problem could appear when sending a multicast packet internally on ejabberd. Actually, everything seems to work correctly.
So now I consider the implementation of mod_multicast to be completed. At least it supports XEP-33 v1.1.

The next steps are: active server multicast, and abuse/spam prevention.

Publicado por badlop en 19:29 0 comentarios

Etiquetas: ,

Saturday 16 June 2007

Packet Relay? No, thanks

During my development of a multicast service for ejabberd that implements XEP33: Extended Stanza Addressing, I found a phrase that catch my attention:

The server MAY choose to limit whether non-local servers can send address headers that require the local server to send to third parties (relaying).
Packet relay: server A wants to send a packet to server B. Instead of simply doing that, he sends a packet to server C requesting him to resend it (relay it) to server B.

Why should a public Jabber server accept orders from another Jabber server to send packets to a third Jabber server?

This feature may or may not be useful on open networks (like the XMPP Federation), and may or may not on private networks. But I think that packet relay does not solve any critical problem right now, and instead it brings many new undesired problems.

Just to name one problem related to packet relay: abuse to send spam. You just need to see what happened to email relay.

I've removed all support for packet relay on my implementation for ejabberd. I proposed to describe packet relay support as an optional feature on XEP33, and discourage its usage on open networks.

If a server developer wants to implement it, ok, implement it. If a Jabber server admin needs that feature for some reason on his private network, ok, enable it. But I think there are more important features that I must implement during this GSoC project than packet relay.

Please post a comment if you would like to have packet relay support on ejabberd's multicast service. If so, explain why you find that feature useful.

Related links: MUC logs.

Publicado por badlop en 18:24 1 comentarios

Etiquetas: ,

Saturday 9 June 2007

Extended Stanza Addressing: initial commit to SVN

I've sent to ejabberd-modules SVN the initial commit of mod_multicast, the module for ejabberd that implements Extended Stanza Addressing (XEP-33).

It's an independent component. It only acts passively: when a user or server sends a packet, it checks and routes.

This version implements almost all the tasks described on the protocol: wait for packets, query other servers and components for support, cache responses, verify age of cache responses, check packet syntax and route to final destinations, either local or remote.

I think the only missing feature is to clean the cache every X time. After that, I want to verify the access control works correctly both for local users and remote users/servers.

Implementing XEP33 is not the end of my project. It seems that's only the beginning: that XEP needs some parts to be rewritten, and several aspects to be added. For example, error reporting; how exactly to use with MUC and Pub-Sub.

There isn't yet a public dummy server where people can try the implementation. For now, you can get the code from SVN, compile, install on your ejabberd server and try. Please don't use this on a production server! Tobias Markmann has already commented that will try it. /me crosses fingers.

Publicado por badlop en 00:17 0 comentarios

Etiquetas: ,

Subscribe to: Posts (Atom)