I am using Autobahn to broadcast messages to subscribed clients. However, when a client is NOT connected to the Internet, it is still necessary that they receive the messages when they reconnect. Will I need to use something like RabbitMQ to accomplish this or can Autobahn handle this natively?
AutobahnPython does not persist messages. Retrieval of message history is an upcoming feature in WAMPv2, and a broker with message persistence will be available as part of Crossbar.io.
Disclosure: I am original author of Autobahn, WAMP and Crossbar.io, and work for Tavendo.
Related
Situation
Am trying to build a real-time chat toy app using the following technology stack
RethinkDB
Laravel 5
Ratchet
What I perceive to be the conceptual situation
The green arrows represent the real-time exchange of data.
The black arrows represent other non real-time requests and exchange of data.
My question
I was wondering if my understanding of the implementation of chat using the technology stack is correct based on the diagram?
if there are inaccuracies, what would they be?
Your interpretation seems correct, although I would not suggest using the websocket to send data to but only to distribute live data to all subscribers of a channel.
To do this, get an API(preferably) going to receive new posts/chats/users.
And use a push server to send the data received to the socket.
A push server is just an in between of the app and websocket that allows php(laravel) to access the socket easily.
Edit: to elaborate
To retry explaining this to you.
All clients listen to the WebScoket Server. This is a connection which is passive and they will only receive messages from the socket according to what topics/subscriptions they have.
When someone wants to send a message(in case of a chat application) they send it to an API to check if the right user sent it, maybe even use apikeys or other means of security.
Once the message is received in the API then the API wants to distribite it to all listening clients for that chat room/topic/subscription.
So the message is forwarded to the pushserver which is an in between of the backend (API, controllers) and the WebSocket (subscriptions, topics).
The pushserver forwards the message to the WebSocket afterwards and then the WebSocket distibutes the message to the correct listeners.
Advantages of using an API:
Security
Scalability
Me and my friend having a little bit of a problem using websockets, I'll quickly explain so we maybe could get it working.
We got a websocket server up and running and its doing fine, lisening to a specific port and connects all our clients as it should.
But we would like to have channels. For an example: http://www.example.com/channel/682831
And we can't figure out how to solve that, because right now its like "broadcasting" and we would more likely have "multicasting"
where we could say this message is going there and this message is going here.
So please help us.
Thanks!
WebSocket provides point-to-point raw messaging. What you describe usually runs under the term "Publish & Subscribe".
A subscriber signals it's interest in a topic, publisher send events to that topic, and a broker dispatches events to the right clients based on a book of subscriptions it maintains.
This needs to be layered on top of WebSocket. You might have a look at WAMP, an open standard WebSocket based protocol that provides Publish & Subscribe (as well as Remote Procedure Calls).
Disclosure: I am original author of WAMP (now an open community effort) and work for Tavendo.
Using kaazing jms demo with AMQP 1.0 AND ActiveMQ
https://demo.kaazing.com/demo/jms/javascript/jms-javascript.html
Register/Subscribe to new Queue and process it for application server and send message back to client[kaazing] from application server.However, client subscribed to same queue did not received any message, any reason why?
I assume you're trying to use two browsers clients: a publisher and a subscriber. I just tested it, and it works fine on the URL you provided above.
A while back I published a 6-minute screencast of the steps. You can see the messages flying back-and-forth at around 3:30.
I'm working with the stomp protocol using the active mq implementation as stomp server/broker. I would like to have a message queue for a stomp client, that can be filled while the client is offline so that when the client connects from time to time it can fetch the massages that have been deposited while it was offline.
As I read, this can be achived with simple subscription or durable subscription. I decided for durable subscription. Is this the right way?
Then I was wondering wich messages and headers I should use on the client side. Actually I'm using the following
CONNECT
login:
passcode:
client-id: some_mac_adr
SUBSCRIBE
destination: /queue/some_mac_adr
receipt: receipt-msg
durable-subscriber-name: default
now waiting for messages
timeout -->
DISCONNECT
Is this message sequence correct? I'm furthermore not using the unsubscribe command. Is this correct as well?
I decided for durable subscription. Is this the right way?
Queues are durable by default so you do not have to make the consumer durable explicitly.
Regarding the headers, as I said, since you do not need to make the consumer durable, you can avoid passing the durable-subscriber-name header. And, not sure if this was incidental, but you do not need to keep the queue name and client-id same.
BTW, which language you are using? STOMP implementations in different languages should take care of reasonable defaults so you do not need to worry about headers for CONNECT, SUBSCRIBE, etc.
I'm furthermore not using the unsubscribe command. Is this correct as well?
Again, unsubscribe() does not make much difference for the queues but it's cleaner to unsubscribe when the consumer is done with its job.
I hope that helps your case.
I'm looking forward to develop a realtime API for my web application using Websocket. For this I'm using RabbitMQ as the broker and My backend is based on python (gevent + websocket),and Pika/Puka as rabbitmq client.
The problem I'm facing here is that, how we can use websocket to connect with rabbitMQ. After the initial websocket connection establishment, the socket object wait for new messages from client, and in the case of rabbitMQ, we need to setup a consumer for it, so it will process the message when it receive one. We can take this in this way,
Clients are established connection with server via full-duplex websocket.
All clients should act as RabbitMQ's consumer after initial websocket handshake, so they all get updates when a client gets some message.
When new message arrives at websocket, that client will send it to RabbitMQ, so at this time this client act as publisher.
The problem is Websocket wait for a new message, and the RabbitMQ consumer wait for new message on its channel, I'm failed to link these two cases.
I'm not sure whether this is a wrong method ...
I'm unable to find a method to implement this scenario.If I'm going wrong way or is there any alternate method ?, please help me to fix this.
Thank you,
Haridas N.
I implemented similar requirement with Tornado + websocket + RabbitMQ + Pika.
I think this were already known method. Here is my git repo for this web chat application.
https://github.com/haridas/RabbitChat
It seems very difficult to the similar thing with gevent/twisted because the rabbitMQ clients couldn't supporting the event loops of gevent/twisted.
The pika has tornado adapter, so that makes this easy to setup. Pika development team working on the twisted adapter also. I hope they will release it very soon.
Thanks,
Haridas N.
http://haridas.in.
A simple solution would be to use gevent.queue.Queue instances for inter-greenlet communication.