I was thinking about a project the other day and an idea stumbled across my mind:
How would you set up a server, for instance at a restaurant, and have an app of the restaurant chain which finds and directly connects to the locally running server without being in the same network. This should work at higher ranges, so simple Bluetooth is not fitting here.
I've done some research, but I'm not very... good with protocols, and nothing I've found seems to really fit that goal. So I'm wondering what the best way to code this connection would be. Any ideas would be helpful :)
Here are the requirements:
A standard phone should be able to perform the operation.
It should have a fairly high range, think a big store or restaurant.
Server and device do not have to be in the same network.
The connection get's established by the phone on app start, to a server that can do whatever it needs to get this done.
Related
Does iOS store DNS and if so, how do I reset it after a server transfer? I have an App that is released, and before I migrate by server to a different IP, I want to make sure I know if the people using my App will have any issues with the API calls in the App. Any knowledge would be appreciated. Thank You for your time!
I'm a DNS expert, but not so much for iOS. So this answer is how the DNS is intended to work. I can't say whether or not iOS got this right (but they have a better reputation for rightness than some others I won't mention).
In the DNS each RR (that's Resource Record, the basic unit in the DNS, your address [assuming you only have one] is in a single RR) has a TTL, which specifies how long it will be good for. In normal operation you set these to a fairly long time (at least a few hours, often several days). When things aren't changing, this says how long the DNS client should hold the data before querying again. When you're contemplating a change, you set the TTL down low (say a few minutes) in advance, and then you can make the change at the right time and since no hosts should hold on to the old data for longer than that lowered TTL, you know that everyone should have the new data within that time. The reason you use higher TTLs normally is to lower the demands on both your server and your (and everyone who connects to you) Internet connection.
I am writing an app that is suppose to work without a connection to mobile carrier and without local WiFi. Each device will act as transmitter, receiver and router.
My main challenge so far is that I cannot figure out how exactly MultipeerConnectivity works as documentation on MC is really limited. Apple denied revealing technical specification of MC claiming it's a proprietary network stack, so I have to rely on network sniffers and reverse-engineering which is not the quickest way to figure out how MC works.
Suppose I have 100 devices forming a mesh network in such way that each device is within the range of at least one other device and at maximum three other devices.
Is there any way to send a message from node A to node B that is not within the range of node A without the need to broadcast the message to all other nodes? I mean that message should be properly routed through all other nodes.
Does MC include a routing layer too or I have to write it myself?
From what I can see ad hoc delay tolerant wireless networks is still a hot subject in research.
These slides on ad hoc delay tolerant wireless network shed more light on the subject as it was a few years ago. And also this paper. Has Apple progressed it much with MC?
I cannot really see any way to send a message between nodes not directly connected to each other without flooding.
Correct?
The MCSession Reference states that
Sessions currently support up to 8 peers, including the local peer.
Also, the overview you cited says
In the discovery phase, your app uses a browser object […] to browse for nearby peers[.]
Moreover, the documentation on managing peers manually suggests that all peers in a session must be connected with each other to have them in a session.
This is suggesting that the framework only covers the communication between nearby devices, as in 'reachable by bluetooth or WiFi'. Naturally, those devices do not need complex routing, as they do communicate with each other and the benefit of the framework is simple multicasting between nearby devices, from a programmers' point of view.
As far as your question goes, this is about it - trivially, since all peers an a MCSession have links to each other - there is no routing needed.
This does however, allow you to construct a routing layer pretty easy.
Given your scenario, there will be multiple MCSessions with devices being part of at least one. All devices that are part of more than one MCSession do become routers and interconnect the MCSessions with each other.
The rest of the task should be straight forward; defining a namespace for addressing devices and implementing a routing protocol of your choice.
The old days of the internet, with unstable dialup connections, might be a plus factor for you as the routing protocols in place are rather stable in regards of link loss.
Here are two good starting points for you to make your choice of better fit:
Link state routing
Distance vector routing
I am writing an application that keeps track of content pushed around between users of a certain task. I am thinking of using WebSockets to send down new content as they are available to all users who are currently using the app for that given task.
I am writing this on Rails and the client side app is on iOS (probably going to be in Android too). I'm afraid that this WebSocket solution might not scale well. I am after some advice and things to consider while making the decision to go with WebSockets vs. some kind of polling solution.
Would Ruby on Rails servers (like Heroku) support large number of WebSockets open at the same time? Let's say a million connections for argument sake. Any material anyone can provide me of such stuff?
Would it cost a lot more on server hosting if I architect it this way?
Is it even possible to maintain millions of WebSockets simultaneously? I feel like this may not be the best design decision.
This is my first try at a proper Rails API. Any advice is greatly appreciated. Thx.
Million connections over WebSockets, using Ruby, I can't see its real if you not using clustering to spread connections between different instances to handle all the data processing.
The problem here is serializing and deserializing data.
As well you have to research of how often you will need to pull data to client from server, and if it worth to have just periodical checks using AJAX, then handling connection for whole time. Because if you do handle connection and then you not using it - it is waste of resources. WebSockets are build on top of TCP layer, and all connections are not "cheap" as well going through for OS and asking them for data available again is not the simple process, with millions connections it is something really almost impossible without using most advanced technologies in the world.
I head that Erlang is able to handle millions of connections, but I don't have details over it. As well connection is one thing, another is processing data and interaction between connections - this you might want to check, because if you have heavy processing algorithms, then you definitely need to look into horizontal scaling options over clustering solutions.
If you are implementing chat, use websockets.
If you are implementing 1 way messages in realtime use server sent events.
If you are implementing 1 way messages sent every few hours or so, use APNS.
The saying goes phone in hand, use websockets / server sent events.
Phone in pocket, use APNS.
APNS will alleviate wifi dips, tcp/ip socket hangs and many other issues. Really useful. There is the chance that it may take a little time to get through. But then again, there is the chance that websockets will take
Recent versions of iOS let you send APNS to the client without a popup message to the client so it can ask the server for more information. That along with some backgrounding implementations really improves things.
If possible, do not implement totally anonymous clients. It is very tricky to detect if a client reinstalls the app. So you'll end up sending duplicates to the client. Need to take that into account.
APNS looks trivial to implement in ruby, but I'd suggest avoiding the urge and going to using an existing gem/service out there that supports both google and apple. It is much trickier to implement than it may seem at first.
If you decide to stick with websockets, it may make sense to just leverage websockets in nginx like https://github.com/wandenberg/nginx-push-stream-module
ASIDE:
Using SMS where speed is critical is very expensive. $1/month per phone number only sends a max rate of 1 message per second. So sending 100 messages per second = $100/month plus message fees. Do note that 100 messages at a rate of 50 messages/second = $50/month. But if you want to send 1k messages, that takes 20 seconds.
Good luck
Hie members! ----am Boniface M - - a beginner in android[University student]..
My question is am planning to develop an android app/middleware that will act as a grid service .i.e an app for grid computing.. the application needs to be installed in 1....n devices. in the connection, one device must act as a server for all others. communication between the devices is via the wifi under the permission of the server device.which is determined by a certain algorithm[no problem here].
The problem is should i use a database that will keep track of all the services a device is running which are accessible to other devices or is there any way that i can directly keep all this information and then retrieve them as i request them from another app installed in another device.
and also how i can share files via wifi like blutooth
Thanks....
You're asking many questions in one and I'm actually unsure what you mean overall. Here's a few links that are sure be of some use...
http://developer.android.com/reference/android/os/Build.html This library is good for finding out information about the device you're running on.
http://developer.android.com/reference/android/location/Criteria.html - Criteria might be useful, lets you know what location based services you have running
Other than that, if you're looking to see if particular things are running check out this question: How to check if a service is running on Android?
If you're looking to keep a central hub of what devices have what available etc. you're going to need a middle man for what you want to do I suspect. If it was me, I'd do HTTP requests to a server, to php scripts I have written which would then read/write from a MySQL database to get information about other devices.
If you want to share files via wifi.. you're going to need an FTP server on the phone. There's an app swiFTP which does this to some degree (phone -> PC) but the concept should be the same. Take a look at it. It's a starting point! http://www.tested.com/news/how-to-transfer-files-wirelessly-to-your-android-phone/53/
Again, I'm unsure EXACTLY what you're looking to do but hopefully all of that is of some help. If it's not leave me a comment and I'll try and assist you further.
hope it helps!
is it easy to write a script to test whether the network is ever down for the next 24 or 48 hours? I can use ssh to connect to a shell and come back 48 hours later to see if it is still connected to see if the network has ever been down, but can i do it programmatically easily?
The Internet (and your ethernet) is a packet-switched network, which makes the definition of 'down' difficult.
Some things are obvious; for example, if your ethernet card doesn't report a link, then it's down (unless you have redundant connections). But having a link doesn't mean its up.
The basic, 100 mile view of how the Internet works is that your computer splits the data it wants to send into ~1500-byte segments called packets. It then, pretty much blindly, sends them on their way, however your routing table says to. Then that machine repeats the process. Eventually, through many repetitions, it reaches the remote host.
So, you may be tempted to define up as the packet reached its destination. But, what happens if the packet gets corrupted, e.g., due to faulty hardware or interference? The next router will just discard it. Ok, that's fine, you may well want to consider that down. What if a router on the path is too busy, or the link it needs to be sent on is full? The packet will be dropped. You probably don't want to count that as down.
Packets routinely get lost; higher-level protocols (e.g., TCP) deal with it and retransmit the packet. In fact, TCP uses the packet drop on link full behavior to discover the link bandwidth.
You can monitor packet loss with a tool like ping, as the other answer states.
If your need is more adminstrative in nature, and using existing software is an option, you could try something like monit:
http://mmonit.com/monit/
Wikipedia has a list of similar software:
http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
You should consider also whether very short outages need to be detected. Obviously, a periodic reachability test cannot guarantee detecting outages shorter than the testing interval.
If you only care about whether there was an outage, not how many there were or how long they lasted, you should be able to automate your existing ssh technique using expect pretty easily.
http://expect.nist.gov/
Most platforms support a ping command that can be used to find out if a network path exists to an IP address somewhere "else". Where, exactly, to check depends on what you are really trying to answer.
If the goal is to discover the reliability of your first hop to your ISP's network, then pinging a router or their DNS regularly might be sufficient.
If your concern is really the connection to a single node (your mention of leaving an ssh session open implies this) then just pinging that node is probably the best idea. The ping command will usually fail in a way that a script can test if the connection times out.
Regardless, it is probably a good idea to check at a rate no faster than once a minute, and slower than that is probably sufficient.