Project

General

Profile

How to send message from Server to Client

John Catron
Added about 5 years ago

Hey! We are working on creating a 'roster-reload' packet to trigger a roster push for all users when the DynamicRoster list shows it has a change.

I was wondering What information we need to send a message from server to a user and how to do this.

Can i just build the Packet object and pass it to some static method on some class?

Do i need the user's session so that I can get the stanzaID for the next message or can i just put a random # here since we have a processor which will catch the packet server-side so client never receives it?


Replies (3)

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam about 5 years ago

There is no spec or XMPP extension for this right now so anything you do would be a custom thing anyway. You could actually do it in 2 possible ways:

  1. Send a notification to a client to ask the client to simply request a new roster from the server - client pulls a new roster (using roster version you can optimize it for retrieving roster only if it has changed)

  2. Make the server to simply push the roster to a user (again you can optimize it somehow to push roster only if it has been changed)

The first approach has some advantages:

  1. Make the client pull the new roster:

    1. You do not need any custom modification on the server, you just make the client pull the roster in a normal way
    2. You can send the notification from any XMPP entity (an XMPP bot - more or less standard XMPP client, or a custom XMPP component, PubSub, .....)
    3. The notification can be a completely custom IQ packet or something based on existing roster IQ:
<iq type='set' from='server' to='user' id='some id' xmlns='jabber:client'>
 <query xmlns='jabber:iq:roster'>
    <reload xmlns='roster:notification'>
  </query>
</iq>

The second approach has following advantages:

  1. Push the roster from the server to a client

    1. No need for any custom code or logic on the client side, so compatible with all standard XMPP clients

This approach just needs a custom logic on the server which would trigger a roster reload and push to the client. The custom logic could be actually an admin ad-hoc command - a loadable script on the server. So basically you do not even need to change the Tigase base code.

Added by John Catron about 5 years ago

Yes so we are already doing the 2nd option here.

We are executing a roster-push to the users but this means we need to be within the user's session since RFC mandates a roster set has to come from yourself.

In order to get to each individual user's session we are essentially implementing a pub/sub model via XMPP packets.

Desired flow:

Backend updates.

Triggers our new push code.

New push code builds a 'roster-reload' packet and sends it to each member of the DynamicRoster (publish)

We intercept the 'roster-reload' packet on the user's behalf during processing. (subscribe)

This means we are now inside each individual user's session and can run the roster set operation.

The issue is the 'publish' section here. We don't know how to send the packet we have built so that it goes to the user's in the list so that our processor can catch it.

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam about 5 years ago

You should really look at the admin ad-hoc commands framework. There are even commands/scripts for roster processing already. The admin command can access user's session and can push a packet for on the user behalf. Existing commands can already change user's roster and update it to offline storage and push the change to user's online connections.

I suppose your roster push-only version would be much simplified script of what is already there.

The admin ad-hoc command (script) is usually executed through a standard client/user connection, but just need to be an account with admin permissions. One of possible approach is to use our command line tool for executing admin tasks, or another would be to write an XMPP bot which could collect data from your system and execute admin commands on the Tigase server.

    (1-3/3)