There is an attribute called expirationCounter in subscription resource with following details in TS-0001:
"This attribute (notification policy) indicates that the subscriber wants to set the life of this subscription to a limit of a maximum number of notifications. When the number of notifications sent reaches the count of this counter, the subscription resource shall be deleted, regardless of any other policy."
Should expirationCounter be decreased by the count equal to number of notificationURI present in a subscription and when notification is successfully received by the receiver?
For example:
a has 4 notificationURI and expirationCounter set to 100. when an event occurs, notification is successfully received by 2 URI while 2 notificationURI couldn't be reached.
What will be the value of expirationCounter in this case?
In TS-0001, section 10.2.10.7 „Notification message handling procedure“ the procedure is described in detail. Here it says
The expirationCounter shall be decreased by one when the Hosting CSE successfully sends the notification request to Receiver(s). If the counter reaches zero, the corresponding subscription resource shall be deleted.
This means that the expirationCounter is decreased by one for each notification event and when it could successfully send the requests, not for each request it sends to one or more receivers. It is independent from the number of URI in notificationURI.
For example, when a subscription‘s expirationCounter is set to 10, then the subscription is removed after the 10th time it is triggered (assuming the requests could be successfully sent).
Related
When sender issues a Transfer action, runtime subtracts a deposit, issues receipt and node routes it to another shard.
What happens if recipient account doesn't exist? Will tokens be refunded back to the sender?
Yes. Runtime generates a refund receipt from a sender system with a single action Transfer for the total amount of deposit.
I'm trying to implement SMS transmission between two GSM devices. I've searched and read standards and articles a lot but couldn't find the answer to the following question. Does anyone know how does SMSC get aware of the sender's number and insert it in the TP-OA field of the SMS-Deliver packet stack?
Actually I'm not sure that either this is what you need or this would help you but anyways..
In GSM network there are a lot of nodes and each does certain things for which it is responsible. They communicate to each other with messages, that contain certain information needed for processing of required operation: establishing a call, sending SMS, doing Update Location etc.
So the information about sender's number comes to SMSC from another node called VLR/MSC together with a message saying to it "Yo, one guy wants to send SMS to another guy. So here is this message and information about these guys. Please, forward it".
Here is scenario of user A sending SMS to user B:
User A sends SMS to VLR/MSC together with information about its destination
VLR/MSC then invokes MAP message ForwardSM (Forward Short Message) to send received data further through the network to a node called SMS IMSC
SMS IMSC is a node that plays a role of interface between network and SMSC
SMS IMSC on receipt of ForwardSM message sends TPDU (Transfer Protocol Data Unit) message towards SMSC with the text of sent SMS and routing information
After this SMSC sends reply to user A with a result of receiving the SMS. If it's successful then SMSC starts routing this SMS through the network towards user B
So the message you are looking for is TPDU message from Point 3. Type of this message is SMS-SUBMIT according to TPDU types.
Edit:
Authentication is separate operation that takes place when subscriber starts his activity (eg turns on his phone) or roams to another area that is being served by another VLR/MSC. Anyway, VLR/MSC treats this user as new to this area. Skip this part if you know what is VLR/MSC:
HLR is a node that stores all the information about every subscriber in operator's network. So basically it's a database that has all the info about every single subscriber in the entire operator's network.
And network covers huge geographical area so it's divided is smaller areas called cells. VLR/MSC is a node similar to HLR (it also stores subscribers' data). But it is responsible for one certain cell, so it stores data of subscribers who currently operate in this certain cell. So when new subscriber comes to its area VLR/MSC downloads his data from HLR. And when subscriber leaves this area VLR/MSC removes his data.
And if some node would need to get subscriber's data, it won't "ask" HLR for it, but instead it will "ask" VLR/MSC in whose area the subscriber is currently active.
So when VLR/MSC sees a new subscriber coming to its area, before downloading his data from HLR it triggers authentication process to check if this user is valid and that someone else doesn't pretend to be this user:
VLR/MSC sends Send Authentication Info MAP message together with IMSI (mobile subscriber number which is uniquely identified by his SIM card) to HLR
HLR checks the given IMSI and validates subscriber. If subscriber exists and there is no troubles with him then HLR sends IMSI to AUC (Authentication Center)
On IMSI reception AUC generates a triplet (some encryption keys needed for subscriber identification) that contains SRES, RAND and Kc values and sends this data back to HLR
HLR forwards this data back to VLR/MSC which triggered authentication process
VLR/MSC after reception of SRES, RAND and Kc sends received RAND to mobile subscriber
After mobile subscriber receives the RAND he calculates SRES using given RAND and Ki (some value that is written in user's SIM card) and sends calculated SRES back to VLR/MSC
On the final step VLR/MSC compares SRES generated by AUC with SRES generated by user. And if they match then user is identified successfully, VLR/MSC fetches subscriber's data from HLR and authentication process is completed.
After VLR/MSC downloaded data from HLR every other node that would need data of this subscriber would fetch it from VLR/MSC not HLR. And after that authentication process won't start every time subscriber wants to do something (make a call, send SMS and so on).
So when user A sends SMS to user B the data about user A (his number for example) is stored in VLR/MSC already and it arrives to SMSC from VLR/MSC together with the SMS user A sent.
Currently I'm working on a SaaS with support for multiple tenants that can enable push notifications for their user-bases.
I'm thinking of using a message queue to store all pushes and send them with a separate service. That new service would need to read from the queue and send the push notifications.
My question now is: Do I need to come up with a complex sending strategy? I know that with GCM has a limit of 1000 devices per request, so this needs to be considered. I also can't wait for x pushes to fly in as this might delay a previous push from being sent. My next thought was to create a global array and fill it with pushes from the queue. A loop would then fetch that array every say 1 second and send pushes. This way pushes would get sent for sure and I wouldn't exceed the 1000 devices limit.
So ... although this might work I'm not sure if an infinite loop is the best way to go. I'm wondering if GCM / FCM even has a request limit? If not, I wouldn't need to aggregate the pushes in the first place and I could ditch the loop. I could simply fire a request for each push that gets pulled from the queue.
Any enlightenment on this topic or improvement of my prototypical algorithm would be great!
Do I need to come up with a complex sending strategy?
Not really. GCM/FCM is pretty simple enough. Just send the message towards the GCM/FCM server and it would queue it on it's own, then (as per it's behavior) send it as soon as possible.
I know that with GCM has a limit of 1000 devices per request, so this needs to be considered.
I think you're confusing the 1000 devices per request limit. The 1000 devices limit refers to the number of registration tokens you add in the list when using the registration_ids parameter:
This parameter specifies a list of devices (registration tokens, or IDs) receiving a multicast message. It must contain at least 1 and at most 1000 registration tokens.
This means you can only send to 1000 devices with the same message payload in a single request (you can then do a batch request (1000/each request) if you need to).
I'm wondering if GCM / FCM even has a request limit?
AFAIK, there is no such limit. Ditch the loop. Whenever you successfully send a message towards the GCM/FCM server, it will enqueue and keep the message until such time that it is available to send.
I'm implementing a download manager in cocoa. The user can add several download requests, and the request manager will show the progress of the requests in a panel. I came into problem about the pause/resume of the request in the queue.
For simplicity, supposing the max concurrent operation count is 1, I add several requests with order:1, 2, 3,4,5. If it is not interrupted, the request is downloaded from 1 to 5 in sequence. Supposing I pause the request 1, the request 2 should continue to download. During that time, I resume the request 1. Hence, after the request 2 is finished, I hope the request 1 can be continued before request 3.
The problem here is that: For the single request when I paused it, the request in fact was cancelled. when I resumed the request, a new request was initialed and then started. In an operation queue, now I sent [self cancel] if the request was paused so that the next request could be started. However, I don't know how to do if it is resumed. The canceled request cannot be added to the queue again. If I created a new one and add it to the queue, how can I promise the priority like the before?
Please give tips on how to do it.
thanks
Currently I make a solution myself using:
make a custom request inherited from ASIHttpRequest;
make a NAMutableArray to contain all the requests;
If one request is added, enumerating the array to see if the maximum requests are executing.
If not, start the request in its own queue. If exceeding the maximum, just add the request to the array, and set its status to waiting;
If one request is finishing or failing, enumerating the array to see the request which is in the first position by adding time with a status waiting;
I am writing a Message Handler for an ebXML message passing application. The message follow the Request-Response Pattern. The process is straightforward: The Sender sends a message, the Receiver receives the message and sends back a response. So far so good.
On receipt of a message, the Receiver has a set Time To Respond (TTR) to the message. This could be anywhere from seconds to hours/days.
My question is this: How should the Sender deal with the TTR? I need this to be an async process, as the TTR could be quite long (several days). How can I somehow count down the timer, but not tie up system resources for large periods of time. There could be large volumes of messages.
My initial idea is to have a "Waiting" Collection, to which the message Id is added, along with its TTR expiry time. I would then poll the collection on a regular basis. When the timer expires, the message Id would be moved to an "Expired" Collection and the message transaction would be terminated.
When the Sender receives a response, it can check the "Waiting" collection for its matching sent message, and confirm the response was received in time. The message would then be removed from the collection for the next stage of processing.
Does this sound like a robust solution. I am sure this is a solved problem, but there is precious little information about this type of algorithm. I plan to implement it in C#, but the implementation language is kind of irrelevant at this stage I think.
Thanks for your input
Depending on number of clients you can use persistent JMS queues. One queue per client ID. The message will stay in the queue until a client connects to it to retrieve it.
I'm not understanding the purpose of the TTR. Is it more of a client side measure to mean that if the response cannot be returned within certain time then just don't bother sending it? Or is it to be used on the server to schedule the work and do what's required now and push the requests with later response time to be done later?
It's a broad question...