I am developing an sms gateway using jsmpp library.
This is my scenario.
I bind to the SMSC(telecoms company) on 2 connections and receive messages on 2 shortcodes, say 30002 and 30003 , assigned to me by the SMSC.
Then, third party binders(companies involved in bulk sms push) who normally should bind directly to the SMSC bind to my gateway via SMPP connections to my SMPP server(which serves as an SMSC of sorts to them)
The third party binder sends messages to the SMPP server and I capture this messages, queue them and send them to the main SMSC(telecoms company).
The telecoms company then responds with delivery reports and messages from the bulk message reports and other data which I forward to the third party binders.
This scenario has worked well for when I have only 1 third party binder.
But now we want to handle a more general case where we have many third party binders.
Since I have only 2 short codes available on which the SMSC forwards messages to me, how do I know which of the third party binders owns the SMSC response?
I have the unsavoury and inefficient option of forwarding the responses to all connected third parties.
The only other option apart from the above is to get a different short code from the SMSC for each third party binder, which is not cost efficient for my scenario.
First of all, you can pretty easily forward all DLRs to the correct third parties. In order to do so, you will have to store some extra data in a database of your choice (if you only have 1 application node and low traffic, even SQLite will suffice; otherwise look towards some NoSQL solution):
Every time you receive a submit_sm_resp packet from telecom SMSC, start storing a pair (key-value, actually) message_id -> third_party_id.
Every time you receive a deliver_sm packet from SMSC, retrieve the message_id from the packet, then look for this message_id in your DB to find which third party to forward it to.
Consider removing the message_id -> third_party_id pair after you have successfully forwarded the final DLR for that message_id.
The situation is a lot worse with the MO messages. The only possible (but nonetheless very bad) way of using a single shortcode for multiple clients (third parties) is having a fragile combination of TTLs and timeouts on you data. It also only makes sense when every MO that you expect is a reply to a previous MT message.
Separate incoming MTs that need reply from the receiver using TLV or extra SMPP links. Let us call those MTs Questions.
Handle Questions something like this:
Handle MO messages (Answers) like this:
UPD. Text elaboration
In order to know the correct third party for MO message (not delivery report) you need some additional info about who the message is addressed to. This info might originate from either the third party or the subscriber (one who has initiated the MO message in the first place). My diagrams formally describe the case where the third party gives you this information.
A third party sends you an MT message that they expect to be Answered by the recipient.
You make a note in the database, that if the recipient sends you an MO message in the next N minutes, then this Answer should be forwarded to the aforementioned third party.
I apologise that my answer is not specific to jsmpp but I have little knowledge of this library, however, I also believe it should be fairly easy to implement an algorithm once you understood it regardless of your instrument.
Related
I'm newbie in Apache Camel, so please forgive me for the stupid question.
I am browsing examples of sending messages using multicast and I don't understand it.
I know that (in the network layer) multicast source sends datagram to specified address from range 224.0.0.0 to 239.255.255.255, to subscribers, but multicast source "does not know" how many subscribers are, only one datagram is sent for anyone of subscribers .
I do not understand either the example from the documentation (https://camel.apache.org/components/latest/eips/multicast-eip.html#_multicast_example) or from here (https://www.javarticles.com/2015/05/apache-camel-multicast-examples.html).
Why (if I understood correctly) the subscribers of the message are explicitly specified ("direct: a", "direct: b", "direct: c")?
After all, in one moment there may be 3 of them, in another time 10 of them, and so on. I don't think I need to change the code and define e.g. "direct:10", am I right?
Does the Apache Camel multicast mean something different than the one from the network layer?
Yes its not the same. Multicast EIP is a way of sending a message to N recipients at the same time (where the number of recipient is fixed/known ahead of time).
yes, you correctly understand that there is difference between network layer multicast and apache camel multicast.
The use case for camel multicast is when you want to send same message to the multiple endpoints. So in example from docs:
from("direct:a").multicast().to("direct:x", "direct:y", "direct:z");
The same message from "direct:a" will be send to all three endpoints. And the number of "destination" endpoints is defined for each route and could be different for different routes.
Note that in case of:
from("direct:a").to("direct:x").to("direct:y")
You are chaining processing of the messages. The result from the "direct:a" will be send to "direct:x" and the result from "direct:x" will be send to "direct:y", so "direct:y" could get different message as "direct:x".
I have a simple question about messaging. I have two applications that communicate via RabbitMQ. The first application regularly sends messages to say "New data has arrived". The second application subscribes to these messages and looks up the information in a common database if it is interested. So the questions is: Should the messages be structured as an alert and an ID so that the second application can do a look up to retrieve the data or should the message contain the complete data set so that a look up is not required? The message content is around 1KBytes. I guess to some extent this is a stylistic question, but I am curious to know if there is an accepted "Best Practice"
I'm developing a 'WS oriented' application basing on Spring/CXF/Oracle DB. Now, I stuck with some architectural consideration about right approach to organize message processing (already stored in db).
Briefly, process looks as follows:
(A) Get the message from client -> Validate -> Store -> Send reposponse
(B) Process -> Update data
I consider two general approaches for part B of the process:
1) Use JMS queue
Just after validation and storing incoming message details in DB publish a message to the JSM queue. On the other side define cosumer which will retrieve the message and do the processing
2) Fetch data to be processed
Manually fetch data from with db and process it.
Additional facts:
The processing won't be compute-intensive, so for new I dont think that work distribution will be needed (all in single JVM).
All data in single db schema
So, I'm interested what are key factors to choose JMS in such case?
JMS would be a better approach. In positive scenario, approach #2 works as well. But JMS would provide you some in-built capability, specially for failed case. Though internally JMS would be using a DB-based persistent storage; it would provide a better interface to communicate that data.
For example, you could configure an error queue to track all the messages, whose processing failed.
It would also provide you scalable architecture, where some other app (in future) could starts consuming your message and process.
Reliable: Due to asynchronous messaging, all the pieces don’t need to be up for the application to function as a whole.
Flexible : Think of scenario, in which you might want to process certain type of data before all other (prioritization). JMS would provide more better approach than tweaking logic in a program.
We're developing special devices that uses XMPP to talk to each other. A new API i am developing now, should talk to these devices too. The problem i am facing - all these devices are building little groups - for each customer we have... so we will have a chat-room for each group of devices, or, for each of our customer with his bunch of devices ;)
But now.. the api should be able to talk to every device that is connected. I don't need a real broadcast-mechanism - in the end, i will send a message only to one specific device..
But i don't want to login to each chat-room either - running a product with over 40k customers and much more devices, will end in a funny api, that is opening over 40k chat-rooms at startup... even if don't tried this yet, i can't imagine that an app like this will run well... even though we can have millions of customers in a few years.. i don't like solutions that will grow linear with the amount of customers, if you know what i mean :/
Now, basically i'm thinking of a solution, where i just can use the basic XMPPConnection to do my stuff.
MyCustomMessage msg = new MyCustomMessage();
msg.setTo("*"); // don't know what to address, i want to send it to "all"
msg.setFrom("ThatAPI"); // just a string telling that is sent from my java api ;)
msg.setEvent(event); // stuff that is coming through the parameters of the method where this code is inside
msg.setCustomStanza(data); // same here
connection.sendPacket(msg); // my try to send it to all till now..
Somewhere in the Ignite Realtime Forums i have read of one guy who "solved" it, but everything he says is "it's working now, i push my message through the sendPacket of Connection"... ok nice, my attempt of this seems not to work :(
Any better ideas/real implementations how this will work fine?
Basically i start to think that XMPP will not be the best technology to achieve something like this at all - i wish i could have a real/basic socket-implementation where something like this would be piece of cake.. But i can't choose - the third-party-system has implemented XMPP already... not enough time to change all of this... Just if you're wondering why we try this on XMPP..
You seem to have some conflicting requirements in that you want to send to all devices now, but only 1 specific device later. Are both models required at the same time, or do you plan on switching? How either is done would be different solutions.
As for your current approach, I think pubsub would make more sense than your chatroom approach, as that is oriented to generic message passing to subscribers.
You could set up a pubsub node per customer to send messages to all
of their devices.
As for a broadcast to all, you can make all devices
subscribe to a single pubsub node.
Thus you control broadcast and group messages by sending to the appropriate pubsub node.
For sending to a specific device, that is just a sendPacket to the specific entity, nothing really special there.
I have a chat program implemented in Java. The client can send lots of different types of information to the server (i.e, Joins the server and sends username, password; requests a private chat with another user on the server, disconnects from the server, etc).
I'm looking for the correct way to have the server/client differentiate between 'text' messages that are just meant to be chat text messages sent from one client to the others, and 'command' messages (disconnect, request private chat, request file transfer, etc) that are meant for the server or the client.
I see two options:
Use serialized objects, and determine what they are on the receiving end by doing an 'instanceof'
Send the data as a byte array, reserving the first N bytes of the array to specify the 'type' of the incoming data.
What is the 'correct' way to do this? How to real protocols (oscar, irc) handle this situation?
I've googled around on this topic and only found examples/discussions centering on simple java chat applications. None that go into detail about protocol design (which I ultimately intend to practice).
Thanks to any help...
Second approach is much better, because serialization is a complex mechanism, that can be easily used in a wrong way (for example you may bind yourself to internal content of a concrete serialized class). Plus your protocol will be bound to JVM mechanism.
Using some "protocol header" for message differentiation is a common way in network protocols (FTP, HTTP, etc). It is even better when it is in a text form (people will be able to read it).
You typically have a little message header identifying the type of content in all messages, including standard text/chat messages.
Either of your two suggestions are fine. (In your second approach, you probably want to reserve some bytes for the length of the array as well.)