I'm programming an android application that uses Wifi Direct. I'm trying to start my service and I'm calling WifiP2pDnsSdServiceInfo.newInstance. However, I have been searching for the different service types that I could use, and so far I have only found "_presence._tcp".
I understand that I should somehow find a service type that "makes sense" with what my application tries to accomplish. Can I just "invent" it? Is there any available list of protocols?
Thanks a lot!
Android documentation provides some info to start with in the guide Using Network Service Discovery. According it the service type specifies which protocol and transport layer the application uses. The syntax is _<protocol>._<transportlayer>. So you should only use existing transports in the second part. Most commonly used are tcp and udp, of course.
As for the first part, there is a bunch of application level protocols. For example, presence is a messaging protocol from xmpp.org, and ipp is a printer service. You can find more or less complete list of the registered protocols at the dns-sd.org site. Also you may have a look at the service names registry at iana.org.
As the DNS-based Service Discovery is a part of Zero-configuration networking which has numerous implementations, additional lists of protocols can be found on specific vendors sites. For example, here is the list of Apple's Bonjour service types.
I don't think there exists a single exhaustive list of protocols used worldwide. Nevertheless, I suppose you could invent your own name with a reasonably distiguishable underlying structure (acronyms and/or semantics) - just search through the Internet and make sure your name does not appear in relation to Zeroconf and DNS-SD.
Related
I've made app that allows me to connect to bluetooth le device and lists all services and characteristics. However the only recognized service is 'Device Information Service', there is also 'Unknown Service' but it doesn't seem to pass data that im looking for. I'm sure that device is working properly because official app that was attached to the device works fine. What could be the problem? Is it possible that information that im looking for are passed in unknown service and are somehow encrypted?
Your app correctly discovers the services, the problem isn't there. The problem is that you expect the service to be a generic one but it isn't, it's a vendor specific service.
A vendor specific service (characteristic) is easily recognizable : Its UUID is 128 bits long. Also it's not resolved by generic BLE apps such as nRF Connect for the simple reason that they are specific and not generic.
When a company sells a device that implements generic services, they know that it will work with multiple applications but they also know that these applications will also work for the other devices from their competitors. By example, you can buy a heartrate belt from several companies and use them with several fitness apps on your smartphone.
When a company sells a device that implements vendor specific services, they know that it will not work with another application than their own one and that not any competitor will be able to sell a device that also works with their application.
Two different strategies, many different goals.
Basically, the company that designed the device you are playing with did not want you to be able to use another app than their own app to access the data in the device. It's that simple.
Now you still can reverse engineer their service. Use a sniffer, compare the data transferred when using their app with the data actually displayed in the app and maybe you'll find some logic, and learn the hard way how they have hidden the data in their service. However they probably have some clause stating you shall not reverse engineer this or that.
You can see the generic services here, but you won't learn anything more than what I've said : BLE GATT Services
I searched in many topics and forums. But i still don't find the way to do this.
How can we set the wifi direct request connection message.
And so.
How can we set the peer info list to see not just is android ID, but things like a pseudo, a player level or rank, etc...
Any help is welcome.
Thanks.
short answer is: You don't.
Basically the peer list shows just peer information. If you need more then you need to do Service discovery after the peer discovery. Though if you do just quick discovery, then its rather safe to do only Service discovery. For reference see my blog article
With service discovery you could deliver data wither via Bonjour or UPnP.
With UPnP limitations for data delivery are summarized in here.
And with Bonjour you could either deliver some 100 bytes of data via instance name variable in service advertisement, or have data added to Dns-Sd records. The limitations are summarized also in my blog.
I'm implementing the wifi p2P (direct wifi) in my android application, in order to share small files between clients.
I'm following these pretty good tutorials:
http://developer.android.com/guide/topics/connectivity/wifip2p.html
http://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html
I can now discover peers and connect to them.
I'd like to know if there is a way to filter the discovered peers. The first thing I'd like is to show only the peers who are using the same application. Indeed, currently my application show me all peers (phones, tablets, printers with direct wifi). I think it would be easier for the user to only have the compatible peers (peers also using the application).
If this work, I'd like to improve this and only show peers who ave accepted to share their files (a client can receive files or/and share their own files if he had activated it)
So, is it possible to do these types of peer filtering?
Thank you.
There is a way to achieve this ...
Adding Network Service Discovery (NSD) to your app allows your users to identify other devices on the local network that support the services your app requests. This is useful for a variety of peer-to-peer applications such as file sharing or multi-player gaming.
first you need to do
1.Register Your Service on the Network
2.Discover Services on the Network
3.Connect to Services on the Network
4.Unregister Your Service on Application Close
Take a look here.
So using NSD your app will only see devices that supports the services your app requests, cool isn't it..?
I will get back to you if I come up with some intelligent logic for the second part.
The current version of android supports multiple APNs but does not support multiple active PDP contexts. Why had Android choose not to go down this route? And is it planned in future releases of the android platform?
The background to my question is that my application needs to communicate over a special APN. But when I do this I lose connectivity for all other running connected applications on my device.
Does anyone have a cleaner approach to solving this issue?
My suggestion, why Android does not support multiple active PDP contexts is that Android is based on *nix, and networking is based on classic sockets. If take looks sockets API, there's no PDP contexts.
Solving the issue.
At first one may ask himself: why do he need to send data through special APN. Special APN usually is used to connect to "Private Garden" networks, usually, corporate LAN. Other words, APN is kind of VPN, but in terms of GSM technology. Why one like to use VPN? In many cases, to protect data while transferring.
The APN or VPN is not the only solution for such purposes. You can use SSL: it will ensure that data is encrypted and remote host is not faked. And when using HTTP over SSL, ability to delivery data is much higher because access to the Internet from many networks is provided by proxy server.
Using multiple PDP-context cannot be compared simply to VPN. A PDP context can also be use to request better QoS from the network in the case of a voice application for example.
As far as I know, this is still not supported by Android nor by IOS, except when it comes to VoLTE and MMS where both those services run natively on distinct APNs.
can anybody confirm what are the currently allowed methods for peer-to-peer communications within the Android framework? I need to transfer json strings and I'm currently using SMS which works ok but the problem is that the data also ends up as lots of text messages. I've read Reto Meier's first edition of Professional Android Application Development where he says that the data transfer options were not implemented due to security concerns.
Has this changed at all and how would you do peer-to-peer transfer of data?
Have you looked at Qualcomm's AllJoyn library? It is designed to work over Bluetooth or wifi, so may fit, though if you're connecting over 3G or wider range networks it won't work.
Given the variation and reliability of networks between two remote devices not on the same network, I'd question whether peer-to-peer is the best solution, and would venture to suggest considering using an application server in between, so you could then use Cloud to Device Messaging [deprecated] (perhaps in tandem with Google App Engine). i.e. to send a message the sender passes it to the server, and the server then passes it on to the recipient.
In theory all devices on the net have a unique IP address and can talk to each other, but it's rarely that simple as routers/firewalls are configured differently so you'd need to pay great attention to the ports you use, especially considering many inbound ports are blocked by default for security reasons.
You can simply use UDP/TCP sockets. In a separate thread you set up the server-side listener socket and that's it. Of course your application has to be started first (or should run in the background all the time). Here's an example:
http://thinkandroid.wordpress.com/2010/03/27/incorporating-socket-programming-into-your-applications/
If you also need peer discovery that will make the thing more difficult.
You should also take a look at peerdroid, an open source project available here. I've been looking in to peer communication options from the point of view of having a collection of federated devices (pre-paired, if you like, similar to Bluetooth pairing); this library looks like it may give you the foundation for what you are trying to do.
If you are on your own network (for example a home or office WiFi) then you should be able to query for other connected devices. If the network you are on is not under your control (the mobile network or a public wifi) then the network will have been configured to isolate each device from everything else. In this case you will have no choice but to put a server up to act as the man in the middle. That brings its own architectural compromises - every device has to regularly poll the server or keep a connection open - unless you use Google App Engine which supports push notifications over Google's own infrastructure.
Thanks for your answer ldx but I would need peer discovery as you indicated. Some further research appears to indicate XMPP as a suitable technology and there are now some services on offer, although these appear to be aimed at 'server' to client notifications. There is a good discussion here on XMPP and some more here although it would appear that there are still some issues to deal with such as polling v push, long-running open http connections and battery life. Xtify looks promising, especially their web service. I hope this provides suitable information to others looking at the topic of peer-to-peer data communication.