File transfer to a multi user chat
By mridul on Nov 17, 2006
Background.When a user wants to chat with his contact, typically he does so with one to one messages - that is, he sends a <message /> with the to set explictly to the reciepent. Now, suppose he invites another contact into this chat : it ceases to be a one to one chat - there is an xmpp protocol extension for multi user chat (muc) defined for this.
In most clients, like ours, there is no visible difference in both usecases : the client upgrades the one to one chat to a private conference behind the scenes and things continue from there.
Actually in our client, there is no visible difference between a private one to one chat, a private conference or a public conference - the UI is consistent across all these usecases.
The problemUnfortunately, functionality is not strictly the same ... and one of the key areas where this affects is in file transfer : something which users are used to. Currently, there are a number of ways defined on how to negotiate file transfer between two entities - how to negotiate the parameters, how to do the actual transfer - peer to peer/inband, etc.
But when it comes to file transfer in a muc, there is no standard extension or proposal.
This does not mean that file transfer is not supported at all - it just means that there is no standard way to support this.
For more than a year now, our client and server has been supporting filetransfer even in the case of conferences.
The problem is that, this works only with our client and server - as there is no standard in this space, none of the other clients can interoperate with our clients when it comes to this feature.
RequirementsLet us look at a minimal set of requirements :
- Different clients used by the participants in a conference might support different set of file transfer profiles. Hence, there need not be a intersection of transfer profile supported by all.
- If a single client is to multicast the file to all the participants, the bandwidth requirements could choke it.
- The server might want to decide who gets the files in a conference, and might want means to enforce this. Ditto for who can send a file, file properties, etc.
Potential solution ?I am not discribing what we support, but thinking of a really simple solution.
What could be done is :
- XMPP Server has an affiliated 'hosting service' - say a http,
ftp, etc server : on which it has reasonably high control. Let us
assume HTTP service in
- This service is not browsable, so you cannot get listing of
files - similarly, it must not be possible to easily guess/find
arbitrary files from this store - unless the server has divulged the URI to you.
Hence URI's generated should also be opqaue and non-guessable to a reasonable degree.
- When client wants to send a file to a conference, it will negotiate with the room - not with the participants.
- If transfer is to be allowed, the room will assign the client a
URI to PUT
the file to. Also, it might
give it some sort of authorization
credentials to be used at the HTTP service.
- Once the client has transferred the file to the URI, it will
notify the room - which in turn will multicast the location of the file
at this URI to required participants (along with creds to fetch it, if any) : the sender would be specified as the initial user.
- The participant clients will use GET to pick up the file from this service - while using the passed on creds.This way, even if you guess the URI, you will need to also guess the creds to retrieve it.
- After successful transfer, participant clients would notify the room of completion. A file could get purged when all participants have downloaded it, or if some room configured timeout expires - need not be a pro-active cleanup, but possibility of cleanup after both could be high (impl detail actually).
The caveats are obvious :
- We are introducing a new form of file transfer profile - though we are using HTTP above, it is still a new mechanism !
- You are going to have N participants per conference hitting this service for the file - so the service should be able to scale well, in terms of client connections and bandwidth. Might not really be a concern for modern webservers though.
- Associating URI based credentials might not be that simple : especially if you consider the tie-in required with the XMPP server for achieving this at runtime (PUT, GET creds) : can it be done ? Ofcourse it can be - out of the box support exists ? I am not very sure if it does.
- You might need some mechanism to clean/purge stale files from the
Comments, suggestions ?