I'm using a gsm modem itengo 3800. I'm currently doing a project that interface with a website to send/receive bulk sms, schedule sms and etc.
The problem is, i don't really know which should it be coded in. Should it be coded as a asp.net web application? or should it coded as a windows programs that interface with the web application for send/receiving sms?
Also receiving/sending multiple sms is important, so i requires queue or anything for buffer? Would be glad if sample programme is provided.
Because sending messages via gsm modem can be slow, what I'd do is have the ASP.NET app post the messages to a message queue, then have a windows service read the queue and send the messages. This allows the website to avoid any degradation issues when sending out lots of messages.
Here is a decent article that discusses using MSMQ: http://www.15seconds.com/issue/031202.htm
The ASP.NET app would:
MessageQueue queue = new MessageQueue(QUEUE_PATH);
Message msg = new Message("5555551212|message");
queue.Send(msg);
And the service would listen:
MessageQueue queue = new MessageQueue(QUEUE_PATH);
Message msg = queue.Receive();
Related
I have to following scenario:
My app requests and receives data from an BLE peripheral (a glucometer). It it possible that the user has another app (from another developer) installed, that also communicates with the peripheral. I noticed that my app receives characteristic notifications for requests that where initiated by the other app. This causes my app to receive some data twice.
Is there any way to distinguish between responses to my request and responses that are caused by another app? Or how can I handle it?
While the stack obviously knows which app a certain (read, write) response belongs to (because there may only be one pending request, and it knows who sent the request), there is no logical or sound reason why it should dispatch a notification to a single app (among those who have enabled notifications).
Note that the GATT specification does not define "multiple gatt clients per link", there is only one client, so the peripheral doesn't even know there might be two apps talking to it. Hence when it sends a notification, it doesn't include a "target app" field.
The feature of multiplexing multiple apps to the same GATT connection is something iOS and Android teams etc. came up with.
Intro:
In the below architecture, there are three key components.
Users - Machines where user application is running.
Applications - which are running inside the remote server.
Gateway/Broker - Required for isolation between user devices and server applications.
Message flow between user device and server application should happen as below
User shall transmit message to remote server, which will be used by
the one or more server applications.
Application shall broadcast/publish message to all connected
users.
Application shall send message to a particular user device
(Unicast).
In addition, one or more users will be connected or disconnected to the server arbitrarily and one or more application will be spawned or terminated arbitrarily.
For the above problem statement, I have designed the below zmq architecture.
The Gateway/Broker handles arbitrary assignments of users and applications and also provides the required isolation. It publishes user messages to all applications. It also aggregates all messages needed to be sent to users from applications via a SUB socket.
The application sends a two part message, the first part is the user identity and the second part is the actual message. The Gateway/Broker transmits that message to a user, based on identity. A special identity for a broadcast will be created, the gateway, if has received broadcast identity, will publish the message to all users via PUB socket.
The user connects to both ROUTER and PUB sockets in gateway. Fair queued data will be received from both sockets. While sending, the message will be sent to only gateway's ROUTER socket, not PUB socket.
Questions:
Q1: Is there any flaw with above architecture?
Q2: Is it possible to improve it more?
Metric assumed for the Q2:
The users and applications are dynamic in nature, they connect and disconnect on their own, the design should withstand that,
User reports its status periodically to server, design should facilitate latency of less than 333 [ms] ( a user, connected to server over internet, WAN connectivity btw user and server provides a latency much less than 333 [ms] )
Lossless transmission between server and users ( ACKing at backend, retransmission if lost )
You can try Malamute, which gives you what you need and more like credit-flow, keep-alive, tracking.
Malamute is small broker based on zeromq and part of the zeromq community. You can run Malamute as a component inside your application and don't need a dedicate service or daemon for it.
If you are using C or C++ that is no brainer as it integrate naturally. It also has binding for a lot more languages.
https://github.com/zeromq/malamute
I learned that PUSH NOTIFICATION service is like a persistent TCP connection.
But I don't know how maintain the connection even if the phone terminate the app.
In mobile application, if the subscription is destroyed, how we publish and deliver the message?
Should I use GCM, APNS or SMS? And wait until client subscribe the topic?
That's correct, you have to be connected with the broker (mosquitto broker in this case) to receive the push notification (you also must be subscribed to topic).
In Android I'm using paho client libray, a Service for keep connection in background, and BroadcastReceiver to start service at reboot.
For iOS you can find swift and Objetive-C MQTT-client librarys (I'm using CocoaMQTT) but you can't keep connection in background indefinitely. You have to use APNS.
I am trying to implement Reliable WCF Service with MSMQ based on this architecture (http://www.devx.com/enterprise/Article/39015)
A message may be lost if queue is not available (even cluster doesn't provide zero downtime)
Take a look at the simple order processing workflow
A user enters credit card details and makes a payment
Application receives a success result from payment gateway
Application send a message as “fire and forget”/”one way” call to a backend service by WCF MSMQ binding
The user will be redirected on the “success” page
Message is stored in a REMOTE transactional queue (windows cluster)
The backend service dequeue and process the message, completes complex order processing workflow and, as a result, sends an as email confirmation to the user
Everything looks fine as excepted.
What I cannot understand how can we guarantee that all “one way” calls will be delivered in the queue?
Duplex communication is not a case due to the user should be redirected at the result web page ASAP.
Imagine the case when a user received “success” page with language “… Your payment was made, order has been starting to process, and you will email notifications later…” but the message itself is lost.
How durability can be implemented for step 3?
One of the possible solutions that I can see is
3a. Create a database record with a transaction details marked as uncompleted, just to have any record about the transaction. This record may be used as a start point to process the lost message in case of the message will not be saved in the queue.
I read this post
The main thing to understand about transactional MSMQ is that there
are three distinct transactions involved in a transactional send to a
remote queue.
The sender writes the message to a local queue.
The queue manager on the senders machine transmits the message across the wire to the queue manager on the recipient machine
The receiver service processes the queue message and then removes the message from the queue.
But it doesn’t solve described issue - as I know WCF netMsmqBinding doesn’t use local queue to send messages to remote one.
But it doesn’t solve described issue - as I know WCF netMsmqBinding
doesn’t use local queue to send messages to remote one.
Actually this is not correct. MSMQ always sends to a remote queue via local queue, regardless of whether you are using WCF or not.
If you send a message to a remote queue then look in Message Queuing in Server Management you will see in Outbound queues that a queue has been created with the address of the remote queue. This is a temporary queue which is automatically created for you. If the remote queue was for some reason unavailable, the message would sit in the local queue until it became available, and then it would be transmitted.
So durability is provided because of the three-phase commit:
transactionally write message locally
transactionally transmit message
transactionally receive and process message
There are instances where you may drop messages, for example, if your message processing happens outside the scope of the dequeue transaction, and also instances where it is not possible to know if the processing was successful (eg back-end web service call times out), and of course you could have a badly formed message which will never succeed processing, but in all cases it should be possible to design for these.
If you're using public queues on a clustered environment then I think there may be more scope for failure as clustering msmq introduces complexity (I have not really used so I don't know) so try to avoid if possible.
how do i send an sms message from my web application using asp.net with c#.
You cant send messages directly through asp.net.
What you can do is send a web request or an email to an online SMS provider,
or to a local gateway (like a phone) and it can then pass the message onto
the GSM network.
Try Clickatell to get an idea of what I mean.
http://www.clickatell.com/brochure/coverage.php
If you don't want to pay, most cell phone carriers have an email that you can send messages to that will then forward them to the proper recipient. E.G. (10 digit phone number)#txt.att.net.
Bu of course this means that you will have to know the carrier, and many of them will not send outside the U.S. so that might not be the most attractive option.
You find a gateway (I use Clickatell, but there are others) and integrate with them. It's generally quite trivial (but of course, you pay to send the messages). They often have SMTP, HTTP and other types of APIs.