Passing messages in message Queue - message-queue

How can I, in my application, sent a message as input to my application using message queue?
It is showing as number of messages in message queue is zero.

Providing that you use Linux and C language, a simple example how POSIX message queue can be used to pass data between separate threads or processes can be found here.

Related

OBD2 - 0x7E8 Messages greater than 8 bytes - ISO 15765-2

My question concerns 0x7E8 response messages where the message is greater than 8 bytes.
I am sure OBD2 experts won't need much of the detail below but for the sake of clarity......
When a diagnostic device (eg scantool) sends a 0x7DF message with a Mode and PID value, most 0x7E8 responses consist of a single message of up to 8 bytes.
However some response messages require more than 8 bytes. eg request for the VIN and many vehicle manufacturer specific Mode/PID values. In this case ISO 15765-2 specifies that the first response 0x7E8 message has the code 0x10, Number of bytes, Mode, PID followed by data.
The diagnostic device then responds with a 0x7E0 flow control message according to the ISO 15765-2 spec. Noting that there is no information in that flow control message to identify which 0x7E8 response message is being flow controlled.
When the flow control message is received, the responding device then sends further 0x7E8 messages with the 0x2? code where "?" is the sequence number of the message. Again there is no information is those further 0x7E8 messages to identify which 0x7DF message Mode/PID is being responded to.
So my question is - Is it possible to have 2 or more diagnostic devices on an OBD2 bus sending 0x7DF messages where the response is more than 8 bytes?
As there is no information in either the 0x7E0 flow control message or the following 0x7E8 0x2? coded messages to identify the original 0x7DF request, multiple diagnostic devices on the OBD2 bus will not be able to identify which 0x7E8 response messages correspond to their request.
I have seen this 0x7E8 message confusion happen in practice with more than one scantool connected to a vehicle. But maybe I have missed something?
If you have more than one scan tool on the bus, then you need to take special care about orchestration, i.e. only the tester who initiated a question is allowed to send flow control ACKs.

setting a message attribute of a message in an SQS queue w/boto?

Is there a way to set a message attribute of a message in an SQS queue? I am trying to examine a message sent to an SQS queue and change its value. The last line of the code below gets and prints the value.
for message in queue.receive_messages(MaxNumberOfMessages=10, AttributeNames=['All'], MessageAttributeNames=['All']):
print(message.body)
print(message.attributes)
print(message.message_attributes)
print(message.message_attributes.get('attr').get('StringValue'))
I would like a way of setting the StringValue of attr in this message. Is there any way of doing that? I would prefer a way of doing this using boto (rather than boto3).
The message attributes of an SQS message are immutable once the message has been sent to the queue. The SQS Query API (used by all client libraries) has no support for modifying a message in the queue, other than to change its visibility timeout.

Is there a way to configure a "Topic exchange" to send the non routed messages to a queue?

With the default behaviour when a message is not routed the message is lost.
You could create a queue that receives all messages by using the # for the routing key in the binding. Then create a process that handles all the non routed messages. The process will have to connect to the queue and receive all messages and somehow know whether they have been routed or not. What you will need to do is call the management plugin cli to return all the bindings for an exchange. Parse that result to get you this list of the bindings for the exchange and ignore any incoming message which matches the bindings. Then you can just process the ones that never got routed in the first place. You could even read them back to another queue for a worker process to consume.
have a look at this for information on the management plugin cli.
If you prefer to use the rabbitmqctl you could use
sudo rabbitmqclt report
to get a report that would need to be parsed to get all the bindings. See here

BitTorrent Peer wire protocol (TCP)

How are the messages encoded or sent/received by peers?
If there is a message
have: <len=0005><id=4><piece index>
How is this sent(in binary,how is it translated to binary?) and received?
Is there a specific order in which the messages are sent to peers?
I have read the specification but it leaves me with questions.
Thanks
I'll answer the ordering question.
In general, you can send any message at any time. But there are some messages which have special rules. The BITFIELD message has to be sent out early for instance. Most clients send PIECEs back in the order they were REQUESTed, but I don't think that is a requirement if memory serves.
In general the messages are of two types. One kind are control-oriented messages telling peers about general status (HAVE messages falls into this group). The other kind are data-oriented messages that actually transfers the file and requests new data from the peer. These message types are "interleaved" and one of the reasons you send PIECE messages no larger than 16 kilobytes is to make sure control messages can be interleaved in between. A trick is that when a PIECE message has been sent, then send all control-oriented messages by priority before the next PIECE message. That way, you quickly tell the other party of your intent.
There is also a "bug" in the original protocol which is solved by the FAST extension. It effectively make each REQUEST result in either a PIECE message or a REJECT-REQUEST message. This is another example of an ordering. If you get a REJECT-REQUEST message for something you never REQUESTED you disconnect the peer.
Prior to declaring the have message the specification says:
All of the remaining messages in the protocol take the form of <length prefix><message ID><payload>. The length prefix is a four byte big-endian value. The message ID is a single decimal byte. The payload is message dependent.
You've got the binary format for length and id right there. The 'piece index' part is this message's specific payload. It should be four bytes long since the message has a fixed size of 5 bytes and 1 byte went to the message ID (viewing other messages with the same format should give you a clue).

NService bus message not coming in sequence (i.e as it is sent)

We are using NService bus for our messaging framework.Sometime the message is not coming as par the sequence of sending .Sometimes last message is coming first and than later first message.
Please help me out Thanks
The nature of NServiceBus does not guarantee that messages will be received in the order they were sent. Each message is meant to be processed independently.
If an action can only be undertaken after two related messages arrive, then you need to utilize a Saga
Edit in response to first comment:
You mention you're sending the same message in chunks. Does this mean that you have a large payload that you have to split up into multiple parts to transmit via MSMQ?
If so, you have a few options:
Store the payload out of band, in a database or file system, and only put enough data in one message (an ID or file system path) to load the data from the message handler.
Make the message a MessagePart that contains a BundleID, PartNumber, TotalParts, and PayloadChunk. Then, create a saga for MessagePart that stores each part and when all parts have been received, reconstitute the chunks together and do what you need. Of course, if you need to then send the resulting large object back onto the Bus, this would get annoying really quickly, so then the out-of-band option would look much more attractive.
In any case, there are a ton of reasons why any MSMQ message, not just NServiceBus messages, could arrive out of order, so you have to be able to deal with it.
Would Bus.Sending a collection of Imessages work? NServiceBus allows batching of messages