I have SMPP server, use CloudHoper.
When I get a message I should return a delivery report.
Please, tell me, how I can do it?
At this moment I return SubmitSmResp...
Of course you still need to answer the SubmitSm PDU with a SubmitSmResp PDU as you do now.
A delivery report is a "special" DeliverSm PDU which is generated in your SMPP server and sent additionally to your client. See SMPP 3.4 Appendix B how it is formatted (https://github.com/twitter/cloudhopper-smpp/blob/master/src/etc/SMPP_v3_4_Issue1_2.pdf). You also need to set esmClass of the DeliverSm PDU to 0x04 to indicate it's a delivery report.
If your client is using a transceiver bind, you can use the same session to send the DeliverSm PDU to, otherwise you need use the clients receiver session. If no active session is available you need to queue the DeliverSm PDU.
The main question is when to send the delivery report. First of all, you may send only a delivery report, if the client requested one, by setting the 4th bit of the SubmitSm esmClass.
Although, if your client is using a transceiver connection, don't send it directly in the firePduRequestReceived handler. The client may receive it before it receives the SubmitSmResp. Additionally this delivery report would not have more value than the SubmitSmResp itself.
So there are three cases when you may generate this delivery report and queue it until you have a proper session from your client to send it to:
1) When you receive some external event indicating that the former SubmitSm was actually processed (e.g. delivered) by it's destination.
2) When you are able to forward the SubmitSm to the next processing unit.
3) When you detect any error or the SubmtSm expired
Create a DELIVER_SM for that message and send that to the client.
Related
I would like to send 1000 messages and retransmit only those that failed. Is there any way?
Are there any methods to identify each failed message, such as a unique message ID?
As you can see, there is no identifiable message ID.
Is actually possible that only one message should be resent as in this case?
Should I resend only this message or all the bulk?
Should I use Exponential Backoff? Then, Where can I find example source?
I'm having a confusion on how to receive delivery receipt from ESME to SMSC?
For Example : If i terminate an Message from SMSC to ESME,then how can ESME sends delivery receipt for the corresponding Message received from SMSC.
If SUBMIT_SM is used for sending the delivery receipt to SMSC,then How can the SMSC differentiates a Normal Text Message and a Delivery Receipt from ESME?
Thanks in advance. :)
Within the SUBMIT_SM message, there is a field called "esm_class" which will allow you to send a delivery receipt to the SMSC. From the SMPP specification 5.0 page 125 the field contains a number of flags that can be set depending upon what kind of message you are sending. The flags for delivery receipts are below.
xx0001xx Short Message contains MC Delivery Receipt Message Type (bits 2 and 5)
xx1000xx Short Message contains Intermediate Delivery Notification
xx0010xx Short Message contains Delivery Acknowledgement
I believe that you will need to send an Intermediate Delivery Notification then a Delivery Acknowledgement message to the SMSC. The Intermediate Delivery Notification is probably optional.
Note that this is highly dependent on what is implemented in the SMSC. It's possible that the SMSC does not even handle these delivery receipts and perhaps will assume that the SMS has been delivered when you send the SUBMIT_SM_RESP in response to the SUBMIT_SM, or perhaps as soon as the SUBMIT_SM message is sent. You will need to test what happens.
I have a problem with my client , I dont know where to look or pinpoint the problem but as far as I know im using qos 2 and my broker is mosquitto. Does anyone have any problem with messages that are not received but delivered?
My process is like these
ClientServer(acts as a bridge to the database) subscribed to "topic1"
Client publishes a payload to "topic1"
Something went wrong then ClientServer then send back to Client that it has not been saved.
Client receives the message and send the message with correct payload again.
ClientServer doesn't receive anymore (Mostly 2 - multiple times publish)
Then i use another client to send some mqtt-client statistics to send a payload message to the ClientServer and in the ClientServer publish tokens most ImqttDeliveryToken data is pending. I dont know why is it because of QOS 2?
So is there a problem with my current pseudo-code when using qos 2 with Client(having the same unique client-id) and ClientServer(having the same unique-client-id)?
PS: What i meant about same unique client-id is that since runtime my clients dont use generated client-id to allow qos 2 to work.
I think i found my answer.
Seems like in order to get over from this problem is to enter higher number of
max_inflight_messages
(in mosquitto.conf )
to N number of messages that makes the ClientServer accommodate, it was its default was 10 that i think thats why 100+ records sent asynchonously will be pending or i don't know what happened but it stopped processing incoming messages.
As for my testing I set it temporarily to 1000.
Hope some people might enlighten me for additional information about this inflight messages?
How I can send file from one client (A) to another one (B) via socket? and vice versa, send file from B to A. I mean that make the client sender and receiver at the same time.
In other word, when muticlient connect to server, how I distinguish between clients ?
You need to implement you own communication message format in short a simple protocol .
You keep a list of all active sockets in a shared list/map , and based on the request from the message you pick up the apt client and push the desired message to that.
You can implement the actual message format as you want, but this can be the blueprint.
In this case lets say your client A sends message : 1. Client Id 2. File Start 3 X . File Content 4. File End
as soon as you get a connection you get the target client id , the file start message lets you understand the next message just needs to be diverted to target and file End message defines the transfer complete.
Also, you may would like to send Acknowledgement message from server to client, in order to eradicate transfer issues.
It is good way to manage client using their id(i.e. a unique long or string or any other for each user). At the time of connection to socket client send their id , store that is in collection. And when a user(Client) want to send file send with own id and Id of that user(Client) want to send.
I would like to have an advice for this issue:
I am using Jbos 5.1.0, EJB3.0
I have system, which sending requests via UDP'S to remote modems, and suppose to wait for an answer from the target modem.
the remote modems support only UDP calls, therefor I o design asynchronous mechanism. (also coz I want to request X modems parallel)
this is what I try to do:
all calls are retrieved from Data Base, then each call will be added as a message to JMS QUE.
let's say i will set X MDB'S on that que, so I can work asynchronous. now each MDB will send UDP request to the IP-address(remote modem) which will be parsed from the que message.
so basicly each MDB, which takes a message is sending a udp request to the remote modem and [b]waiting [/b]for an answer from that modem.
[u]now here is the BUG:[/u]
could happen a scenario where MDB will get an answer, but not from the right modem( which it requested in first place).
that bad scenario cause two wrong things:
a. the sender which sent the message will wait forever since the message never returned to him(it got accepted by another MDB).
b. the MDB which received the message is not the right one, and probablly if it was on a "listener" mode, then it supposed to wait for an answer from diffrent sender.(else it wouldnt get any messages)
so ofcourse I can handle everything with a RETRY mechanisem. so both mdb's(the one who got message from the wrong sender, and the one who never got the answer) will try again, to do thire operation with a hope that next time it will success.
This is the mechanism, mybe you could tell me if there is any design pattren, or any other effective solution for this problem?
Thanks,
ray.
It's tough to define an exacting solution without knowing the details, but I will assume that when a response is received from a modem (either the correct one or not), it is possible to determine which exact modem the request came from.
If this is the case, I would separate out the request handler from the response handler:
RequestMDB receives a message from the [existing] queue, dispatches the request and returns.
A new component (call it the ResponseHandler) handles all incoming responses from the modems. The response sender is identified (a modem ID ?) and packages the response into a JMS message which is sent to a JMS Response Queue.
A new MDB (ResponseMDB) listens on the JMS Response Queue and processes the response for which the modem ID is now known.
In short, by separating concerns, you remove the need for the response processing MDB to only be able to process responses from a specific modem and can now process any response that is queued by the ResponseHandler.
The ResponseHandler (listening for responses from the modems) would need to be a multithreaded service. You could implement this as a JBoss ServiceMBean with some sort of ThreadPool support. It will need a reference to the JMS QueueConnectionFactory and the JMS response queue.
In order to handle request timeouts, I propose you create a scheduled task, one for each modem, named after the modem ID. When a request is sent, the task is scheduled for execution after a delay of the timeout period. When a response is received by the ResponseHandler, the ResponseHandler queues the response and then cancels the named task. If the timeout period elapsed without a cancellation, the scheduled task executes and queues another request (an reschedules the timeout task).
Easier said than done, I suppose, but I hope this helps.
//Nicholas