I know the RARP protocol is used for mapping physical address to logical address and its some practical applications. Now I have studied RARP(reverse ARP) protocol but cannot find its practical applications. Can anyone give some scenerios and practical applications of RARP protocol.
RARP is now an obsolete protocol that was used to allow a host to determine it's IP address based on the host's MAC address. The protocol was rendered obsolete by more modern techniques and protocols such as BOOTP and DHCP (Dynamic Host Configuration Protocol).
It's unfortunate that RARP is obsolete, because it's extremely handy in determining an unknown IP address of a device. If someone sets a static IP on a device, then years later it is forgotten, moved to a different network, found sitting on a shelf and someone wants to use it, you could RARP the MAC address printed on the device to retrieve its IP.
Related
When I hear/read about internet address, it is always IPv4 address or its successor IPv6 address? But as far as I know, these are not built into the internet itself. Instead, these addresses are defined and used by the IP protocol. In that case, why isn't there an alternative protocol?
If it is there, does that use a different internet address? I never heard any addresses like this!! My device's IP address is decided by my ISP. Instead if I'm using some other protocol, address for that also will be provided by my ISP?
Also, does MAC address have alternatives? For this, I think the answer is 'no'. Because, MAC address is built into the device while manufacturing. So, I want to use a different protocol, which uses a different kind of address, then entire device has to be changed! Is this correct? If not, what are the other hardware addresses like MAC?
Is it possible to have a communication network without IP? Sure.
But the internet, by definition, is a network of networks that use TCP/IP to communicate. IP is the gule that makes it possible to the point that you could argue that the IPv4 internet is a separate network than the IPv6 one.
I have a Client issuing a request to server S. Assume UDP/TCP request. HOP1 is a load balancer switch and assume it has detected that path HOP4->HOP5 is better to route the packet to ServerS. My Question is , After HOP1 has received the pkt generated by client, how can it force the packet to take the best path as calculated to reach S i.e. via HOP4 only.
CL -------HOP1---------HOP2-------HOP3--------ServerS
| |
|-----------HOP4-----HOP5-----------|
I was thinking, that HOP1 should set the field SA,DA, MAC-SA, MAC-DA fields of the pkt as follows :
SA : HOP1
DA : ServerS
SMAC - HOP1MAC
DMAC - HOP4MAC
Would that work ? Is there any better approach ?
My Other doubt is that, for Server S, HOP4 would appear as CLient since it forwarded the client request impersonating as client to Server S. So, HOP4 would receive the reply from Server S. How HOP4 can determine that the reply it has received is actually for the CLient CL and not for itself ? Does NAT comes into picture ? Can somebody shed some light ?
IP has a source routing option, but no network engineer worth his pay configures routers to allow source routing. Network routing needs to be deterministic, and the routing protocols will determine which direction packets should go. Allowing an end-device or application to do that breaks this.
MAC addresses are layer-2 addresses, and the layer-2 frames are stripped off the layer-3 packets and discarded at each hop. A new layer-2 frame is created for each hop in the path, and it is stripped off and discarded at the net hop. MAC addresses are only local to a LAN, and they do not survive across a router hop. Using a destination MAC address that is not local to the source LAN will guarantee failure. In fact, not all layer-2 protocols use MAC addresses, and you have no way to know if any of the links between the hops do are don't use MAC addresses. Of the layer-2 protocols that do use MAC addresses, some use 48-bit MAC addresses, and some use 64-bit MAC addresses.
There really is no way an application or host can guarantee the path that packets will take. That is a job for the routers.
I think after gaining some more wisdom in the field of networking, I got the answer to this Question.
Source packet routing (SPRING) is the new buzz in networking to achieve it.
Other techniques is Tunneling - Ip in IP encapsulation, GRE tunnels etc.
May I listen to any ip address from a java application?
Please note that I do not mean to say any existing local address.
I'm talking about any ip address.
I have a network interface receiving traffic mirrored from a certain link, and the destination IP address will vary "randomly", but I want to be able to get those packets to be sent to my java application.
Thanks.
-Bob
With the library jpcap you can sniffing all packages incoming and outgoing from a network interface.
http://jpcap.sourceforge.net/
Or perhaps you need Java Sockets.
https://docs.oracle.com/javase/tutorial/networking/sockets/
This is a pretty open ended question, can you be a little more specific?
The answer is yes, you can listen to any IP address that the network stack of your hosting OS can see (even if it's not for the network card in the system but modern switching will limit how useful that is, see promiscuous network).
Try using 0.0.0.0 as the expected address in your configuration but it seems like there is something missing on your question.
I have a server and a few clients, software-wise, and I want the client to figure out the IP address of the server without actually referring to a specific database.
I had a misconception about UDP up until now that UDP only used the Port as a common identifier between servers and clients, but I was wrong apparently.
Requirement:
I want my server to broadcast a message to ALL devices on the network, once every 5 seconds or so.
That message will contain the IP of the server.
Software using such technique already:
A photo transfering app for iOS, called "Photo Transfer App" is really easy to use because it basically tells you to open the app on your Mac and on your iPhone, and then you press "Discover", and BAM! your devices have found each other.
But how?
How can my requirement be achieved?
EDIT
I googled a bit. Could server host on 255.255.255.255and clients connect to that address solve my problem?
According to this Wikipedia article, 255.255.255.255 is used for broadcasting.
Can someone confirm?
If you will use broadcast address (255.255.255.255) or network broadcast (like 192.168.1.255 for network 192.168.1.xxx or in the prefix notation 192.168.1.0/24). You will get essential limitation: your broadcast will NEVER leave that network. So all host inside the LAN will see your broadcast message but nobody else.
Multicast as mentioned by null is better because it can leave your network and pass through the IP routers. But this is feasible only by special network settings on that routers (and require multicast routing capability on that routers).
Another technology without such limitation can be use is dynamic DNS (server will register itself via DNS).
Multicast would be better than broadcast. See also: Bonjour, multicast DNS & SSDP.
More information on Bonjour is available here.
I'm trying to develop an applicaton for p2p communication between two android devices. In order to punch a hole through my NAT(s), I'd need to know my external ip address and port.
To that end, I've developed a java server on GAE to report my "remote" ip address and port. The problem is that on GAE I can get my ip address, but not my port. Without it, I'm unable to successfully punch the hole.
So, my question is what's the best, free method to find out my external IP address and port?
That's a question that has no answer with TCP.
Here's the problem: your "port" is not a fixed value. You don't have "an" external port. You typically get one dynamically assigned for each outbound connection.
As answers you should see from the test sites posted in another answer clearly indicate, it's a moving target (though it may stay stationary for a short time due to the browser using HTTP/1.1 keepalives and actually reusing the same connection, not just the same port)... but if you hit the site repeatedly, you'll see it either drift around randomly, or increment. Trying it from two different web browsers on the same machine, you'd never see the same port number -- the port corresponds to the specific source connection, not the machine sourcing the connection.
Sometimes, you may find that it's the same port number as the port your machine's stack opened for the outbound connection, but even when it is, it doesn't matter, because no traffic should be able to return to your machine on that port unless it is from the IP address and port of the machine to which you made the outbound connection. Any decent network address translating device would never accept traffic from another source IP address and/or port, other than the one you addressed in the outbound connection.
There is no standard, simple, predictable, reliable, or consistent way to punch a hole in TCP NAT and then exploit that hole for a peer-to-per connection. To the extent that such things are possible in a given NAT implementation, that is an implementation that is shoddy, broken, defective, and insecure.
See also: https://www.rfc-editor.org/rfc/rfc5128
Sounds like your app could use a STUN server to get its external address.