I was quite surprised when I found out that there was a really big range of IP addresses allocated for loopback (127.x.y.z).
I didn't find much information about why it's like this, except that it could be used for testing networks and protocols locally, which got me thinking if it could be a good idea to use these addresses for IPC.
At the moment, as far as I know, IPC based on networking is usually done with TCP/UDP by opening sockets on ports which are most likely not used by any other service.
So my question is, to be even more sure that there won't be a port collision, could other loopback addresses be used instead?
For a more concrete example, could two processes communicate through sockets on address 127.31.41.59 and ports 27 and 18 (or even different loopback addresses)?
Related
Different websites uses different ports, like Codecademy uses localhost:8000 in its AngularJS and Ruby On Rails tutorials. So, I want to know what is the use of this 8000 in localhost:8000. Thanks in advance :-)
This is not specific to one framework, it's a much lower level. From Wikipedia:
In computer networking, a port is a software construct serving as a communications endpoint in a computer's host operating system. A port is always associated with an IP address of a host and the protocol type of the communication. It completes the destination or origination address of a communications session. A port is identified for each address and protocol by a 16-bit number, commonly known as the port number.
Specific, well-known port numbers are often used to identify specific applications and services. Of the thousands of enumerated ports, 1024 well-known port numbers are reserved by convention to identify specific service types on a host. The protocols that primarily use ports are the Transport Layer protocols, such as the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) of the Internet Protocol Suite.
In the client-server model of application architecture, ports are used to provide a multiplexing service on each port number that network clients connect to for service initiation, after which communication is reestablished on another connection-specific port number.
I assume, there's a task runner like grunt or gulp serving the page via BrowserSync (or similar). They use a different port than 80 to not interfere with an already occupied port by a local web server (apache, nginx,...).
This is just a port which rails is listening to. It depends on how you configure your rails server, and, IMHO does not mean anything useful. Sometimes you have to assign service to a different port because default port is occupied by some other service. Sometimes it is done by security reasons, so the hacker from outside world has to know the port you are using. But it's actually not very hard to know
Just to add to what the others have said: all network communications require an ip address (which can be got from a domain name like www.google.com) and a port number. However, if a port number is not supplied then the http server uses the default: this is usually port 80. So, if you were to go to "localhost" without a port, you are effectively saying "localhost:80". Your computer probably doesn't know what to do with this. If you say "localhost:8000", and there's a rails server there, then it will handle the request.
In my recent app I managed to send data (mostly audio) via UDP in my local network (WiFi) to other iPhone. And now I need to do this same but in WAN. Can You guys please point me in the right direction where to start? What I need to achieve this?
I'm using GCDAsyncSocket to manage sockets. I believe that I have to got server, where I can keep IP addresses of both devices.
Also, how can I connect to device behind NAT/Firewall? I'm guessing, that I need to have public IP address (scrapped for instance from http://checkip.dyndns.com/). And then do I need to traceroute? Or NSLookup? Or piggyback? Or do I need to use UDP hole punching?
I know it's a lot of question, but if you can just point me to the right technology, I would be very grateful.
To achieve a communication between two participants behind a NAT you could use Hole-Punching like you mentioned it. This is explained quite well here: http://en.wikipedia.org/wiki/UDP_hole_punching#Flow
Basically a Server with a Public IP and Port is used to share the Port-numbers of the iPhones.
But a NAT may use a different Port for every different IP the iPhone talks to. So if iPhone1 sends data to the server the NAT uses port X, but if iPhone1 wants to send data to a different IP the NAT may choose port Y. (See http://en.wikipedia.org/wiki/Network_address_translation#Symmetric_NAT)
To overcome this problem there is a protocol called UPnP and the lesser known NAT Port Mapping Protocol.
I am not well versed in UPnP but maybe someone else can provide some information on that.
The protocol NAT-PMP enables you to dynamically request an external port to be forwarded to your device. See http://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol, RFC 6886 .
This allows you to "predict" your external port and establish connections over NAT.
There is a lot of other answers related to this issue, however I believe this is specific.
I am using Delphi XE2 and Indy 10.5.8 and TIdUDPServer
In my local development network I have everything on the same network ip subrange and all connected to the very same Access Point (LinkSys)
I have Androids sendind UDP Broadcast to 255.255.255.255 to request the server ip address that is written in Delphi listening using TIdUDPServer on the port 44444.
The requests get there fine and I can answer back no problem. Works exactly as expected.
However I have noted that in some networks it does not work! It is always simple networks based on an access point, I am not sure but seems that where the problem happens the server PC is connect to the LAN port while the devices are using the wifi, all in the same access point.
Could be the case that the access points do not broadcast the UDP packet by the both LAN and wifi? I know that this kind of broadcast is very limited, but I have not found any information that tell me that in the same access point there is limitations like that.
Is there are ways to test, or workaround?
This solution needs to be strong enough to deal with the many AP out there.
EDIT: For those that want to get the source code for retrieving more information from the network including the broadcast ip as mentioned on the answer below follow this solution, it is all there.
http://www.code10.info/index.php?option=com_content&view=article&id=54:articleretrieve-network-adapter-information&catid=47:cat_coding_algorithms_network&Itemid=78
255.255.255.255 is not the best option for sending UDP broadcasts, and some routers/firewalls do block it unless configured otherwise. The better option is to use the NIC's actual subnet broadcast IP instead. For example, if a UDP socket is bound to local IP 192.168.0.1 with a subnet mask of 255.255.255.0, then the broadcast IP for that subnet is 192.168.0.255.
Most platforms have OS-specific APIs for retrieving a NIC's actual broadcast IP, such as getifaddrs() on POSIX systems, or at least for retrieving the NIC's subnet mask, such as GetAdaptersInfo() and GetAdaptersAddresses() on Windows, so you can calculate the broadcast IP manually.
Retrieving the local broadcast IP(s) may be added to Indy in a future version.
I would like to do a scan in a LAN network to find devices linked.
I'm developping an app in IOS for IPAD
How do I do???
Because those are mobile devices I will assume you want to find devices on a wireless network. Theoretically, since wifi uses shared medium for communication, you can passively listen for traffic flowing through the network and collect data about client without sending any packets. This is something that is commonly referred to as a promiscuous mode. In practice there is 99% chance that the network adapter driver will allow you only to get traffic destined for your MAC address. In that case you will need to resort to actively scanning the network subnet which is not 100% accurate and depending on how the network is implemented can be considered as a possible attack.
The simple way of scanning is sending ICMP requests (ping) to every IP address in the subnet and collecting data from those who send back the echo reply. This is not reliable because some hosts won't respond to ICMP echo request even if they are active. First thing you need is to find out your own IP address and the subnet mask, and calculate the range of possible addresses in your subnet. The range is obtained by using logical AND operator where operands are binary values of your IP address and subnet mask. This is an example from the program that calculates this for typical 192.168.1.1 subnet with 255.255.255.0 subnet mask (192.168.1.1/24 in CIDR notation):
Address: 192.168.1.1 11000000.10101000.00000001 .00000001
Netmask: 255.255.255.0 = 24 11111111.11111111.11111111 .00000000
Wildcard: 0.0.0.255 00000000.00000000.00000000 .11111111
Network: 192.168.1.0/24 11000000.10101000.00000001 .00000000
Broadcast: 192.168.1.255 11000000.10101000.00000001 .11111111
HostMin: 192.168.1.1 11000000.10101000.00000001 .00000001
HostMax: 192.168.1.254 11000000.10101000.00000001 .11111110
Then you would iterate through the range and ping every address. Another thing you can consider is listening for broadcast traffic such as ARP and collecting some of the information that way. I don't know what are you trying to make but you can't get many useful information this way, except for vendor of a host's network adapter.
Check my LAN Scan on Github. It does exactly what you want.
I recently used MMLANScan that was pretty good. It discovers IP, Hostname and MAC Address.
Bonjour have been around since 2002, have a look at it!
I mean, just look at their current tagline:
Bonjour, also known as zero-configuration networking, enables automatic discovery of devices and services on a local network using industry standard IP protocols. Bonjour makes it easy to discover, publish, and resolve network services with a sophisticated, yet easy-to-use, programming interface that is accessible from Cocoa, Ruby, Python, and other languages.
Here is a wireshark capture of an ARP request PNG image, I contains the sender MAC inside the ARP packet. The receiving station can derive the MAC from the Ethernet frame. It seems to be redundant. Is there any particular use of separately including the sender MAC address in ARP Request too ?.
The "redundancy" was by design (RFC 826), and can be useful in targeting different layers. In RFC 3927 there's what is known as Gratuitous Address Resolution Protocol (GARP), and in certain circumstances the redundancy, or lack of, plays an important role, especially in troubleshooting and monitoring networking stacks.
Actually it's not rendunancy at all, the MAC (physical, layer 2) and IP (logical, layer 3) addresses are not the same thing. They serve different purposes on different network layers.
On large scale networks it's quite common to observe changes in the MAC/ARP/Source/Dest information, and at times can seem almost incorrect. For example, you might see a host send an ARP request with its own address as the target address. Depending on the exact situation, it might be telling us it's a link up/down event, maybe it's trying update other devices ARP tables, or possibly detecting an ip conflict and moving the ip to another NIC.
I could get into clustering, failovers — the list goes on, although I would end up writing a book trying to explain it all. Hopefully this gives you a bit of insight about the "redundancy" you were questioning. ;-)
More Info:
RFC 826 /
RFC 3927
/ Wireshark Gratuitous ARP
Although often used in conjunction with Ethernet, ARP by itself is an independent protocol. Imagine other link layer protocols that do not expose MAC addresses. ARP would not work in such circumstances if the sender field was not provided.
There is no rule that the ARP protocol field sender mac address to be same as ethernet source mac address. Eg: Its possible in few applications where multiple interfaces of same host are on network, but one only interface sends arp responses for all interfaces.