I have read an article named "Content-centric Routing in wifi direct multi-group networks",in this article,it told us the method to implement inter-group communication ,but I couldn't implement it with program in android device ,if some one who has interest in this problem ,please contact me!!!!!
First, for those without IEEE Digital Library access, here is a link to the Arxiv PDF of this research: http://arxiv.org/pdf/1412.0880v1.pdf
The Wi-Fi Direct specification allows for a legacy device (i.e. a device without Wi-Fi Direct) to connect to a Wi-Fi Direct GO using its Wi-Fi interface. The authors of this research have used this to allow a GO to be a client in another group. So the GO has clients on the P2P interface and also connects to another GO using its legacy Wi-Fi interface.
To implement this, you will need to do the following:
Allow GOs to acquire their Wi-Fi Direct group passphrase/key.
Distribute the passphrase securely to other GOs.
Allow GOs to using a legacy Wi-Fi connection to connect to other GOs.
As the paper describes, there will be IP address conflicts, so messaging between all pairs of devices will not be possible at the IP layer, e.g. the client of one GO will not be able to communicate with the client of another. To overcome this, you will need to implement a messaging layer at the application layer.
First, from the documentation, we know that we can start a P2P Group that can accept legacy connections using the WifiP2pManager.createGroup (WifiP2pManager.Channel c, WifiP2pManager.ActionListener listener) method and its details can be fetched using WifiP2pManager.requestGroupInfo (WifiP2pManager.Channel c, WifiP2pManager.GroupInfoListener listener). The onGroupInfoAvailable(WifiP2pGroup group) method of GroupInfoListener allows us to access a WifiP2pGroup object that represents the group. WifiP2pGroup.getPassphrase() will retrieve the group's passphrase. Now that we have the passphrase, we can distribute this to other GOs that wish to connect to this group's GO by Wi-Fi.
wifiP2pManager.requestGroupInfo(channel,
new WifiP2pManager.GroupInfoListener() {
#Override
public void onGroupInfoAvailable(WifiP2pGroup group) {
if(group != null){
// clients require these
String ssid = group.getNetworkName(),
String passphrase = group.getPassphrase()
}
}
});
Having distributed the passsphrase, a GO can connect to another GO programatically, as described in the answer to How to connect to a specific wifi network in Android programmatically?.
Related
I have a SIM800C GSM module that I want to use to make a server. I am really confused about knowing the public IP address. In order to make people to connect to any server is that they need the correct public IP address and the correct port, and of course the correct protocol (TCP, HTTP and so on..).
There is already a command to get the local IP address (AT+CIFSR); in case I make a server and I want to let my friends connect to it, I need the public IP address. How do I get it?
I searched on the internet but found nothing.
AT+CIFSR (as well as the standard command AT+CGPADDR) returns your IP as soon as you activate the PDP context. Unfortunately, if it is public or not depends on your operator. In fact, due to the need to face the IPv4 address exhaustion they often perform a Network Address Translation (NAT) that will actually provide a local IP to your device.
As a consequence, your device won't be reachable for communications that are not device-initiated, and you won't able to create a public server at all.
So, that's not a public IP opposed to a local IP: there's just the IP you obtain from the network. If doesn't perform NAT, then the IP you obtain with AT+CIFSR will be the public one.
Design work-around
Usually the NATted IP limitation is faced with a design trick
A wake-up SMS is sent to the device hosting the server. The SMS can either be a basic one (just text containing data relevant to the application) or a special SMS type (Wap Push notifications).
As soon it receives the SMS, the device starts the server and sends some data to the remote peer
This will result in a device initiated communication, so from the network side the NAT will be opened and the device will be temporarily public.
After a certain inactivity time (operator dependent) the NAT will be closed again
"Commercial" solution
If the design solution is not feasible, there's another option involving the purchase of special (and more expensive...) SIMs specific for M2M and IOT applications:
SIMs which will always obtain a public IP
SIMs which will always obtain a public fixed IP
If I establish a connection with a friend on Skype, the audio and video data does not go through Microsoft but directly. I also have a p2p client X that does a similar thing. I do not fully understand how this happens internally. How does a machine establish the connection with the other if there is no direct identifier such as a public IP address? Multiple computers in the same network can each do p2p or Skype calls at the same time.
I have been wondering about this for a week because I want to connect two Nodes with each other (like a socket server/client). Can you point me in the right direction?
If two clients want to connect, but neither knows the address of the other, some sort of intermediary that they both know has to be in place to help set up the connection. They both contact the intermediary with the desire to connect, the intermediary tells them both what the others direct address is, and the connection can be set up directly.
Sometimes (read: always) one or both machines share a public IP with others behind NAT, and NAT traversal techniques are needed to establish end-to-end connectivity, usually some form of ICE or SIP.
I think about the following setup, but I do not know how to connect the main parts.
One the one side there is a Kamailio SIP server. This server provides VoIP connectivity within a certain network (non public intranet).
On the other side there is a SIP provider. This provider provides a single telephone number from the PSTN. Let's say the number is 0034-443322.
Both components are working fine so far.
I want to use that number as a dial-in to my private network. A user with number 8282 in my network should be reachable via 0034-443322-8282 from the outside world. Outgoing calls aren't necessary.
How to reach my goal? I don't know what to look for :/ Any ideas are very welcome :)
kind regards
K.A.
If your PSTN gateway can be reached by dialing the full number (including the extension), simply let the gateway forward every incoming call to your Kamailio instance which will forward the call to the appropriate user. For that, you need to create your users (known as subscribers in Kamailio) and they need to register to your Kamailio instance so that they can receive incoming calls. Regarding mapping extensions to users, you can simply let the extension be the username; or you can add extensions as aliases of the subscribers.
At the bottom, it's all about socket communications. If there is some way to get the ip of the both users, why can't the connection be directly setup between the users instead of having to go thru a server in the middle?
My 2 cents:
No one out there forces us to have a server based real-time communication model. Infact XMPP have an extension called "Serverless Messaging" which defines how to communicate over local or wide-area networks using the principles of zero-configuration networking for endpoint discovery and the syntax of XML streams and XMPP messaging for real-time communication. This method uses DNS-based Service Discovery and Multicast DNS to discover entities that support the protocol, including their IP addresses and preferred ports.
P2P chat applications have been for over a decade now. Having a server in the middle is purely a decision dependent upon your application needs. If your application can live with chats getting lost while the user was transitioning between online/offline status, then you can very well have a direct P2P model going. Similarly, there are a loads and loads of advantages (contact list management, avatars, entity discovery, presence authorization, offline messages, ....) when it comes to choosing a server based messaging model. If you try to have all this right inside your P2P based clients, they might die or under-perform because of all the work they will need to perform by themselves.
"WebSockets" were not designed for P2P/Serverless communication, rather they were designed to provide a standardized PUSH semantic over stateless HTTP protocol. In short, "WebSockets" is a standardized way replacing hacky comet, long-polling, chunked-encoding, jsonp, iframe-based and various other technique developers have been using to simulate server push over HTTP.
Named WebSockets (if someday it is fully and widely supported) could be the solution.
http://namedwebsockets.github.io/spec/
Named WebSockets are useful in a variety of collaborative local device
and local network scenarios: Discover matching peer services on the
local device and/or the local network.
Direct communication between users is possible in Peer To Peer (P2P) networks. In P2P each participant can act as client as well as server. But for P2P networks you need to write a separate program to make the communication possible.
Web Sockets let you leverage existing common browsers as clients. All depends on what is the purpose of your application and how you want to deploy it.
If there is some way to get the ip of the both users
You nailed the answer right in your question.
Most machines I use have IP address of 192.168.0.10 (or similar from 192.168. private network) and are deep, deep behind several layers of NAT. With the end of free IPv4 address pool and IPv6 nowhere near sight, this is the reality most users live. Having a stable intermediary of known, routable address helps a ton working around this issue.
WebSockets don't allow the socket to listen for connections, only to connect as a client to a server (not reverse). Technically they could make it allow this, but as far as I understand the spec doesn't currently (nor is it expected to) allow listen functionality for WebSockets.
The new WebRTC (http://www.webrtc.org/) spec looks like it might support peer-to-peer connections. I have not played with WebRTC at all so I'm not in a position to comment on it. I think it would be a bit more involved than WebSocket stuff. Maybe someone who knows WebRTC better can chime in. (Also apart from the latest version of Chrome I'm not sure if any of the other browsers really support WebRTC yet).
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