Ever since the introduction of push services in IOS I wonder how it works.
From what I found out the push function is basically an open connection that does not close serverside.
But mobiles are connecting at different points of the internet, the only way for a server to know where the mobile is connected is when the mobile tells the server where that it has changed location.
I read something about polling a connection so it stays open.
What advantage is there to manage and keep a changing open connection alive vs just checking if something is to pull?
Internally yes, push is implemented by having your phone poll for new data. The thing that makes push notifications attractive is that they are routed over Apple's service and that has many advantages.
From the phone's point of view, it only has to poll from one service, which means it can conserve bandwidth and piggyback on the normal operations of keeping a cellphone online. That means a lot less battery is used, and you can do things like set your phone to only receive push notifications every half hour, which means that 29 minutes out of every half hour you can turn off the data connection.
From the server's point of view, you no longer need to cache messages or provide quality-of-service guarantees. If you want to send a push notification to a phone that's out of range of a cell-tower for a few minutes, you may need to store the message for a considerable amount of time until the phone comes back online. Apple handles all this for you, and lets your server just be in charge of creating notifications, not storing and relaying them.
Related
I want to fetch the data of a stock. Since the data changes very fast, is there any way to pull the data like 50-100 times a second from trading websites?
And can we implement that using a raspberry Pi 4 8gig model.
RasPi4 should be more than adequate for this task. Both the ethernet and WiFi hardware is capable of connections at these speeds. (Unless you’re running a bunch of other stuff on it.) Consider where your bottlenecks may be, likely ISP or other network traffic). Consider avoiding WiFi in favor of cat5e or cat6. Consider hanging this device off your router (edge) to keep lan traffic lower and consider QOS settings if you think this traffic may compete with other lan traffic.
This appears to be a general question with no specific platform in mind. For stocks, there are lots of platforms to choose from.
APIs for trading platforms often include a method to open a stream. Instead of a full TCP conversation for each price check, a stream tells the server to just keep on sending data. There are timeout mechanisms of course, but it is good to close that stream gracefully (It’s polite since you’re consuming server resources at a different scale. I’ve seen some financial APIs monitor and throttle stream subscribers who leave sessions open.).
For some APIs/languages you can find solid classes already built on GitHub. Although, if simply pulling and reading a stream then the platform API doc code snippets should be enough to get you going.
Be sure to find out what other overhead may be implicated. For example, if an account or API key is needed to open a stream then either a session must be opened first or the creds must be passed with the stream being opened. The API docs will say. If you’re new to this sort of thing, just be a detective and try to infer what is needed. API docs usually try to be precise and technically correct with the absolute minimum word count.
Simply checking the steam should be easy. Depending on how that steam can be handled by your code/script, it may be harder to perform logic on the stream while it is being updated. That’s usually a thread issue or a variable scope issue depending on the script/code. For what you’re doing I would consider Python or PowerShell depending on your skill-set and other design parameters.
After knowing about some great features of WebRTC, I thought of using WebRTC one to one audio/video calls in my web application. The web application is for many organizations/entities of a category who can register and keep recording several records daily for their internal working and about their clients. The clients of these individual organizations/entities also have access to the web application to access their details.
The purpose of using WebRTC is for communication between clients and organizations. Also for daily inquires by new people to these organizations about products and services.
While going through articles on google etc. I found broadcasting or one to many calls requires very high bandwidth to users if we don't make use of Media Server.
So what is the case for one to one calls?
Will it affect the performance of web application or bring any critical situation if several users are making audio/video calls(one to one) to each other simultaneously as a routine?
The number of users will be very large and users will be recording daily several entries as their routine work. But still it is manageable and application will be running smoothly but I am not sure about the new concept WebRTC. Will it require a very high hosting plan? Is using WebRTC for current scenario suitable or advisable?
WebRTC by its nature is Peer-to-Peer. Meaning that the streaming data is handled CLIENT side. All decoding, encoding, ICE candidate gathering/negotiation, and media encrypting/transmitting will happen on the client side and not on server side. So, you will be providing the pages, client side JS, and some data exchange(session negotiation signalling) but all in all, it is not a huge amount of work. It should be easily handled without having to worry about your host machine being over worked.
All that said, here are the only a performance concerns that would POSSIBLY affect your hosting server.
Signalling session startup, negotiations, and tare down. This is very minimal(only some json data at the beginning of a session). This should not be too much of a burden but you should be aware that if 1000 sessions start at the same time, you will have a queue of messages to direct to the needed parties. How you determine the parties, forward the messages, and what work you do server side could all affect performance. If written smartly(how to store sessions, how to forward messages, etc.) should not be a terrible burden.This could easily done with SignalR since you are on ASP.NET or you could use a separate one running Node.js(or the same box, does not matter) if you so desired.
RTP TURN relay if needed. This will probably be through a different server(or the same one as your hosting server if you want). For SOME connections, a TURN server is needed and any production ready WebRTC solution should take this into account. Here is a good open source turn server. Bandwidth usage here could be very high as RTP packets are sent to this server and the forwarded to the peer in the connection.
If you are recording the streams, you may have increased hosting traffic depending on how you implement it. Firefox supports client side recording of the streams but Chrome does not(they say it is in the works currently). You could use existing JS libraries to record the feeds client side and then push them anywhere you want. You could also push all the data through a MediaServer that will mux, demux, and forward the data to be recorded anywhere you like. Janus-Gateway videoroom is a good lightweight example of a mediaserver.
Client side is a different story.
There are higher level concerns in the Javascript. If you use one of the recording JS libraries, this is especially evident as they do canvas captures numerous times a second which are a heavy hit and would degrade the user experience.
CPU utilization by the browser will increase as the quality of the video being streamed increases. This is rather obvious as HD video frames take more CPU power to encode/decode than SD frames.
Client side bandwidth usage can also be an issue. Chrome and Firefox try to modify the bitrate of each video/audio feed dynamically but the video Bitrate can go all the way up to 2 Mbps. You can cap this in Chrome( by adding an attribute in the SDP) but not in Firefox(last I checked) as of yet.
I do an application design for a soft real-time software application now.
The application will probably need to notify its mobile users about some events in the system. An event can happen during a 15-minute time frame which starts after the user's first interaction with the system. The event notification should be done in soft real-time: if a user notified later than 15-20 seconds he was supposed to be notified, then it is critical. Basically, I need to notify a mobile user about an event no later than 15-20 seconds after that event happens during a 15-minutes time frame.
I plan to do that with some kind of PUSH technology (XMPP/Jabber, native app with Comet connection or maybe PUSH email).
Unfortunately, the most obvious solution which is to have mobile web-site (example: http://www.lightstreamer.com/) with real-time push notifications is not suitable, because in that case the user will have to stare at the screen during all the 15-minute time frame. Notifying a user with a sound or a vibration would be a much more pleasant user experience (connect to the system via smartphone -> start interaction with the system -> put the smartphone back into the pocket or a bag -> get notified).
I have done a simple experiment by sending Jabber chat messages between my laptop (WiFi/100Mbit) and my Android smartphone (GPRS/3G). The thing is that some of the messages sent to the smartphone are late (it takes about 1 minute until they arrive at the smartphone) or just lost (they never arrive at the smartphone). Moreover, I have noticed that the Jabber client at the smartphone goes offline regularly for a few seconds. I do not know if it is because I have a very cheap Android smartphone or because the 3G connection is not very good, but this behaviour is not acceptable for the software application that I design.
Thus, I am interested in the following:
is there any technology standard that can guarantee pushed message delivery to mobile (GPRS/3G) consumers in soft real-time? I.e. a technology standard which guarantees that a mobile client will be notified no later than N seconds from now;
do you know any examples of mobile apps which have soft real-time push notifications?
what are the ways to address the issue of delivering/pushing soft real-time messages to mobile devices in soft real-time? (e.g. keep sending the same message until the mobile device confirms the receipt of the message)
P.S. The intended use of the software application is with any smartphone, be it iPhone, Android, WP or any other internet-connected smartphone.
Note: This question is similar to one of my previous questions, but this one is about on a completely different use-case with strong focus on soft real-time requirements.
I know that this question is 3 years old but it doesn't have any answer.
A PUSH notification is always Best Effort. It means that the server will do it's best to deliver it but can not guarantee that it will be done on time or if it will be delivered at all.
Never rely on PUSH notifications to achieve a critical job.
I have to devise a push notification plan for some mobile devices where push is not yet officially supported by C2DM / APNS / BES ,etc. MQTT was also a good option but I could not get an MQTT Client for my required platform. (Blackberry Playbook, ActionScript only)
Going back to basics, I had the options of Long Polling and streaming. Streaming using a high keep-alive value seems good to me, as the development of the mobile app (it is not a browser) and the server code are both in my control. To maintain the connection open, I just need to ping the server occasionally.
What issues I may be facing in this approach ? I understand this would constantly open an HTTP connection from the device to the server. Would the battery life of mobile device drain quickly just by persistently opening a server connection ? ...Afterall the data is not being transferred, just by keeping the connection open...right ?
You might want to consider Urban Airship or take a look at this realtime technologies guide.
If realtime really matters, I'm talking about seconds or milliseconds, then a realtime web technology using WebSockets or HTTP Streaming is your best option as they deliver updates the instant they are available. This sort of thing is best suited to the sort of application that a user is actively using during a reasonable period of time where they need instant notifications or are collaborating/chatting with others.
WebSockets are probably a better standard to be using with longer term technology considerations in mind since they are the first standard for full duplex bi-directional communication between a client (mobile, web, desktop) and server.
What platform could you not find an MQTT client for? http://mqtt.org/software lists clients in just about every language I can think of and more than I'd like to bother using. The mosquitto C client library is very portable.
For battery life, it really depends what you're doing between the keepalives...
If you app runs in a country where the network isn't in the best shape, then having all your clients keep a connection open can put strain on their infrastructure (assuming you are that popular).
Battery life is the other consideration, yes, a lot of devices aren't that efficient in keeping an idle radio/3g connection open and it drains the battery a lot faster than not having a connection open.
What all would be the requirements for the following scenario:
A GSM modem connected to a PC running
a web based (ASP.NET) application. In
the application the user selects a
phone number from a list of phone nos.
When he clicks on a button named the
PC should call the selected phone
number. When the person on the phone
responds he should be able to have a
conversation with the PC user.
Similarly there should be a facility
to send SMS.
Now I don't want any code listings. I just need to know what would be the requirements besides asp.net, database for storing phone numbers, and GSM modem.
Any help in terms of reference websites would be highly appreciated.
I'll pick some points of your very broad question and answer them. Note that there are other points where others may be of more help...
First, a GSM modem is probably not the way you'd want to go as they usually don't allow for concurrency. So unless you just want one user at the time to use your service, you'd probably need another solution.
Also, think about cost issues - at least where I live, providing such a service would be prohibitively expensive using a normal GSM modem and a normal contract - but this is drifting into off-topicness.
The next issue will be to get voice data from the client to the server (which will relay it to the phone system - using whatever practical means). Pure browser based functionality won't be of much help, so you would absolutely need something plugin based.
Flash may work, seeing they provide access to the microphone, but please don't ask me about the details. I've never done anything like this.
Also, privacy would be a concern. While GSM data is encrypted, the path between client and server is not per default. And even if you use SSL, you'd have to convince your users trusting you that you don't record all the conversations going on, but this too is more of a political than a coding issue.
Finally, you'd have to think of bandwidth. Voice uses a lot of it and also it requires low latency. If you use a SIP trunk, you'll need the bandwidth twice per user: Once from and to your client and once from and to the SIP trunk. Calculate with 10-64 KBit/s per user and channel.
A feasible architecture would probably be to use a SIP trunk (they optimize on using VoIP as much as possible and thus can provide much lower rates than a GSM provider generally does. Also, they allow for concurrency), an Asterisk box (http://www.asterisk.org - a free PBX), some custom made flash client and a custom made SIP client on the server.
All in all, this is quite the undertaking :-)
You'll need a GSM library. There appear to be a few of these.
e.g. http://www.wirelessdevstudio.com/eng/
Have a look at the Ekiga project at http://www.Ekiga.org.
This provides audio and or video chat between users using the standard SIP (Session Initiation Protocol) over the Internet. Like most SIP clients, it can also be used to make calls to and receive calls from the telephone network, but this requires an account with a commercial service provider (there are many, and fees are quite reasonable compared to normal phone line accounts).
Ekiga uses the open source OPAL library to implement SIP communications (OPAL has support for several VoIP and video over IP standards - see www.opalvoip.org for more info).