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.
Related
I'm developing an app which uses Wi-Fi direct to connect devices. I read how to connect, send data and disconnect the devices here: http://developer.android.com/guide/topics/connectivity/wifip2p.html. Now, I'd like to send some data BEFORE the connection, in order to show some informations about the device. I've Googled this but the only answer I've found is this: Sending data in Android WiFi Direct service discovery instead of connecting, which uses services discovery.
Is there a way I can send data before the pairing process without using the service discovery? If I can't, can you explain what is the difference between service discovery and normal Wi-Fi P2P?
Thank you.
Unless you have some other medium you can rely on (e.g. some sort of back-end you can use to exchange information), you will need Service Discovery.
I have already written a few answers regarding WifiP2p and Service Discovery, and I suggest you take a look at them first. The last one should probably interest you the most.
Why is discovering peers for Android WifiDirect so unreliable
Wi-fi P2P. Inform all peers available of some event
Wifi P2P service discovery works intermittently
To answer your question about the difference between WifiP2p and ServiceDiscovery, let me use a small analogy:
Imagine you're at the airport, you've just landed in a foreign
country. You're leaving the duty-free zone and you see all the people
that are waiting for people who have landed at the airport just like
you did. You need to find your taxi driver. You know he should be
waiting for you with a small piece of paper with your name on it. You
can see many guys like that, every single one of them is holding a
piece of paper with a name on it. You need to read through many of
them until you find the one with yours. But you don't have to talk to
all those people. You will talk only to your taxi driver, and you will
probably tell much more than just your name.
Now let me explain... Every single person holding a piece of paper represents a Broadcasted Service. Every broadcasted service can carry a small piece of information (a person name). The space for the information is very limited (you can't write much on the paper), and is "relatively permanent" (it takes a bit to change it). When you were searching for the right person, you were performing a Service Discovery. You did not have to talk to all those people to read the names on those pieces of papers - you didn't have to connect to them (WiFiP2p-wise). When you found the one you were interested in, you talked to the man - you established a WiFiP2p connection. Now you can talk to him as much as you want - you can pass as much data as you want through the connection.
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.
There are several choice for making a WiFi program in android, most common methods are using NSD and WifiP2pManager.
What is different between these 2 choice?
Firstly, these are not two entities to be differentiated. Even if you use Wi-Fi P2p for NSD, you should use WifiP2pManager for connection initiation and negotiation. NSD is to be used for Discovery phase
I assume your question to be difference between Using Wi-Fi P2p Service Discovery(NSD) and Not using it (using normal scan WifiP2pManager.discoverPeers() ).
The answer is explicitly provided here under three sub-topics. However
The difference is actually in the initial phase: The peer discovery phase
When you don't use the Wi-Fi P2p Service discovery, you scan for all
devices that are active with WiFi direct. The scan result list may contain peers that are not of your interest. You can't help it, as you do not have a filter.
In the case where you need to discover only peers that are of your
interest, then Wi-Fi P2p Service discovery should be used. Here, the
filter condition is set in the name of Service.
For ex: your app "XYZ" needs
to form groups ONLY with other devices that also use the same app
"XYZ", then you can create a service and name it, say service_xyz,
and this service info will be broadcast along with the Wi-Fi Direct
device details. On the receiver end, you implement a service listener
that listens for the service "service_xyz". By doing so, only devices
with the desired service name are discovered and listed. Useful for
gaming apps, social networking apps.
However, after this phase, in both the methods, from the discovered list a particular device is selected and connect request is initiated. From here on, the following phases are the same - connection request, negotiation, group formation...
hope this helped you.
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.
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.