Wednesday Aug 08, 2007

File transfer to an MUC

We recently submitted a proposal to XSF to standardize what was a proprietary implementation for message moderation ... which we have had for a couple of years now. The other effort which we should probably kick off soon is file transfer to multi-user chat room - this is another custom implementation which we have been carrying on for a few releases now ...
This has come up time and again in JIG as part of other threads, and yet we never got much farther that 'yep, we should document it'. I know of atleast one other server who have their own implementation to support this .... so maybe it is time we standardized this !
To give a basic idea of what we do:
Currently, our client supports IBB - so does the server, and the muc (which is part of the server). So idea is simple - essentially stream the data from the client to the server, store it locally (if content filtering, etc is enabled) post-process it (if enabled), and then the component streams it to the recipients.
As all the participants who can understand this are Sun IM clients - we just use IBB for now.
The caveats are obvious - potentially very heavy server traffic due to the IBB. But the main advantages are:
  1. The sender transmits only a single copy of the file - in comparison to a p2p model (imagine streaming a 512 KB file to a muc with 100 participants from a moderately low b/w connection).
  2. It will always work for all cases - irrespective of firewall, nat, etc. IBB is the lowest common denominator.
  3. Ability to analyze the content before sending it on to the recipients - including the possibility of archiving it (for participants who might join the room 'later').
There are ofcourse other means of achieving the same while satisfying the requirements above - including other means of file transfer which are yet to be standardized (custom, future additions).
File transfer in general was unfortunately not a very strong point in xmpp, and we are still working on the details ... so I am not very sure if we have to wait for the churn to subside, before proceeding - or start work on this in parallel, so that the requirements for multicasting file(s) to a room are kept in mind while tackling the file transfer problem.

Saturday Jul 28, 2007

Message moderation specs

We recently submitted two proposals for message moderation - Message Moderated Conferences and Managing message moderators in MUC rooms - both of which are extensions to Multi-User Chat (muc) spec.
Taken together, they allow a message moderation system to be put in place. It has been a conscious decision not to introduce another set of acl's for this, but to reuse the affiliations and roles specified in muc. I will try to go through the basic intent and design decisions behind the specs.

Message Moderated Conferences

This proposal specifies how a conference which has message moderation enabled would interact with participants - particularly, participants who dont have 'voice' or the ability to post message to the room.
If message moderation is enabled, these occupants would be able to request the room for approving the messages they want to post - and on approval, room would publish them to all occupants of the room. Simple scenarios would be a celebrity chat, moderated webcast/presentation, etc.
The spec does not deal with how the message moderation happens - just the interaction between a occupant and the room - how they interact, state changes, notifications, etc. So in effect, you could have any number of backend moderation implementations - but the interface between the occupant and the room will remain the same.
The basic flow is as follows :
  1. Occupant sends message to room for approval.
  2. Room assigns a message id to the submitted message (which is then used to identify the submitted message for all further interaction, in this and other moderation related specs) and returns that to the user with message in pending state.
  3. After the backend moderation system decides on the message, room will inform the submitted about the 'decision' - approved, rejected (or error).
  4. If approved, room will then multicast it to all the occupants.
That is it !
The actual moderation might be quite involved, with multiple moderators/moderation modules chained, clustered/distributed rooms, etc in complex deployments - but the occupant will have a simple and clean interface to communicate with the room (room's bare jid actually).

The way we designed it, hopefully this will someday get rolled into XEP 45 itself :-)

Managing message moderators in MUC rooms

This spec defines one possible way in which message moderation can actually be implemented - where the moderation is done by participants who have sufficient rights (owner's and moderators of the room).
It defines how a room moderator/owner can become a message moderator (and other state changes), how they notify room of the moderation decision, and how the room is expected to manage these moderators and submitted messages for moderation.

Both of these specs are based on our implementation - though what we support currently is quite different from what we have submitted.

As a sidenote : It should be noted that, in both the specs we have tried to make sure that the interface between the various entities in question remains as simple as possible - while not precluding more complicated scenarios .. like usecases which are not specifically related to users chatting over a moderated conference (for example an approval workflow) - there could be custom configurations with extensions to room configurations which allow for more complicated scenarios while keeping the actual client interfaces (at both submitter and moderator side) constant.

Monday Mar 26, 2007

S2S connection availability & state recovery

some thoughts on xmpp s2s availability and failover : and lack of protocol support for it.[Read More]

Saturday Dec 16, 2006

In order delivery in xmpp servers

Discusses some rationale behind thoughts on why strict in order delivery maynot be a 'good thing'.[Read More]

Tuesday Nov 28, 2006

server pool and expirimental stuff

One of the things which we introduced with the previous interim release was the concept of server pool.The admin can have a combination of disparate set of boxes - solaris sparc/x86, linux and logically combine them to create a single XMPP deployment.Ofcourse, one deployment could support multiple hosted domains - so typically it is a single deployment : not really a single domain which is hosted on a pool.

For the purpose of minimising internode communication, we have also introduced to concept of an xmpp aware load balancer called redirect server.The actual redirection mechanism is an spi and can be customized, but there are a bunch of out of the box methods - including ones which allow for roster based logical grouping of contacts to nodes.The server pool will redistribute any new load across itself in the face of failures ... So, introducing redundency into the pool not only helps in performance of a single node under normal operation, but allows the pool to operate smoothly when you are faced with network, power, etc outages.

Taken together this results in some interesting usecases.
There is minimal network overhead and yet high degree of failover and scalability can be achieved - we have not really tested to reach the limits of how 'large' a server pool can be .... This essentially means that a service provider can not only support a large number of hosted domains, but also provide high availability for all of them with a single deployment.
As far as the end user is concerned, there is no difference whether he is talking to a server pool or to a single server: the behaviour is uniform and spec compliant.
If you consider the distributed nature of features like pubsub, muc, etc in the server pool - it essentially means that you do not have the concept of failure: unless every node in the pool goes down that is :-)
So essentially, you can use the server as a near-realtime messaging middleware with very high availability and scalability.

And yes, the next release we have does include expirimental support for caps and pep at the server and in client api ... might not be the latest version of the spec though. But developers wishing to hack at it are welcome : this impl is not very rigourously tested - so I am not going to popularise it :-), but we have used it for avataar and seen it working beautifully !
The api which is hosted at collab project of netbeans has the client side support for this (:pserver:anoncvs-AT-cvs.netbeans-DOT-org:/cvs , collab/service/src/org/netbeans)
Btw, did I mention that we have always supported privacy lists ?

Friday Nov 17, 2006

File transfer to a multi user chat

File transfer to a Multi user chat is not defined in the current set of xmpp extensions. Though this does not really describe what our server/client does today, this post discusses a simple means to achieve this required functionality.[Read More]

Wednesday Nov 15, 2006

Corner cases of presence probes in xmpp

Some random thoughts on presence probes in rfc 3921 and the xmpp bis specs ... just random rambling, I could be grossly wrong ![Read More]

Sunday Nov 12, 2006

Security improvements in upcoming Sun IM server release

A small summary of primary features to expect in security and authentication in the upcoming release of Sun's IM server[Read More]

Thursday Nov 09, 2006

Minimising S2S traffic in XMPP - elaboration , clarifications and corrections

Elaborated the idea posted in the previous post along with some clarifications and corrections.[Read More]

Wednesday Nov 08, 2006

Minimising S2S traffic in XMPP

Discusses a potential proposal we are considering to implement which will minimise the interserver traffic tremendously without compromising on security, responsibility and accountability.[Read More]



« February 2017

No bookmarks in folder