I was looking at using Faye for a project I've been working on since socket.io has been causing me trouble. I set up and played with some of the examples on their github and found that clients can publish straight to whatever room they are connected to. This is different behavior than what I would like. I want to limit client behavior in certain rooms to where they cannot publish at all but the server will periodically send data to the room updating them all on new information (Basically a strict subscribe behavior on certain rooms). Is this type of behavior possible with Faye or am I barking up the wrong tree?
With CometD, you can fine tune the behaviour you want.
You have available a SecurityPolicy that allow you to control coarsely the publish authorizations, and channel Authorizers that allow you to control finely the publish authorizations (among others).
Have a read at the SecurityPolicy documentation, and at the Authorizers documentation.
The Bayeux protocol has been designed by the CometD project where you can find the latest specification.
Have also a look at the CometD tutorials, if you want to get started with CometD.
Related
This is what I want
A user(bot) that always shows status Online
When a message comes for the user, I will hit a webhook associated with the user
The response from the webhook request will be sent as reply to the sender
This user will be able to intercept any message (let's say for profanity moderation)
This user will be able to send message to anyone (let's say broadcast)
This user will come in every users roster as default(like echo bot of skype)
I can't seem to find any resource on how to achieve this. I've found a way to intercept the incoming packet in openfire but I don't see any easy way to do this with MongooseIM. I haven't started diving deep into the source code yet, still looking for a way to do this without touching the source code and locking myself to a specific version of MongooseIM.
Disclaimer: I'm on the MongooseIM core team.
There are multiple ways this could be achieved. The easiest way to achieve this depends on your familiarity with Erlang, the programming language MongooseIM is written in.
You won't need any Erlang to use the event pusher module with its HTTP backend and the default settings, but you'd need some Erlang to control what messages get forwarded to the HTTP service or to make more complex setups. To send messages back, you'd either need to use the MongooseIM REST API or connect as an ordinary XMPP client to the server using one of the many XMPP libs available out there. This is probably the best approach to achieve your goal.
You can skip using the event pusher and just connect your bot as an XMPP client written in any language whatsoever. The bot might have your business logic within or can forward messages it gets to the HTTP service.
If you're comfortable working in Erlang, then the mechanism to extend the server is called Hooks and handlers and is described in the official MongooseIM documentation. This requires writing code in Erlang and building from source, but does not necessarily require modifying upstream MongooseIM code.
You could use the XMPP component protocol, which allows to extend the functionality of an XMPP server, yet structure it as multiple services. The components may be written in any technology you want and the most popular XMPP libraries should support the component protocol out of the box.
Depending on your choice from the above list and the language and environment you prefer, you might have to pick an XMPP library to use. There are XMPP libs available for iOS (ObjC and Swift), Android (Java and Kotlin), Python, JavaScript, C, and even some emerging ones for Rust, Dart and possibly more.
I'm a PHP developer with a lack of experience on other sever side langages.
I’d like you to give me leads, advice, keywords or whatever that could help me refine my research better.
What I want to do is basically to create a one to one mobile app chat that will scale.
There will be channels of 3 users: User A, User B and the "computer" pushing some messages according to some channels informations like the last time a message has been sent, etc.
User A should know if User B is online, writing, etc.
Every conversation should be stored in a database and would be analyzed by some algorithms. Those algorithms would also analyzed stuffs on user Facebook open graph.
The application should be able to send notification on IOS and Android.
A web administration should allow admin to set some stuff that will define what kind of message would be sent by the "computer".
I'v read lot of posts about websocket, xmpp, node.js, socket.io, etc but I don't have enough knowledge in those areas to decide what architecture should I build to make everything works together. Or maybe there is some cloud base solutions that would fit my needs...
Thanks
As you've stated there are many ways to implement that kind of structure but I am going to write about node.js + socket.io part;
1) It is scalable. You can use cluster, nginx, haproxy. etc. to apply load balancing to your socket.io application (see here) Of course you've to use redis or mongo or some kind of store for socket.io that different servers and processes can communicate each other. (see here)
2) socket.io have rooms. That means clients and any computer bots can join that room to share events with each other. So, in your scenario User A, User B and a computer bot should join to same room and events sent to that room will be broadcasted to every room member. (events can vary as online, typing, new message, anything) (see here)
3) node.js can send push notifications both for iOS and Android.
4) You can write every message to database of your choice on new message event.
5) You can create a REST api with Express framework for your Administration page. And you can use passport for authentication and authorization purposes. You can consume the rest api with Jquery or some other frontend framework like React etc.
Meteor is very well suited for something like this and gives you everything you need. There are also open sourced chat systems built with meteor already to get an idea of where you need to go. The more custom route would be to do what #cdagli said.
How do I correctly set up a publisher-subscriber architecture with multiple subscribers (which all receive a published message) using MassTransit and MSMQ.
Note that I do not want to use the MSMQ multicast feature as it is a bit flaky and relies on PGM (which has some restrictions of its own).
I have read this, this and this but still cannot figure out how I should setup
the subscription service,
a publisher,
and a couple of subscribers.
In particular the sbc.UseSubscriptionService("uri"); which is used in many examples is now obsolete (I am using MassTransit 2.7). The obsolete comment says The extension method on UseMsmq should be used instaed, but I cannot find such a method.
How are we supposed to setup up the subscription service?
The Distributor sample on the MassTransit Github page gets closest to what I want but it sets up consuming subscribers.
Please point me to or provide a example of how to setup a publisher-subscriber architecture where multiple subscribers are possible.
Thanks for your time.
To use the UseSubscriptionService extension method you need to import the MSMQ configuration namespace.
Imports MassTransit.Transports.Msmq.Configuration
you can now write this (VB.Net)
sbc.UseMsmq(Sub(c)
c.UseSubscriptionService(ConfigurationManager.AppSettings("MassTransit_SubscriptionService"))
End Sub)
That's for configuring the Service, but in order to make everything work correctly (using MSMQ) you need to have the MassTransit Runtime Service running (latest version available from GitHub MassTransit Runtime Services; you'll need this one instead of the one available from the binaries on the MassTransit website, those are outdated).
Once you have downloaded the source, you should run SetupSQLServer.sql first.
Next is adjusting the config file to point to your database and use the correct credentials.
You should now run this program (as console during dev, but best installed as windows service in non-dev environments). Make sure the console is before starting your publishers/subscribers since they depend on this 'service'.
I have just now realized a fully functional setup and experienced my moment of bliss. I intend to do a full write-up of all my steps, but I hope this helps a bit already.
This article explains the setup of the Runtimeservice in a little more detail.
I think "sets up consuming subscribers" is the give away as to the source of your difficulty - all subscribers are "consuming subscribers".
The best way to think about MassTransit is in terms of fan-out: MassTransit maintains routes to all consumers interested in certain type of message. You setup one or more consumer at one or more endpoints and MassTransit makes sure a copy of the message gets to each consumer.
Distributor is actually a specialized case where this is intentionally not true and not one you should be looking at, unless you're interested in load-balancing.
Here's the relevant docs link: http://docs.masstransit-project.com/en/master/overview/publishing.html#plain-msmq
I am not sure if pubsub or multiuserchat is the way to go?
What I think I need is pubsub, but with the added ability for subscribers to broadcast messages to the feed as well. Bidirectional information flow, if you will.
The use case is such that subscribers will be subscribed to on average 1000 different feeds, but each individual feed only broadcasts information on average once per week. So, lots of feeds, but low activity in each one. However, b/c there are 1000 different active subscriptions, a subscriber might still be notified of 100 messages per day, and they should be able to "reply" aka post content to any one of those feeds.
It seems like what I need is a pubsub/multiuserchat hybrid. But that doesn't exist, or does it? Any ideas or pointers?
Thanks a bunch!
If a subscriber is publishing data then they are not just a subscriber, they are a publisher. And there is no reason the same entity can't be a publisher and a subscriber at the same time.
As for your more general question about pubsub vs. MUC, that's a question that I find comes up a lot nowadays.
Obviously at first glance MUC and pubsub are very similar, they are both about broadcasting to a group. Many applications could easily use one or the other with no trouble.
To help decide which fits best with your applications, let's go through some of the differences between the two protocols.
MUC:
Is absolutely good for standard chatrooms of online users communicating with each other. If this is what you're doing, use it.
Includes presence, i.e. notifying other occupants about joining, leaving and changing status.
Allows for anonymous private communication between occupants.
Works out of the box with practically any standard XMPP client (for standard chat messages).
Automatic leaving of the room when the user goes offline or disconnects.
Messages with custom payloads are supported, meaning you are limited to routing standard chat messages.
Pubsub:
One or a few publishers transmitting to many read-only subscribers is core pubsub territory. In contrast to MUC the subscribers are not publishing, and are not receiving information about other subscribers.
Server implementations tend to have much more flexible access control for pubsub.
Custom payloads only, no standard chat messages.
Optionally has full item persistence.
A node can be managed as a list of items (ie. add/remove with notification) rather than just simple broadcast.
Subscriptions can persist through being offline.
The points above are just a guide. A lot can typically be achieved through server configuration. As an example, the MUC specification allows for rooms withholding presence broadcasts for certain classes of occupants based on configuration. The catch here is in the implementations... since this is an uncommon usage of MUC, you will find it may not be supported in many MUC implementations. The point being that as MUC was designed for chatting and not generic pubsub, you will largely find all the implementations and tooling around MUC to focus on that kind usage.
Not sure what the problem is. The subscriber simply needs to be a publisher as well. There is nothing stopping them from publishing as well as subscribing (unless the nodes are configured to disallow it).
This appears to be a very typical pubsub case.
I'm trying to design an application based on the OpenSocial API, and I'm uncertain of how the pubsub apparatus will work. This appears to be analogous to a Unix pipe, or perhaps an RSS feed.
Is a channel persistent across browsers / computers? That is, can I subscribe to channel "x" on browser A and publish to "x" on browser B, and have this data be read in browser A? If not, is there a convenient opensocial method of accomplishing the same thing?
Also: if one gadget subscribes to a channel after data is published, can that data still be read?
Pubsub is an API feature that allows different OpenSocial gadgets to talk to one another while being on the same page in an OpenSocial container.
That means the connection is not persistent, but if for example you have a map gadget, and a gadget with a list of restaurants which both appear in a page, this mechanism can enable the list to stay relevant to the currently shown area of the map.
This would require the two gadgets to agree on a message format and channel ahead of time.