I need to send int and double values from one computer to another. The two pc's are connected to the same wireless network and the values I get are generated by a Matlab code. Can this be done in Matlab or do I need to use a medium between the two?
Sending data over WiFi is basically the same as sending it over any network. You'll need the other computer's local IP address (various ways to find this on different operating systems, ask google). You don't want to use an external IP address like this, since this would usually require you to change some settings on your router (e.g. port forwarding).
Once you have a local IP address, you could use something like Sockets - Loren has a good blog post.
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 have a Dell desktop machine with one ethernet port and one NIC.
I need to use ethernet connection for two completely different purposes.
One is to get internet access via LAN and read more stackoverflow.
The other is to talk to my FPGA eval board and send/receive data
using ethernet.
Is having two NICs a good option, a splitter box externally connected or any other solutions for this kinds of usecases?
(I do not want to mess or change the configurations everytime I switch between internet to eval board with just one ethernet port on the system.(I am doing it currently))
Yes, that is no problem.
The one you connect to internet typically use DHCP.
The other set it to static IP address with another subnet than the first one.
The FPGA also use static IP address.
So lets say I have a laptop which connects through a Wireless Access Point which is then connected to a router.
I'm trying to figure out if this happens as a result of an ARP response using the MAC address or, if the laptop uses the IP address to find the router. I know most models have switches built into them so lets negate that for this.
Does that mean that the laptop explicitly uses the IP address to find the router and will only use the MAC address if it needs to traverse through a switch somewhere else in the topology?
Thanks in advance. This is quite a difficult topic to find information on.
First lets rewrite your question to:
Question 1: How does a wireless lan (WiFi) connection differ from a wired connection?
Question 2: Does a WiFi connection transmit data directly to the router's IP, or does it uses the MAC address?
Question 3: Does a Laptop forward PDU's into the router through the wireless access point? does it than use the IP or MAC?
Assumption, PDU refers to Protocol Data Unit
Awnser question 1:
To understand how WIFI works, we first need to understand how a Wired network works. For this we use the OSI model.
The PDU for each of the 7 layers in the model is different and dependent on what that layer represent.
Layer 1 (Physical) is all about electrical signals, Frequencies, voltages, amplitudes and the likes. it defines how we transmit the data down a wire (or through the ether), in this layer there is no network. All communication is from node to node
(so like
"switch <=> switch"
"switch <=> Accesspoint"
"Accesspoint <=> Laptop"
Etcetera
)
This layer does not (normally) have any security or encryption.
Layer 2 (Data Link) is the layer were we start to get a network.
In this layer we start to see structures in the data (the PDU's are called frames) and we get addresses (MAC) Data can now only travel within this physical network (also known as subnet). Encryption is possible but not often implemented outside of the Enterprise networks.
Layer 3 (Network) is where we start to really get interesting. We have all the parts now to build networks and networks of networks (internet).
This layer's PDU is called a packet and its address is an IP address.
From this point on we can make connections that span over multiple hops though different networks with the so called routing scheme's.
Now to WiFi has the following changes to this standard model:
Layer 1: this is wireless (through the ether) so we get channels, bands, frequency and interference. It means that besides how to encode the bits we also have to dial a transceiver. to facilitate this there is a mechanism that uses names for humans to identify networks (SSID).
also because normally we do not have encryption anyone could just see all your data , WiFi adds an encryption scheme to this layer to ensure only authorized devices can communicate on it. (WPA for example)
Answer question 2:
WiFI is on layer 1, so it does not connected to anything but what is directly connected to itself (ergo WiFi is only on the ether), the router is on a different connection. We need at least layer 2 to communicate with it (using MAC addresses) or if we want to send data to other networks we need at least layer 3 and an IP address.
Answer question 3:
Well, for data to be transmitted to other networks (a router connects at least 2 networks) we need layer 3 and an IP address. so the only way your laptop can transmit data like this we use IP addresses.
Footnote:
To learn more about all this you could capture the data transmitted in your own network (DO not capture data on other people there network this is often illegal consult your local law proffesional!). To capture this data Wireshark is a great tool. you can see all this in action in it.
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
I have been working on a local LAN service which uses a multicast port to coordinate several machines. Each machine listens on the multicast port for instructions, and when a certain instruction is received, will send messages directly to other machines.
In other words the multicast port is used to coordinate peer-to-peer UDP messaging.
In practice this works quite well but there is a lingering issue related to correctly setting up these peer-to-peer transmissions. Basically, each machine needs to announce on the multicast port its own IP address, so that other machines know where to send messages when they wish to start a P2P transmission.
I realize that in general the idea of identifying the local IP is not necessarily sensible, but I don't see any other way-- the local receiving IP must be announced one way or another. At least I am not working on the internet, so in general I won't need to worry about NATs, just need to identify the local LAN IP. (No more than 1 hop for the multicast packets is allowed.)
I wanted to, if possible, determine the IP passively, i.e., without sending any messages.
I have been using code that calls getifaddrs(), which returns a linked list of NICs on the machine, and I scan this list for non-zero IP addresses and choose the first one.
In general this has worked okay, but we have had issues where for example a machine with both a wired and wifi connection are active, it will identify the wrong one, and the only work-around we found was to turn off the wifi.
Now, I imagine that a more reliable solution would be to send a message to the multicast telling other machines to report back with the source address of the message; that might allow to identify which IP is actually visible to the other machines on the net. Alternatively maybe even just looking at the multicast loopback message would work.
What do you think, are there any passive solutions to identify which address to use? If not, what's the best active solution?
I'm using POSIX socket API from C. Must work on Linux, OS X, Windows. (For Windows I have been using GetAdapterAddresses().)
Your question about how to get the address so you can advertise it right is looking at it from the wrong side. It's a losing proposition to try to guess what your address is. Better for the other side to detect it itself.
When a listening machine receives a message, it is probably doing do using recvfrom(2). The fifth argument is a buffer into which the kernel will store the address of the peer, if the underlying protocol offers it. Since you are using IP/UDP, the buffer should get filled in with a sockaddr_in showing the IP address of the sender.
I'd use the address on the interface I use to send the announcement multicast message -- on the wired interface announce the wired address and on the wireless interface announce the wireless address.
When all the receivers live on the wired side, they will never see the message on the wireless network.
When there is a bridge between the wired and the wireless network, add a second step in discovery for round-trip time estimation, and include a unique host ID in the announcement packet, so multiple routes to the same host can be detected and the best one chosen.
Also, it may be a good idea to add a configuration option to limit the service to certain interfaces.