I want to know how can I fetch the device details on a BB10 based device from C++ (details like Device Name, IP Address etc.)
thanks
Most should be found on http://supportforums.blackberry.com and https://developer.blackberry.com and their sub-pages. Your question is hard to answer, because your examples for needed information are from different kind:
device name is readable in bb::device::HardwareInfo
IP address is another kind of information and found in any network information object, which refers to your choosen network API (do you use QtNetwork or other?). But you will be able to find your way to the right information at the link above.
Note that the IP address in your network infomation object on the device will be the LOCAL network address, and this will in most cases differ from that seen from any server point of view. You have to use an implementation of "whatismyip" (you can find PHP and other implementation) on a server, which is called by your device to find out your external IP address.
Related
I'm not sure I've phrased the question correctly but I'll explain a bit more.
I have a server running on a virtual machine on PC1. I can access this through a particular IP address on the same computer.
Now on a different PC2, when I try the same IP address I see the content served by PC1's server. Both computers are on the same network.
I don't really understand how that IP address is serving the same info on PC2. I'm not sure of the mechanics in the background either and it would really help if someone could explain what's happening here.
If you are using a wifi network then it is because of it you can access the content of the server you have created.
You can see the architecture as that of the internet but on a small scale. Your IP addresses are stores in the wifi (routing tables) so that it can send packets accordingly (See hoping and packet transmission). To be precise, each and every individual system maintains a routing table in it. Thus, in order to fetch a particular site, a system sees its routing table. If the particular IP address is present, the router returns it and the system shows that page. On the contrary, if the IP address is not present the router asks the nearby systems/servers for that particular IP address and the phenomenon continues till the IP address is found.
So, when you search for a local server via system B, whose data is in system A, then the router requests all its child systems to search for the particular IP address in their routing tables, and thus you can access the local server via systems connected on the same network.
To add furthermore, since the local servers are known to be locally operated, the router just sends the seek requests to its child systems only and not globally.
I have tried to keep it as simple as possible supposing that you have not learned about computer networks yet.
I'm working on an Enterprise app that communicates with our company servers. I have full two-way communication between the phone and the server through 3G/4G, and it works from my home wifi, but using the wifi at the office where it is connected to the company network the app doesn't see the server that way.
The app is set to look for our external IP address, and the port is open to the server. But I guess the external IP address is not 'visible' from within the network. When I plug in the internal IP address of the server, it goes through just fine.
For the vast number of our users, that would not be a problem. Most of our users (employees) work in the field or in other offices. But for users inside our network, this arrangement is useless unless the user turned off his wifi. But that's not a professional way to do it.
I need to know if there's a way for my app to either use 3G/4G exclusively, or to discover the SSID of the wifi and decide which IP address to use. I'm guessing that the answers to both of these will be, "you can't do that," But I thought I'd ask anyway.
Thanks!
You could have it attempt the internal IP, and fall back to the external IP if it can't connect. A better solution might be to have an internal DNS server that serves the internal IP to in-network devices, though.
Well, I discovered this code is exactly what I need. It gives me the SSID in string form, and I can compare the SSID string with a string of our wifi's SSID, and if it matches then the app uses the internal IP address. And if it doesn't match, it will connect to the external IP address. So far it works perfectly!
Followup: ceejayoz, I don't know if your second suggestion is the same as what our IT guy did, but he created a domain name that will resolve to the server whether it's internal or external. That seems to be the best way to go. So even though I had a workable answer, the URL works better with less code.
I've read tons of questions about this all over the web, and can't seem to find a solid answer. If I have an iPhone that's running on cellular data and another iOS device on wifi (in two separate locations), is it possible for them to send data to each other directly without sending it first to a web server, then retrieving it? Are the only options sending and receiving from a server/Apple's iCloud? What if I knew the devices' ip addresses? Note that the iPhone has WiFi disabled.
I'm not looking to put this in the app store, it is for personal use. I know NSNotificationCenter isn't an option.
Using the gamekit framework you can send data between two iOS devices. It is easy to implement. Other than that I don't think there is any other way to send data between two iOS devices.
Actually, it IS possible. You may want to google for something called "UDP hole punching" or "TCP hole punching".
The main approach in short: Assuming you got something like a relay server, that is some server in the internet that is publicly addressable from every private LAN that is connected to the www. No you have your two clients A and B in (different) private LANs, with some Network address translation (NAT) going on, that want to establish a peer to peer connection.
First of all both will tell the server their IP address and the port they have in their own LAN. In the UDP or TCP packet, the server will find the public address and port of the device (or the NAT (router)). So the server knows the private and the public IP address as well as the ports.
If now A wants to communicate with B, it asks the server for help. The server will send a message to B that A wants to communicate with her telling her A's public and private IP and port. A gets back B's public and private information and port.
Now here is where the magic happens. Both clients now send packets out to establish a connection simultaneously to the private and public addresses of the other party and thus punching a whole in their NATs such that incoming connections will not be blocked. Even if one party's connection establishing packets will arrive before this whole is created, the other's packets will get through to such that a connection can be created.
Beware of some NATs that scan the data for IP addresses and translate them as well, but if you encrypt your data or change the appearance of the address (complement, ...) you will be fine.
Now the master question, how can the server communicate with one of the clients without an active connection. Well in this case you can use "connection reversal" and apple's "push notifications". Use the "push notifications" (pn) to tell a client behind a NAT that there is something of interest going on and that it should contact the server. Once it has done that the connection is active and can be used in the previous described fashion.
I hope this helps some people that get to this problem although the post is quite old!
You can only use direct IP address communications if the IP address are publicly reachable IP addresses accessible over the internet, and they are static (enough) so that they are not changing on you regularly as devices get assigned to addresses dynamically. In many (most) cases, that won't be true because your devices will be assigned their IP address dynamically and those addresses are frequently going to be self-assigned IP addresses that aren't publicly addressable.
As others have commented, using Apple-provided mechanisms like iCloud are probably the easiest options. If that's not something you'd like to entertain, there are probably ways to make use of a dynamic DNS service like DynDNS to manage the actual IP addresses of your devices. With something like that you might be able to use a direct IP connection between devices based on a named DNS lookup. You'd probably have to jump through some hoops to make that happen though and I'm not sure you'd want to go to that extent.
I think that Bluetooth would be a good option for you
Writing an iPhone app in which I want to save the user the grief of typing in IP addresses by finding other clients on the local network.
Is this possible?
If so, what is the preferred way of doing this?
Yes, use Bonjour. See NSNetService.
This class is used to advertise information about the service you're running using multicast DNS. Use NSNetServiceBrowser to find published services of the type you're interested in.
The clients need some way to register with the server. Or you can use portknocking. Long time back there was a protocol from Novell SLP. There is a OpenSLP now. Found a interesting link, I hope this helps
http://www.opendoor.com/shareway/slp.html
Using services like http://canyouseeme.org/ one can find out whether a particular port is open and his (public) IP is reachable from outside world.
Assuming I have my (expected) public IP and port, is there some easier or more reliable way to check my reachability than e.g. calling canyouseeme.org ?
iPhone's don't have a public IP (as far as I know).
Using 3G coverage you get allocated a local IP on your networks WAN.
Using WiFi you get allocated a local IP from your router.
Therefore I doubt you'll ever be able to truly identify your iPhone using an IP you think is associated with it (but probably isn't)