I am using MQTT.js library as a MQTT client in my node app.
I am using Qos 2.
I just need to know if there is any property that controls the number of messages to send at once to the Emq broker.
In low band width like 10kb/s my application not sending data to Emq (The data size for each message is 25kb and there will be only 10 packets every time in the outgoing store).
Related
I'm using the stomp-client library and i want to know if it is possible to know if the message was delivered to the queue. Because im implementing a java service to do the dequeue of the messages and an node js to send the messages to the queue. the code bellow shows how I send the message to the queue.
this._stompClient.publish('/queue/MessagesQueue', messageToPublish, { })
When you send a SEND frame (i.e. publish a message) you can add a receipt header and then when you receive the RECEIPT frame from the broker you know it has successfully received the message. The STOMP specification says this about the receipt header:
Any client frame other than CONNECT MAY specify a receipt header with an arbitrary value. This will cause the server to acknowledge receipt of the frame with a RECEIPT frame which contains the value of this header as the value of the receipt-id header in the RECEIPT frame.
However, looking at the documentation for stomp-client I don't see any mention of how to receive RECEIPT frames. I actually would expect the ability to specify a callback on the publish method which was called when the RECEIPT frame is received. It doesn't appear that stomp-client supports working with receipts. Unfortunately that means there's no real way to confirm the message was received by the broker.
I recommend you find a more mature STOMP client implementation that supports receipts. For example stomp-js supports receipts.
Running SS 4.0.54 at the moment and what I want to accomplish is to provide clients a service where by they can send one way HTTP requests.
The service itself is simple. For the message, open a DB connection and save some value.
What I don't want to have happen is I get a flood of requests within a minute and have to open up a 1000 connections to the DB.
Ideally the client would send their requests over HTTP and fill the queue. SS would then every X milliseconds or if MAX number of messages have been queued, send them to the service.
This way we don't have messages queued up for too long, and we only process X number of messages at a time.
I've looked through http://docs.servicestack.net/messaging but something isn't clicking.
The InMemoryTransientMessageService doesn't buffer, it processes the message as soon as it receives it. You'd need to use one of the other MQ Servers to have the requests published to dedicated queues in the configured MQ Broker which are then processed serially outside the context of the HTTP Request, the concurrency of which can be controlled using the threadCount when registering the handler.
When you have a MQ Server registered, any requests sent to using the SendOneWay API (or /oneway pre-defined route) are automatically published to the configured MQ Server.
How do I send my message that is published to a Redis channel only to subscribed server (which is connected to the subscriber) and not to my other servers (where the required subscriber isn't connected).
I'm using Socket.IO and Redis server.
Have you read the documentation?
not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into channels, without knowledge of what (if any) subscribers there may be
I other words, you cannot target a specific subscriber.
Depending on what you are trying to achieve, you can consider using multiple channels, with each consumer using its own.
I am building a push notification system using Node.js, Socket.io and RabbitMQ.
The flow of my system is as follows:
RabbitMQ is published through a PHP script with fan-out exchange type.
Node.js server is subscribed to a queue connected through the same exhange as created in step 1.
When a client connects to node.js server, it sends a unique id through an event.
The unique id sent in step 3 is then compared with the message that is received from the queue subscribed in step 2.
If the condition in step 4 returns true, the entire message from the queue is then emitted to a client with that unique id. So only the specific client receives the desired message and not to all the clients connected.
So is it feasible to loop through all the unique ids of all the connected clients? So in this case every message consumed from the queue will be compared with all the connected clients.
I am expecting 50 to 60 thousand connections, so is it actually feasible to loop these many connections?
Or will it be feasible to create 50 to 60 thousand Queues binded to one exchange?
Or Should I simply broadcast the message to all the clients and comparison will be handled at client side?
Are these the only solutions or there could be some different implementation to handle this.
I am writing a Client, Server-based chat. The Server is the central component and handles all the incoming messages and outgoing messages. The clients are that chat users. They see the chat in a frame and can also write chat messages. These messages are sent over to the server. The server in turn updates all clients.
My problem is synchronisation of the clients. Since the server is multi-threaded, both messages can be received from clients and updates (in form of messages) have to be sent out aswell. Since each client is getting updated in in its own thread, there is no guarantee that all clients will receive the same messages. We have a snychronisation problem.
How do I solve it?
I have messed with timestamps and a buffer. But this is not a good solution again because there is no guarantee that after assigning a timestamp the message will be put into the buffer immediately afterwards.
I shall add that I do not know the clients. That is, I only have one open connection in each thread on the server. I do not have an array of clients or something like that to keep track of all the clients.
I suggest that you implement a queue for each client proxy (that's the object that manages the communication with each client).
Each iteration of your server object's (on its own thread) work:
1. It reads messages from the queues of all client proxies first
2. Decides if it needs to send out any messages based on its internal logic and incoming messages
3. Prepares and puts any outgoing messages to the queues of all its client proxies.
The client proxy thread work schedule is this:
1. Read from the communication.
2. Write to the queue from client proxy to server (if received any messages).
3. Read from the queue from server to client proxy.
4. Write to communication channel to client (if needed).
You may have to have a mutex on each queue.
Hope that helps