I am looking for a list of ways of enabling peer discovery in mobile networks, preferably without centralising control. Obviously the different techniques have trade-offs, usually related to the scale/scope of the network.
My initial list includes:
Bluetooth - good for very limited range
Message Broadcast - good for LANs and private networks
Central server - good for internet scale networks
Are there any other methods?
If you want to communicate directly between two specific mobile devices, the initiating device can act as a temporary server (e.g., ServerSocketConnection) and SMS the IP address/port to the phone number of the other mobile device. The receiving device can automatically wake up upon receipt of the SMS through PushRegistry techniques, extract the IP address/port combo in the SMS message and connect to the server socket connection.
Related
So I have a PC connected to a micro-controller via a serial cable and an Ethernet cable. Initially the PC sends a byte across the serial cable to the micro-controller. This results in the micro-controller sending back a UDP datagram via the Ethernet cable.
I want to know whether the code running on my PC should be a server or a client?
Per Wikiepdia Client/Server:
The server component provides a function or service to one or many
clients, which initiate requests for such services
And Master/Slave:
Master/slave is a model of asymmetric communication or control where
one device or process controls one or more other devices or processes
and serves as their communication hub
The above scenario looks like the Master/Slave. In the initial, 'idle' case, there is no "SERVER" that is waiting ("listening") for requests. Only when the PC activate the micro-controller they will start communication (via UDP).
You could use either term depending on what you were talking about. As other people have noted, client and server are terms used to describe how distinct parties are involved in a service. The terms can be useful in some situations (e.g. a web server and the browser as a client) but in other situations it's a less useful term (e.g. peer-to-peer protocols).
Presumably you're on stackoverflow because you're dealing with code.
In this case it's useful to be more precise and I'd suggest using terms to match whatever primitives are exposed by your language. Most will use/expose Posix sockets as their standard API, and hence you'd want to talk about/use connect or accept (potentially after binding first). Note that these calls work across TCP and UDP (except accept), but the semantics of sending and recving on the resulting connected sockets will obviously be different.
I am trying to find out whether the machines in a network are running a certain app. More like, I am trying to resolve addresses of nodes in a network.
I built a small code based on ARP, but it works only on a local network(same subnet). What I want to do is resolve addresses out of the subnet i.e. all other nodes.
I read these answers: UDP broadcast packets across subnets
and Broadcast on different subnets
But they all talk about changing router setting or creating a multicast network.
From what I read for multicasting to work, I need to create a multitask network beforehand. Is it really necessary?
And for changing router setting, does it really have to be a "special" router?
This is all for a college assignment and would be demonstrating it probably on an ad-hoc network or something like that.
I am open to ideas to solve the original problem.
PS:
1. I am a beginner in networking so do excuse me for any fault or misinterpretation.
I am using sockets and C(No other option).
Edit 1:
I am well aware ARP is useless outside the subnet. I mentioned it because I used it and it helped explaining the problem.
Edit 2:
The original problem is:
Building a chat application, nothing fancy sending messages from one point to another, without using a central server of any kind. Not even a hybrid network with a central store is allowed.
i.e. if A and B are two clients, A should directly connect to B and vice versa.
I did some research and decided to use P2P architecture. And now I am stuck to how will A discover address of B. If I know the subnet of B, I can brute force and locate B but since I don't have such information what do I do?
ARP is not intended to be routed outside the local network, where in IPv4, the "local network" typically corresponds to a subnet. You should not expect ARP traffic to transit routers from inside to outside or vise versa.
Similarly, UDP broadcasts generally do not propagate outside the local network, and it's a good thing that they don't, for reasons related to both security and traffic volume.
From what I read for multicasting to work, I need to create a multitask network beforehand. Is it really necessary?
Basically, yes. Your routers need to be configured to support multicasting (which may be their default). All participants need to agree on and join the same multicast group. There might not be a need for any new networking hardware, but multicast communication has its own protocols and network requirements; it is not merely a broadcast that can traverse network boundaries.
And for changing router setting, does it really have to be a "special" router?
If you mean changing router settings so that UDP broadcasts are routed between networks, you do indeed need a router that exposes this capability. But I urge you not to do this, as it will let broadcasts from all other sources, for all other reasons transit the router, too. At minimum, this will significantly increase the noisiness of all networks involved, but it could produce bona fide misbehavior of applications and services other than yours.
The Limited Broadcast (255.255.255.255, which is used by ARP requests as the destination address, and ARP only works for IPv4 on the local LAN) cannot cross a router, and a Network Broadcast (last network address, where the host is all ones) by default cannot cross a router (Directed Broadcast) because it is a security risk (see RFC 2644, Changing the Default for Directed Broadcasts in Routers).
Some routers can be configured to forward directed broadcasts, but this can be dangerous.
Multicast is a form of broadcast. Multicast routing is very different than unicast routing, and every router in a path must be configured for multicast routing. Also, hosts must subscribe to a multicast group before they will even listen for packets from a multicast group. Additionally, there are some multicast groups that all hosts listen for, but those are link-local multicasts that cannot be forwarded off the local LAN.
Adding to what other answers have provided:
ARP is not useful for a system in another subnet. Even if you were able to send an ARP request to a system in the other subnet, and receive its response somehow -- providing you with that system's MAC address -- you could not use it to send a packet to that system because Ethernet does not provide a routing mechanism, and so the system will never see any Ethernet packet you address to it.
If you are simply trying to identify which systems within another IP subnet are live, you can probably do this by other means. Take a look at the nmap command, for example. It supports a wide variety of IP communications methods that will be routed to the other subnet and can often detect what machines are present and which services are available on the machines found.
And you can of course duplicate what nmap does yourself. For example, if you want to find out which systems in subnet 192.168.10.0/24 are listening on TCP port 80, one way is to simply attempt to connect to port 80 on each system in that subnet. In general, there are four answers you may receive back:
Connection success (No error: the machine is present and there is a program listening to that port)
Connection refused (errno ECONNREFUSED: the machine is present but there
is no program listening to that port)
No route to host (EHOSTUNREACH: there is no machine answering to
that IP address)
No response (ETIMEDOUT: several reasons why this can happen; for example, the system could have firewall settings causing it to simply ignore the request)
(And there are other less likely possibilities as well.) Using other IP access methods (ICMP/ping, UDP packets) will have a different matrix of possible results.
As others have explained, multicast mechanisms would only be helpful for discovering a set of cooperating machines that are pre-configured to join a multicast group.
I just spoke with a phone company in Denmark, that offer "Free 3G/4G", on the phone, but they have a limitation if you create a hotspot and share the connection, this limitation is on 50GB.
How do they detect if your mobile device is sharing the connection? Do they intercept some special headers that the computer/other phones send over the connection?
MAC addresses are used at a lower layer than IP and relate to each hop or leg of an end to end communication so they don't really help with this issue.
Detecting tethered devices is quite a complicated task and there are special solutions to do exactly this. They tend to look at multiple things to try to determine if other devices are using the mobiles connection, even if the devices are spoofing or manipulating headers etc.
Examples of things a solution will look at:
number of simultaneous sessions
HTTP user-agent headers
device type
device screen size
TCP Timestamp
TCP Source Port
TCP Sequence Number
Application-based correlation to TCP flows
Node-pair correlation to TCP flows
See here for an example solution and more details of the above (this is just one example solution):
https://www.sandvine.com/downloads/general/sandvine-technology-showcases/policy-control-for-connected-and-tethered-devices.pdf
We put the question to Three, which not too surprisingly declined to
answer. However, if you think about it logically, it should be fairly
simple to detect tethering. Every device with a network connection
(including Wi-Fi) has a unique hardware identifier called a MAC
address. Assuming that the operator can trace the final destination of
the data packets, it should be able to determine that the final MAC
doesn't match your phone's.
source
Although the post is about UK operators, it should apply in Denmark.
I am currently looking at designing an application protocol using the QP Framework to talk to several devices using a serial bus like Canbus or LonWorks.
My idea was to develop an active object that subscribe to a set of events and translate to commands in the serial bus. And using two types of messages; peer to peer and broadcast. Peer to peer will be a send and response protocol. Button press from a display device will use a peer to peer command while adc value like temperature change will use a broadcast message.
The other solution propose by a colleague was to implement network variables similar to LonWorks. This requires a module to monitor variables change on one device, and performing polling read on the other. This requires knowledge of variable address of the other device in the bus during initialization.
I am leaning towards the first solution as this seems simpler and fit nicely to an event driven paradigm.
It will be great if someone can share some experience using QP framework for multiple devices, and type of application protocols used.
Ryan
I'm trying to find a way to send a udp broadcast packets through a silverlight application. Most of the research i've done lists that this is not possible through silverlight due to the support for sockets being limited to tcp only. But is there some other way to send a broadcast packet for example through javascript or something that the silverlight application can call?
Silverlight 4 supports UDP for multicast.
Articles / Examples
example of using UDP multicast support in Silverlight 4
blog entry from the System.Net Team
Classes
UdpAnySourceMulticastClient
UdpSingleSourceMulticastClient
The only plugins that support UDP client sending is Unity3D or Java. The problem mainly is when you use UDP you also need NAT punchthrough usually. So it is more complex (need a third party facilitator) since typically it is also peer to peer not just client-server.
You might be able to rig something with a proxy with Unity3D or Java but that would be a serious slowdown passing it into silverlight.
Silverlight and Flash only support TCP sockets currently.. Flash 10 does have some support for RTMFP which is UDP based but that is primarily for flash media server integration.
A response on the support of UDP in Silverlight: http://silverlight.net/forums/t/20249.aspx
You'll probably need to create your own custom browser plugin to do that for you.
As far as I know it isn't possible to use UDP with the major browser plugins, Flash, Silverlight etc. TCP is the lowest you get.
Browser based JS does not give programmatic access to UDP or even TCP. That is why you have AJAX, HTTP binding, Comet, XMPP Bosh etc. They try to emulate TCP's features with HTTP...
It appears Flash supports UDP as of Flash 10. I haven't tried it out but it sounds like it is not a low level API, only through RTMFP.
http://www.flashcomguru.com/index.cfm/2008/5/15/player-10-beta-speex-p2p-rtmfp
http://justin.everett-church.com/index.php/2008/05/23/astrop2p/
Flash Player 10.1 supports P2P with Adobe RTMFP and Stratus service. Stratus service is a Beta hosted rendezvous service that aids establishing communications between Flash Player endpoints. Unlike Flash Media Server, Stratus service mainly focuses on network address lookup and NAT traversal services for Flash Player endpoints, instead of supporting media relay, shared objects. This kind of service will also be integrated into next version of FMS.
No there isn't. Most browsers limit you to HTTP or FTP so calling out to Javascript isn't going to help either.