I want to use PubNub's Java client (publish/subscribe) with a chat-engine Angular client. The only material I could find on how what to accomplish this was this page in the wiki which describes the channel structure. After attempting to subscribe/publish on every combination of their channel structure as synonymous with a direct message, eg: globalChannel + '#user#' + myUUID + '#write.*', I could not get a chat-engine client and a pub/sub client to communicate. Has anyone been able to do this successfully? Is the channel structure actually different? Are their limitations due to the lack of invitations? I have the clients detecting each other's presence, so I can't imagine I'm far.
I decided on a workaround. Instead of direct chat, you can create a 2 person private channel with chat-engine (say channelName) and can subscribe in java with "chat-engine#chat#private.#" + channelName. This isn't direct messaging but should be functionally similar.
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 want to use mediasoup server from flutter app for two use cases.
Send stream to server to record on the server side (preferring ffmpeg).
One on one or small groups up to 4 live video chats.
I would like to start with the simple option which is single stream sent to server, and for that I want to use https://github.com/ethand91/mediasoup3-record-demo as reference.
My problem is that mediasoup is not using standard offer and answer flow as I know and used to when implementing webRTC clients and in all mediasoup examples they use mediasoup-client that in fact using rtpCapabilities instead of the commonly used SDP format.
I did find this good intention repo: https://github.com/cloudwebrtc/flutter-mediasoup-client
But so far it looks like intention only.
So my question is, what's the flow I should use in order to privide the client side application with SDP, or how can I get SDP format from mediasoup transport and router rtpCapabilities.
Also, if I build the SDP myself, what should be the flow?
client-> connect ->server
server-> create-transport ->client
client-> connect-transport ->server
server-> create-producer(router rtpParameters translated to sdp offer) ->client
client-> produce(sdp answerr translated to producer rtpParameters) ->server
Does it make sense?
Any different approach also will be appreciated.
Thanks.
Use the mediasoup forum if you want authors of mediasoup to answer. We do not use Stack Overflow:
https://mediasoup.discourse.group
I started to implement it myself:
https://github.com/tan-tan-kanarek/flutter-mediasoup-client
I find that the dart webRtc stream is not giving me all the info I need regarding encoding and tracks separation.
Help will be appreciated.
Mate, you need walk through on mediasoup... you can start with javascript basics and move on to flutter as basic just works on all platform
this youtube channel is very useful on mediasoup Amir
In the article http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.html the author describes:
Often with PubSub, developers feel the need to create a channel per user in order to deliver private messages to a client. For example, if a trading system wants to notify a user of completed trades, the temptation is to create a channel like /trades/a_user_id and each user will subscribe to their own channel. This approach works, but is not the most resource sensible way of solving this issue and requires security code to prevent unauthorized clients subscribing to other users channels.
What are the trade-offs between the service and broadcast channels to implement messages for a particular user? I understand the security aspect of the trade-off but what about resource overhead? I don't understand why there would be any more resources used with a broadcast channel than there would be for custom-routed service. If you could explain why one is better over the other for the use-case, rather than a blanket statement of being sensible or not, that could help lead me to a decision.
The article is pretty old, it refers to CometD 1 while we are now at CometD 3.
You may want to check updates on the CometD website and read the CometD 3 documentation.
The concepts behind broadcast vs service channels are still valid for CometD 3.
The server allocates data structures for every channel is created, being it a broadcast or service channel.
In the example from that article, it is compared creating N broadcast channels - one for each user_id, versus creating just one service channel. The former solution is obviously using more resources on the server than the latter, and it's subject to sneak peeking (a client can guess a user_id and subscribe to that channel, thus receiving messages that are destined to other users).
For this particular case, all the application needs to do is to deliver a message to a specific client. For this use case, it is better to use a service channel because it uses less resources (the same server-side channel can be used for all users, without the risk that a user receives messages not destined to him/her) and it is more secure.
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.
I have to develop a message bus for processes to send, receive messages from each other. Currently, we are running on Linux with the view of porting to other platforms later.
For this, I am using ZeroMQ over TCP. The pattern is PUB-SUB with a forwarder. My bus runs as a separate process and all clients connect to SUB port to receive messages and PUB to send messages. Each process subscribes to messages by a unique tag. A send call from a process sends messages to all. A receive call will fetch that process the messages marked with the tag of that process. This is working fine.
Now I need to wrap the ZeroMQ stuff. My clients only need to supply a unique tag. I need to maintain a global list of tags vs. ZeroMQ context and sockets details. When a client say,
initialize_comms("name"); the bus needs to check if this name is unique, create ZeroMQ contexts and sockets. Similarly, if a client say receive("name"); the bus needs to fetch messages with that tag.
To summarize the problems I am facing;
Is there anyway to achieve this using facilities provided by ZeroMQ?
Is ZeroMQ the right tool for this, or should I look for something like nanomsg?
Is PUB-SUB with forwarder the right pattern for this?
Or, am I missing something here?
Answers
Yes, ZeroMQ is capable of serving this need
Yes. ZeroMQ is a right tool ( rather a powerful tool-box of low-latency components ) for this. While nanomsg has a straight primitive for bus, the core distributed logic can be integrated in ZeroMQ framework
Yes & No. PUB-SUB as given above may serve for emulation of the "shout-cast"-to-bus and build on a SUB side-effect of using a subscription key(s). The WHOLE REST of the logic has to be re-thought and designed so as the whole scope of the fabrication meets your plans (ref. below). Also kindly bear in mind, that initial versions of ZeroMQ operated PUB/SUB primitive as "subscription filtering" of the incoming stream of messages being done on receiver side, so massive designs shall check against traffic-volumes / risk-of-flooding / process-inefficiency on the massive scale...
Yes. ZeroMQ is rather a well-tuned foundation of primitive elements ( as far as the architecture is discussed, not the power & performance thereof ) to build more clever, more robust & almost-linearly-scaleable Formal Communication Pattern(s). Do not get stuck to PUB/SUB or PAIR primitives once sketching Architecture. Any design will remain poor if one forgets where the True Powers comes from.
A good place to start a next step forward towards a scaleable & fault-resilient Bus
Thus a best next step one may do is IMHO to get a bit more global view, which may sound complicated for the first few things one tries to code with ZeroMQ, but if you at least jump to the page 265 of the Code Connected, Volume 1, if it were not the case of reading step-by-step thereto.
The fastest-ever learning-curve would be to have first an un-exposed view on the Fig.60 Republishing Updates and Fig.62 HA Clone Server pair for a possible High-availability approach and then go back to the roots, elements and details.
Here is what I ended up designing, if anyone is interested. Thanks everyone for the tips and pointers.
I have a message bus implemented using ZeroMQ (and CZMQ) running as a separate process.
The pattern is PUBLISHER-SUBSCRIBER with a LISTENER. They are connected using a PROXY.
In addition, there is a ROUTER invoked using a newly forked thread.
These three endpoints run on TCP and are bound to predefined ports which the clients know of.
PUBLISHER accepts all messages from clients.
SUBSCRIBER sends messages with a unique tag to the client who have subscribed to that tag.
LISTENER listens to all messages passing through. currently, this is for logging testing and purposes.
ROUTER provides a separate comms channel to clients. Messages such as control commands are directed here so that they will not get passed downstream.
Clients connect to,
PUBLISHER to send messages.
SUBSCRIBER to receive messages. Subscription is using unique tags.
ROUTER to send commands (check tag uniqueness etc.)
I am still doing implementation so there may be unseen problems, but right now it works fine. Also, there may be a more elegant way but I didn't want to throw away the PUB-SUB thing I had built.